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: Slow line #3 upstream  (Read 475 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 8797
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Slow line #3 upstream
« on: June 15, 2020, 04:19:56 PM »

For a very long time now I have been moaning and whining on and on about the upstream performance of my line #3.

Recap: line #3 upstream has been struggling because the upstream SNRM has been going up and down in sizeable steps diurnally (I forget, maybe 4dB high) and this meant that I had to set the upstream target SNRM really high to make sure that itís still going to be ok (ie something near to the recommended upstream target SNRM of 6dB) on the Ďlowí part of the cycle later on. So the upstream target SNRM was set to 9dB, and this made the upstream rate really slow compared to the other lines. Two things: one thing is that itís slow, the other thing is that itís different; being different might possible muck up the load splitting algorithm used when allocating load to the various lines (I have four slow ADSLL2 lines). Also for all I know this difference in speed could confuse a receiving TCP entity because the timing measurements will be different when an upstream PDU arrives at its destination the receiving TCP entity sees a transit time that varies depending on whether or not DSL line #3 was the route used. Note that downstream has always been fine, itís upstream only.

However, hereís the good news: the mysterious cycle has gone away! The upstream SNRM at 6 dB, which is the target, and itís keeping to that, so goodbye to the 9dB upstream target as thereís no need for it any more if it keeps like this.
And also there is bad news: Line #3 is really slow upstream - 376 kbps. Why is it so slow? This is weird because the upstream target SNRM and current actual SNRM is ~6dB which is what it should be.

Do I have absolutely no chance with Openreach because itís an upstream problem and they donít care about upstream?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 29861
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Slow line #3 upstream
« Reply #1 on: June 15, 2020, 04:31:23 PM »

I can't give you an answer to your query but I will make a suggestion. Power off the modem connected to line #3 and disconnect the relevant cable linking it to the NTE5. Now leave the circuit like that for, say, 12 hours so giving the DSLAM line-card port time to "relax".

Normally, when I make that suggestion, I recommend leaving the circuit in that state overnight and reconnecting & restarting it the next morning. Obviously your situation is completely different . . . night and day are just one continuum. Hence my suggestion to "relax" the DSLAM line-card port for 12 hours.
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: 8797
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Slow line #3 upstream
« Reply #2 on: June 16, 2020, 03:41:43 AM »

Will do. That makes a lot of sees to me because the function synch_rate = f( target_SNRM, noise, attenuation, tx-power, Ö ) has a list of arguments whose values, as far as I can see, have not changed. So if that is correct then here must be an additional argument which I would think is the state of the DSLAM/MSAN as that could alter the decision process used in choosing a sync rate so as to be more conservative.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 8797
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Slow line #3 upstream
« Reply #3 on: June 16, 2020, 04:54:42 AM »

