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 4 ... 12

Author Topic: Odd shaped SNR-vs-tone graph - line #4 fault again  (Read 21455 times)

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #15 on: April 14, 2020, 09:35:04 PM »

So a bad joint has been fixed. Exactly where that joint is located . . .  :shrug2:

But all is now well, once again.  :)
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: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #16 on: April 15, 2020, 10:31:44 PM »

The SNRM-vs-tones graph is still approx. unchanged - still has that depression in the top of it. The downstream sync rate is still quite poor by the usual standard of things. I’m not sure what to do about it:


xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:   8000
Last initialization procedure status:   0
Max:   Upstream rate = 436 Kbps, Downstream rate = 2828 Kbps
Bearer:   0, Upstream rate = 525 Kbps, Downstream rate = 2578 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):    3.1       5.7
Attn(dB):    64.0       40.7
Pwr(dBm):    18.3       12.4

         ADSL2 framing
         Bearer 0
MSGc:      54      11
B:      28      62
M:      8      1
T:      3      1
R:      16      12
S:      2.8343      3.7736
L:      700      159
D:      1      8

         Counters
         Bearer 0
SF:      367531      367760
SFErr:      25      0
RS:      8269456      1955956
RSCorr:      16479      1951
RSUnCorr:   26      0

ReXmt:      17649      0
ReXmtCorr:   17648      0
ReXmtUnCorr:   31      0

         Bearer 0
HEC:      29      0
OCD:      0      0
LCD:      0      0
Total Cells:   35782273      7306913
Data Cells:   858511      170651
Drop Cells:   0
Bit Errors:   1104      0

ES:      100191      59
SES:      74      3
UAS:      4209      4136
AS:      5897

         Bearer 0
INP:      28.00      2.00
INPRein:   0.00      0.00
delay:      8      8
PER:      15.94      16.03
OR:      30.10      8.48
AgR:      2597.91   532.16

Bitswap:   431/431      12/12

Total time = 5 days 38 sec
FEC:      7699356      101286
CRC:      209426      134
ES:      100191      59
SES:      74      3
UAS:      4209      4136
LOS:      8      2
LOF:      62      2
LOM:      0      0
Latest 15 minutes time = 38 sec
FEC:      98      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:      2580      156
CRC:      4      0
ES:      4      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Latest 1 day time = 38 sec
FEC:      98      0
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:      94368      22784
CRC:      3002      111
ES:      194      42
SES:      63      3
UAS:      4096      4034
LOS:      7      2
LOF:      53      2
LOM:      0      0
Since Link time = 1 hours 38 min 17 sec
FEC:      16479      1951
CRC:      25      0
ES:      25      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

« Last Edit: April 15, 2020, 10:39:02 PM by Weaver »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #17 on: April 15, 2020, 11:03:45 PM »

I complained to AA about the slight downstream sync speed reduction : 2.5Mbps down from 2.8Mbps. Did a copper line test, which failed to complete, the test algorithm failed three times and finally cam back with a result of ‘line test OK’. Seems very fishy, it failing repeatedly like that - just as it did going way back to before the repair.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #18 on: April 15, 2020, 11:46:49 PM »

If you would perform a harvest of the data, for line #4 only, and then send a copy of that data to the usual e-mail address, I'll create the four snapshot graphs locally.
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.

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #19 on: April 16, 2020, 02:01:55 AM »

I have now taken a look at the data and created the usual four snapshot plots.

The "sag", seen in both the Bit Loading and the SNR plots, is puzzling. It's not like any perturbations usually seen when circuits are degraded. See the montage, attached below.

Any opinions, please?  :-\
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: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #20 on: April 17, 2020, 02:10:56 PM »

After Openreach turned out to make repairs on my line 4, the downstream sync rate dropped by between 11-17% to 2.51 Mbps d/s sync from a former typical 2.8-3.0 Mbps sync rate. The upstream is unchanged. The downstream sync rate has been around 2.8-3.1Mbps consistently for the last four years, and was at 3.0-3.1Mbps this winter. Is there anything I can do to get things back to the way they were?

