This is the part that is wrong:
Another pair of useful parameters are the size of the small data blocks protected by FEC (aka Forward Error Correction), and the size of the parity data that does the protection. This information is held in these parameters:
B: 63 237
I: 80 127
N: 80 254
For downstream, my understanding is that B gives the amount of user data within an RS block (an RS block is the lump that is protected by FEC, and spread out by interleaving), and N gives the total size of the block. That means (N-B) is the parity (protection) data, which is an overhead.
Here, an RS block is 80 bytes long, carry 63 bytes of user data, and 17 bytes of overhead parity data.
The line is carrying 63/80 user data, or 79%, The parity overhead is 17/80, or 21%.
So... if the line's attainable rate is 64Mbps, you can see it really can only carry 79% of that as user data - or about 51Mbps. The rest of the "attainable rate" *is* still being used to carry useful information - but it is used as part of the FEC process, rather than directly for end-user-data.
It is better written as:
Another couple of useful parameters give the size of the data blocks protected by "Forward Error Correction" (aka FEC), and the size of the parity data that gets added for the protection. This information is held in these parameters:
R: 16 16
N: 80 254
For downstream, my understanding is that there is a missing parameter K that gives the amount of user data within an RS block (an RS block is the lump that is protected by FEC, and spread out by interleaving), and N gives the total size of the block. Parameter R specifies how much of the RS block is dedicated to the parity (protection) data, which is an overhead. Therefore N=K+R.
These additional "parity" bytes, through a miracle of maths, allows the modem to fix a small number of errors in the user data - thereby saving the transmitter from having to re-transmit. The downside is that the parity data represents a permanent overhead.
Here, an RS block is 80 bytes long, carry 64 bytes of user data, and 16 bytes of overhead parity data.
The line is carrying 64/80 user data, or 80%, The parity overhead is 16/80, or 20%.
So... if the line's attainable rate is 64Mbps, you can see it really can only carry 80% of that as user data - or about 51Mbps. The rest of the "attainable rate" *is* still being used to carry useful information - but it is used as part of the FEC process, rather than directly for end-user-data.
Two further parameters specify the way that interleaving works:
D: 861 1
I: 80 127
"I" defines the size of blocks that get interleaved, while "D" specifies how far apart the output bytes will be. In this case, byte 0 (first on the input stream) will be transmitted first, byte 1 will be transmitted 861st, while byte 80 (first in the second block) will be transmitted second.
When both interleaving and FEC are combined, the effect is that a burst of noise hits a number of consecutive bytes within the "interleaved" stream. However, when they are de-interleaved, the broken bytes end up within different RS blocks.
Statistically, not many bytes within each RS block get destroyed by the noise, and the problem is sufficiently small that it can be corrected using the parity bytes.
If it turns out that FEC can't correct the errors, DLM might intervene again to turn interleaving up higher - in which case more parity bytes are likely to be needed with fewer user data bytes.
My Conclusion:
Graphing "I" and/or "D" will give an indication of the extra latency being added by interleaving (the delay is actually given by "I" multiplied by "D").
Graphing "R" and "N" (or percentages based on these numbers) will show how much capacity is being "stolen" by the parity overhead of FEC.
Pages in this thread: 
Print Thread
