My FTTC 80Mbps Profile is still decreasing - It is now <30Mbps

[#1]

Although I can't actually encourage it (because it may be 'against the rules' at some level - since the modem belongs to BT Openreach), I think this is a good example of where an unlocked modem with the ability to view (and log) connection statistics can be a very valuable tool.

[#2]

Quote from: w23

Although I can't actually encourage it (because it may be 'against the rules' at some level - since the modem belongs to BT Openreach), I think this is a good example of where an unlocked modem with the ability to view (and log) connection statistics can be a very valuable tool.

I agree, but BT would then get a lot more complaints if users could actually see their stats  
I know you can download alternative (un-crippled) firmware and if I can't get BT to fix it then maybe that's the way to persuade them.

[#3]

[Stealth]
http://huaweihg612hacking.wordpress.com/
[/Stealth]
If you have the HG612, the other one is a bit more complicated than that.

[#4]

Looking at my Speedtest results, see graph, I was actually only above 40Mbps for about 2 weeks at the begining of March, then at 38Mbps from 16th March until 16th April and then 36Mbps from 16th April until 16th August.
So it has actually droped from 36 down to 29Mbps in the last month !
I thought it was dropping more slowly, maybe there is now a detectable fault ?
All the blips were at weekends.

[#5]

Quote from: Dave

I will read through them a couple more times to see if I can get my head around everything you are all telling me.

The gist is that BT never aim to maximise your speed. Instead, they aim to minimise the errors seen on your line (which, with the current modem, is entirely hidden from you). When they detect errors, they slow things down until the errors go away.
So, while you look at it this way:

Quote from: Dave

However, I don't understand why, if I was downloading at approx 44Mbps for the first 5 or 6 weeks without any apparent issues, then I can't believe that 29Mbps is now the best I can expect to get.

instead, BT will say that your line can only sustain the 29Mbps without causing errors. Great if you desire stability, but not if you want raw speed.
Seriously though - even though the issues aren't apparent to you as a human, they *are* apparent to the modems. The modems are detecting the effect of those issues as errors in the bitstream - but they don't care what the actual issues are that are causing the errors. They merely report the error count through to DLM, which in turn drops the profile until errors stop being reported.

Quote from: Dave

Plus Net want me to allow a BT engineer to do yet another site visit, but on a week day and as the fault only appears at weekends, I don’t see how he will find anything

The objective, I guess, is to find out what has caused the errors to appear. If it is a line error, then BT need to attend, to see if they detect anything.
But... it is entirely possible for your degraded speed to be entirely caused by crosstalk from other subscribers. Practical tests performed by the manufacturers of FTTC cabinets show that crosstalk from around 30 other users can (worst case) slow you down by about 30%. It is one reason that the BT estimates are so much lower than people's initial experiences.
As we can't tell the cause, you'd probably best allow the visit.
Finally, though, an extra thing for you to try:
If your errors on FTTC really do continue to only occur at weekends, then you will probably need to gather some extra evidence. This could be direct evidence (such as monitoring the error counts on a hacked modem) or indirect evidence visible from some monitoring software. One that may help (but mostly if you have a static IP, or at least a rarely-changing IP) is the TBB ping monitor graphs. See here for the TBB signup page, and here for some examples of graphs for other Plusnet users. The red parts of those graphs suggest packet loss - which you are likely to be encountering at your problem times.

[#6]

Note also that maximum raw speed won't give maximum actual throughput.
If your raw speed is 60Mbps but half the packets have to be retransmitted your effective actual throughput is going to be less than 45Mbps. In addition the experience isn't going to be good, with very bad VoIP and gaming experience, pages failing to load when browsing etc. Slow the line down and the actual throughput will be much nearer the raw speed and the overall experience will be much better.

[#7]

I have just enabled the TBB Monitor and it appears to be working, so we will see what occurs.
All understood about BT / Modem attempting to get zero errors by constantly reducing speed.
So in my case then, as the fault only occurs intermittently it will continue to drop my sync until it gets to zero and will never recover, but the chances are that BT will never be available to test my line at the same time as the interference is present.
PN have managed to get BT to call this weekend, so hopefully they will find something.

[#8]

I am attaching the TBB output for the first 12 hrs.
Now all I need to do is read up on how to interpret it

[#9]

I can see that interleaving was probably reduced at 4am this morning, you have red from the top which shows packet loss (due to a modem resync I would think), but at the bottom you can see the ping time reduced slighlty.
I've been having a very similiar problem to you, but have been graphing mine since the day it was installed, I won't go into detail here as I don;t wish to hijack or confue your thread. I'm trying one last thing my end before I raise a fault ticket and a new thread on here.
You can read my thead on Kitz http://forum.kitz.co.uk/index.php/topic,11632.0.html and view the graphs.
Edit: One thing you should be aware of, is the screenshot you've attached shows your home IP address - you can share graphs without displaying your IP address via the options underneath the graph when viewing it on Think Broadband website.

[#10]

Hi Ronski, I've had a quick look at your post, but I'm at work currently so will take a closer look when I get home.
My latency/ping always used to be between 10 & 18ms, but just recently it has been between 28 & 40, so it's interesting to see that it appears to have dropped back, as you say possibly due to a change in interlacing.
I wonder if the change caused the resync or if the resync caused the change in ping
Here ia a live link to mine
or http://www.thinkbroadband.com/ping/share/1bc9423be3c910722c8b3fdb9077b509.html if that does not post correctly

[#11]

I would think that the DLM caused the resync to change the interleaving level - seen it a lot on mine, even a high level drop back to 1 (basically none).
The yellow spikes are when your connection is being used, and thus slow down the responce times of the pings.

[#12]

The graph is read thus:
- IIRC the pings occur once per second, and each pixel across on the graph represents 100secs
- Therefore each column of coloured pixels shows you the average behaviour over 100 seconds
- Every little red pixel at the top indicates some % of packet loss (read down the scale on the right-hand side):
- The green/blue/yellow section at the bottom indicates the time it took for the ping response to get back (read up the scale on the left);
-- The green shows the minimum response time... and invariably follows a straight horizontal bar, unless there is a resync with a change in interleaving
-- The blue shows the average response time... this mostly sticks close to the green
-- The yellow shows the longest response time.
Some things to observe:
- When you are busy transferring files, the blue tends to get a lot higher, with extra yellow sections
- When Plusnet are busier (like last night), the yellow tends to get taller without much blue.
- A deep, narrow, red spike is a sign of a resync. It isn't always the case, but a step change in latency at the same time definitely indicates a resync.
- A large trail of red across the top indicates general errors on the line
The picture at 4AM is *exactly* what I would expect to see when DLM decides your line is good on the current profile - and so shifts you to the next profile up, in this case one with lower latency (thus reduced interleaving).

[#13]

As an example, here's a couple of graphs from my 2nd & 5th days on FTTC at our old house.
Note: When FTTC is installed, the DLM process usually monitors for 48 hours before making the first profile change.
In my case, I got a 40/2 sync for the first 48 hours - but the 1st picture below shows that I was getting sufficient errors on the line to cause 5% packet loss. DLM changed profile so I dropped to 36/2, increased interleaving and increased latency.
A day later, PN regraded my connection so I could get 10Mbps upstream. This caused DLM to be reset, so it went back to a full 40/10 and monitored again for 48 hours.
After the second period of 48 hours, DLM again changed the profile (to 36/10 this time).
In both cases, you can see the effect that turning interleaving (and the associated error correction) back on. No more packet loss - but the cost was that all the extra error-correction information being carried caused my speed to drop from 40Mbps to 36Mbps.
It is likely that, in the past, your line would have been rather like my old one!

[#14]

Yes that's very useful, I will look out for the red packet losses, I can confirm that my latency has dropped back down to 18msecs (best ever was 10ms), but I can’t see my profile increasing before the next weekend of interference.
The red packet losses at present are very few and far between, but I’m sure they will increase significantly when the fault reappears.
I will continue to monitor it, but I believe my problem will be different to yours.
It is probable worth noting that my problems started the exact day my exchange became ADSL +2  enabled, which was approx. 2 weeks before I was upgraded to ADSL+2 and then approx. every 4 weeks I would have a loss of carrier, etc. from then, Sept 2011 to Feb 2012 when I went FTTC.
When I was on ADSL, approx. 1 weekend in 4, I used to lose my connection entirely, or it would drop to > 500Kbps and be very unstable until about 7pm on the Sunday evening when it would suddenly recover back to 14Mbps, but after I got PN/BT involved, every time an engineer fiddled with it, the sync speed would drop and my line attenuation would increase.
Up until the point when I went FTTC, 3 BT engineers had made changes (new pair to cabinet, new pair from cabinet to exchange & different DSLAM at exchange), each one actually making things worse such that my sync speed went from >14Mb to <9Mbps and my downstream attenuation had risen from 35 to 43dBi.
I suspect that some sort of interference was affecting my line, but why only 1 weekend in 4
Anyhow, I expect to have to wait a few more weekends now before it reoccurs, but at least now I should be able to record it and then we might be able to finally get to the bottom of it once and for all.

[#15]

Ronski's link is worth reading in detail as it demonstrates how an unlocked modem used with graphing scripts can give a lot of very useful information but don't worry at all if you don't understand it all.
If the problem remains ongoing long term I'd definitely recommend doing similar.
The graphing scripts are not too difficult to use and there's plenty of support if you want to give them a go.
Intermittent problems are always the most difficult to solve but if you can provide graphs which show a specific pattern then you're definitely a step closer to a solution.