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] 3

Author Topic: Bizarre low upstream SNRM - line #3 again  (Read 884 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6565
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Bizarre low upstream SNRM - line #3 again
« Reply #15 on: November 26, 2018, 01:58:19 PM »

finally, a low, upstream SNRM again, precipitous drop from ~5.8 dB to ~1.7 dB. See attached raw data for all stats as requested, plain ascii

[Attempt to attach text files failed somehow - see attachment at subsequent post below.]

[Moderator edited to remove the attachment of the size zero file.]
« Last Edit: November 27, 2018, 06:06:00 PM by burakkucat »
Logged

re0

  • Reg Member
  • ***
  • Posts: 389
Re: Bizarre low upstream SNRM - line #3 again
« Reply #16 on: November 26, 2018, 03:32:54 PM »

0 KB? :hmm:
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6565
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Bizarre low upstream SNRM - line #3 again
« Reply #17 on: November 26, 2018, 11:33:03 PM »

I have no idea what on earth happened there, try again  :-[
Logged

johnson

  • Reg Member
  • ***
  • Posts: 538
Re: Bizarre low upstream SNRM - line #3 again
« Reply #18 on: November 27, 2018, 12:03:05 AM »

As simple graphs:
Logged

johnson

  • Reg Member
  • ***
  • Posts: 538
Re: Bizarre low upstream SNRM - line #3 again
« Reply #19 on: November 27, 2018, 12:03:31 AM »

And Hlog:
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 24558
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Bizarre low upstream SNRM - line #3 again
« Reply #20 on: November 27, 2018, 12:36:01 AM »

I have also plotted the snapshot graphs -- sent to Weaver as an e-mail attachment -- and here is the montage of the four plots . . .
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.

re0

  • Reg Member
  • ***
  • Posts: 389
Re: Bizarre low upstream SNRM - line #3 again
« Reply #21 on: November 27, 2018, 03:19:29 AM »

Shame that QLN and Hlog isn't showing anything for the upstream, but perhaps we won't need it.

Going on things from the SNRM perspective, unless I have missed something important, I can't actually see any issues. The data provided shows that the SNR values would be high enough to sustain the bits allocated at a SNRM target of 6 dB (bits*3+6) across the whole upstream.

If the modem was reporting an SNRM of ~1.7 dB at the time of taking these stats, then I am stumped. I think this reporting could be erroneous if the previous condition is true, but part of me questions how it could be inaccurate (makes me believe I am wrong somehow).

Anyone else got an input? Have I overlooked something?
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6565
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Bizarre low upstream SNRM - line #3 again
« Reply #22 on: November 27, 2018, 08:06:48 AM »

I’m hoping we can spot the specific points of difference between the data sets for the ‘high’ and ‘low’ states. Line #2, the latest, has these vertical jump transitions too, but not as large.

[Line #3 which is being discussed here is, in chronological order, the second pair in the first drop cable. (Line #4 is the first pair of an additional drop cable, which was put in later, and line #2 is #4’s later companion.) The numbering unfortunately ended up a bit weird because of AA allocating a ‘slot’ entry to a link of another type, other than a DSL line, a SIM, iirc, at some point in the history.]

It really is a damned nuisance losing such a big chunk of upstream, something like 20% or maybe more. I could increase the target SNRM to 9dB if things get really bad. Another problem is that I have to set the Brick’s upstream egress rates to be correct for the speed of each link, so unless I get those numbers right, ie low enough to cope when the rate drops because it happens to sync at a low SNRM time, then I am going to get terrible packet loss, dreadful speed and unreliability. So I won’t be able to ever get any benefit by resyncing during the high SNRM periods, not unless it is guaranteed to be able to hang on without dropping the link.

Another question: Can I get some idea of how many real errors, uncorrected corrupted upstream packets, are being seen when the SNRM is very low? That way I will know if Inhave another real problem.
Logged

johnson

  • Reg Member
  • ***
  • Posts: 538
Re: Bizarre low upstream SNRM - line #3 again
« Reply #23 on: November 27, 2018, 09:25:24 AM »

Another question: Can I get some idea of how many real errors, uncorrected corrupted upstream packets, are being seen when the SNRM is very low? That way I will know if Inhave another real problem.

So CRC errors?

You can examine their totals for up and down using xdslctl info --stats, or for time series data if you are still running the SNRM graphing firmware on any of your devices then the CRCs for down and up are the last two entries in that order, in the logfile (/var/tmp/stats/data/logfile) eg:

Code: [Select]
1517542818 3.6 6.2 4762 0 0 0
1517542849 3.6 6.2 4262 0 0 0
1517542879 3.4 6.1 42196 0 7 0
1517542909 3.6 6.2 132515 0 0 0
1517542939 3.4 6.2 4148 0 0 0
1517542970 3.4 6.2 10259 0 0 0

This shows a burst of 7 down stream CRCs. From left to right, time - down SNRM - up SNRM - down FEC - up FEC - down CRC - up CRC.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6565
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Bizarre low upstream SNRM - line #3 again
« Reply #24 on: November 27, 2018, 10:22:13 AM »

Am I correct in thinking that the FECs were corrected? Or uncorrected but handled by L2 ReTx ?(because we have PhyR here, at least in the downstream direction, both directions?)

I get confused because there are so many levels where ‘errors’ may or may not have been mitigated, FEC successful mathematical correction, then errors fixed by an L2 Retx, at the cost of some time lost for the retransmission, and then a corrupted packet and total failure, with an ATM HEC error, but I think our kitizens told me that ATM doesn’t correct bad cells, only detects them, and so finally we end up with duff data delivered to L3.

The other thing I find very confusing is ‘errors per what’ and ‘ or counts over what period / since when? And cumulative counts or deltas?

I ought to try and get some help writing all of this stuff up and putting it in one place for reference so that I will be able to refer to it without the failed attempts to remember it.
Logged

re0

  • Reg Member
  • ***
  • Posts: 389
Re: Bizarre low upstream SNRM - line #3 again
« Reply #25 on: November 27, 2018, 06:34:02 PM »

Am I correct in thinking that the FECs were corrected? Or uncorrected but handled by L2 ReTx ?(because we have PhyR here, at least in the downstream direction, both directions?)
FEC errors are corrected - FEC means 'Forward Error Correction'. This correction is present when the line is interleaved (and interleaving has a slight overhead).

CRC (Cyclic Redundancy Check) errors are more important to look out for as those require restansmission (corrupt) and can slow down throughput if there are many.

I am not sure about PhyR (someone probably explained it to me in the forum before but I don't remember) but surely PhyR has its own counters like G.INP?

The other thing I find very confusing is ‘errors per what’ and ‘ or counts over what period / since when? And cumulative counts or deltas?
It is not unusual for the the rate of FECs and CRCs to increase with a lower SNR margin. Each line has its own characteristics so there is all the reason to be confused what is considered ample. An easy way to grasp the concept of error rates is to either use a third-party application that can telnet/SSH to your modem, or even use the adsl info --stats command since it shows error rates for the:
  • Total time
  • Latest 15 minutes
  • Previous 15 minutes
  • Latest 1 day
  • Previous 1 day
  • Link time (since xDSL link established)
Errors, just like resyncs, can be categorised using values that signify MTBx (Mean Time Between x) in reference to the DLM; MTBE (Mean Time Between Errors) in this case. There's a good amount of information here for that. May be relevant if you have the DLM enabled.

Since we have seen your stats with the upstream SNR low, perhaps you could also provide the same stats from when the SNR is about normal? Would be nice for comparison.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6565
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Bizarre low upstream SNRM - line #3 again
« Reply #26 on: November 28, 2018, 09:22:36 AM »

Raw stats’ session log, captured straight from CLI, attached
Logged

re0

  • Reg Member
  • ***
  • Posts: 389
Re: Bizarre low upstream SNRM - line #3 again
« Reply #27 on: November 28, 2018, 10:35:12 AM »

What is the current SNRM? It looks like it is about 6 dB.

If it is the case that the SNRM is about 6 dB, then the statement I made in a previous post (about the SNR per tone being sufficient) is false and I will need to revisit the excel document and ensure I know what I am talking about. Perhaps there is an aspect of ADSL that I am missing.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 24558
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Bizarre low upstream SNRM - line #3 again
« Reply #28 on: November 28, 2018, 05:48:35 PM »

Raw stats’ session log, captured straight from CLI, attached

Montage of the four plots, attached below . . .
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

  • Addicted Kitizen
  • *****
  • Posts: 6565
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: Bizarre low upstream SNRM - line #3 again
« Reply #29 on: November 28, 2018, 06:56:24 PM »

It was 6dB upstream when that data was captured, if memory serves.
Logged
Pages: 1 [2] 3
 

anything