Disappointing performance 18months in

Hi all,

I've had FTTC (BT Infinity) 18 months now. When it was first installed I was estimated 35/8 but got the (then max) 40/10 IP profile. Openreach engineer said the line was (if I remember correctly) at about 61mbps.

When I upgraded to 80/20 this time last year for about 6 months I was getting about 55mbps. Unfortunately I never saved any speedtest results so can't prove the drop conclusively. About 6 months ago Openreach disconnected me - as it turned out they were installing further up the street. I reported the fault but was reconnected about 2 hours later. An engineer still came out but took nothing more than a cursory look.

Anyway since then I've struggled to get anything over 30mbps, and a few evenings over Xmas it dropped down to 25mbps. I've finally got around to hacking the Modem and have obtained the line stats. Do they "look about right" for my line (~600m from the cab using likely cable route measured on google maps) once high take-up/crosstalk is taken into consideration or should I be having a whinge to BT?

First the wholesale checker output:

Available Products


Downstream Line Rate(Mbps) | Upstream Line Rate(Mbps) | Downstream Range(Mbps) | Availability Date

Featured Products
WBC FTTC Up to 58.2 Up to 20 -- Available
WBC ADSL 2+ Up to 5 -- 3 to 7.5 Available
WBC ADSL 2+ Annex M Up to 5 Up to 1 3 to 7.5 Available
ADSL Max Up to 4 -- 2.5 to 7 Available

Now the Line stats:

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 18089 Kbps, Downstream rate = 34848 Kbps
Path: 0, Upstream rate = 18018 Kbps, Downstream rate = 32418 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.8 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 13.1 6.6
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 64 64
R: 0 16
S: 0.2356 0.4203
L: 8151 4835
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 510804457 492541
OHFErr: 18677 2675
RS: 0 2370571
RSCorr: 0 34669
RSUnCorr: 0 0

Path 0
HEC: 17295 0
OCD: 0 0
LCD: 0 0
Total Cells: 109401197 0
Data Cells: 55594366 0
Drop Cells: 0
Bit Errors: 0 0

ES: 8591 3536
SES: 72 1
UAS: 51 51
AS: 1932692

Path 0
INP: 0.00 0.00
PER: 3.76 6.72
delay: 0.00 0.00
OR: 59.43 33.31

Bitswap: 1081858 243851

Total time = 1 days 21 hours 56 min 7 sec
FEC: 0 0
CRC: 36425 0
ES: 8591 3536
SES: 72 1
UAS: 51 51
LOS: 19 0
LOF: 10 0
Latest 15 minutes time = 11 min 7 sec
FEC: 0 0
CRC: 0 0

Thanks for reading and all feedback appreciated!

Rob

Those statistics alone look fine, but they aren't quite enough.

The "--stats" command tells us lots, but we need the remainder of the output. The lower groups of FEC/CRC/ES values are more useful than the topmost set - which lies, and gives stats for the full uptime, not the "1 day, 21 hours" it says).

We also need the output of the "--pbParams" command, so we can see the attenuation and SNR values.

What *is* present is enough information to tell us that you don't have interleaving or FEC turned on, and you aren't synchronised at a "nice" round figure. These two facts mean that DLM hasn't intervened... so whatever happened to your line resulted in one that is running without any major glitches.

The drop over Christmas, of roughly 20% of your speed, is what I would expect if DLM *did* intervene and turn on a "reasonable" level of interleaving and FEC. There is no evidence left to say whether this did indeed occur, or not.

But there is nothing yet that suggests this is a line that ought to be carrying anything like 55Mbps.

@WWWombat
Thanks for the response. Here's the additional output you mention.

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 17996 Kbps, Downstream rate = 34236 Kbps
Path: 0, Upstream rate = 18018 Kbps, Downstream rate = 32418 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.6 6.1
Attn(dB): 0.0 0.0
Pwr(dBm): 13.4 6.6
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 64 64
R: 0 16
S: 0.2356 0.4203
L: 8151 4835
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 514741464 212708
OHFErr: 19227 2718
RS: 0 2401834
RSCorr: 0 41922
RSUnCorr: 0 0

Path 0
HEC: 17516 0
OCD: 0 0
LCD: 0 0
Total Cells: 1037136873 0
Data Cells: 56222250 0
Drop Cells: 0
Bit Errors: 0 0

ES: 8799 3563
SES: 72 1
UAS: 51 51
AS: 1947589

