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: Detecting errors - pushing things too hard  (Read 2808 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Detecting errors - pushing things too hard
« on: August 06, 2018, 06:27:35 PM »

I was wondering what stats I should look at to see whether or not I am pushing my ZyXEL VMG 1312-B10A modems too hard. Since Broadcom PhyR RETX is working, perhaps I could look at those counters but I need something as a denominator to go with that. An actual error rate counter for corrupt packets is what I am after. Trying to spot L4 retransmissions caused by corrupted IP packets being dropped is too hard and they could just be from legitimate packet loss elsewhere.
Any suggestions amongst the stats?
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Detecting errors - pushing things too hard
« Reply #1 on: August 06, 2018, 07:53:06 PM »

>> An actual error rate counter for corrupt packets is what I am after.

If I've understood the question correctly then Err Seconds is the standard counter used by most systems.

>>> Since Broadcom PhyR RETX is working,

Then you should also be looking at LEFTR(s) = Loss of Error Free Throughput
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

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Detecting errors - pushing things too hard
« Reply #2 on: August 07, 2018, 05:07:54 AM »

Quote
VMG1312-B10A
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    8000
Last initialization procedure status:   0
Max:    Upstream rate = 392 Kbps, Downstream rate = 3524 Kbps
Bearer: 0, Upstream rate = 440 Kbps, Downstream rate = 3115 Kbps

Link Power State:       L0
Mode:                   ADSL2+ Annex A
TPS-TC:                 ATM Mode(0x0)
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        1.3             6.8
Attn(dB):        69.5            41.4
Pwr(dBm):        18.3            12.4

                        ADSL2 framing
                        Bearer 0
MSGc:           53              11
B:              35              6
M:              4               16
T:              3               8
R:              12              16
S:              1.4562          8.0000
L:              857             128
D:              2               4

                        Counters
                        Bearer 0
SF:             20210047                531995
SFErr:          119             15
RS:             894294614               696755
RSCorr:         5315717         9589
RSUnCorr:       364             0

ReXmt:          248244          0
ReXmtCorr:      160111          0
ReXmtUnCorr:    391             0

                        Bearer 0
HEC:            351             14
OCD:            8               0
LCD:            8               0
Total Cells:    2407280194              340119129
Data Cells:     92699891                16830818
Drop Cells:     0
Bit Errors:     14779           1566

ES:             88              42
SES:            18              0
UAS:            195             177
AS:             327812

                        Bearer 0
INP:            26.00           2.00
INPRein:        0.00            0.00
delay:          8               8
PER:            16.10           17.00
OR:             29.29           8.00
AgR:            3130.10 446.25

Bitswap:        97765/97839             153/153

Total time = 4 days 23 hours 31 min 55 sec
FEC:            5317814         13493
CRC:            1035            58
ES:             88              42
SES:            18              0
UAS:            195             177
LOS:            16              0
LOF:            0               0
LOM:            2               0
Latest 15 minutes time = 1 min 55 sec
FEC:            1701            0
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 15 minutes time = 15 min 0 sec
FEC:            13656           3
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 1 day time = 23 hours 31 min 55 sec
FEC:            1314376         2842
CRC:            5               9
ES:             4               7
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 1 day time = 24 hours 0 sec
FEC:            1388990         861
CRC:            3               0
ES:             3               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Since Link time = 3 days 19 hours 3 min 31 sec
FEC:            5315717         9589
CRC:            119             15
ES:             36              13
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: Detecting errors - pushing things too hard
« Reply #3 on: August 07, 2018, 05:16:02 AM »

Looks like you need actual G.INP to get LEFTRS:

From my xdslctl info --stats:
Quote
         G.INP Counters
LEFTRS:      1      0
minEFTR:   25594      0
errFreeBits:   282772      0

From your stats these look the most similar:

Quote
ReXmt:          248244          0
ReXmtCorr:      160111          0
ReXmtUnCorr:    391             0

But I have to ask, if you are not experiencing actual packet loss in the higher networking layers and the connection doesnt drop, what good is knowing "how hard" the modem is working to correct errors? If it doesn't break or cause problems then keep going!

Edit: On reflection I guess this view is pretty naive given we are trying to look for uncorrected errors. I'm not familiar with non G.INP retransmission, but "ReXmtUnCorr" looks to be a good candidate.
« Last Edit: August 07, 2018, 05:32:28 AM by johnson »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Detecting errors - pushing things too hard
« Reply #4 on: August 07, 2018, 05:37:28 AM »

I was looking for actual uncorrected errors causing packet loss - and extra TCP retx or much much worse, failure of UDP and things such as failure of DNS lookups and so in.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Detecting errors - pushing things too hard
« Reply #5 on: August 07, 2018, 06:16:45 AM »

So there were indeed some errors visible there, in PhyR counters, in SES and in uncorrected errors.

Q1: The problem here is a I do not have a denominator to make a ratio? Or do I ? - because this is ATM and it is sending idle cells all the time? So do I just include these, so that they 'count', and form a denominator?

I was thinking: I need to think about how much IP (more accurately in fact PPP) data has been sent, when comparing these numbers, so that if there has not been much 'activity' then numbers at a particular value are actually really bad news, whereas if there has been tons of activity then that is not so bad. But this is wrong thinking?

--
Also: I would like to compare numbers generally:

2. What kind of numbers do other people get for ES, SES, uncorrected errors etc?

3. Does anyone else have PhyR (ie the Broadcom-proprietary low-level L2-retx, equivalent of G.INP)?
« Last Edit: August 07, 2018, 07:09:13 AM by Weaver »
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 4093
Re: Detecting errors - pushing things too hard
« Reply #6 on: August 07, 2018, 02:07:46 PM »

Looks like you need actual G.INP to get LEFTRS:

Indeed you do.

Quote
From your stats these look the most similar:

The only PhyR figures given are

Code: [Select]
ReXmt:          248244          0
ReXmtCorr:      160111          0
ReXmtUnCorr:    391             0

The matching G.INP figures appear to be

Code: [Select]
Retransmit Counters

rtx_tx:         96663925                0
rtx_c:          228398          0
rtx_uc:         59169           0
 >

Weaver your ES numbers look very very good to me

Code: [Select]
Since Link time = 3 days 19 hours 3 min 31 sec
FEC:            5315717         9589
CRC:            119             15
ES:             36              13
SES:            0               0

You're averaging under 10 ES per day.
Average ReXmt is about 45 per min, which seems decent to me.
« Last Edit: August 07, 2018, 02:19:17 PM by j0hn »
Logged
Talktalk FTTP 550/75 - Speedtest - BQM

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Detecting errors - pushing things too hard
« Reply #7 on: August 07, 2018, 05:33:21 PM »

That is good to know j0hn. I had my suspicions as I had had the odd weird error but I am inclined to blame recent Apple iOS instead as things were VERY good until iOS 11.4(.0).

That modem is being pushed hard as you see, the downstream SNRM is quite low. The DLinks naturally ran at much lower SNRM downstream say 0.6 - 0.8 dB even sometimes. And they had no L2 RETX capability, being Mediatek chipset based so no Broadcom-proprietary PhyR retx nor any standard G.INP either, not in the modems and anyway not in the Broadcom DSLAM for G.992.3, so we think.

We have not worked out how to make target SNRM adjustments ('tweaks') persistent yet.

And unfortunately we do not yet know how to tweak the upstream, that is where it really would count, upstream stuck at 6dB and one is at 6.7 dB upstream [!].

For all I know it is completely impossible, as it may be that the rx end controls everything so there is absolutely nothing that could be done. Does anyone know? I have not ploughed through the standards docs to that section yet, on negotiation.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Detecting errors - pushing things too hard
« Reply #8 on: August 07, 2018, 05:36:40 PM »

ES is used a lot as kitz said, but unless you have something like interleaving or g.inp expecting that to be 0 or close to it is unrealistic, so I tend to use SES as a means to see if my line is been pushed too hard, usually if SES is 0, then I dont get any type of affect on my service that I notice from errors.  But if SES increases it tends to be noticeable, like in reduced throughput, missing images on web pages etc.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Detecting errors - pushing things too hard
« Reply #9 on: August 07, 2018, 05:48:49 PM »

In the past I have had zero ES. These ZyXELs are so much more stable than the DLinks and the PhyR is a godsend. They are not that much faster than the DLinks but given that the DLinks run naturally with such a low actual SNRM downstream in order to compare like with like you need to reduce the SNRM to match. That makes them 300kbps faster downstream sync rate, from 2.8 Mbps to 3.1 Mbps d/s sync or around 11%.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Detecting errors - pushing things too hard
« Reply #10 on: August 19, 2018, 05:42:26 PM »

I was looking for actual uncorrected errors causing packet loss - and extra TCP retx or much much worse, failure of UDP and things such as failure of DNS lookups and so in.
For what it's worth when our line was being interfered with by an electric fence on 20CN we were getting a pretty much constant 2800 ES per hour.  Running a speed test when the fence was on or off showed absolutely zero significant difference, in actual fact the "fence on" test was marginally faster.  From which I think I conclude that retries resulting from drops within the wider Internet effectively swamp those due to local errors. 
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Detecting errors - pushing things too hard
« Reply #11 on: August 20, 2018, 01:47:36 AM »

The electric fence thing might be an example of interleaving doing its job, dealing with a case that it is very much designed to handle. Unless the spike is of too great a duration, one might characterise that situation as 'easier' because it is exactly what the system is set up to cope with.

But my excessively low SNRM thing might not have such a fortuitous distribution of errors. Does that sound fair?
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Detecting errors - pushing things too hard
« Reply #12 on: August 21, 2018, 06:47:59 PM »

My understanding is the errors corrected by interleaving wouldn't contribute to the ES counts.  Maybe someone can confirm.

What was happening was that each click of the fence at intervals of around 1.25 seconds generated either one or two CRCs.  That could clearly be seen on the OR guys tester that showed real time stats.  On DSL stats the per minute counts were round about 70 or so CRC per minute.  By my reckoning that's about one error in 350 packets during a download.

Just by the by 21CN rides out this interference much better, maybe it has fancier interleaving.  And although ES counts are still high, A&A have been able to disable BT's DLM.
Logged