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

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Afternoon burst of errors
« on: August 09, 2021, 09:58:11 AM »

The other day, I noticed that one of my ZyXEL VMG1312-B10A modems’ Johnson graph-plotting function was showing a large burst in errors per unit time during the afternoon of the 7th. Janet had a workman at the house for that time interval although the time he was here was much longer than the duration of the interference period. When I asked her about it she said, "but he wasn’t on the same mains supply!", which is good thinking, and is true, because the site where he was working, an outbuilding, has its own separate mains feed, it isn’t fed from the house. I explained to her the concept of RF interference and had to tell her something about what radio frequency EM energy is, then I think the penny dropped.

Anyway, I have some pretty pictures below, one of "FECs" and one of "CRC errors".

Could someone help me understand how these images were arrived at? I’m being really, really stupid again.

There’s also the question of how/where the PhyR L2ReTX protocol fits in and how it affects the definition of these terms - ie pre- and post- L2ReTX recovery vs protocol ReTX timeout.


FECs:





CRCs:



And what kind of tools and what kind of badness in those tools (if any) causes RF interference like this?

Normally the CRC rate is between 0 - 4 per time interval, so very clean. And once again I have forgotten what the unit time interval is in these Johnson graphs; Burakkucat and friends must have reminded me at least twice already - so I will need yet another reminder if you all would be so kind and then I’ll write it down somewhere prominent. Trying a search of the Kitz forum proved too confusing.
Logged

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5261
    • Thinkbroadband Quality Monitors
Re: Afternoon burst of errors
« Reply #1 on: August 09, 2021, 02:15:26 PM »

What was he doing?  I work on the assumption that any kind of inductive load can spit out a ton of RF on various frequencies.
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Afternoon burst of errors
« Reply #2 on: August 09, 2021, 05:13:43 PM »

And once again I have forgotten what the unit time interval is in these Johnson graphs; Burakkucat and friends must have reminded me at least twice already - so I will need yet another reminder if you all would be so kind and then I’ll write it down somewhere prominent. Trying a search of the Kitz forum proved too confusing.

Unless it is shown as otherwise then, with such plots, I would always assume the time quantum is "per minute". (Per second and per hour would be somewhat illogical.)

The question to ask yourself is "What is the sampling rate?" and the answer is "Once per minute". The counters are read once per minute and then the delta between two adjacent reads of the counter in question is then is plotted.
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 #3 on: August 09, 2021, 07:44:56 PM »

I didn’t explain my confusion properly at all. My apologies. I should have asked about the exact definition of CRCs and FECs.

As for the time quantum being ‘per minute’, that is my best guess having zoomed in on the graphs of certain suitable, moderately ‘busy’, alternating 0-1, 50% duty-cycle datasets.

@Alex - he was repairing a floor that was damaged by a flood caused by sheep-attack. No I’m not joking, sheep who were scratching rubbed on a plastic water pipe and managed to damage a connector or something, causing a huge flood. Several floorboards were cut out and replaced and then (amazingly good-looking) fake tongue-and-grooved plastic ‘wood’ was laid over the whole floor.

It is our first experience of a sheep-attack. Donkeys also scratch their backs on things. Janet has purchased some strong, stiff wire fencing material to keep sheep (and haggis) out of where they shouldn’t be.
Logged

tubaman

  • Senior Kitizen
  • ******
  • Posts: 12514
Re: Afternoon burst of errors
« Reply #4 on: August 10, 2021, 07:44:10 AM »

Serious RF noise like that can be caused by a badly suppressed motor in an electric drill or the like. Another possibility is a badly suppressed petrol engine - from a standalone generator perhaps?
 :)
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 #5 on: August 10, 2021, 05:24:39 PM »

At the point when a "CRC" event is counted, as a result of corrupt data received that cannot be recovered by the Reed-Solomon method, is it after that that the PhyR or G.INP algorithms kick in and save the day? If that’s true and the ‘CRCs’ are counted before L2ReTX has corrected errors then the ‘CRC’ count will be a dramatic exaggeration of the true number of corrupted PDUs received, no?

Or is the CRC event counted after PhyR or G.INP algorithms have recovered your data by retransmission(s)?

That was my confusion about the detailed stats in the pictures.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Afternoon burst of errors
« Reply #6 on: August 10, 2021, 05:39:02 PM »

I have always understood that the CRC count is that of the "residue" after all corrective methods have been attempted. (But I could well be wrong.) It's not something of which that I have given a great deal of thought . . .
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.

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5261
    • Thinkbroadband Quality Monitors
Re: Afternoon burst of errors
« Reply #7 on: August 10, 2021, 11:28:13 PM »

You'd think CRC would count BEFORE retransmission, as technically you did lose that packet, but if it does - who knows.
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

tubaman

  • Senior Kitizen
  • ******
  • Posts: 12514
