21CN ADSL2+ why doesnt it say Fast Path???

A disconnect bug with the HomeHub 2.0 Type B has led me to wondering why both versions of the HomeHub 2.0 are reading my line as having interleaving enabled when it is quite clearly performing Fast Path like.

Here are the HomeHub 2.0 Type A's ADSL stats page:

ADSL line status
Connection information
Line state Connected
Connection time 0 days, 0:02:32
Downstream 9,539 Kbps
Upstream 1,071 Kbps

ADSL settings
VPI/VCI 0/38
Type PPPoA
Modulation ITU-T G.992.5
Latency type Interleaved
Noise margin (Down/Up) 12.2 dB / 5.9 dB
Line attenuation (Down/Up) 33.0 dB / 16.8 dB
Output power (Down/Up) 0.0 dBm / 12.7 dBm
Loss of Framing (Local) 0
Loss of Signal (Local) 0
Loss of Power (Local) 0
FEC Errors (Down/Up) 0 / 0
CRC Errors (Down/Up) 3 / 2147480000
HEC Errors (Down/Up) nil / 7
Error Seconds (Local) 2

And the HomeHub 2.0 Type B's ADSL stats page:

ADSL line status
Connection Information
Line state Connected
Connection time 0 days, 00:03:08
Downstream 10,455 Kbps
Upstream 1,115 Kbps

ADSL Settings
VPI/VCI 0/38
Type PPPoA
Modulation G.992.5 Annex A
Latency type Interleaved
Noise margin (Down/Up) 12.2 dB / 6.0 dB
Line attenuation (Down/Up) 35.9 dB / 16.6 dB
Output power (Down/Up) 15.9 dBm / 1.7 dBm
Loss of Framing (Local/Remote) 0 / 0
Loss of Signal (Local/Remote) 0 / 0
Loss of Power (Local/Remote) 0 / 0
FEC Errors (Down/Up) 0 / 0
CRC Errors (Down/Up) 0 / 32
HEC Errors (Down/Up) 7 / 0
Error Seconds (Local/Remote) 0 / 0

A bit of background before I continue:

I moved house and ended up much closer to the exchange but the line was noisy. BT quickly fixed the problem including cleaning up connections to the pole etc resulting in a line which benefits greatly from ADSL2+ with a maximum sync of ~14000 Kbps and the SNR fluctuates by only ~1.5 dB over a 24 hour period.

However my HomeHub 2.0 Type B has a disconnect bug which occurs when I view the ADSL stats page. The broadband disconnects and reconnects when I click on the ADSL stats link on the HomeHub's web interface which of course causes the BT DLM to believe a fault exists eventually resulting in target SNR increases.

I sourced a HomeHub 2.0 Type A to compare and found that it doesn't suffer from the disconnect bug but I wanted to continue to use the Type B because it was sync'ing at ~14000 Kbps whereas the Type A was sync'ing at ~12000 Kbps. I sourced another Type B but it too suffered from the disconnect bug.

I used to be a gamer so I knew Fast Path style pings from Edinburgh to London best case would be ~20ms and very recently I checked and the ping times were ~21ms. Both Home Hub 2.0's were showing the Latency type as interleaved and so I became interested in requesting BT switch my line to Fast Path but I anticipated being told that my line was already on Fast Path and that the HomeHub 2.0 was erronously saying interleaving was enabled.

I made the switching to Fast Path request and I received email confirmation that it would be actioned making me believe that perhaps 21CN with interleaving enabled is capable of pings of ~21ms to London. However, that same day the pings to www.jolt.co.uk and www.bbc.co.uk increased from ~21ms to ~36ms and FEC errors started to occur whereas before the FEC errors always remained at zero. Somehow my line was now performing like it was interleaved so before this change it must have had Fast Path??? Another difference was that the HomeHub 2.0 Type B disconnect bug wasn't occuring anymore.

Yesterday I received confirmation via a text message that the switch to Fast Path had occured and once again there are no FEC errors occuring and the pings to www.bbc.co.uk and www.jolt.co.uk have dropped from ~36ms to ~21ms and you guessed it the HomeHub 2.0 Type B disconnect bug is occuring again and of course as a result of the disconnect bug the SNR has jumped from 6 dB to 12 dB.

I'm now thinking my best course of action is to ask for interleaving to be properly enabled and to have the target SNR reset to 6 dB. For me 36ms isn't much different to 21ms anymore (occasional recreational play) and of course I now know that switching to proper interleaving fixes the HomeHub 2.0 Type B disconnect bug so I will be able to read the stats without fear of target SNR increases.

