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:

Pages: 1 [2]

Author Topic: Afternoon burst of errors  (Read 1602 times)

niemand

  • Kitizen
  • ****
  • Posts: 1839
Re: Afternoon burst of errors
« Reply #15 on: August 20, 2021, 12:53:07 PM »

DTU doesn't have a fixed size. It's a multiple of either 53 byte ATM cells or 65 byte PTM codewords wrapped in some overhead.

I don't think these DTUs will be packaged inside ATM. They're generated by the remote modem and carry ATM so presumably are part of the DSL layer and will be transported as superframes.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 10422
  • Retd s/w dev; A&A; 3x7km lines; Firebrick
Re: Afternoon burst of errors
« Reply #16 on: August 20, 2021, 08:36:42 PM »

Iím digging out some more reading matter.

I found this interesting. https://doc.lagout.org/electronics/doc/ikanos/DO-435935-WP-1_Improved-Impulse-Noise-Protection_ReTx1.pdf
Have only just started reading it as not feeling very well this evening, fuzzy and headachy.

I have been mislead by the experience of old dial-up modemsí retx protocols which used very small DTUs (perhaps 64 bytes iirc, but itís been thirty years and I just canít remember).

@Kitz I used the term L2 in L2ReTX from OSI L2 to distinguish it from TCP ReTX at L4. Sorry if created more confusion than clarification. There are so very many layers, layers within layers. I ought to start using the DSL-internal layer terminology.
« Last Edit: October 23, 2021, 08:24:09 PM by burakkucat »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 34778
  • Over the Rainbow Bridge
    • The ELRepo Project
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 10422
  • Retd s/w dev; A&A; 3x7km lines; Firebrick
Re: Afternoon burst of errors
« Reply #18 on: January 11, 2022, 07:32:33 AM »

[I have a lot of questions in the following. If friends would be kind enough to answer individual ones one at a time then as usual I will be very very grateful indeed, many thanks.]

Is PhyR use more-or-less exactly the same thing in detail as G.INP (not just in concert or high-level aim), or are there differences in the protocol?

Kitz wrote:
> Thats why we say a CRC is something that hasn't been fixed by the modem and has to be passed higher up the network chain - as it is irrespective if g.inp is in use or not.

@Kitz - This is important. So a CRC error count is counted even if G.INP kicks in and recovers the situation by successfully retransmitting DTUs as needed. In other words, if PhyR or G.INP fixes the problem situation by retx this doesnít affect the CRC error event count. Is that correct? So if we see CRC counts we may have a serious problem but these errors could in fact be getting fixed by G.INP.

And is that just as true if I substitute ĎPhyRí for G.INP?

So going back to my graphs at the start, where I see 34 CRC events per time quantum, which is per minute as Burakkucat has explained, we are seeing 34 corrupt RS frames RX per minute and an RS frameís size is determined by the DSL framing parameters (B * M iirc). We canít tell from that anything about how many IP PDUs are being corrupted.

Is all of that correct?

G.INP proper is allowed in conjunction with G.992.3 / G.992.5 isnít it? But BTís DSLAMs/MSANs donít generally support it outside of some FTTC cabs ?

Iím assuming that I am only lucky enough to have PhyR because I have a ZyXEL modem that has a Broadcom chipset in it now which supports PhyR and so does the now six year-old 21CN DSLAM at NSBFD. Is that correct ? And other ADSL2 / 2+ users are not so lucky if they donít have the matching pair of good hardware in their modem and DSLAM ? Thatís what Iíve been telling myself.

If all of that is correct, then that would agree with my feeling that the ZyXEL with its Broadcom chipset is much more robust under poor line conditions than my MediaTek-based DLink DSL-320B-Z1 modems at a low SNRM. Iíve been telling myself that the support for PhyR is the reason why Iím very very happy (no CRCs and no ES at all) even at a downstream target SNRM of 3dB. Compare this with upstream, which I believe has no PhyR support so is not entirely happy even at 6dB upstream target SNRM.

Another question: if you are getting a lot of CRC errors and have PhyR or G.INP, do you get a measurable slowdown due to the retransmissions, if you look at things carefully?
« Last Edit: January 11, 2022, 08:39:26 AM by Weaver »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 6721
Re: Afternoon burst of errors
« Reply #19 on: January 12, 2022, 11:50:29 AM »

To me a CRC is a uncorrected error, any kind of error correction, if it fixes errors will not result in a CRC error been counted, on all the things I have seen error correction implemented, I have never seen corrected errors tallied as CRC.

Those with G.INP hopefully can help you more on your last point, I do think though that G.INP has its own set of stats which may show how many times its had to do retransmissions? (latency increase hit).
Logged
AAISP - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

tubaman

  • Addicted Kitizen
  • *****
  • Posts: 8739
Re: Afternoon burst of errors
« Reply #20 on: January 12, 2022, 01:46:23 PM »

To me a CRC is a uncorrected error, any kind of error correction, if it fixes errors will not result in a CRC error been counted, on all the things I have seen error correction implemented, I have never seen corrected errors tallied as CRC.

Those with G.INP hopefully can help you more on your last point, I do think though that G.INP has its own set of stats which may show how many times its had to do retransmissions? (latency increase hit).

Quite agree, and yes, G.INP has its own stats counters. A quick search found me this explanation of them (https://www.manualsdir.com/manuals/736472/exfo-maxtester-max-630.html?page=92)

"G.INP RTX_TX is the number of frames retransmitted by the transmitter. The Local number is what is retransmitted from the CPE to the DSLAM. The Remote value is what is retransmitted from the DSLAM to the CPE.

Note: The RTX_TX number may contain retransmits not requested by the receiver(that is, the retransmission request channel got corrupted and a retransmission was sent automatically) resulting in an incremental value even though the same frame ID was retransmitted multiple times.

G.INP RTX_C is a counter that is increased each time a frame is detected in error and has successfully been corrected by a retransmission. The Local number is received by the CPE, the Remote value received by the DSLAM.

G.INP RTX_UC is a counter that is increased each time a frame is detected in error and has not been corrected by one or more retransmissions within the maximum delay period. The Local number is received by the CPE, the Remote value received by the DSLAM."
Logged
BT FTTC 55/10 Huawei Cab - Zyxel VMG8924-B10A
Pages: 1 [2]