Re: Afternoon burst of errors
« Reply #8 on: August 11, 2021, 08:16:48 AM »

I have always understood that the CRC count is that of the "residue" after all corrective methods have been attempted. (But I could well be wrong.) It's not something of which that I have given a great deal of thought . . .

That is my understanding too, but I've never seen it actually documented anywhere.
Logged
BT FTTC 55/10 Huawei Cab - Zyxel VMG8924-B10A

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Afternoon burst of errors
« Reply #9 on: August 20, 2021, 02:43:12 AM »

I have always understood that the CRC count is that of the "residue" after all corrective methods have been attempted. (But I could well be wrong.)

True.   CRC isn't error correction.  It's error detection for corrupt data packets that have not be sent. (lost packets or packet loss)
It doesn't record errors that may have been corrected by 'lower level' error correction methods.

Remember how broadly speaking* we say that FECs have the potential to be CRCs if the line wasn't Interleaved?   

>>  as technically you did lose that packet, but if it does - who knows.

If it was corrected by any of the lower level error correction methods then no - because it was successfully recovered. 
The relevant error correction methods keep counters of that method it was recovered by.   There's a big difference between error correction and error detection and its why since G.INP I specifically say error detection or error correction as opposed to Interleaving.
   
CRCs go waaay back higher up the stack for recovery such as ARQ.  Sufficient packet loss at this level has the potential to grind a connection to a noticeable crawl.




*Technically it should be Interleaved and using RS encoding.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5261
    • Thinkbroadband Quality Monitors
Re: Afternoon burst of errors
« Reply #10 on: August 20, 2021, 02:48:02 AM »

That's where its unclear, because G.INP is error detection, the packet IS lost, its just able to more efficiently get re-transmitted.  So presumably if that counts as CRC or not would depend on if it occurs lower down the chain so it can't be detected as a CRC.

My guess would be it probably doesn't count as a CRC because the whole point is it corrects the problem long before that point, to avoid it being seen as packet loss which in turn could trigger a loss of sync?
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Afternoon burst of errors
« Reply #11 on: August 20, 2021, 03:30:14 AM »

>>> PhyR L2ReTX

I'm not sure as the mention of L2 is confusing me here, so ignoring that bit.....
Would have thought that since its the modem performing this function then it would be the same level as G.998.4 and 'beneath' RS encoding. 
 
As above,  Retransmission and RS (and TCM) are types of error correction used with DSL.  CRC is a counter of errors not able to have been fixed by any of the error correction methods employed by the xDSL modem.

Retransmission uses RS methods for protection.  The level of protection is set using parameters in similar way to standard INP.   If the DTU doesnt arrive then a CRC is recorded and dealt with at higher level in the protocol stack.


Further reading on this topic on the main site under
 - Data Transmission
 - Error Correction
 - G.INP Retransmission
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Afternoon burst of errors
« Reply #12 on: August 20, 2021, 03:52:58 AM »

That's where its unclear, because G.INP is error detection, the packet IS lost, its just able to more efficiently get re-transmitted.  So presumably if that counts as CRC or not would depend on if it occurs lower down the chain so it can't be detected as a CRC.

My guess would be it probably doesn't count as a CRC because the whole point is it corrects the problem long before that point, to avoid it being seen as packet loss which in turn could trigger a loss of sync?

G.INP is classed as error protection.   
OK I get what you say about it being error detection, but all error correction methods first have to be able to perform error detection to know when & which  packets need to be corrected.


If I say that CRCs are errors that haven't been able to be corrected at the 'DSL layer' rather than modem,  does that help to clarify it a bit better?
CRC's are passed higher up the chain and have to be dealt with higher up in the (TCP/IP) protocol stack ie by the 'network card'.   

The whole packet has to be resent - unlike with TCM, RS & G.INP which can attempt to repair the packet.   
OK again that's a bit basic explanation because g.inp can re-request a packet...  but purely at the 'DSL layer' between the modem and dslam....  rather than the more traditional method of between the PC and remote server.     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.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5261
    • Thinkbroadband Quality Monitors
Re: Afternoon burst of errors
« Reply #13 on: August 20, 2021, 04:43:44 AM »

Yes, that makes sense.  Plus presumably a DSL packet is much smaller than say a TCP packet, so you're retransmitting much less data if its fixed at the DSL layer?
« Last Edit: August 20, 2021, 04:46:38 AM by Alex Atkin UK »
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Afternoon burst of errors
« Reply #14 on: August 20, 2021, 05:15:43 AM »

I’m getting confused about PDUs here. How large is a DTU in PhyR ? (Need to read Kitz’ article again thoroughly.)

So is an incoming AAL5 PDU which is seen as a string of PhyR DTUs checked, retransmission performed if needed, and if the retransmission process fails then that is a "CRC error" event?
Logged
Pages: [1] 2
 

anything