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] 5 6 ... 12

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

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #45 on: June 09, 2020, 09:22:25 PM »

Remembering A-level maths and anecdotes about picking up Radio 4 on your metal teeth, demodulation of AM was what I was thinking about. Iím not sure of the mathematics of why nonlinearity helps with the kind of errors one sees in DSL specifically though.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 31617
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #46 on: June 09, 2020, 10:19:03 PM »

Keeping things very simple, we have two radio transceivers (of very low power) linked together by a metallic pathway that is only marginally AC balanced. The fact that xDSL actually works is just sub-miraculous. Inset imbalances, series or shunt resistances, series or shunt capacitances, couplings from other circuits & non-linear elements into that radio-frequency transmission line and errors have to be ever present.
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: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #47 on: July 11, 2020, 01:11:37 AM »

Itís back. Line 4 is showing a drop in downstream speed after a resync and the line 4 SNRM vs freq graph shows the characteristic dent / hollow between tones 40-80 approx.



Live sync rates:
  #1: down 2701 kbps, up 509 kbps
  #2: down 2762 kbps, up 512 kbps
  #3: down 2883 kbps, up 376 kbps
  #4: down 2354 kbps, up 522 kbps

Line 4 downstream was the same as the other three until the resync.

AA reported the following:
Quote
Tx rate (adjusted) 2486358 to 2066526 (rx 522000)

- and I think those numbers are IP PDU rates, not sync rates; ĎTxí means downstream.
« Last Edit: July 11, 2020, 01:20:10 AM by Weaver »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 31617
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #48 on: July 11, 2020, 02:17:20 PM »

