Hi Craig, if you still read these forums (or some1 else from BT) and can turn interleaving off please let me know. Long live online gaming . I had enough conversations with customer support and I don't think another one will be good for my health. I think that the last person I spoke with some time ago, presented himself as the head of technical support. He told me that they will switch interleaving on (it was on already) which will help me to get download speeds higher than 10KB in the evening .

Edited by deleted (Tue 11-Aug-09 20:17:05)

Hi Setho,

Sure thing if your Broadband service is with BT I can certainly turn off interleaving on your line. PM me your details and I will get right on it.

All the best,

Robbie
BT Support

Would switching interleaving off help my line?

I copied the stats from the home hub.

Line state Connected
Connection time 14 days, 3:05:34
Downstream 7,616 Kbps
Upstream 448 Kbps

ADSL settings
VPI/VCI 0/38
Type PPPoA
Modulation ITU-T G.992.1
Latency type Interleaved
Noise margin (Down/Up) 7.7 dB / 24.0 dB
Line attenuation (Down/Up) 33.0 dB / 21.0 dB
Output power (Down/Up) 19.8 dBm / 11.9 dBm
Loss of Framing (Local) 3
Loss of Signal (Local) 3
Loss of Power (Local) 0
FEC Errors (Down/Up) 340579 / 12
CRC Errors (Down/Up) 2135 / 2147480000
HEC Errors (Down/Up) nil / 8
Error Seconds (Local) 3819

In reply to a post by malacath:

Would switching interleaving off help my line?

I copied the stats from the home hub.

Line state Connected
Connection time 14 days, 3:05:34
Downstream 7,616 Kbps
Upstream 448 Kbps

ADSL settings
VPI/VCI 0/38
Type PPPoA
Modulation ITU-T G.992.1
Latency type Interleaved
Noise margin (Down/Up) 7.7 dB / 24.0 dB
Line attenuation (Down/Up) 33.0 dB / 21.0 dB
Output power (Down/Up) 19.8 dBm / 11.9 dBm
Loss of Framing (Local) 3
Loss of Signal (Local) 3
Loss of Power (Local) 0
FEC Errors (Down/Up) 340579 / 12
CRC Errors (Down/Up) 2135 / 2147480000
HEC Errors (Down/Up) nil / 8
Error Seconds (Local) 3819

i get similar stats on mine, not as many crc errors tho. the SNR seems too low (like mine) and i think it may need to be interleaved otherwise more errors would occur on fast mode ?
im tempted to rewire my home in an attempt to fix it and if it does, then request fast mode.
unless someone else here can shed more light on wether we can use fast mode with fec errors ?

try different filters malacath, some gave me a snr of 4-6 and LOTS of errors like yours shows, another filter gave me a snr of 12 and its better although not perfect!

I think i may already have the best filter available. It's a faceplate filter that was fitted by a BT engineer when I was having problems with my previous ISP bulldog.
I was having regular disconnects with bulldog due to the noise margin dropping too low in the evenings.
The BT engineers blamed bulldogs equipment at the exchange though because they couldn't find a fault with the line. They fitted a faceplate which did make my line 1meg faster but didn't help stability.

I've since switched to BT and now my line is faster and 100% stable.
So either interleaving has stabilised my line or bulldog's equipment in the exchange was dodgy.
Although Bulldogs phone service was poor and unreliable as well. There were echos on the line and sometimes callers couldn't hear me speak so maybe it was their equipment at the exchange.

In reply to a post by smokeymacpot:

In reply to a post by malacath:

Would switching interleaving off help my line?

I copied the stats from the home hub.

Line state Connected
Connection time 14 days, 3:05:34
Downstream 7,616 Kbps
Upstream 448 Kbps

ADSL settings
VPI/VCI 0/38
Type PPPoA
Modulation ITU-T G.992.1
Latency type Interleaved
Noise margin (Down/Up) 7.7 dB / 24.0 dB
Line attenuation (Down/Up) 33.0 dB / 21.0 dB
Output power (Down/Up) 19.8 dBm / 11.9 dBm
Loss of Framing (Local) 3
Loss of Signal (Local) 3
Loss of Power (Local) 0
FEC Errors (Down/Up) 340579 / 12
CRC Errors (Down/Up) 2135 / 2147480000
HEC Errors (Down/Up) nil / 8
Error Seconds (Local) 3819

i get similar stats on mine, not as many crc errors tho. the SNR seems too low (like mine) and i think it may need to be interleaved otherwise more errors would occur on fast mode ?
im tempted to rewire my home in an attempt to fix it and if it does, then request fast mode.
unless someone else here can shed more light on wether we can use fast mode with fec errors ?

try different filters malacath, some gave me a snr of 4-6 and LOTS of errors like yours shows, another filter gave me a snr of 12 and its better although not perfect!

