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 7476 times)

niemand

  • Kitizen
  • ****
  • Posts: 1836
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: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 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

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • 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: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 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 22, 2022, 05:14:46 AM by Weaver »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
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

tubaman

  • Senior Kitizen
  • ******
  • Posts: 12507
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

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Afternoon burst of errors
« Reply #21 on: January 22, 2022, 05:27:45 AM »

The key point for me is that there can be an error detected by one software/hardware component, here RS CRCs, but is fixed by a later component, here PhyR or G.INP. And if there is an RS CRC detected error, then that counts one stats error counter event even if the problem is subsequently fixed by PhyR or G.INP ReTx. So you have a stats counter error even if there was no fault seen at L3, no practical problem except for a small latency increase due to the L2 retx.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Afternoon burst of errors
« Reply #22 on: April 29, 2022, 11:58:55 AM »

I checked with Mr Johnson. Burakkucat’s guess as to the time quantum in the Johnson graphs was not correct, just logical :) The quantum in in fact 30 s, so the count is "events per 30 s". Johnson has very kindly made a new release for me which shows a " / 30 s" on the vertical axis for people like me who can’t remember anything.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Afternoon burst of errors
« Reply #23 on: January 15, 2023, 10:45:44 AM »

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.

That makes sense, because the DTU is then a very appropriate unit such that the code that stitches together newly received retransmitted DTUs into the saved existing good parts of the earlier large PDU does not have to deal with for example a part of an ATM cell’s worth of new DTU payload content or half a PTM 65-byte codeword. Perhaps that’s not really an important issue for simplifying the code, but an appropriate DTU size choice can’t hurt.

Can anyone tell me what the likely value or range of values of the multiple is ? And what determines the choice of the value ?

I do wonder if I ought to work out the DTU size in the current situation because then I could say "there are n uncorrected errors per b bytes of received data and each error means the loss/corruption of d bytes" with an exact report on the data loss and a summary percentage shown to the user if I give out full details in ‘verbose’ mode. If there is no ARQ, then you would have to report different numbers: CRC count and the total size of the lost DSL PDUs vs the received total download size.

But going back to the PhyR situation, one bad DTU means one entire (possibly larger) DSL layer-x PDU lost as half a PDU is no use. I suspect that a bad DTU might stuff up more than one DSL layer-x PDU where multiple layer-x DSUs are packed into one layer-x DTU, is that right ? I need to re-read the ADSL2 spec on this point and I also need to remind myself of what the various correct DSL sublayers’ names are, so the above could be made less vague and confusing. Mea culpa maxima.

I’m sure I have been told this, but once again I forget. Are there going to be more errors if a download is in progress than if the link is idle ? I’m assuming the answer could be very different for the cases of VDSL2, ADSL2+PTM and ADSL2+ATM ?

I’m thinking that the link is always busy in ATM even if there’s no user data in transit ? I have no idea about PTM though ?

Looking back, I see that at various places I expressed opinions that were wrong and I think that was because I hadn’t spotted or had not understood some of Kitz’s points.

Just to once again check my understanding, I’m assuming that ES counting is exactly driven by the CRC count increment events, and the value of CRCs and ES is different because you can occasionally get several CRC events within one 1 s time quantum and that whole group of CRCs still only counts as one ES.

I presume that I made the correct choice by picking ES as the health metric in my modem-stats DSL link wellness assessment program, but CRCs would have been a reasonable choice too. Do you agree ?

And even PhyR or G.INP retransmission-corrected errors are not shown in the CRC or ES value ? That is, if there is a RS-uncorrected error then it’s not shown in the ES or CRC total if PhyR or G.INP successfully recovers from the situation within a specified max time limit ?

In my iPad wellness program, I thought about looking at the PhyR-related stats that my modems show. This would be a pain because some modems won’t have PhyR and in some situations the DSLAM won’t support PhyR or G.INP, so I would have to deal with all those alternatives, although that wouldn’t be a big pain in the code. The syntax of these stats might vary between modems and will probably be different for G.INP stats compared with PhyR stats, and that parsing would be a pain to handle. I certainly wasn’t keen to do a lot of work unless there was some real reason why looking at these stats was essential, and if ES or CRC count does effectively summarise the health of the link including absolutely all L2 error correction techniques available, then there’s no reason to do any unnecessary extra work. When I had the idea that the CRC count might show exactly how many RS-uncorrected PDUs there are, never mind those later corrected by L2 retx ie ARQ ie PhyR or G.INP, then I did think about looking at the PhyR/G.INP stats.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Afternoon burst of errors
« Reply #24 on: January 15, 2023, 03:30:05 PM »

Can anyone tell me what the likely value or range of values of the multiple is ? And what determines the choice of the value ?

No. Sorry, not I.

Quote
I’m sure I have been told this, but once again I forget. Are there going to be more errors if a download is in progress than if the link is idle ? I’m assuming the answer could be very different for the cases of VDSL2, ADSL2+PTM and ADSL2+ATM ?

The xDSL link is established and has various protocols in place to help maintain that established state. Why would the presence or absence of "the stuff" being carried by the xDSL link make any difference? (I guess I'm answering "no" and "no" to your two preceding questions.)

Quote
I presume that I made the correct choice by picking ES as the health metric in my modem-stats DSL link wellness assessment program, but CRCs would have been a reasonable choice too. Do you agree ?

Yes, that seems to be a sensible choice.

Quote
And even PhyR or G.INP retransmission-corrected errors are not shown in the CRC or ES value ? That is, if there is a RS-uncorrected error then it’s not shown in the ES or CRC total if PhyR or G.INP successfully recovers from the situation within a specified max time limit ?

"Yes" and "yes" is my response (until such time as I am corrected by a more knowledgable member).
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: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Afternoon burst of errors
« Reply #25 on: January 15, 2023, 06:05:57 PM »

> Why would the presence or absence of "the stuff" being carried by the xDSL link make any difference?

I can think of an example. From the Stone Age (1970s). RS232 links have the line in one of two states (oversimplified) which I’m going to call idle and frame, because I don’t know the official names if any such names exist. Being in the idle state means that no data is being currently sent, and the line is just unchanging, always high voltage. In the frame stage the line goes up and down for each bit in a short block of between 7 and 9 payload bits plus some extra bits for protocol framing overhead. Now if there is an EM noise spike while the link is in the idle state, ie no data currently being sent, then depending on the hardware possibly no error condition is indicated and certainly there will be no corrupted byte or bytes received, because we are in the idle state ie no data being transmitted so nothing is currently being received that can get corrupted. (Methinks there are other possible problems that could occur in such a situation but I’ll leave that analysis to the aged experts amongst us.)

Anyway, with this physical layer there is a concept of currently idle link state vs currently busy link state (my ‘frame’ state in this particular case). You might not see any evidence of badness produced when a spike occurs in the idle state but this is dependent on several unknowns. If you are doing a big download flat-out then possibly you would pick up a certain number of error events per unit time whereas if you transmitted nothing, then depending on these various unknown system-dependent factors you might have zero error events.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Afternoon burst of errors
« Reply #26 on: January 17, 2023, 10:17:28 PM »

In your case, your xDSL links are never quiescent, for you have the incessant 1 Hz Firebrick <---> Firebrick ping-pong running over the links.
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.
Pages: 1 [2]
 

anything