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

Weaver

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

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

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

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

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

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

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

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

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Slow line #3 upstream
« Reply #9 on: November 07, 2020, 05:02:36 AM »

Just to show exactly what’s happening here, line 3’s upstream bit loading is consistently 2 bits less than that of the other lines.

Here’s line 3 (green is upstream):





and for comparison here’s line 4 below:



The surprising thing is that the upstream attenuation of line 3 at 40.5 dB is very slightly better than that of line 4 at 40.7 dB, so it must be higher noise ingress. Or crosstalk? Am I correct in thinking that crosstalk is less likely at these low frequencies given that this large difference is an upstream-only phenomenon?

Summary:

Live sync rates:
  #1: down 3015 kbps, up 522 kbps
  #2: down 2964 kbps, up 563 kbps
  #3: down 2844 kbps, up 386 kbps
  #4: down 3012 kbps, up 557 kbps

Notice how the downstream bit loading curves differ in shape slightly, and line 3 is slower than line 4 downstream. But take a look at the speeds of line #2 compared with #4; it has the highest upstream rate and yet its downstream speed is slightly lower than line #4, so there’s no general pattern where upstream speed implies downstream speed.



Line #3 upstream bit-loading:

Bearer:   0, Upstream rate = 386 Kbps, Downstream rate = 2844 Kbps

Tone number      Bit Allocation
   0      0
   1      0
   2      0
   3      0
   4      0
   5      0
   6      0
   7      8
   8      9
   9      9
   10      9
   11      9
   12      9
   13      8
   14      8
   15      8
   16      7
   17      6
   18      6
   19      6
   20      5
   21      5
   22      5
   23      4
   24      4
   25      4
   26      4
   27      4
   28      3
   29      3
   30      3
   31      2
   32      0

--   
Line #4 upstream bit-loading:

Bearer:   0, Upstream rate = 557 Kbps, Downstream rate = 3012 Kbps

Tone number      Bit Allocation
   0      0
   1      0
   2      0
   3      0
   4      0
   5      0
   6      0
   7      9
   8      10
   9      11
   10      11
   11      11
   12      11
   13      10
   14      10
   15      10
   16      9
   17      9
   18      9
   19      8
   20      8
   21      8
   22      8
   23      7
   24      7
   25      7
   26      6
   27      6
   28      6
   29      5
   30      5
   31      5
   32      0
« Last Edit: November 07, 2020, 05:26:14 AM by Weaver »
Logged

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5260
    • Thinkbroadband Quality Monitors
Re: Slow line #3 upstream
« Reply #10 on: November 07, 2020, 03:30:39 PM »

You also have less downstream bitloading too, its just not quite as extreme as the upstream difference.
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: Slow line #3 upstream
« Reply #11 on: November 07, 2020, 04:41:20 PM »

Indeed, but my point is there isn’t a consistent link between upstream and downstream - see line 2’s sync speeds, a line whose figures I didn’t include in full.

I’m just wondering why there’s this ~30% loss in upstream speed, which is really mucking up total bonded performance, for some reason.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Slow line #3 upstream
« Reply #12 on: November 07, 2020, 06:36:51 PM »

Could this be a fault in the twist as in twisted-pair ? I’m looking for something that affects this line but not the others. If the twist is crushed, would that be enough to mess up the effectiveness of the degraded twist?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Slow line #3 upstream
« Reply #13 on: November 14, 2020, 02:28:15 PM »

As I may have said already, the upstream SNRM variation on line 3 has now gone away seemingly for good fingers crossed.

The speed of line 3 upstream remains very slow at 389kbps whereas the others are all around 530kbps u/s. What is odd is that as of a week or two ago, the combined upstream speed reported by multiple tests on two different speed testers is consistently about 10-20% worse than before; now it’s around 1.0-1.2 Mbps speed tester reported as opposed to 1.3-1.6 Mbps some while back. At one time a figure of 1.5 was consistently obtained.

Is the slow line 3 messing up TCP? I’m wondering if it would even be worth telling my router not to use line 3 for upstream? [!] `just to de-confuse TCP.
Logged