The very high CRC error count is in fact a small negative number - it's a well-known bug in the firmware that doesn't recognise negatives.

All the other error counts are remarkably low for over 14 days connection.

The error correction that comes with interleaving just corrects certain errors in-flight instead of needing the packet to be re-transmitted. I think CRCs always need re-transmission. Re-transmitting that number of FECs over 14 days is nothing and the error seconds are no problem either.

As you say, the downstream margin is slightly low for 33dB attenuation but not disastrous so. What you could both do is follow this FAQ if you haven't already done so.

Also plug-in phone extension leads are bad news unless of top quality. Builder-installed fixed extensions are also often suspect due to inferior (cheap) cable instead of BT-approved.

Filters do not affect the "target" SNRM applied by the exchange systems at connection time. However smokey, diagnosis if you are sync'ed at 7616 is difficult as the behaviour of SNRM at maximum sync changes from that at lower speeds. In which case you may indeed have had a duff filter before.

I think that's enough for now, except I think mac's line is suitable for Fast Path as it is, but may be better after the FAQ above and your suggestion re trying different filters.

What is important when trying things is not to disconnect/reconnect more than say 5 or 6 times in an hour. That is taken as instability and a longish-term slow-down of the line by raising the target margin can result.

In reply to a post by RobertoS:

In reply to a post by smokeymacpot:

In reply to a post by malacath:

Would switching interleaving off help my line?

I copied the stats from the home hub.

Line state Connected
Connection time 14 days, 3:05:34
Downstream 7,616 Kbps
Upstream 448 Kbps

ADSL settings
VPI/VCI 0/38
Type PPPoA
Modulation ITU-T G.992.1
Latency type Interleaved
Noise margin (Down/Up) 7.7 dB / 24.0 dB
Line attenuation (Down/Up) 33.0 dB / 21.0 dB
Output power (Down/Up) 19.8 dBm / 11.9 dBm
Loss of Framing (Local) 3
Loss of Signal (Local) 3
Loss of Power (Local) 0
FEC Errors (Down/Up) 340579 / 12
CRC Errors (Down/Up) 2135 / 2147480000
HEC Errors (Down/Up) nil / 8
Error Seconds (Local) 3819

i get similar stats on mine, not as many crc errors tho. the SNR seems too low (like mine) and i think it may need to be interleaved otherwise more errors would occur on fast mode ?
im tempted to rewire my home in an attempt to fix it and if it does, then request fast mode.
unless someone else here can shed more light on wether we can use fast mode with fec errors ?

try different filters malacath, some gave me a snr of 4-6 and LOTS of errors like yours shows, another filter gave me a snr of 12 and its better although not perfect!

The very high CRC error count is in fact a small negative number - it's a well-known bug in the firmware that doesn't recognise negatives.

All the other error counts are remarkably low for over 14 days connection.

The error correction that comes with interleaving just corrects certain errors in-flight instead of needing the packet to be re-transmitted. I think CRCs always need re-transmission. Re-transmitting that number of FECs over 14 days is nothing and the error seconds are no problem either.

As you say, the downstream margin is slightly low for 33dB attenuation but not disastrous so. What you could both do is follow this FAQ if you haven't already done so.

Also plug-in phone extension leads are bad news unless of top quality. Builder-installed fixed extensions are also often suspect due to inferior (cheap) cable instead of BT-approved.

Filters do not affect the "target" SNRM applied by the exchange systems at connection time. However smokey, diagnosis if you are sync'ed at 7616 is difficult as the behaviour of SNRM at maximum sync changes from that at lower speeds. In which case you may indeed have had a duff filter before.

I think that's enough for now, except I think mac's line is suitable for Fast Path as it is, but may be better after the FAQ above and your suggestion re trying different filters.

What is important when trying things is not to disconnect/reconnect more than say 5 or 6 times in an hour. That is taken as instability and a longish-term slow-down of the line by raising the target margin can result.

Thanks.

So my line might be alright for fast mode after all.
I already have that NTE5 ADSL faceplate mentioned in that link though.

NTE5 faceplate should have fixed that bit then. I still reckon Fast Path is OK for you.

I'd be interested to know what the stats look like with a filter plugged into the test socket revealed when the faceplate is taken off. Chances are it wouldn't be any better, off-chance is a fair improvement.

Always sync in daylight for best speed. Read the stats immediately after your next re-sync, as the noise margin varies continuously afterwards and it is the value at sync time we need.

Hi Malacath

Drop me a Pm with your account details and we can have interleaving switched off for you, should you have any problems as a result of this we can always put interleaving back on for you.

Stuart
BT Support

In reply to a post by RobertoS:

The very high CRC error count is in fact a small negative number - it's a well-known bug in the firmware that doesn't recognise negatives.

I'd venture to suggest that the real bug is in any code that can produce negative error counts... doesn't inspire confidence in the rest of the code