Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: lcl00 on January 22, 2016, 05:47:19 PM
-
Hi guys
I'm probably wrong, but I think my upload speed might be a little low when compared to my download speed. After some tweaking my download speed is currently hovering between about 51 and 54mbps... but my upload is always a solid 7/8mbps (depending on G.INP which has started to go off and on again).
Is it normal to have lines that have downloads as high as that with uploads as low as that? I always assumed that they balanced to some extent.
One thing to add. My line characteristics are a bit odd. My line length for the above speeds is somewhere around 1.3km which would never give speed reading anywhere near that in normal circumstances!
I'm lcl00 on MDWS btw. :)
-
TaKe a look at my speeds MDWS, my upload has dropped from 12 to 6 and crept back to around 8, my download has risen to around 48, although it was very briefly better, oh and although some won't believe me my line is only 450 meters.
Also if you look on MDWS you'll see others have high downloads but low uploads or vice versa, all lines are different.
-
I can't see MDWS on this device, so I'm working on memory from looking earlier...
Yes, that speed looks imbalanced. Some might be explainable...
Your hlog graph looks fine. Your SNR shows very low signal in U2, resulting in no bits ... leading to a low upstream sync.
Meanwhile, downstream bit-loading shows only a very small "hole" in the ADSL frequencies (altogether, I reckon you are 600m from the cab, which itself is 5km from the exchange). The small power reduction in the ADSL frequencies, because the cab is far from the exchange, means you are getting relatively high bit-loading - perhaps as much as 6-8Mbps more than those whose cabs are 2km from the exchange.
So, I think some of the difference can be explained, if not all.
I didn't check the QLN graph to see what that says, so I'll come back to that.
As for the line characteristics, it'd be better to see the command- line output, rather than MDWS graphs.
-
Some recalculations, now I can see MDWS directly...
The distances are, I reckon, nearer 750m to the cabinet (assuming 0.5mm copper), with the cab 4km from the exchange.
The "gap" in bit-loading (in the bits/tone) is slightly larger than I originally remembered, but it is still perhaps a third of the size of mine. I reckon that still gives you a 5-6Mbps advantage over lines with cabs about 2km away.
If we compare you with other lines in the 48Mbps region, as seen on MDWS:
- You appear to be have almost identical physical properties (the line attenuation values) to "Kamix2" and "digginsa"
- You appear to have very similar patterns of bit-loading to these two lines
- But you're a little different to "Ronski", whose line appears to have lower attenuation. That line gets better performance out of U2 and D3 than yours, but comparatively worse performance in U1 (fewer bit/tone) and D1 (a bigger hole caused by the ADSL power masks).
One thing to add. My line characteristics are a bit odd. My line length for the above speeds is somewhere around 1.3km which would never give speed reading anywhere near that in normal circumstances!
I still can't figure this last sentence out. Are you saying that your line is actually 1.3km? Or that the line characteristics suggest it is 1.3km? Or that the speeds suggest it is 1.3km?
The attenuation tells you what a line is behaving like electrically, and is often converted into a distance for convenience - using the scale factor for 0.5mm copper. However, just remember that the attenuation actually depends on the material (copper vs aluminium), the length, and the gauge or diameter ... and the gauge has a significant impact.
This BT-Cables page (http://www.btcables.com/products/voice/outside-plant-secondary-cable) shows CW1128-spec copper cables of 4 different gauges: 0.5mm, 0.6mm, 0.63mm and 0.9mm, while the PDF includes 0.4mm too (which I think is used on my line).
The resistance plays a significant role in the attenuation - and the following lines would all have the same resistance:
- 480m of 0.4mm copper
- 750m of 0.5mm copper
- 1.1km of 0.6mm copper
- 1.2km of 0.63mm copper
- 2.4km of 0.9mm copper
All five lines would behave in a similar manner.
In general, duct space becomes the critical factor nearer the exchange, and thin copper can be used to save space. Out in the country, keeping within the maximum resistance becomes the critical factor for long lines, and fat copper has been used in the past to offset the extended distance - so that the line stayed within the limits needed for a voice service. Over the whole length of a line between premises and exchange, the gauge can change.
-
Sorry, I reread that and realized it wasn't clear. The line is 1.3km from the cabinet. I am pretty rural though, so I am almost certain there's 0.9mm copper used for some of that. The 500m up the road to my house is 0.6mm, I did ask when it was being installed.
Is this what you're requesting?
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 7026 Kbps, Downstream rate = 54734 Kbps
Bearer: 0, Upstream rate = 7010 Kbps, Downstream rate = 53975 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 6.0
Attn(dB): 0.0 0.0
Pwr(dBm): 13.1 -7.4
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 207
M: 1 1
T: 0 41
R: 10 4
S: 0.1440 0.9422
L: 14116 1800
D: 8 1
I: 254 106
N: 254 212
Q: 8 0
V: 0 0
RxQueue: 42 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 1192819
OHFErr: 0 48
RS: 2175729760 3059256
RSCorr: 386381 68
RSUnCorr: 0 0
Bearer 1
OHF: 4893758 0
OHFErr: 0 0
RS: 39149572 0
RSCorr: 31 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 1120998 368677
rtx_c: 46931 2758114
rtx_uc: 31956 2282
G.INP Counters
LEFTRS: 625 117394
minEFTR: 53987 7963
errFreeBits: 3605968203 1439245690
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3864021130 0
Data Cells: 279368393 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 15 55
SES: 11 0
UAS: 108 108
AS: 78628
Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 9.69
OR: 0.01 26.40
AgR: 54029.95 7036.66
Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01
Bitswap: 50748/50749 3211/3213
Total time = 1 days 1 hours 35 min 58 sec
FEC: 7887220 236575
CRC: 571 56
ES: 15 55
SES: 11 0
UAS: 108 108
LOS: 1 0
LOF: 8 0
LOM: 0 0
Latest 15 minutes time = 5 min 58 sec
FEC: 4183 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 1827 0
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 35 min 58 sec
FEC: 11215 7
CRC: 0 6
ES: 0 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 386374 77
CRC: 0 45
ES: 0 44
SES: 0 0
UAS: 60 60
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 21 hours 50 min 27 sec
FEC: 386381 68
CRC: 0 48
ES: 0 47
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
adsl info --pbParams
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 7014 Kbps, Downstream rate = 54777 Kbps
Bearer: 0, Upstream rate = 7010 Kbps, Downstream rate = 53975 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205)
DS: (33,859) (1216,1961) (2793,3245)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 7014 kbps 54777 kbps
Actual Aggregate Tx Power: - 7.4 dBm 13.1 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 5.9 34.9 N/A N/A N/A 16.6 44.0 70.3
Signal Attenuation(dB): 5.9 34.1 N/A N/A N/A 22.1 43.6 71.6
SNR Margin(dB): 6.0 6.1 N/A N/A N/A 6.3 6.3 6.3
TX Power(dBm): -18.1 -7.8 N/A N/A N/A 11.0 7.8 2.8
-
For comaprison purposes I'm about 1.7km from the exchange in an urban area, and they estate was built early to mid seventies, no idea what the cable is as BS was unable to obtain that information.
-
@ronski
Is your line made of thin copper, or does it have aluminium in it?
@lcl00
Those are the right stats.
I originally asked because the MDWS graph for attenuation just had zero. I found the line attenuation values instead, so you already have my guess that the line is working the same as a 750m one of "standard" copper.
-
Unfortunately WWWombat I have no idea (BS couldn't access that data), but given the poor speed for the distance I would think there's got to be some aluminium in there. Some houses close by but slightly further from the cab have speed estimates of 70Mbps whilst the others are around 50.
-
Just dragging this one back up. Turns out that my poor upload speed was due to a fault! The port in the cabinet was changed and I'm now getting 50730 down and 10339 up which is a bit more like what I'd have guessed it should be. However, I have no G.INP on the downstream, so that figure is likely to go back up a little bit once that is reapplied.
Anyone got any idea how long it takes G.INP to come back onto lines now? My downstream ES are woeful!
-
Anyone got any idea how long it takes G.INP to come back onto lines now? My downstream ES are woeful!
As I can't check your circuit's data on MDWS at the moment, I'll just say "sometime this week" (based upon your last sentence).
-
At least it's a bit more prompt than last time (took a few months).
Am I at risk of it going interleaved for a time first, or will it just jump straight to G.INP now?
I'm not sure why MDWS isn't reporting... will look into it now. :)
-
I'm not sure why MDWS isn't reporting...
It may well be all present and correct. Due to what I am currently doing, I am unable to view your circuit's statistics . . . so there should be no problem on your part! :)
-
The 'Upload data to MyDSLWebStats' box was not ticked... whoops!
Reporting now. :)
Am I right in saying that after a DLM reset my line remains on an open profile for 48 hours? I was going to mess around with different equipment to see what's currently working best!
-
Am I right in saying that after a DLM reset my line remains on an open profile for 48 hours?
It will definitely be on a "wide open" profile for 24 hours; it might even be 48 hours but I'm not certain.
I was going to mess around with different equipment to see what's currently working best!
Now would be a good time to test. Just ensure that you do not cause a number of resynchronisation events in quick succession.
-
TaKe a look at my speeds MDWS, my upload has dropped from 12 to 6 and crept back to around 8, my download has risen to around 48, although it was very briefly better, oh and although some won't believe me my line is only 450 meters.
Also if you look on MDWS you'll see others have high downloads but low uploads or vice versa, all lines are different.
not about believing you, but for sure yours is by far the worst 450m line stats I have seen anywhere, even fully ali lines with mega crosstalk perform better.
Your sync speed is about 30% down on worst case trial results for crosstalk.
My line not much shorter than you, when my sync speed dipped below 50 (and I still had a 20 max sync upload) BT didnt even try to argue, they swapped the pair as I think even openreach knew it was way below par at that point. (Also last 50m of my line is ali)
-
@Chrysalis, there's something a bit weird on our estate, houses next door to me and nearby get roughly the same estimates, but a small cul-de-sac slightly further away from the cab has half the houses showing 70Mbps estimates when I last checked. BS has checked my line route and confirmed it as 450 meters but couldn't access the records for what it's made up of. Whilst the speeds are not fabulous it does us perfectly well, so I gave up chasing for improvements.
-
yeah its odd for sure, either you got a fault somewhere or the official records are wrong (not impossible).
But end of the day what counts is if you happy with it, and you are so its fine I guess.
-
And... now it's broke again. A BT engineer decided to pay a visit to fix another line connected to my DP and decided to disconnect and reconnect my line countless times - great. Now DLM has kicked in and I'm pretty certain the line is banded (before interleaving kicked in it was at 49997). Any idea how long it takes for the banding to be lifted? I know interleaving just does it as and when it fancies!
-
My banding stayed for over a year. Was initially caused by my dodgy dsl-ac68u, but persisted even when I switched to an HG612
I only finally lost it when I switched providers and got a DLM reset. Gained me about 6 mbit on my downstream
-
for whatever reason banding seems to stick around a lot longer than interleaving on green lines.
-
Will moving to a new ISP give me a DLM reset when it switches? My current ISP (Zen) say that they'll have to send out an engineer to do that.
-
Will moving to a new ISP give me a DLM reset when it switches? My current ISP (Zen) say that they'll have to send out an engineer to do that.
Yes, the two ways to get DLM reset are:
a) Have an Openreach engineer visit and then request one; or
b) migrate ISP
-
moving between standard, speed and stable will also do a reset but no isp's seem to be willing to do that.
-
Is there possibly a cost associated with changing those types of profiles?
-
It used to be a charge yes, and might well still be.
Its actually the reason why changing isp sometimes causes a DLM reset. As not all isp's use the same profile.
-
Regrading between different upstream speeds also seems to cause a DLM reset. At least it did in 2011, going from 40/2 to 40/10.
-
yep so consider this, is e.g. 9 profiles (soon to be 12)
speed,standard,stable 40/2
speed,standard,stable 40/10
speed,standard,stable 80/20
(soon) speed,standard,stable 55/10
If an isp migration doesnt change the profile, there is no DLM reset, if it moves then there is a DLM reset.
So moving from speed 80/20 to speed 40/10 as wombat says will do a DLM reset.
Like wise going speed 80/20 to standard 80/20 will do a DLM reset.
However if both isps use 80/20 speed, then there is no reset as the underlying profile/product isnt been changed. (note this one may not apply if going between different GEA providers as a cease and reprovide is carried out which will possibly always do a DLM reset).