Yet another mysterious event.  :(
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: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #49 on: July 11, 2020, 07:16:08 PM »

So either the (fairly) recent BT engineer didnít fully fix the fault (in a lasting way), although the result was an excellent outcome, or otherwise there was more than one problem and the other latent fault was lurking, waiting to appear. Andrews and Arnold took a look at it yesterday. I would say that it isnít slow enough yet for them to be able to justify getting an engineer out. It may deteriorate over time, as before. But nearly 420kbps is quite a big drop, a damned nuisance.

Is it possible for faults to get fixed and then become unfixed, just like that?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 31617
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #50 on: July 11, 2020, 07:57:50 PM »

Is it possible for faults to get fixed and then become unfixed, just like that?

I guess that anything is possible but without knowing exactly what was fixed, last time, it is really difficult to say.
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.

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 32584
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #51 on: July 12, 2020, 10:14:30 AM »

it may be crosstalk.   
 
Prior to vdsl and the availability of QLN graphs then a nice smooth dish shape on the SNR was about the only way to identify crosstalk.   On the SNR/tone graph & bitload graphs, crosstalk causes what I've always called a "shallow bowl" effect.   On QLN graph the curve shape is reversed and looks like a seagull wing.
 
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

  • Addicted Kitizen
  • *****
  • Posts: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #52 on: July 12, 2020, 11:54:23 AM »

Thanks Lesley, I didnít know that.

A question for you all though. The thing is though, our BT man fixed something successfully last time, so, as far as I can see, strictly speaking it would have to be a susceptibility to crosstalk thing, no? Otherwise it wouldnít be fixable and also we wouldnít have an explanation as to why other lines are not getting it.

People talk about Ďbalanceí; is that right? Iím not exactly sure what that means as I donít have an electronics degree, just a failed theoretical physics student. Iím assuming it means an undesirable dissimilarity between the two legs of a copper pair so that common mode rejection (which I believe is taking the difference between the voltages at the rx end) doesnít work properly as the two sides arenít equal, so their subtraction doesnít cause cancellation of common noise. Is that right? Either that or else a failure of adequate twist in a twisted pair which amounts to the same kind of noise susceptibility problem.

Itís a damned nuisance, a 15% drop roughly, something like that, but not enough to count as a FTB

Do we have any guesses about why such a thing would suddenly start up ? - either the previous fault having been all good for a time, since it was last fixed, or alternatively this is a second separate fault, independent of the first one, which remains fixed.



Current detailed stats for modem 4. Pretty pictures below:

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:   8000
Last initialization procedure status:   0
Max:   Upstream rate = 439 Kbps, Downstream rate = 2540 Kbps
Bearer:   0, Upstream rate = 522 Kbps, Downstream rate = 2354 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.0       5.9
Attn(dB):    65.5       41.7
Pwr(dBm):    18.2       12.4

         ADSL2 framing
         Bearer 0
MSGc:      51      11
B:      27      62
M:      8      1
T:      3      1
R:      16      12
S:      2.9953      3.7975
L:      641      158
D:      1      8

         Counters
         Bearer 0
SF:      15597186      67600
SFErr:      11734      57
RS:      333389855      4151784
RSCorr:      1364442      118752
RSUnCorr:   12127      0

ReXmt:      2676494      0
ReXmtCorr:   2675741      0
ReXmtUnCorr:   12953      0

         Bearer 0
HEC:      13724      64
OCD:      0      0
LCD:      0      0
Total Cells:   1392268593      311379799
Data Cells:   60057824      16553586
Drop Cells:   0
Bit Errors:   731900      9624

ES:      11744      262
SES:      42      0
UAS:      199      157
AS:      252751

         Bearer 0
INP:      26.00      2.00
INPRein:   0.00      0.00
delay:      8      8
PER:      16.00      16.13
OR:      28.48      8.42
AgR:      2373.11   528.81

Bitswap:   54625/54626      305/305

Total time = 15 days 14 hours 19 min 10 sec
FEC:      1440420      126580
CRC:      12299      66
ES:      11744      262
SES:      42      0
UAS:      199      157
LOS:      1      0
LOF:      7      0
LOM:      33      0
Latest 15 minutes time = 4 min 10 sec
FEC:      1349      98
CRC:      6      0
ES:      5      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:      5088      654
CRC:      36      5
ES:      35      2
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Latest 1 day time = 14 hours 19 min 10 sec
FEC:      305710      21339
CRC:      2843      7
ES:      2684      3
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Previous 1 day time = 24 hours 0 sec
FEC:      473605      33180
CRC:      4220      21
ES:      3996      14
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Since Link time = 2 days 22 hours 12 min 29 sec
FEC:      1364442      118752
CRC:      11734      57
ES:      11099      41
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0




Current SNR vs tones for modem 4:





Bits per bin for modem 4:



« Last Edit: July 12, 2020, 04:25:15 PM by Weaver »
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #53 on: July 12, 2020, 04:22:01 PM »

There is more weirdness going on too with modem 4: the numbers of FEC errors (corrected error events iirc?) and CRC errors (uncorrected errors) are radically different something like 10 times higher number of FEC errors, very roughly, if I can read the graphs correctly. Just look at the y axis scale and reel in amazement. It means that modem 4 is working really really hard, successfully correcting a lot of errors, whereas modem 3 is having an easier time of it. Pictures follow, comparing modems 4 and 3.

Modem 4 FEC event rates over time :



I think we said this was events per unit time where the unit of time was 30 s ? Or was it one minute ? I think the former and I think our friend kitizen Johnson told me a little while ago, but Iíve managed to forget again thanks to all the NHSís fine products. (Sorry Theo for being so dim.  :( )



This is modem 3 FEC count. See modem 4 had, what, 100-200 events / unit time rather than the 3-15 events we have for modem 3 here.





Modem 4 CRC event count:





Modem 3 CRC count. Pretty much zero errors most of the time; compare this with the picture of several CRC errors every time period shown with modem 4 previously.

« Last Edit: July 12, 2020, 04:25:35 PM by Weaver »
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 3269
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #54 on: July 12, 2020, 06:01:24 PM »

Can you post the "info --stats" output of modem 3?
You've already posted modem 4 in the previous post.

There's definitely a noticeable difference between the 2 lines, particularly the rate of CRC
Logged
BT FTTP 160/30 - BQM - speed test

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #55 on: July 13, 2020, 01:51:00 AM »

Hereís modem #3ís detailed stats for comparison with modem #34 as you asked.

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:   8000
Last initialization procedure status:   0
Max:   Upstream rate = 305 Kbps, Downstream rate = 3096 Kbps
Bearer:   0, Upstream rate = 376 Kbps, Downstream rate = 2883 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.7       6.3
Attn(dB):    65.5       41.3
Pwr(dBm):    18.2       12.4

         ADSL2 framing
         Bearer 0
MSGc:      52      11
B:      33      5
M:      4      16
T:      3      8
R:      10      14
S:      1.4841      8.0000
L:      787      110
D:      2      4

         Counters
         Bearer 0
SF:      20005969      375886
SFErr:      14      18
RS:      870259670      3664793
RSCorr:      23338      7194
RSUnCorr:   38      0

ReXmt:      2044      0
ReXmtCorr:   1927      0
ReXmtUnCorr:   41      0

         Bearer 0
HEC:      38      21
OCD:      0      0
LCD:      0      0
Total Cells:   2211224491      288296203
Data Cells:   94360009      14883067
Drop Cells:   0
Bit Errors:   2040      2344

ES:      134      64
SES:      0      0
UAS:      108      108
AS:      325158

         Bearer 0
INP:      26.00      2.00
INPRein:   0.00      0.00
delay:      8      8
PER:      16.13      17.00
OR:      28.74      8.00
AgR:      2899.49   382.50

Bitswap:   87169/87182      4126/4126

Total time = 16 days 18 hours 53 min 34 sec
FEC:      46536      40526
CRC:      211      72
ES:      134      64
SES:      0      0
UAS:      108      108
LOS:      0      0
LOF:      0      0
LOM:      0      0
Latest 15 minutes time = 8 min 34 sec
FEC:      30      1
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:      29      7
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 = 18 hours 53 min 34 sec
FEC:      3218      887
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:      8376      2020
CRC:      14      8
ES:      2      8
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Since Link time = 3 days 18 hours 19 min 17 sec
FEC:      23338      7194
CRC:      14      18
ES:      2      17
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
« Last Edit: July 13, 2020, 01:55:00 AM by Weaver »
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #56 on: July 27, 2020, 06:30:52 PM »

It has gone incredibly bad again. Saturday morning everything went to hell. Have emailed AA who unfortunately want me to swap modems over, which I canít do on my own of course. Have some gruesome screenshots from the modems via johnson easy stats-graphing. To tired to write further or post them up just now.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #57 on: July 28, 2020, 11:25:23 AM »

Stupidly, I didnít save any stats data just now and currently I canít get any for your delectation. Janet has just swapped the modems 3 and 4 over at AAís request, and now modem 3 - into line 4 - is down (line 4 is, that is). So just now I canít ask the modem what the stats are as weíre not in sync in the showtime state. I will grab some for you when the line decides to come back up.

Scenes of horror from the last couple of days follow:



Look at this nightmare now - SNRM versus tones / frequency :





SNRM - Upstream is in green, downstream in blue:






FEC errors (corrected):





CRC errors (uncorrected):





« Last Edit: July 28, 2020, 11:42:04 AM by Weaver »
Logged

Alex Atkin UK

  • Kitizen
  • ****
  • Posts: 1882
    • My Broadband History
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #58 on: July 28, 2020, 05:34:22 PM »

Yikes.  Its so weird that such extreme interference would happen to just one line.
Logged
INTAKE (ECI) Zen: Home Hub 5A OpenWrt Plusnet: VMG-3925-B10B Three 4G: Hauwei B535-232 Router: pfSense (i5-7200U) WiFi: Ubiquiti nanoHD
Thinkbroadband Quality Monitors

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9485
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #59 on: July 28, 2020, 08:03:40 PM »

Iím thinking that the evidence of the SNRM-vs-tones graph with the hollow bowl where the hilltop should be means thereís an enhanced pickup of rf interference in those frequencies. Non linearity, poor balance I donít know. What do our sages think?

AA is sending an engineer out tomorrow.

Logged
Pages: 1 2 3 [4] 5 6 ... 12