Significance of Max Rate to Faults

[#1]

I understand that the max attainable rate is a theoretical figure which is reduced by restrictions put on by the DSLAM to meet the line conditions, but does it provide any indication of problems that need to be investigated?
I have a fairly long FTTC connection over a mixture of copper and aluminium cable. The synch speed has varied over time from around 18.5 Mb/s at best down to around 13Mb/s. Last week the max attainable rate was being reported as over 24Mb/s. This week it is down to 13.3Mb/s. (BT HH5) The synch rate at the moment is nearly 16Mb/s and the noise margin hovers around 6dB. Despite the low max rate, there are no disconnections, but I guess if the HH5 restarts (as it does occasionally in response to admin termination requests) it will re-synch at a much lower rate.
I've run RouterStats from time to time and cannot see any patterns related to time of day. Max speed and noise margin tend to drift over periods of days. However there do seem to be occasional jumps in speed or drops in speed which again seem to be at random times. Could this be related to a poor joint?
I've attached a couple of graphs. I'd be grateful for any thoughts about whether this is something that indicates a possible problem, or is normal performance.

[#2]

No replies, so I guess either no one knows the answer, I wasn't clear enough, or it was a stupid question. My logic says that if max rate is the capability of the line before you take into account cross-talk, external em interference and presumably other variables, then it ought to be relatively stable. Mine has now fallen below 13Mb/s and has almost halved in a week. What could cause this? You can only get limited stats from HH5 - is max rate not worth even looking at or can it indicate there is an issue that should be followed up?
If any of the more knowledgeable members could comment, I would be grateful.

[#3]

the attainable rate is what the line would sync at with the target snrm and no FEC.  It is estimated by the modem, not necessarily accurate.  If the line suffers from crosstalk then the attainable rate will be affected and be reduced accordingly.  The modem has no idea how much signal is lost from crosstalk.
Usually the sync speed will be very close to the attainable rate but with the following scenarios it may not be.
If interleaving is enabled FEC will make the actual sync speed below the attainable.
If DLM caps the line, attainable will be higher than sync speed.
If the line syncs at the max speed for the product spec and has spare capacity, then the attainable will be higher.
If the snr is volatile and the sync is at a low point then excess snr can make a higher attainable rate (but probably temporary). likewise the sync can be higher than the attainable speed if snrm is low.
So eg. if a line syncs at 20mbit/sec on the 80/20 FTTC product but has an attainable of 37mbit, it is logical to assume it has been limited to 20mbit/sec by DLM banding.  So its helpful when diagnosing DLM, but it wont tell you much about crosstalk unless you have historical data for the line and have been monitoring it over a period of time.

[#4]

As long as the variations aren't caused by the HH5 spontaneously resyncing, as I've seen some reports that say they do, others say they have no problem - then it's quite possible that the  external interference or cross-talk comes and goes which could be down to a possible line fault, may be not on your line - a line in the same cable from the DP to Cab could cause that, or just general sporadic high levels of interference - eg. a dodgy unsuppressed electric lawn mower maybe?
Just keep an eye on your own line, check you can't hear any audible crackling etc when on the phone.

[#5]

The Plusnet DCT guys can do a GEA test on your line that will do a number of checks - see http://community.plus.net/forum/index.php/topic,130781.msg1139486.html#msg1139486
This will give you an idea if there are any line issues and whether cross talk is detected. I believe Openreach are bringing in an even more comprehensive GEA test that will:
- Check the copper pair
- Tell the CP the distance of the end user to the fibre cabinet
- Analyse the line speed performance and say whether it's better/worse/ok compared to what's expected
- Check for interference and determine when it's occurring/where it's occurring
- Compare your FTTC speeds to your neighbours

[#6]

That'd be good, but would it force OR to replace iffy Al cable 

[#7]

That I'm not sure about, but I would assume that if they detect some issue, they will try and fix it.
I think the newer tests are centred more around the fact that FTTC is eventually going to become self-install. ISPs will then be able to feed back more information to end users if their service is not working as well as it could or should.

[#8]

Quote from: AndyH

That I'm not sure about, but I would assume that if they detect some issue, they will try and fix it.

Cynic hat on - having seen quite a few cases where they haven't and have even refused as well, to replace a deteriorated cable, hmm, I remain to be convinced     (when I win the lottery, when pigs might fly, when.............)

[#9]

Thanks for the replies everyone. It's never simple is it. I can see that there are plenty of good reasons that the synch speed will be lower than the max rate. The thing that concerns me is the continuous wide variation in max rate. There are no signs that the HH5 is having to re-synch due to that, but it will re-start due to admin activity soon, and with the max rate now at 12.5Mb/s the current synch rate of 15.99Mb/s is presumably going to take a big hit.
If the modem is calculating max rate and does not know the effect of crosstalk, then something else must be depressing the numbers I am seeing. I would also expect crosstalk to have some daily variation related to use of other circuits in the cable. I do not see that here (but then all I am looking at is max rate and I can't see anything useful like error counts).. It was running at 24Mb/s max rate for most of last week. This week it has been at or below 13Mb/s for a number of days now with no obvious correlation with busy periods. There was heavy rain last week when the max rate was high and it seemed to drop in speed after that but I couldn't say that I could show a correlation between rain and max rate or synch speed over any period.
There are times when the rate jumps or falls suddenly by anything up to 1Mb/s but this can happen at any time of day and for varying lengths of time.
My own guess is that it is related to 40 year-old aluminium cable although the quiet line test is quiet. When I had FTTC installed the OR guy told me that half the cable length to to the cabinet was being replaced and I would see a speed improvement. Sure enough the synch jumped from about 11 Mb/s to around 16-17 Mb/s.
While the synch remains stable I am happy not to worry about it but I If it doesn't improve, or the synch rate gets hammered I'll see if the DCT will be kind enough to run tests. As people are saying, even if there are problems, getting BT to take out the aluminium will be a challenge.
AndyH
I followed your link but wasn't really sure how that related to this case.

[#10]

Before you get stuck in with admin activity, can you Disconnect your PPP Internet session on the HH5? I'd recommend doing that first if you want to end up rebooting but much better powering off and on later - I'll explain.
Log in and click Disconnect to drop the PPP Internet session before and waiting about 30 seconds before powering off or Restarting.  After you power  back up or Restart is complete, then Log in and click Connect to re-establish an Internet PPP session. This should avoid any issues with stale sessions stopping you reconnect quickly.
If you just want to Gateway hop, then instead of powering off or Restarting, after the 30 seconds.just click Connect.
IIRC doing it this way, also means that the Radius log of the PPP session shows this as User Initiated rather than a random session drop.
Now, always better to power on in daylight hours - but maybe not at the time a neighbour is moving the lawn etc.     Ideally when you turn off, preferably leave it off for at least an hour, but better still overnight, but certainly I would advise not less than 15 minutes, all to hopefully help DLM not treat it as a drop in connection. HTH.

[#11]

I may have misled you here. This isn't admin activity that I'm carrying out voluntarily. It's activity that happens occasionally on the HH5 and is triggered by BT or their agents through the TR069 route. (I think) You may remember all the fuss about HH5s restarting periodically. Mine used to go down every 3 days or so but now it's extended to about 12 days. There's been a lot of discussion and as far as I'm aware there's no way of blocking it.
I have no need to restart the router and will leave it on as long as I can , but I know that the VDSL session will be dropped and re-started by some external request soon!

[#12]

Yep, Ok understood. I've never looked into this issue with the HH5, not wishing to possess one, in light of what does go on, but with one that's not locked, depending on it's firmware, whether possible via the GUI or CLI command, to turn off the TR-069 as well as the commands for accepting firmware updates. I'm thinking probably not as I'm sure there are better people than me that have these things that have had a jolly good dig into them, or if it's possible it's not widely publicised.
Anyway the method above is still useful if you want to resync at anytime, or change settings and reboots are needed, it can be done off-line.

[#13]

Thanks, Anotherone, It is really useful to have the procedure for shutting down stated clearly. It would make a useful sticky.
The max rate is now constantly below 11.5 Mb/s (although noise margin is up around 7dB) and has even dipped below 11Mb/s.
I'm still not sure why the continuous max rate would more than halve in this way unless there was a problem nor related to external emi or crosstalk, but i'm bracing myself for a re-synch which is now about 3 days away.

[#14]

jsm51 - My point is that if you ask the DCT guys, they can do a test on your line which will pick up any potential problems (like crosstalk/electrical interference/bad wiring). This might give you an idea of where your issue is, if you have one.

[#15]

Thanks, Andy,  is the best way to do that to raise a ticket or will they respond from here?