I complained to AA and got a very unhelpful reply which appeared as if they might be saying I didn’t know what I was talking about. Seeing as they have a published no "bullsh*t" policy, I could have a go at them on that basis, but feeling charitable and working in “assume good faith”, a fairly rare thing for me, I am proceeding on the basis that this has been a misunderstanding based on definitions of rates; I quoted synch rates to them, while they could have been thinking about their egress rates ie rate limiters’ rates which are = sync rate * 87.91% approx iirc. Or they could have been thinking about IP + TCP SDU (ie TCP payload) rates at 84.2 - 86.1% of synch rate. Those differences are large enough to cover the gaps between differently defined sets of rates and could make it just miscommunication. Despite feeling miffed at the possibility I had been brushed off I noticed that AA tech support have set up regular capture of the synch rate on a repeating timer, every hour a server remotely queries my modem via BT. That’s good because then they will be seeing synch rates not one of the other measures. And it means they are doing something.

Just recently I have watched the SNRM very carefully, waiting until such a time as the downstream synch rate may happen to go above 3.15 Mbps. Now 3Mbps is the downstream SNRM target, and a +0.15 Mbps additional gap seems to be sufficient such that if you choose a moment when the synch rate is at about that level and then force a resynch then you will then end up with a higher downstream synch rate. I’ve mange to push it up by small amounts three times by this feeble method, in total from about 2.51 to 2.667 Mbps d/s synch. It’s not much but it is a sizeable chunk of what I lost now regained (went down from a former 2.8-3.1 Mbps downstream sync rate to 2.51 Mbps at lowest). I managed to creep up in steps: from 2.51 Mbps to 2.564 to 2.61 to 2.667 Mbps. However I feel that there is no reason to assume that this method will get me very far long term though, perhaps I’m wrong. I assume that the further up I manage to crawl, the more infrequent the opportunities may become, also if I were to get things wrong one time then I think I could then easily lose the entire total of such feeble gains, and possibly even more, in one single large drop. Anyway, I don’t see that there’s anything sustainable about these tactics.

There’s also the question of the strange shape of my SNRM-vs-tones graph nowadays. As mentioned earlier, Line 4 has a weird dent or depression or ‘sag’, as Burakkucat said, in the top of its graph as mentioned earlier in the thread, for reasons unknown.

Does this odd-looking feature have anything to do with my downstream sync rate loss problem?

Since it’s a depression in such a graph then this could either mean (i) more noise at the middle frequencies or (ii) less signal at those frequencies. Usually without additional information it’s impossible to tell which of the two it is because all you have in SNR is a ratio derived from two quantities. In this case though the second option seems totally unbelievable; I can’t see how there could be reduced signal levels only in middle frequencies, lower than the higher signal levels at frequencies both below and above. So we must be left with the first option: higher noise in a selective frequency band, which is fairly wide, from > tone 40 to < tone 80 on the SNRM-vs-tones graph, but on a bit loading graph the depression is from tone 48 - 78 inclusive and is 1 bit deep. So that’s (78 - 48+1)=31 bits per symbol period lost ie a rate reduction of 31 * 1 * 4k = 124 kbps. So if that were filled in it would mean 2.667 + 0.120 = 2.791, and if the top were rounded off into a more realistic-looking hump, following the general SNRM-vs-tones curve rather than being sliced flat, that might mean another ~ 60kbps, which would take us all the way back to roughly where we should be. So the SNRM curve depression does fit in with the theory of a noise source - it’s about the right size so that it fits. Another way in which this fits is that the dent/sag is in the downstream tones only and only the downstream synch rate is affected; the upstream rate is not.

Another question: looking at the stats regularly, I noticed my downstream ‘attainable rate’ has gone up too when the synch rate has gone up. Could someone remind me what this is all about as I’ve forgotten completely? Does it mean I have a chance of getting to that rate if I do <something>? - no idea what though.

