In reply to a post by InQ:

Thanks Andrew.....forgot about Interleaving and i think it is on currently but not sure how to check it other than telnet into my router.
Any ideas if the Interleaving depth is the "D" row i have highlighted below?
...
Deleted the rest but there were "FEC" counts so think this is "Forward Error Correction" and hence Interleaving is on?

Yes, the D row is the interleaving depth. It is the number of packets over which real data packet is spread.

1 = Fast Path, as that means the data is all in one packet.

FEC's are another way of detecting interleaving, yes. Though some routers, IIRC the BT Home Hub being one, can mis-report the upstream, making it always equal to the downstream.

Thanks Bob, helpful as always!

Is putting it on Fastpath from Interleaving likely to give me much sync wise?

Edited by deleted (Tue 17-Jan-12 21:34:53)

In reply to a post by InQ:

Any ideas if the Interleaving depth is the "D" row i have highlighted below?

Yes, they are the Interleaving depth.

there were "FEC" counts so think this is "Forward Error Correction" and hence Interleaving is on?

EDIT: Yes, also shown as "RSUnCorr" (I think, but you can confirm with the deleted FEC figure). {I always confuse FEC with HEC. Thanks, Bob}

Your ES (Error Secs) are a rather high for Interleaving. Nothing to worry about unless you notice an adverse effect. I'd expect 1 ES in every 5 mins or longer (AS/ES).

Edited by XRaySpeX (Tue 17-Jan-12 21:51:47)

In reply to a post by XRaySpeX:

It's the RS errors that indicate Interleaving.

LOL! I didn't notice those. Yes, I agree, but would also expect RS corrected and uncorrected to equal the FEC figures. As I understand it, Reed-Solomon is just a particular algorithm for implementing FEC. (Probably the predominant one these days).

In reply to a post by XRaySpeX:

Your ES (Error Secs) are a rather high for Interleaving. Nothing to worry about unless you notice an adverse effect. I'd expect 1 ES in every 5 mins or longer (AS/ES).

Think they are high cus i've been messing about, this is the stats since the last sync;

Since Link time = 1 hours 34 min 25 sec
FEC: 5097 72
CRC: 49 13
ES: 32 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0


So 1 ES every 3 minutes on average but we are over the noisy period of the day, over a 24 hour average it should be alot less.

Edited by deleted (Tue 17-Jan-12 22:00:46)

Deleted the rest but there were "FEC" counts so think this is "Forward Error Correction" and hence Interleaving is on?

Not sure anybody picked this particular point up.

Yes FEC = Forward Error Correction.

It's "forward" in the sense that a error correction block is calculated and sent along with the data so that the other end can correct transmission errors - up to a point - without having to "NAK" the data and ask for a retransmit. It's always on (AFAIK) regardless of interleave setting.

What interleave does is increase the usefulness of FEC in the face of noise spikes. E.g say the FEC is set up to correct a one bit error per byte and a noise spike covers a whole byte - FEC won't correct that block of 8 single bit errors. Now suppose that you send a block of 8 bytes. First byte contains all the bit 0's, second all the bit 1's etc. Now a noise spike covering one byte causes 8x 1 bit errors and FEC can correct it.

The downside is that you have to accept all 8 bytes before you transmit any of them which increases latency.

The real block lengths and error correction capability are, of course, larger but I hope that this illustrates how it works.

Thanks.
I'm pinging bbc.co.uk at 33ms so not bad considering interleaving is on.

Sorry, I can't accept that.

You will never find FEC counts non-zero on Fast Path, ie no interleaving. There is however also Impulse Noise Protection which I know little about, which is generally used in conjunction with FEC, and does not require interleaving to be on. I don't recall any counters for errors corrected by that.

Interleave depth 1 definitely means the packet is transmitted integrally, ie Fast Path, thus avoiding the extra latency of FEC. What happens regarding error correction within the many bytes contained within a packet is another matter, but is not FEC.

For instance Be users have the ability in their control panel to turn interleaving on and off on their line, but only support can turn INP off. I did skim through a writeup about INP once but remember little.

INP settings are one of the reason Broadcom routers and DSLAM line cards get on well together on Be, as there is an extension to the INP specification that Broadcom have implemented and Be use. I don't know of any non-Broadcom routers that have this.

Just got the wife to reboot the router as its daytime and sync has gone up to 10735kbps at noise margin of ~6dB. Will see how that goes then might get interleaving switched off.

Can anyone harbour a guess on how much sync wise interleaving would be holding me back?

Edited by deleted (Wed 18-Jan-12 11:29:28)

In reply to a post by InQ:

Can anyone harbour a guess on how much sync wise interleaving would be holding me back?

Not significant in my opinion. Geek stuff.

There are two effects. One, a possible small change in connection speed, and the other a potential change in throughput at any given sync speed.

The first is the one I would mainly apply "insignificant" to. The second you can think about yourself, by watching how your FEC/RS Corrected ramp up, and whether increases occur fairly evenly or in definite bursts. By removing interleaving every one would require a request for and retransmission of the corrupt package, which again could be subject to corruption ....

With interleaving on, a million or so a day is considered not excessive, but I don't know what effect using Fast Path would have at that volume. A consistent few thousand a second, which I have experienced in the past, is a line fault.

Edited by RobertoS (Wed 18-Jan-12 12:26:23)