Path 0
INP: 0.00 0.00
PER: 3.76 6.72
delay: 0.00 0.00
OR: 59.43 33.31

Bitswap: 1090664 245980

Total time = 1 days 2 hours 4 min 24 sec
FEC: 0 0
CRC: 36975 0
ES: 8799 3563
SES: 72 1
UAS: 51 51
LOS: 19 0
LOF: 10 0
Latest 15 minutes time = 4 min 24 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 8 0
ES: 7 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 2 hours 4 min 24 sec
FEC: 0 0
CRC: 75 0
ES: 45 22
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 2246 0
ES: 455 102
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 22 days 12 hours 59 min 47 sec
FEC: 0 41922
CRC: 19227 2718
ES: 5086 1894
SES: 14 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#

And

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 17973 Kbps, Downstream rate = 34048 Kbps
Path: 0, Upstream rate = 18018 Kbps, Downstream rate = 32418 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 17973 kbps 34048 kbps
Actual Aggregate Tx Power: 6.6 dBm 13.4 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.0 26.6 40.7 N/A 13.1 33.5 53.2

Signal Attenuation(dB): 5.0 25.5 39.4 N/A 13.1 33.5 53.2

SNR Margin(dB): 6.2 6.1 6.1 N/A 6.8 6.6 6.1

TX Power(dBm): -4.0 -16.2 6.3 N/A 10.5 7.4 5.9

#

Am I right in thinking this is the natural effect of Crosstalk then? I'm annoyed at myself for not hacking the firmware months ago, but I never expected the fall in connection speed would be so dramatic. The concern I have is will it fall even further if even more houses take up fibre? From a completely unscientific test of looking for the number of "BT Fon/Home Hub 3" Wifi access points I can see there are quite a few between myself and the cab, which is not surprising as there is no Virgin Cable in my area and ADSL2+ was ~5mbps on a very good day with the wind behind it. Most of the time it was below 4mbps.

Thanks
Rob

someone stole the old pair, and this one not as good?

or maybe the power has been cutback on the dsl signal.

On the first bit of statistics...

Latest 1 day time = 2 hours 4 min 24 sec
FEC:            0               0
CRC:            75              0
ES:             45              22
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
Previous 1 day time = 24 hours 0 sec
FEC:            0               0
CRC:            2246            0
ES:             455             102
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
Since Link time = 22 days 12 hours 59 min 47 sec
FEC:            0               41922
CRC:            19227           2718
ES:             5086            1894
SES:            14              0
UAS:            0               0
LOS:            0               0
LOF:            0               0

The final set show you averaging 850 CRC per day, or about 30 per hour. Quite low, I think.

The first set shows this continuing for the first 2 hours of "today". The middle set shows that "yesterday" was a worse day, running near three times the average.

Overall, it seems to show good line conditions, perhaps prone to some additional bursts of errors.

MadPom's Line

Max:    Upstream rate = 17973 Kbps, Downstream rate = 34048 Kbps
Path:   0, Upstream rate = 18018 Kbps, Downstream rate = 32418 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
       VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:      17973 kbps         34048 kbps
Actual Aggregate Tx Power:        6.6 dBm          13.4 dBm
============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):  5.0     26.6    40.7     N/A    13.1    33.5    53.2
Signal Attenuation(dB):  5.0     25.5    39.4     N/A    13.1    33.5    53.2
        SNR Margin(dB):  6.2     6.1     6.1      N/A    6.8     6.6     6.1
         TX Power(dBm): -4.0    -16.2    6.3      N/A    10.5    7.4     5.9

The attenuation figures look reasonable for the distance, while the SNR margin certainly looks like the sync targetted 6dB.

As an example, here are the same figures for my old line, taken 15 months ago. That line was 550 metres, but was on a 40/10 package - 80/20 wasn't available at the time, but the cabinet had already been upgraded to provide the 17a profile in readiness.

WWWombat's Old Line: 550 metres, 40/10 package, 17a profile

Max:    Upstream rate = 16464 Kbps, Downstream rate = 59076 Kbps
Path:   0, Upstream rate = 10000 Kbps, Downstream rate = 39996 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
       VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:      16464 kbps         59076 kbps
Actual Aggregate Tx Power:        6.6 dBm          12.3 dBm
============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):  5.4     27.7    40.8     N/A    14.1    34.4    53.1
Signal Attenuation(dB):  11.5    27.2    40.1     N/A    14.1    34.4    53.1
        SNR Margin(dB):  11.3    11.2    11.1     N/A    9.3     11.0    9.9
         TX Power(dBm): -3.7    -16.8    6.3      N/A    8.5     7.9     5.4

