Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Weaver on June 28, 2018, 04:03:18 AM
-
Referring to the Broadcom ‘PhyR’ proprietory low-level L2 retransmission protocol, I am wondering if someone could help me understand exactly what the definition of the so-called ReXmtCorr and ReXmtUnCorr counters are, terms as in the stats displayed by my ZYXEL VMG 1312-B10A modems?
-
I would guess they are pretty similar to their G.INP equivalents.
ReXmt
ReXmtCorr
ReXmtUnCorr
G.INP Retransmission Parameters & Counters
rtx_tx = Count of retransmitted DTUs.
rtx_c = Count of detected and corrected retransmissions.
rtx_uc = Count of detected DTU errors which have not been corrected within the delay_max constaint.
-
This is my understanding of it then -
- We have the total number of distinct DTUs that need at least one retx.
- We have the number of retransmission events, and sometimes a particular DTU could be retransmitted more than once?
- We have the number of occasions when the maximum number of retransmissions were sent with no ack so we failed. (So we think, although the last retx could have done the job but we will never know because any ack will not be received in time, if I am understanding the spec.)
I take it then that ReXmtCorr has to be item 2 because in my stats this was a lower number than 1. Item 3 has to be ReXmtUnCorr, and this was zero, yay! So this means that item 1 is ReXmt.
Does that sound correct?
So my guesses at the definitions are :
- ReXmt : the total number of distinct DTUs that need at least one retx.
- ReXmtCorr : the number of retransmission events, and where sometimes a particular DTU is retransmitted more than once, say k times, then this counts as an additional k counts?
- ReXmtUnCorr : the number of occasions when the maximum number of retransmissions were sent with no ack, so we think this was a failure.
[Moderator edited to fix a broken [tt][/tt] tag pair.]
-
There will be something very useful to be gained from thinking carefully about the three numbers, not just the scale of the numbers in general. If we take a look at the ratio ReXmtCorr / ReXmt, I presume that that tells us how much we are struggling with serious badness because we are having to do multiple retransmissions, so either the interleave is not working or we need to get some, or we are getting really really long period blips ( interleave confuses matters completely so this has to be looked at after mentally reversing the interleave ) or full-on outages. Is that correct?
Some intelligent software in a modem could use this to advantage - a sign that the FEC levels need to be put up if the ratio is not too high, but if it is then it is a sign that we desperately need a ton more interleave depth. Is that right?
How would we decide on what to set the DTU size to be? Setting it too small is undesirable because it is bloatful, inefficient in terms of added overhead bytes.