Anyone got insight into any of the above???

Hi kial,

If you do want interleaving back on drop me an email with your broadband details to [email protected] and I'll get that done for you. It's strange that your stats are showing you as interleaved when you've received confirmation this isn't the case, if you'd like me to take a closer look at this on my end get in touch.

Ta,

Stephanie

Thanks Stephanie.

My broadband appears to have a target SNR of 15 dB now which is rediculous considering the reason for the disconnections is viewing the ADSL line stats lol.

Here is the latest from the ADSL stats page (fortunately this time viewing it didn't cause a disconnect):

ADSL line status
Connection Information
Line state Connected
Connection time 0 days, 02:08:10
Downstream 8,719 Kbps
Upstream 1,095 Kbps

ADSL Settings
VPI/VCI 0/38
Type PPPoA
Modulation G.992.5 Annex A
Latency type Interleaved
Noise margin (Down/Up) 15.3 dB / 6.2 dB
Line attenuation (Down/Up) 35.9 dB / 16.6 dB
Output power (Down/Up) 13.4 dBm / 1.6 dBm
Loss of Framing (Local/Remote) 0 / 0
Loss of Signal (Local/Remote) 0 / 0
Loss of Power (Local/Remote) 0 / 0
FEC Errors (Down/Up) 0 / 0
CRC Errors (Down/Up) 117 / 2
HEC Errors (Down/Up) 375 / 0
Error Seconds (Local/Remote) 114 / 2

And here is the BT speedtester results:

Download speed achieved during the test was - 7846 Kbps
For your connection, the acceptable range of speedsis 600-7150 Kbps.
Additional Information:
Your DSL Connection Rate :8718 Kbps(DOWN-STREAM), 1095 Kbps(UP-STREAM)
IP Profile for your line is - 8000 Kbps
The throughput of Best Efforts (BE) classes achieved during the test is - 14.75:22.85:62.4 (SBE:NBE:PBE)

A ping and tracert to www.bbc.co.uk:

Pinging www.bbc.co.uk [212.58.246.161] with 32 bytes of data:

Reply from 212.58.246.161: bytes=32 time=22ms TTL=50
Reply from 212.58.246.161: bytes=32 time=21ms TTL=50
Reply from 212.58.246.161: bytes=32 time=21ms TTL=50
Reply from 212.58.246.161: bytes=32 time=21ms TTL=50

Ping statistics for 212.58.246.161:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 22ms, Average = 21ms

Tracing route to www.bbc.co.uk [212.58.246.161]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.2.1
2 <1 ms <1 ms <1 ms api.home [192.168.1.254]
3 6 ms 6 ms 6 ms 217.32.142.193
4 7 ms 7 ms 8 ms 217.32.142.222
5 15 ms 15 ms 15 ms 213.120.163.34
6 16 ms 15 ms 16 ms 213.120.157.10
7 15 ms 15 ms 15 ms 213.120.157.178
8 15 ms 15 ms 15 ms acc1-10GigE-1-3-0.mr.21cn-ipp.bt.net [109.159.250.86]
9 20 ms 21 ms 20 ms 109.159.250.1
10 21 ms 21 ms 21 ms core1-pos1-0-0.telehouse.ukcore.bt.net [62.6.201.82]
11 21 ms 21 ms 21 ms 194.74.65.42
12 21 ms 21 ms 21 ms 212.58.238.129
13 21 ms 22 ms 21 ms te12-1.hsw0.cwwtf.bbc.co.uk [212.58.239.222]
14 22 ms 22 ms 22 ms 212.58.255.12
15 22 ms 22 ms 22 ms fmt-vip04.cwwtf.bbc.co.uk [212.58.246.161]

Trace complete.

I realise I directly caused the speed drop by viewing the ADSL stats page but it was because I was investigating the problem. So, I would very much appreciate if you would also reset the target SNR back to 6 dB when switching to interleaving and I'll be sure not to view the ADSL stats page until it's complete. I'll drop an email to [email protected] now.

Based on that trace, I would say that interleaving isn't actually on.

On some combinations of 21CN lines/routers - they report Interleaving on at 0ms - which can also be Fast.

I've seen this on numerous routers and can normally be confirmed when looking at the error counters (errors on Fast instead of Interleaving).

Matt

I agree. The ADSL stats page shows the latency type as interleaving but it's definately Fast Path type results and the FEC errors don't increase.

Maybe the line has no errors?

Ignore the Interleaving status as per my last reply, it is a redherring I believe (and something we see on many 21CN lines).

Matt

There are errors on the line. The stats above shows CRC and HEC errors which of course suggests Fast Path. I should have said about the CRC and HEC errors instead of mentioning no FEC errors so my apologies for the confusion.

In reply to a post by kial:

There are errors on the line. The stats above shows CRC and HEC errors which of course suggests Fast Path. I should have said about the CRC and HEC errors instead of mentioning no FEC errors so my apologies for the confusion.

Why do you say CRC and HEC indicate Fast Path? So far as I know they occur on either FP or Interleaved.

Only the FECs (or RS Corrected if those are shown) indicate Interleaved.

What can happen, for instance O2/Be, is that downstream and upstream settings can be different, and Netgear routers report Fast Path even though O2 is interleaved down, FP up, and the RsCorr figures confirm both.

That is weird. I guess I shouldn't post in a hurry as it wasn't my intention to suggest that lol.

To clarify:

When my broadband had proper interleaving enabled there was FEC errors showing up. I considered it to be proper interleaving because pings and tracerts suggested interleaving and of course because FEC errors were showing up.

Most of the time however my broadband has been Fast Path like and there was zero FEC errors. I considered to to be FP again because pings and tracert suggested it and of course because there was no FEC errors.

I hadn't considered the posibility that no errors would occur on the line lol.

I don't know about O2/Be or anyone else but for my BT Broadband with BT's HomeHub 2.0 it's probably a good idea for it to say Fast Path or at least make it known somewhere that it's broken and could be either FP or interleaved or even have it removed from the ADSL stats page so as not to cause confusion. I had no reason to doubt it was telling the truth and it's only recently I learned otherwise lol.

Target SNR has reset to 6 dB!! Not had any emails so thanks to whoever sorted it.

I switched to using the HomeHub 2.0 Type A just in case of problems as interleaving isn't enabled yet:

ADSL line status
Connection information
Line state Connected
Connection time 0 days, 1:26:17
Downstream 12,671 Kbps
Upstream 1,067 Kbps

ADSL settings
VPI/VCI 0/38
Type PPPoA
Modulation ITU-T G.992.5
Latency type Interleaved
Noise margin (Down/Up) 6.4 dB / 5.8 dB
Line attenuation (Down/Up) 33.0 dB / 16.8 dB
Output power (Down/Up) 0.0 dBm / 12.8 dBm
Loss of Framing (Local) 0
Loss of Signal (Local) 0
Loss of Power (Local) 0
FEC Errors (Down/Up) 0 / 4294967232
CRC Errors (Down/Up) 79 / 2147480000
HEC Errors (Down/Up) nil / 0
Error Seconds (Local) 65

Pings and are ever so slightly higher with the Type A and the second hop is weird at ~99ms too:

Pinging www.bbc.co.uk [212.58.246.158] with 32 bytes of data:

Reply from 212.58.246.158: bytes=32 time=23ms TTL=50
Reply from 212.58.246.158: bytes=32 time=22ms TTL=50
Reply from 212.58.246.158: bytes=32 time=22ms TTL=50
Reply from 212.58.246.158: bytes=32 time=22ms TTL=50

Ping statistics for 212.58.246.158:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 23ms, Average = 22ms

Tracing route to www.bbc.co.uk [212.58.246.158]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.2.1
2 100 ms 99 ms 99 ms BThomehub.home [192.168.1.254]
3 8 ms 8 ms 7 ms 217.32.142.193
4 9 ms 8 ms 8 ms 217.32.142.222
5 17 ms 16 ms 17 ms 213.120.163.34
6 17 ms 16 ms 17 ms 213.120.157.22
7 17 ms 16 ms 17 ms 213.120.157.178
8 17 ms 16 ms 16 ms acc1-10GigE-1-3-0.mr.21cn-ipp.bt.net [109.159.250.86]
9 23 ms 23 ms 22 ms 109.159.250.1
10 22 ms 22 ms 23 ms core1-pos5-0-0.telehouse.ukcore.bt.net [194.74.65.122]
11 104 ms 23 ms 22 ms 194.74.65.42
12 22 ms 22 ms 22 ms 212.58.238.129
13 24 ms 24 ms 23 ms te12-1.hsw0.cwwtf.bbc.co.uk [212.58.239.222]
14 23 ms 23 ms 23 ms 212.58.255.12
15 23 ms 22 ms 22 ms fmt-vip01.cwwtf.bbc.co.uk [212.58.246.158]

Trace complete.