Note that the line is running at a much higher SNR margin than the 6dB target, because it was using a 40/10 package - a long way below the maximum attainable of 59/16.

That line *did* have problems - it ran with interleaving and FEC enabled from day 3 (ie as soon as DLM could intervene, it did). It was using around 22% overhead on FEC, resulting in statistics of about 600,000 FEC per day and 200 CRC per day.

We have since moved, and have a shorter line that started out with an attainable of 90/27 while on a 40/10 package. As soon as we activated the 80/20 package that dropped to 84/26. This gradually dropped to 79/26 over the next 10 months to December, and is now stating an attainable speed of around 76/25. We're still synced at 80/20 because it hasn't been re-synced since early December.

I'm annoyed at myself for not hacking the firmware months ago, but I never expected the fall in connection speed would be so dramatic.

It isn't usually dramatic - more the kind of behaviour that mine has seen. However, it does depend exactly which phone lines have FTTC - and whether they run next to yours over the bulk of the 500 metres.

More strange is the fact that you have almost no errors. Those usually *do* go up!

But there is no getting around it - on those attenuation figures, you *ought* to have a higher attainable speed. And you therefore ought to have a higher actual speed.

The answer may well be hidden in the detailed way that the modem has allocated bandwidth across the spectrum, or in the background noise that your line is experiencing.

Have you seen the software package by Bald_Eagle? Those take even more detailed data from the modem, and create some useful graphs from them. Well worth having, now you've hacked the modem.

I'll try to dig out some of my historical information.

The concern I have is will it fall even further if even more houses take up fibre?

That is the question, isn't it...

In reply to a post by MadPom:

Am I right in thinking this is the natural effect of Crosstalk then?

I don't think we can answer that in absolute terms, but the evidence suggests that the problem isn't obviously crosstalk, but it certainly could be.

Crosstalk appears to your modem (and the one in the cabinet) as noise and interference. This would have 2 main effects:

(1) would be to increase the interference to your data, after a "normal" synchronisation - which would be seen as an increasing rate of errors (both RSCorr when FEC was turned on, and OHFErr when FEC was turned off)

(2) would be to increase the base noise seen prior to, and during, sync negotiation. This would alter the signal-noise ratios (SNR) across the spectrum, resulting in lower speed as a result of the negotiation. With a lower speed, there will be fewer errors visible in (1).

In practice, both happen together. (2) is usually visible (in the hacked modem) because the "maximum attainable speed" decreases - but it usually drops a little more gradually.

(1) usually happens too, but only really becomes visible when DLM intervenes to turn on interleaving and FEC.

In practice, we seem to see (1) rather than (2). Error rates go higher, and interleaving (plus FEC) get turned on by DLM.

In your case, you are seeing almost no errors - so few, that DLM hasn't got interleaving + FEC activated, which would be the normal first step. If that didn't help matters, DLM would resort to banding your connection - which would place a limit on the speed, and reduce the errors that way. That doesn't look to have happened to you (it isn't a round figure, like 30Mbps, and your SNR values are very close to the target of 6dB).

So, you might be suffering crosstalk. If you are, then it has hit you exclusively as (2) with no evidence of (1).

A bit of a mystery!

@WWWombat

Thank you for the very detailed response. I've enabled the scripts with the scheduling batch file but don't always have the Virtual Machine running 24/7 to be able to grab a complete picture.

This is (I assume) the most useful image produced by the scripts based on my line stats at 18:19 today (3/Feb/13). If you wouldn't mind could you take a look please and let me know your thoughts.

Assuming then that I should have faster sync than this, how exactly do I report it to BT? I can't exactly tell them I've hacked the modem can I? All I can point to is the Wholesale line estimation which is nearly double my current IP Profile.

One other thing - at the top of the line stats it states this:

Status: Showtime
Retrain Reason: 2

What does "Retrain Reason 2" mean out of curiosity?

Thanks
Rob

if the sync speed has declined substantially from installation then this is the thing to report - Openreach have a limit on the decline of that parameter.

I'm looking and comparing. It'll be a little before I can respond properly though...

I found my equivalent image, so uploaded it here. It's from an earlier version of the graphing scripts, so looks a little different.

