Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: crystal_ship on August 05, 2012, 08:10:18 PM
-
Hello!
A kind person on the BT forum suggested that someone might be able to kindly interpret some graphs which I have posted on the following link;
http://community.bt.com/t5/BT-Infinity/Speed-suboptimal/td-p/584678
I would be grateful if someone could kindly look at the graphs.
The first graph was when the line was showing better stats, and the second was taken today.
BT predicted 55.2 mb download speed yet I am only getting 36 mb. Something is definitely amiss here!
All input very much appreciated. Thank you.
-
Hello CS, welcome to the Kitz forum. :)
I have read through your thread on the BT forum and I can confidently say that from the symptoms your have reported you most likely have a defective joint (possibly HR) in the D-side pair. I cannot be 100% certain, without connecting test equipment to your line . . .
As for interpreting your graphs, we normally leave that to Bald_Eagle1 (the maestro and developer of the scripts you are using to obtain the graphs) but as he is currently on holiday, perhaps I could ask Asbokid to comment?
-
Hi burakkucat!
Thank you for the swift reply!
It seems rather hard to convince BT that there is a problem :-(
The copper technician arrived after the crackling stopped (and the line stats went back to how they are now) - he plugged in his test kit, did a quiet line test, and said that there was no issue. He refused to check and recrimp the joints as he said there were too many.
I look forward to the interpretation of the graphs, it will help to make more sense of things!
-
Would it be possible to post clearer copies of the graphs here? The ones on the BT forum are a bit unclear.
-
Would it be possible to post clearer copies of the graphs here? The ones on the BT forum are a bit unclear.
Hello Eric!
The images were squeezed into the available space. I'm not sure which web browser you use, but you should be able to right-click on each image and select 'view image'
This should bring it up full sized!
I hope that works!
Looking forward to your thoughts.
-
The copper technician arrived after the crackling stopped (and the line stats went back to how they are now) - he plugged in his test kit, did a quiet line test, and said that there was no issue. He refused to check and recrimp the joints as he said there were too many.
Oh dear, that is unfortunate. :( Perhaps he was having "one of those days" and was also being subjected to undue micromanagement pressures.
Do you have the means to record the audible state of the line? If so, then whenever you notice the line "go noisy", start recording and perform a QLT (quiet line test), call 170702. Ideally you should also try to make a fault call to BT India whilst it is still audible and, as soon as the call is answered, ask the call-centre operative "Can you hear that noise?"
-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww1.picturepush.com%2Fphoto%2Fa%2F8906619%2F480%2Fcrystal_ship%2Fcrystal-ship.gif&hash=03a0155f6b34622619638c568f43a38e4f12ad12) (http://picturepush.com/public/8906619)
-
Hi CS,
You might try inducing the fault with a 17070 option 1 ring back test or two.
Kind regards,
Walter
-
The copper technician arrived after the crackling stopped (and the line stats went back to how they are now) - he plugged in his test kit, did a quiet line test, and said that there was no issue. He refused to check and recrimp the joints as he said there were too many.
Oh dear, that is unfortunate. :( Perhaps he was having "one of those days" and was also being subjected to undue micromanagement pressures.
Do you have the means to record the audible state of the line? If so, then whenever you notice the line "go noisy", start recording and perform a QLT (quiet line test), call 170702. Ideally you should also try to make a fault call to BT India whilst it is still audible and, as soon as the call is answered, ask the call-centre operative "Can you hear that noise?"
Seems life is getting more difficult for us mere mortals in the wonderful world of working and paying taxes :-(
Funnily enough, I immediately called BT India on 151 and the chap on the other end acknowledged the crackling on the line! Though I didn't say anything until a bit later in the call. He did hear it, that was the main thing!
-
Hi CS,
You might try inducing the fault with a 17070 option 1 ring back test or two.
Kind regards,
Walter
I've tried that a couple of times a day after the crackling stop with no joy :-(
I will try and do that on a daily basis though - good suggestion!
The interesting thing is that the max attainable rate drops by 2mb simply by picking up the phone and listening to the dial tone. Not sure if that is normal!
-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww1.picturepush.com%2Fphoto%2Fa%2F8906619%2F480%2Fcrystal_ship%2Fcrystal-ship.gif&hash=03a0155f6b34622619638c568f43a38e4f12ad12) (http://picturepush.com/public/8906619)
This is brilliant asbokid!
I found it rather difficult to compare images by scrolling up and down, this is really helpful!
-
Thanks for all your input so far, keep it coming. It's very interesting and will help me (and hopefully others) to understand the reasons why these things are happening.
-
EDIT: See Bald_Eagle's correct intepretation below..
Initial observations..
Bit Loading is a consequence rather than a cause, so best to leave it until last.
QLN (quiet line noise) has, overall, actually gone down between 29/07 and 05/08.. so it's not a crosstalk issue.
Hlog (line attenuation) is virtually unchanged between the two dates.
SNR (signal to noise ratio) .. that's the interesting one... SNR across the DSL spectrum has dropped, yet not in response to changes in QLN or Hlog.
It seems that the power output of the transmitter in the DSLAM has been turned down. Lower signal power but with similar levels of background noise, results in lower SNR. So your drop in bandwidth is the result of Dynamic Spectrum Management by Openreach.
This is probably the result of a self-adapting algorithm in the DSLAM controller. The controller monitors port utilisation and load, and adjusts its power outputs to limit crosstalk. Maybe there has been a flurry of subscriptions to FTTC as more people become aware of its availability in your area. The objective to Dynamic Spectrum Management is to give all subscribers the best overall service possible.
Reducing output power not just for you but for other FTTC subscribers served by the same DSLAM has reduced the crosstalk onto your line. Evidenced by the drop in QLN - line noise actually went down.
cheers, a
-
Thank you asbokid!
This is very interesting stuff.
So would I be right to expect that there's nothing I can do about this? It's such a shame to lose so much bandwidth because of what Openreach are doing.
Perhaps there was a blip when the line speed jumped up (whilst the crackling was going on).. a one off incident? Because prior to 29/07/2012, the line was working as it is now.. though I'm certain the line was working better prior to repairs being made to fix a crossed line fault.
Any advice on where I can go from here?
-
EDIT: See Bald_Eagle's correct intepretation below..
Sorry, no advice really. The DSM is not officially documented, and I don't think us humble earthlings have much control over it, even less for those of us on the civilised side of the master socket! Though since spectrum management is dynamic, it will presumably take into account local geography and local conditions.
Maybe your DSLAM is now serving subscribers who are a very long distance from the cabinet. And to guarantee those punters any service at all, maybe the output power to nearer subscribers, like you, had to be cut back, to reduce crosstalk. Only guesswork though.
One thing that's clear - and Paul (Bald Eagle) who wrote the scripts to graph the line stats was the first to notice - the DSM of the Huawei MA5616 which is the MSAN/DSLAM in your street cabinet, is quite different to the DSM algorithm used by the ECI MSAN. So there doesn't seem to be one single algorithm in use. There must be at least two, with each being vendor specific.
We can see that your service was/is capped at 40/10Mbps. Presumably if you plumped for an 80Mbps service, you would gain some bandwidth, theoretically up to 80/20. Whether that upgrade would involve a relaxation of the DSM rules for you, no idea. But maybe an upgrade to 80/20 is worth considering, perhaps with the proviso that you can revert back if there's no worthwhile gain in bandwidth?
-
The interesting thing is that the max attainable rate drops by 2mb simply by picking up the phone and listening to the dial tone. Not sure if that is normal!
:no: No, definitely not normal. That is one of the potential indicators of a developing HR (or semiconducting) joint.
-
sorry, i didn't even notice you had said that about the drop in max attainable rate when lifting the handset. Definitely worth getting to the bottom of that. I don't know anything much about line faults, HR joints, etc.. Though the filters/splitters in the faceplates do sometimes fail. And of course there's another splitter/filter at the other end (on the linecard in the cabinet). That potentially could fail. Doesn't seem very likely though.
cheers, a
-
Thanks for the replies guys!
BT have moved me to the 80/20 profile, which I've been on since 02/08/2012. The only difference is a slightly higher upstream rate.
Prior to investigating any further, BT want me to wait until the 10 day training period is over - a few other folks have commented that the 10 day training period is a myth!
I've conducted a few ring backs on my line to see if it changes anything, but sadly no dice (apart from it temporarily reducing the max attainable line rate)
FYI - All my kit is directly connected to the master socket. No extensions here.
I could disconnect the phone and plug the modem directly into the test socket, as that would presumbly isolate the filter in the master socket?
The plot thickens!
-
Thanks for the replies guys!
BT have moved me to the 80/20 profile, which I've been on since 02/08/2012. The only difference is a slightly higher upstream rate. Prior to investigating any further, BT want me to wait until the 10 day training period is over - a few other folks have commented that the 10 day training period is a myth!
Oh well that's good. Hmm.. So that pretty much says that DSM is determined / fixed independently of service profile.
I don't think even BT knows for sure about the detail of Dynamic Line Management. Huawei/ECI probably won't disclose their DLM algorithms. The DSLAMs run totally closed source firmware. Perhaps BT has some role in its development, but probably not. Flicking through some configuration manuals for the Huawei MA5616, and DLM doesn't even rank a mention. Maybe DLM is known by something else to Huawei?
I've conducted a few ring backs on my line to see if it changes anything, but sadly no dice (apart from it temporarily reducing the max attainable line rate)
FYI - All my kit is directly connected to the master socket. No extensions here.
I could disconnect the phone and plug the modem directly into the test socket, as that would presumably isolate the filter in the master socket? The plot thickens!
Sure, and to eliminate the filtering/splitter in your faceplate as the cause of the drop in max attain. rate, maybe find one of those in-line DSL filters/splitters, and try that in the test socket behind the faceplate. Although labelled usually as "ADSL" filters, they should work fine with VDSL2.
Good luck with it all :)
cheers, a
-
Today's line stats attached for information.
-
This is brilliant asbokid!
I found it rather difficult to compare images by scrolling up and down, this is really helpful!
That is indeed a very useful way to compare "snapshot" graphs.
I do it in a more "manual" manner via Windows 7.
Are you able to post the relevant Plink logs for these graphs?
They will need to be zipped first though, to make them a small enough size for posting in this forum.
Once zipped, each log should end up at around 62 KB in size.
In the meantime, I have attached an updated GRAPH6.BAT that you may wish to try out (store/rename your original version though - just in case you don't like the output).
You can also easily re-graph your existing Plink logs by dragging & dropping them onto the GRAPH6,BAT icon to generate output similar to the attached graphs.
-
Initial observations..
- Bit Loading is a consequence rather than a cause, so best to leave it until last.
- QLN (quiet line noise) has, overall, actually gone down between 29/07 and 05/08.. so it's not a crosstalk issue.
- Hlog (line attenuation) is virtually unchanged between the two dates.
- SNR (signal to noise ratio) .. that's the interesting one... SNR across the DSL spectrum has dropped, yet not in response to changes in QLN or Hlog.
Doesn't the QLN graph from 5th August actually show lower attenuation across all 3 bands i.e. increased noise?
(-140 being "quieter" than -120)
That could possibly explain why SNR has dropped.
-
Evening!
I am generating new graphs as we speak!
I will post up the graphs and plink logs shortly.
-
Here are the graphs from the new script you kindly posted up. Do you need anything to reflect today's state of play? The line dropped earlier :-(
-
Tonight's line stats following the recent line drop. Let me know if you need anything else, thank you for volunteering your spare time to help, it is much appreciated. :-)
-
Initial observations..
- Bit Loading is a consequence rather than a cause, so best to leave it until last.
- QLN (quiet line noise) has, overall, actually gone down between 29/07 and 05/08.. so it's not a crosstalk issue.
- Hlog (line attenuation) is virtually unchanged between the two dates.
- SNR (signal to noise ratio) .. that's the interesting one... SNR across the DSL spectrum has dropped, yet not in response to changes in QLN or Hlog.
Doesn't the QLN graph from 5th August actually show lower attenuation across all 3 bands i.e. increased noise?
(-140 being "quieter" than -120)
That could possibly explain why SNR has dropped.
You lost me. HLog measures attenuation. QLN measures noise.
Hlog (attenuation) is essentially unchanged between 29/07 and 05/08.
There was more line noise measured on the 29/07 than on 05/08.
Yet, counter-intuitively, with attenuation unchanged and less noise, SNR nevertheless was reduced across the xDSL spectrum.
If we study the drop in SNR between 29/07 and 05/08 it indicates a managed cut-back in transmitter power at the DSLAM. A different PSD mask applied by Openreach, perhaps?
EDIT: see Baldy_Bird's correct understanding below..
cheers, a
-
Initial observations..
- Bit Loading is a consequence rather than a cause, so best to leave it until last.
- QLN (quiet line noise) has, overall, actually gone down between 29/07 and 05/08.. so it's not a crosstalk issue.
- Hlog (line attenuation) is virtually unchanged between the two dates.
- SNR (signal to noise ratio) .. that's the interesting one... SNR across the DSL spectrum has dropped, yet not in response to changes in QLN or Hlog.
Doesn't the QLN graph from 5th August actually show lower attenuation across all 3 bands i.e. increased noise?
(-140 being "quieter" than -120)
That could possibly explain why SNR has dropped.
You lost me. HLog measures attenuation. QLN measures noise.
Hlog (attenuation) is essentially unchanged between 29/07 and 05/08.
There was more line noise measured on the 29/07 than on 05/08.
Yet, counter-intuitively, with attenuation unchanged and less noise, SNR nevertheless was reduced across the xDSL spectrum.
If we study the drop in SNR between 29/07 and 05/08 it indicates a managed cut-back in transmitter power at the DSLAM. A different PSD mask applied by Openreach, perhaps?
Sorry, I should have stated lower "sound" attenuation measured in dBm/Hz.
The way I have understood QLN is that as the QLN graph is "inverted", the higher the visual appearance the less the noise is attenuated i.e. the noisier the connection.
We quite often discuss noise "spikes" that have a value of say -120 dBm/Hz compared to the underlying value of say -140dbM/Hz.
The examples from July & August appear (to me) to overall show a general increase in "noise".
As you state, Hlog (signal attenuation) is virtually identical, so the signal to noise ratio has taken a hit as depicted in the SNR graph.
Overall DS SNRM levels had also deteriorated from around 10.6dB to 5.3dB, again suggesting either that the signal had weakened or that noise had increased.
This reduced SNRM had the effect of lowering attainable rates from 59168 Kbps to 40292 Kbps.
Over time, QLN appears to have deteriorated on my own connection (quite gradually), suggesting increased crosstalk as more customers are connected.
I believe I was one of the first to be connected to my cabinet as BT checks were stating that FTTC wasn't yet available at the time Plusnet arranged my connection.
(See the attached typical QLN graphs from my connection - October 2011 & July 2012)
Have I misunderstood the interpretation of QLN values (genuine question)?
-
I guess a pair of sketch-graphs, one to show a typically "noisy" line and one to show a typically "quiet" line, would be what you would like to see? :-\
-
The way I have understood QLN is that as the QLN graph is "inverted", the higher the visual appearance the less the noise is attenuated i.e. the noisier the connection.
We quite often discuss noise "spikes" that have a value of say -120 dBm/Hz compared to the underlying value of say -140dbM/Hz.
The examples from July & August appear (to me) to overall show a general increase in "noise".
As you state, Hlog (signal attenuation) is virtually identical, so the signal to noise ratio has taken a hit as depicted in the SNR graph.
Overall DS SNRM levels had also deteriorated from around 10.6dB to 5.3dB, again suggesting either that the signal had weakened or that noise had increased.
This reduced SNRM had the effect of lowering attainable rates from 59168 Kbps to 40292 Kbps.
Over time, QLN appears to have deteriorated on my own connection (quite gradually), suggesting increased crosstalk as more customers are connected.
I believe I was one of the first to be connected to my cabinet as BT checks were stating that FTTC wasn't yet available at the time Plusnet arranged my connection.
(See the attached typical QLN graphs from my connection - October 2011 & July 2012)
Have I misunderstood the interpretation of QLN values (genuine question)?
Sorry, Paul, you are completely right! Ooops.. confusion reigned here :-) I better delete that graphic otherwise everyone will be confused not just me!
cheers, a
-
Phew, that's a relief! I though I was due to be taken to the "funny farm". :P
-
I think that's where I belong! ??? Sorry for causing the confusion everyone, especially Crystal_Ship! Hopefully Baldy_Bird can tidy up the mess!
cheers, a
-
Hello asbokid!
No worries! I'm glad you took the time to contribute your ideas - after all, every day is a school day! ;D
I just wish this so called "10 day training period" would hurry up... things aren't changing at all and BT only want to know the state of play once that time is up....
So what we are saying is that the line is noisy or it's cross talk? This seems to be a very common issue, sadly.
-
sorry, i didn't even notice you had said that about the drop in max attainable rate when lifting the handset. Definitely worth getting to the bottom of that. I don't know anything much about line faults, HR joints, etc.. Though the filters/splitters in the faceplates do sometimes fail. And of course there's another splitter/filter at the other end (on the linecard in the cabinet). That potentially could fail. Doesn't seem very likely though.
I have experienced dodgy external pole top connections AND failed filtered faceplates.
The symptoms were:-
Many random disconnections due to weak/corroded cable connection(s)
SNRM & Attainable rates dropping substantially (sometimes enough to cause a disconnection) caused simply by picking up a telephone.
Dialling in always seemed to effect a temporary cure that lasted from a few hours to a couple of days.
These issues were always more apparent during warm/hot & dry weather conditions & less apparent during wet & cold weather conditions.
It took around 11 months & many engineer visits to finally get these intermittent issues fixed.
Without the benefit of graphical & raw data evidence, I am convinced my connection would never have been fixed as it was always classed as being "within acceptable performance limits" by BT (& initially my ISP).
-
So what we are saying is that the line is noisy or it's cross talk? This seems to be a very common issue, sadly.
It seems to have BECOME quite a bit noisier than it was.
This could be crosstalk or electrical interference or failing cable connection(s) etc.
As the changes are fairly pronounced, it may be worthy of engineer investigation (at the risk that you may be charged if no network fault is found).
I can't recall the exact fault threshold levels, but they are much lower than the speeds you are currently achieving.
-
Thank you.
I already had a copper technician pay a visit, unfortunately though the crackling had gone (and funnily enough that was on 29/07/2012 when the download line stats jumped!) - so he declared no fault found and refused to check and recrimp the joints on the line.
I'm hoping I won't be charged for this - I haven't heard anything since. The call handler at BT India heard the crackling himself when I was reporting the fault.
Hopefully a broadband technician will be on the case once BT agree.
The copper chap said that they measure line stats at certain points along the line to identify where it drops off.
I think BT state that 15mb is the minimum acceptable line sync rate. I don't think £40 a month including line rental justifies that. I could get far more on cable for less (though I gather VM isn't without its problems - but I either choose cable or BT for the last mile)
The line checker states 55.2/18mb as the predicted rate. If I get back to the original 60mb+ I will stay, otherwise I will have to negotiate an exit with BT if it's way below that.
Happy days!
-
Using rs-w v0.4 (thanks Eric!)
Here are this evening's telnet stats and bitloading graph. It's day 8 of the "10 day training period"
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 11585 Kbps, Downstream rate = 42908 Kbps
Path: 0, Upstream rate = 11935 Kbps, Downstream rate = 36378 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.4 5.9
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 6.8
VDSL2 framing
Path 0
B: 63 237
M: 1 1
T: 64 47
R: 16 16
S: 0.0560 0.6338
L: 11435 3206
D: 577 1
I: 80 127
N: 80 254
Counters
Path 0
OHF: 62346447 50638
OHFErr: 79 33
RS: 3380631745 332552
RSCorr: 31297535 2075
RSUnCorr: 2448 0
Path 0
HEC: 517 0
OCD: 0 0
LCD: 0 0
Total Cells: 3163202013 0
Data Cells: 10405532 0
Drop Cells: 0
Bit Errors: 0 0
ES: 131032 258
SES: 246 11
UAS: 154 154
AS: 168149
Path 0
INP: 3.00 0.00
PER: 2.68 7.44
delay: 8.00 0.00
OR: 71.46 34.37
Bitswap: 41055 9872
Total time = 1 days 19 hours 43 min 28 sec
FEC: 64740917 272898
CRC: 55776 592
ES: 131032 258
SES: 246 11
UAS: 154 154
LOS: 40 7
LOF: 40 7
Latest 15 minutes time = 13 min 28 sec
FEC: 205937 0
CRC: 4 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 198018 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 19 hours 43 min 28 sec
FEC: 13217560 64
CRC: 24 12
ES: 8 12
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 15778789 1959
CRC: 45 19
ES: 14 19
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 1 days 22 hours 42 min 29 sec
FEC: 31297535 2075
CRC: 79 33
ES: 25 33
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#
-
QLN & Hlog unly update during the resyncing process as the connection trains & the data sticks until the next retrain.
However, Bit-loading & SNR do change dynamically throughout the duration of a connection between resyncs/retrains.
Have there been any further changes to the graphs (my script versions) & if so, do these changes appear to be time-of-day related?
Have you tried my ongoing 24/7 scripts that will flag any changes & error counts minute-by-minute?
Eric's rsw.exe monitors SNRM changes, but as yet doesn't include any graphical error count details etc. & doesn't yet display all the 4096 available bit-loading tones in one screen.