A new development.  :(   I have just noticed that there has been an upstep in the upstream SNRM, from 5.7 dB to 10.3 dB so it appears that I spoke too soon and it may be that the day I saw without a square wave in it was just an anomaly. At this point Iím assuming the whole thing has been a false alarm.

« Last Edit: June 16, 2020, 05:08:48 AM by Weaver »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 29861
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Slow line #3 upstream
« Reply #4 on: June 16, 2020, 03:16:21 PM »

Acknowledging the latest information.  :(
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: 8797
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Slow line #3 upstream
« Reply #5 on: June 16, 2020, 10:00:18 PM »

After another day of data collection, it seems we are indeed back to the old pattern - square waves 4dB high. I just unfortunately had a downstep from the target u/s SNRM of 6dB drooped to 5.8 dB then dropped suddenly down to 1.8 dB SNRM. Luckily it seems to withstand such a low u/s SNRM value really quite well with occasional uncorrected CRC errors at a modest level even though there are a huge number of FC errors detected. I could always increase the u/s target to 9dB once again, like it used to be, rather than 6 dB, to get a lot more protection if need be.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 8797
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Slow line #3 upstream
« Reply #6 on: June 19, 2020, 12:21:27 AM »

Stats captured over the recent 24 hours: very much back to the typical picture.

Iím so sorry to be a cracked record but am full of morphine tonight, having had a triple dose of it, and so my memory has gone to pieces. Could we recap/ remind me? What did we say about time units here? Time units per unit time for say (n_FECs/time_interval). Also second question: what is a good/bad count of FECs and CRCs per unit time?



SNRM showing a big drop in upstream interference over the night which has been the typical kind of picture daily for a long time, and is the pattern documented in many previous posts on this topic. Notice the really low minimum upstream SNRM. The upstream target SNRM is only 6 dB these days and the upstream SNRM has drooped slightly since initialisation and then later came the large drop down to ~1.5 dB, for reasons unknown.

SNRM:




Huge numbers of FECs relatively outside the low interference time period. I donít know what the units of Ďper what timeí are that are being used here. Did we work this out in an earlier discussion?

FECs:





Surprisingly low number of resulting uncorrected CRC errors despite the low SNRM and the presumably high number of FECs (not knowing the time units or knowing what is bad and what is ok-ish); but certainly the CRC/FEC ratio is high, so that means something: the error correction is working really hard and yet really well, very effective.

CRCs:





Detailed stats:

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:   8000
Last initialization procedure status:   0
Max:   Upstream rate = 326 Kbps, Downstream rate = 3080 Kbps
Bearer:   0, Upstream rate = 449 Kbps, Downstream rate = 2828 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):    2.9       1.8
Attn(dB):    65.5       41.5
Pwr(dBm):    18.1       12.4

         ADSL2 framing
         Bearer 0
MSGc:      52      14
B:      32      46
M:      4      1
T:      3      1
R:      10      12
S:      1.4677      3.2778
L:      774      144
D:      2      8

         Counters
         Bearer 0
SF:      14364721      783041
SFErr:      34      37
RS:      624865386      2568178
RSCorr:      2716      3241073
RSUnCorr:   177      0

ReXmt:      3566      0
ReXmtCorr:   3276      0
ReXmtUnCorr:   183      0

         Bearer 0
HEC:      197      50
OCD:      5      0
LCD:      5      0
Total Cells:   1540547904      244552178
Data Cells:   54545209      10737126
Drop Cells:   0
Bit Errors:   6394      3795

ES:      47      40
SES:      20      0
UAS:      348      328
AS:      230937

         Bearer 0
INP:      26.00      2.50
INPRein:   0.00      0.00
delay:      8      7
PER:      15.96      16.38
OR:      29.07      9.76
AgR:      2845.05   457.06

Bitswap:   46216/46220      14903/14903

Total time = 4 days 3 hours 8 min 38 sec
FEC:      7387      3244471
CRC:      943      46
ES:      47      40
SES:      20      0
UAS:      348      328
LOS:      2      0
LOF:      17      0
LOM:      0      0
Latest 15 minutes time = 8 min 38 sec
FEC:      19      9153
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:      18      17400
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 = 3 hours 8 min 38 sec
FEC:      242      235837
CRC:      0      0
ES:      0      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Previous 1 day time = 24 hours 0 sec
FEC:      708      1020438
CRC:      0      16
ES:      0      13
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Since Link time = 2 days 16 hours 8 min 55 sec
FEC:      2716      3241073
CRC:      34      37
ES:      24      32
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
« Last Edit: June 19, 2020, 09:27:35 AM by Weaver »
Logged

johnson

  • Reg Member
  • ***
  • Posts: 781
Re: Slow line #3 upstream
« Reply #7 on: June 19, 2020, 03:20:20 AM »

Apologies for the lack of clarity about sampling.

All the time series data is sampled every 30s with no averaging, for the values that just increase (FEC, CRC) its the difference in total since last sample, for SNR its just an instantaneous reading every 30s.

I cant tell without zooming, but does the square step not correlate to 2 resyncs? Thats the only time I see such sudden changes in SNRM.

For reference on "bad" numbers of FEC (i.e fully corrected) this is typical of my line:
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 8797
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Slow line #3 upstream
« Reply #8 on: June 19, 2020, 09:07:21 AM »

@johnson thank you for your help on this, my friend.

No, I donít think they are resyncs, but youíve made me think: how should I check for certain ?

1. Is the answer is in the link uptime value given at the very end of the detailed stats report which says 2 days+ ? If my thinking is correct then that is conclusive.

2. If we are seeing resyncs, then there should be corresponding jumps in the downstream SNRM too. But if the d/s SNRM is very near the target then you wouldnít see any jump, and in this case the d/s SNRM is indeed near the target at all times. - so cant prove anything much from this imho.

3. In the SNRM vs time graph, would be seeing a jump to the upstream SNRM target value too at the supposed resynch times, no? Does that fit in with the picture given above? Where the u/s target SNRM was 6dB. Help clear my thinking here. If we are seeing two resyncs, then the first jump in the above picture is to an u/s SNRM value of 5.5 dB not 6 dB the target (we can perhaps ignore this, Iím not sure though). The second jump however is away from the u/s target SNRM value, and by a huge amount.

4. I get an email and an SMS message (enabled/disabled according to preferences and time of day) from my ISP Andrews and Arnold every time the link drops or goes back up. So I would know. That is I think 100% conclusive too. (I get such a notification even if a link goes Ďbadí in the sense of dropping PPP LCP pings for a few seconds, so it is quite sensitive and it takes a modem about 70-80 secs to bring the link back up during a resynch.) All detected link up / down events are visible in AAís logs relating to the line.

Am I correct in my thinking here?

ó
And a Ďwowí : you experience 100 times (more usually 200 times) more FECs per 30s than I do.

This shows just how much value I get from Johnsonís stats-graphing ZyXEL VMG 1312-B10A modem-internal firmware, which has a web server embedded in the modem and which draws these graphs which are retrieved from the modem by http.
« Last Edit: June 19, 2020, 10:06:35 AM by Weaver »
Logged