Note that intepreting these graphs can be a problem, because the X-axis scale means that each pixel horizontally represents quite a large number of tones. In particular, spikes can look wrong.

Note too that mine was working to a 40/10 package, so the bit loading values on mine are probably a bit lower than they could have been if the modem were targetting something higher.

And a link to the Huawei hacking site, and their page about these graphs.

Working backwards from what we already know then...

Your line is carrying less data than my old one, so must have lower bit loading values (bits per carrer) downstream. Comparing those two graphs, we can see:
- that you do better than my line in D3 - the higher frequencies of tones 2792 to 3950.
- that in D2 (tones 1216 to 1963), you are carrying significantly less data - less than half - except for one tiny portion at the end where higher bit loading is evident
- that the lower part of D1 (32 to about 250) seems reasonable, but slightly lower than mine (though my trough appears around tone 500; this differs because of the different distance that the cab is from the exchange)
- that the higher part of D1 (250 to 859) are a little lower than mine.
- and that, on the upstream side, you are using U2 so much more than U1

The modems choose the bit loading based on SNR, so now compare those graphs.
- Your D3 is mostly similar to mine
- Your D2 is noticeably lower than mine, except for 2 spikes - where the improved signal level becomes very similar to mine
- Both lower and upper parts of D1 are notably lower.

Given that your signal level ought to be roughly similar (as there is similar attenuation, and your line has slightly higher transmit power), it seems that you definitely have increased noise throughout D1 and D2 (except for those 2 spikes) but not in D3.

The noise doesn't seem to be worse in any one particular frequency, suggesting that perhaps you are suffering broad-spectrum crosstalk from another VDSL2 customer, but who is perhaps on a longer line and not using any of the frequencies in D3.

Those 2 spikes are strange though...

Moving on to QLN graph, which (I think) is a measurement of the noise detected on the line when no signal is being carried at all. My understanding is that -140 represents very good silence.

Here it is noticeable that QLN in D3 is very good - so would explain why you are using that portion well. However, the QLN value for tones 300-2000ish all seem too high, suggesting too much background noise. Where there are spikes in the SNR graph, I'd expect troughs in this graph... and there is a slight hint. I think it might be present, but masked because of the X-axis scale.

I don't know enough about the Hlog graph to be able to read or interpret it.

Conclusion
I reckon you are suffering from broad-spectrum interference over the frequency range of tones 300-1900ish, or 1.2MHz to 8.2MHz. It seems likely this is caused by other FTTC customers in the form of crosstalk.

What isn't clear is the cause... whether there it is just "luck" (or lack of it), and that you have a very noisy neighbouring line, or that your line has a faulty joint, break, or construction that is allowing a high level of interference in.

For example, I recall someone on here reporting that their hassles were fixed when the engineer found 3 inches of bare copper in the cabinet. Strange problems abound...

As yarwell suggests, the thing to do is to report a fault, on the basis that you are getting much less speed than the estimate *and* that you used to have much better speed before a fault where you got disconnected.

You're going to want the engineer, at minimum, to check joints where you previously got disconnected/reconnected, and check the tie cable joints. If that doesn't work, you'll probably want them to try putting your line on a different pair in the distribution cable, or try a different port in the FTTC cabinet (and different pairs in the tie cable as a consequence)

It may take a number of goes at getting an engineer to attend to get this sorted. I don't know the best approach to take with BT - only with Plusnet.

Note that most other people that have problems, see the effects in terms of errors on the line from interference - and can monitor the effect of any changes by the ongoing error counts. Unfortunately your issue is based on the background noise level... and is probably best monitored using the QLN graph. Unfortunately that data only gets updated when the modem syncs.

In reply to a post by MadPom:

One other thing - at the top of the line stats it states this:

Status: Showtime
Retrain Reason: 2

What does "Retrain Reason 2" mean out of curiosity?

Retrain Reason: 2 is the usual reason following an "on the fly" resync, probably taking less than 20 seconds from disconnection to reconnection.

This type of resync is usually (not always) initiated by DLM taking some sort of action - usually to lower speed & compensate for errors, but occasionally increasing speed following a sustained period of connection stability.

Retrain Reason: 0 is always seen following a modem reboot or power off & on again.
These tend to take quite a bit longer than 20 seconds.
There may be other causes of reason 2, but I haven't seen any of those events.

Very, very rarely, I have seen Retrain Reason: 1.
I have absolutely no idea what may have caused that result.