Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: digitalnemesis on August 04, 2016, 12:36:27 PM
-
Why do I still see FEC errors even though interleaving is off?
Is there still some very slight FEC on fast path?
My pings are 5 ms to bbc.co.uk whereas previously 14 ms.
-
on the upstream?
FEC does not require interleaving, and BT do run FEC alongside fastpath on the US on the open profile.
I did once also see FEC alongside fastpath on my line on the DS when I had my fault a couple of years back.
-
FEC on ds on fast path
-
You can have fec active together with retransmission and no delay. I have the same RS takes care of forward error correction
-
You can have fec active together with retransmission and no delay. I have the same RS takes care of forward error correction
I don't have G.INP. I think I have RS then on fastpath.
-
FEC and interleaving are two separate things.
Sure, FEC is more effective if it runs alongside interleaving, but it works on its own too. Not true the other way around - interleaving alone, without FEC, is pointless.
Having said that, FEC without interleaving (and without G.INP) is rare downstream, even if common upstream.
-
Yes, it's strange, I'm still seeing FEC on fastpath, no G.INP
VDSL2 framing
Bearer 0
MSGc: 18 30
B: 249 238
M: 1 1
T: 64 16
R: 4 16
S: 0.1579 0.8862
L: 12872 2302
D: 1 1
I: 254 255
N: 254 255
Counters
Bearer 0
OHF: 18897652 1014060
OHFErr: 5758 0
RS: 1209424551 1557613
RSCorr: 189897 0
RSUnCorr: 7460 0
Bearer 0
HEC: 6108 0
OCD: 39 0
LCD: 39 0
Total Cells: 349776833 0
Data Cells: 1134236159 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1484 0
SES: 161 0
UAS: 226 58
AS: 47929
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 2.53 14.23
OR: 75.71 20.23
AgR: 50479.97 8596.66
Bitswap: 896/897 0/0
Total time = 6 days 1 hours 51 min 7 sec
FEC: 189897 0
CRC: 5758 0
ES: 1484 0
SES: 161 0
UAS: 226 58
LOS: 1 0
LOF: 8 0
LOM: 39 0
-
Yup. 4 bytes out of every 254 used for FEC correction downstream, and 16 bytes out of 255 upstream. No interleaving, no G.INP.
-
To be honest I would maybe accept light FEC interleaving on my connection DS, even without interleaving it has a noticeable affect on error counts. Of course not as nice as g.inp but its a poor man's alternative when wanting to avoid horrible interleaving.
-
What do these letters represent exactly?
B: 249 238
M: 1 1
T: 64 16
R: 4 16
S: 0.1579 0.8862
L: 12872 2302
D: 1 1
I: 254 255
N: 254 255
-
B (number of bytes in Mux Data Frame)
M (number of Mux Data Frames in FEC Data Frame)
T (Mux Data Frames over sync bytes)
R (number of check bytes in FEC Data Frame)
S (ratio of FEC over PMD Data Frame length)
L (number of bits in PMD Data Frame)
D (interleave depth)
Alphabetical list of line parameters & error counters (http://www.kitz.co.uk/adsl/linestats_errors.htm)
-
How do you calculate the FEC overhead? 4/64 is exactly my tested speed / sync rate indicating 6.25% overhead
-
I = Interleaving block size
N = RS block size
Which means interleaving latency is proportional to (I*D),
and user data per RS block = (N-R).
RS overhead = (R/N).
Note the sync speed is calculated from the accumulated "user data" only (ie N-R), so is calculated after the FEC overhead has been taken off.
The difference between "download speeds" (aka throughput, or goodput) measured by speedtesters, and sync speed comes from the size of the PTM, PPPoE and IP headers.
Remember that speed testers show roughly the same reduction for a line with fastpath and with G.INP (with its associated, rather low, levels of FEC).
-
So in my case sync 40000 R=8 N=147 FEC overhead=5.44% delay=0 so no interleave. Overhead in kbps 2300. The line would sync at 42300 if FEC was off. So as my max is 43400 best case am getting FEC as result of capping to 40000
-
Not necessarily, because the FEC adds coding gain, which the modem will factor in when determining what speed it can connect at.
-
Not necessarily what exactly?
-
Have two sets of R & N values on G.INP Bearer 0 and Bearer 1 which one should I use to get the FEC overheads ?
adsl info --stats
Down Up
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 191
M: 1 1
T: 0 41
R: 10 12
S: 0.1815 0.9566
L: 10492 1706
D: 4 1
I: 238 102
N: 238 204
Q: 4 0
V: 0 0
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
>
-
Bearer 0=data bearer 1=GINP
-
Not necessarily what exactly?
You would not necessarily sync at 42300 if FEC were off, since you would also have removed any coding gain.
-
You would not necessarily sync at 42300 if FEC were off, since you would also have removed any coding gain.
I doesn't really matter. I am capped at 40000 and get FEC as by product. The max rate is 43400 but this is also a calculation
-
Bearer 0=data bearer 1=GINP
With G.INP, bearer 0 carries the data, and bearer 1 carries the overhead data (messages for things like organising bitswaps or exchanging stats and error counters). Without G.INP, those overhead messages are mixed into bearer 0. The line labelled "OR:" further down the stats gives that overhead rate in kbit/s.
-
FEC is only active on the bearer 0 the bearer 1 is fastpath and has no RS error correction. I understand this is because retransmission needs to be fast.
So the G.INP overhead is all goes on bearer 1 and the FEC overhead is only on what is on bearer 0.
As FEC is taken off the sync rate and G.INP is not according to wwwombat than the FEC overhead is calculated as he said it is on bearer 0?
-
Still don't really understanding G.INP now from what I know it's like two channels working independently the uncorrected errors that need to be re-transmitted go into bearer 0 and then overheads FECs will be added to those packets the normal data that has no errors is sent to bearer 1 with no overheads.
Again I am not 100% sure and maybe completely wrong here.
-
Again I am not 100% sure and maybe completely wrong here.
I wonder if this guide (http://www.kitz.co.uk/adsl/retransmission.htm) will help your understanding? :-\ :)
-
https://www.broadcom.com/collateral/wp/XDSL-WP101-R.pdf
I think the idea is that the bearer1 is idle until such time a retransmission is requested
When a data unit is received, its Frame Check Sequence (FCS) is checked, and a first
retransmission request is immediately launched if it is found to be corrupted. Even if corrupted, the data
units are pushed into the receive buffer (R). If the retransmitted data unit arrives while the corrupted
one is still present in the receive buffer, the corrupted data is replaced. If the retransmitted data unit
does not arrive on time, the corrupted data will be further processed by the receiver data path
-
If you look the stats from a connection with G.INP, they show that there is FEC on both bearer 0 and bearer 1.
The overhead that goes into the separate (much smaller) bearer 1 is not G.INP specific. It's the general management messages that a present with all VDSL2 connections. Perhaps it gets put into a separate bearer channel because those messages do not need to be protected by retransmission, and it'll be simpler for the other end to just re-send the message if it doesn't receive the expected reply.
Bearer 1 is not a separate channel only for retransmitted data.
Without G.INP, the management overheads are mixed in with bearer 0 (look at where the OR values are in the stats).
The net data rate is still the net data rate, you don't need to subtract any G.INP overhead from it. The net data rate for bearer 1 is zero, there's no user data, it's all management overheads. If G.INP is working hard and doing lots of retransmission, it will affect the throughput, but only while the retransmission is happening. G.INP uses its own performance monitoring values, such as leftrs (low error-free throughput seconds, recording the amount of time the throughput was below a threshold) and mineftr (recording the minimum error-free throughput).
-
Thankyou ejs that is a post I can understand on how G.INP works :)
-
Bearer 1 is not a separate channel only for retransmitted data.
I understand bearer 1 is exactly only for retransmitted data. That is why there is no upload on this bearer
-
(look at where the OR values are in the stats).
Maybe you could make a judgment on my line with the OR values below
Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 9.84
OR: 0.01 26.00
AgR: 40048.20 6397.59
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
[Moderator edited to fix the broken [code][/code] tags.]
-
People with G.INP active on both the upstream and the downstream would have bearer 1 upstream and downstream. But bearer 1 is not for retransmitted packets.
Let's look at digitalnemesis's stats from earlier in this thread. They have no G.INP.
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 2.53 14.23
OR: 75.71 20.23
AgR: 50479.97 8596.66
Bearer 0 carries 75.71 kbit/s of general management overhead downstream and 20.23 kbit/s upstream.
Here are some old stats from a random connection with G.INP down and up.
Bearer 0
INP: 52.00 46.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 40368.53 15052.70
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
There's 47.81 kbit/s general management overhead downstream, and 31.87 kbit/s upstream, and they have both been moved from bearer 0 to bearer 1.
There's a small amount of these management overheads on all DSL connections, used for things like when your modem wants to know the upstream CRC count, it has to ask the DSLAM for that number, or if the DSLAM wants to know the current downstream SNRM, it has to ask your modem for that value.
@NewtronStar
Because you have G.INP on the downstream but not the upstream, you have bearer 1 for the downstream but not the upstream. 26 kbit/s management overheads get mixed into upstream bearer 0. For the downstream, with G.INP, the 47.81 kbit/s of overheads have been moved into the separate bearer 1.
-
I don't think this makes sense. G.INP uses physical retransmission and therefore needs another bearer for retransmitted data. This bearer shows zero sync rate at the time you run the stats because it is usually idle. The bearer is not interleaved as it needs to transmit fast but it has a lot of error correction so that data is always received. The reason why received packets shows zero in bearer 1 could have to do with the fact that data is merged in the single buffer that is used to receive both errored and retransmitted data. Looking at newton stats the FEC overhead according to the formula of wwwombat is 4.2% but is not included in the data rate. The bearer one is never active unless retransmitting so generally the value can be neglected. Those overhead in the stats may be related to transmission and not to error correction. Anyway this drifting off topic
-
@ejs is right.
Original user data is broken into DTUs (as per @kitz's description page, for which a link was provided by @b*cat), and sent on bearer 0. Any DTUs that require retransmission are sent on the same bearer, with the same amount of FEC and interleaving protection as the original DTU.
Bearer 1 *only* carries management data between the two modems - no user data whatsoever.
Look at those statistics from @ejs again, for bearer 1. The "OR" (overhead rate) is 47.81 kbps down, 31.87 kbps up. Note that the "AgR" (aggregate rate, ie the sum of the overhead rate and the user data rate) is the same value. That is because the user rate is zero.
Bearers 0 and 1 can (and do) have independent levels of FEC, interleaving and retransmission defined. However, I am like most others, and lazily refer to the settings of bearer 0 alone. These are the ones that apply to our user data, and are the ones we care about. And, frankly, account for the biggest volume.
In @ejs' example, bearer 0 runs at 40,368kbps, while bearer 1 runs at just 48kbps - around 0.1% of the total bandwidth. It isn't worth talking about bearer 1. Not unless there is a very specialist topic under discussion.
That last number should offer a further pause for thought. If bearer 1 was used for retransmission, the whole scheme would fall apart if ever more than 0.1% of data needed retransmitting.
-
I found this that explains the protocol fairly complicated
https://www.itu.int/rec/T-REC-G.998.4-201501-I/en
9 PMS-TC function
The PMS-TC functional model consists of two latency paths. However, the multiplexing of overhead data and user data shall be restricted as described below.
Latency path #0 shall contain only the overhead channel and no user data (i.e., B0n=0). This latency path supports FEC and interleaving. Only a reduced number of combinations of L, N, R, and D shall be allowed for this latency path. These combinations are specified in the respective annexes.
Latency path #1 shall carry user data only for bearer #0 (i.e., B1n=0 for n≠0) and shall be protected by retransmission. Latency path #1 shall use the DTU framing as described in clauses 8.1 and 8.2.
9.2 FEC
For operation per Annex C, the FEC shall be the same as in [ITU-T G.993.2]. The interleaving used on Latency path #0 shall be the same convolutional interleaving as defined in [ITU-T G.993.2].
Now in consideration of all of this it seems to me that FEC is counted in the actual data rate reported by the modem is not considered overhead
So in the case of R=8 and N=147 FEC rate=5.4% if sync rate is 40000 and overhead is zero then is available data after FEC removal 94.6% of sync rate i.e. 37840?
-
No, the "sync speed" reported by the modem is the net data rate, it's net in that it's like your net pay, you don't need to subtract tax and national insurance, they've already been taken off. Unlike a payslip though, the modem does not report the "gross" rate like a payslip that shows your gross pay before deductions.
We've discussed two different overheads, the FEC, and a very small overhead for management messages. Neither should be subtracted from the net data rate reported by the modem.
-
Maybe you could make a judgment on my line with the OR values below
Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 9.84
OR: 0.01 26.00
AgR: 40048.20 6397.59
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
[Moderator edited to fix the broken [code][/code] tags.]
AgR=40096 Gross data rate without TCM=L(10496)*4000=41968 FEC overhead would seem 1872
I think there is also a trellis overhead but is negligible?
-
Now my stats are:
B: 191 238
M: 1 1
T: 27 31
R: 2 16
S: 0.1219 0.9227
L: 12736 2211
D: 1 1
I: 194 255
N: 194 255