Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: ReXmtCorr and ReXmtUnCorr counters in stats in Broadcom PhyR  (Read 261 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6104
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick

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?
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 1803
Re: ReXmtCorr and ReXmtUnCorr counters in stats in Broadcom PhyR
« Reply #1 on: June 28, 2018, 09:44:51 AM »

I would guess they are pretty similar to their G.INP equivalents.

ReXmt
ReXmtCorr
ReXmtUnCorr

Quote
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.
Logged
BT FTTC 55/10 ECI now Huawei cab
Zyxel VMG1312-B10A bridge mode with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6104
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: ReXmtCorr and ReXmtUnCorr counters in stats in Broadcom PhyR
« Reply #2 on: June 28, 2018, 11:12:11 AM »

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.]
« Last Edit: June 28, 2018, 05:04:32 PM by burakkucat »
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6104
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: ReXmtCorr and ReXmtUnCorr counters in stats in Broadcom PhyR
« Reply #3 on: June 28, 2018, 11:42:49 AM »

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.
Logged
 

anything