Right now the d/s stable rate is 2908 kbps @3.1 dB SNRM - and current sync rate 2667 kbps.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #21 on: April 17, 2020, 03:34:20 PM »

There’s also the question of the strange shape of my SNRM-vs-tones graph nowadays. As mentioned earlier, Line 4 has a weird dent or depression or ‘sag’, as Burakkucat said, in the top of its graph as mentioned earlier in the thread, for reasons unknown.

Does this odd-looking feature have anything to do with my downstream sync rate loss problem?

Yes, I believe it does.

Quote
Since it’s a depression in such a graph then this could either mean (i) more noise at the middle frequencies or (ii) less signal at those frequencies. Usually without additional information it’s impossible to tell which of the two it is because all you have in SNR is a ratio derived from two quantities.

Hence my request for the opinions of others in my post, above.
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: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #22 on: April 17, 2020, 04:02:13 PM »

Agreed. I think we need the collective wisdom of the high council.

Thinking more about a realistic shape for a hump, taking two 1-bit thick horizontal slices through the top of such an imagined curve, we get the total area in bits*tones = ( 80 + 1 − 38 ) × 1 + ( 79 + 1 − 51) × 1 = 72 bits so we have 72 * 4 kbps= 288 kbps and the lowest sync rate 2510 kbps + 288 k brings us right back up to where we should be in full. To get to our former 3.0 - 3.1 Mbps we might need some cold weather to get better conductivity and reduce the attenuation/loop loss. Maybe those latter figures, which I often achieve, are winter-only though.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #23 on: April 17, 2020, 05:22:48 PM »

This is what the historical SNRM vs time graph (not tones, ie frequency distribution) looks like now:



« Last Edit: April 17, 2020, 05:37:56 PM by Weaver »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #24 on: April 17, 2020, 05:28:07 PM »

I trust your arithmetic and so accept that the "sag" does account for the "missing" synchronisation speed.  :)
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: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #25 on: April 17, 2020, 05:38:34 PM »

And here FYI is the current bit loading ie. bits-per-bin assignments graph:



A less optimistic assumption about area still gives something like bits * tones = 30 * 1 * 2 = 60 which gives A rate increase of 60 * 4 kbps = 240 kbps which is still good enough, so the exact details don’t seem to matter too much.
« Last Edit: April 17, 2020, 05:46:03 PM by Weaver »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #26 on: April 17, 2020, 05:49:45 PM »

I wonder where the extra noise came from; be it crosstalk or whatever but it’s band-limited that’s certain so we can multiply those bin numbers by 4.3125 kbps (iirc) to get the frequency range. And the usual mysteries: why this modem and not the others, and why now?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #27 on: April 17, 2020, 10:07:33 PM »

I just noticed that in the space of a few hours, now the sun has gone down (it’s now 21:05 UTC) the bit loading has changed a little. Compare to the preceding bit loading graph. The top of the graph looks different, less flat. Unfortunately I stupidly cropped off the legend at the bottom below the horizontal axis, so this should read "Tone". So here’s bit-loading II:



« Last Edit: April 17, 2020, 10:38:40 PM by Weaver »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #28 on: April 17, 2020, 10:30:29 PM »

The very latest SNRM-vs-tones graph looks slightly different from that posted at the start of this thread too; if my eyes do not deceive me, the top portion of it is all about 1dB lower. So it looks as if either the attenuation has increased - which doesn’t seem likely at all - or the noise has increased (much more likely) because it’s now night time (21:20 UTC).

So here’s the second SNRM-vs-tones graph:

« Last Edit: April 17, 2020, 10:34:18 PM by Weaver »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #29 on: April 18, 2020, 09:59:47 AM »

I have no idea why you have that shape, but I can tell you in the multiple years I had ADSL, I had multiple of those on my line and were there for the full duration.

The noise bursts I used to get during office hours were shaped like that as well but much more severe.  They came and went in an instant.
Logged
Pages: 1 [2] 3 4 ... 12
 

anything