Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[crystal_ship]

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.

[burakkucat]

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?

[crystal_ship]

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!

[roseway]

Would it be possible to post clearer copies of the graphs here? The ones on the BT forum are a bit unclear.

[crystal_ship]

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.

[burakkucat]

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?"

[asbokid]

[waltergmw]

Hi CS,

You might try inducing the fault with a 17070 option 1 ring back test or two.

Kind regards,
Walter

[crystal_ship]

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!

[crystal_ship]

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!

[crystal_ship]

This is brilliant asbokid!

I found it rather difficult to compare images by scrolling up and down, this is really helpful!

[crystal_ship]

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.

[asbokid]

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

[crystal_ship]

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?

[asbokid]

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?