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 ... 10 11 [12]

Author Topic: Odd shaped SNR-vs-tone graph - line #4 fault again  (Read 21462 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 #165 on: December 25, 2020, 09:02:15 PM »

Today at 2020-12-25 13:59 my line #4 has failed again !

<snip>

Appointment advised. T107:FAULT - Dis In Network

  :o  :(  :wall:
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 #166 on: December 28, 2020, 07:31:51 PM »

Weirdness. I decided I was going to do a 'prove-it' test for AA so that they could book an engineer asap
tomorrow (Tuesday) Such a test would prove that the problem is in OR's network not chez moi.
My wife is going to be out all day on Tuesday, so won't be able to do any modem-swapping 'prove-it' tests. So tonight we swapped modems 2 and 4's connections to the network. Line 4 was in fact down at the time of the test.
We swapped the modems 2 and 4's connections over and this is the report which we got from the Firebrick :

Link status report from Firebrick after 2-4 swapped
===================================================

Gave error messages: modem 2 is connected to line 4; modem 4 is connected to line 2

then:

*** One of the links is DOWN ***

--
Interface (of FB)    PPP     MTU    Uptime          Status     Phone line circuit ID
‒‒‒‒‒‒‒‒‒‒‒‒—————    ‒‒‒     ‒‒‒    ‒‒‒‒‒—          ‒‒‒‒——     —‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒——
IF-MDM1              PPP1    1500   16d 16:32:01    Active     BBEU20700042 - line 1
IF-MDM2              PPP2    1500       -           Link down (Trying)
IF-MDM3              PPP3    1500       02:55:11    Active     BBEU20700055 - line 3
IF-MDM4              PPP4    1500       00:03:00    Active     BBEU29735631 - line 2

( PPPoE connect message)

--
Firebrick named “tg”, model FB2900, queried at address 81.187.---.---

===================================================

Actually this came from a program that I wrote which processes the output of the Firebrick's PPPoE status function so that it is decorated more elaborately and has various possible error messages.

As expected, the bad line 4, which had been down before, moves to i/f 2 as seen by the Firebrick. So this proves two things: that line 4 is (still) bad (when it is connected to modem 2), and proves that modem 4 is good as it works when it has to drive line 2. So all exactly as expected.

So having achieved what we wanted to achieve, we swapped things back. Then things got weird. Firstly line 4 came
back to life, and not only that but at full speed. Inspecting the SNR-vs-tones graph showed that the bad hollow curve shape of the graph as seen in every fault situation was now absent. So somehow, I fixed the problem, just like the OR engineers who have come out have done even though we don't know how.

So at the moment we possibly have no problem, because I have fixed it. There definitely was one today, from the evidence of the above report and from the evidence of the BT copper line test error report.

I am going to update AA as to what’s going on and ask them to do their own additional line tests to see if the line fault is still out there. I can’t see it on a recent second copper line test, so it’s one of those nightmare intermittent things.
« Last Edit: December 29, 2020, 11:43:26 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 #167 on: December 28, 2020, 10:38:41 PM »

We swapped the modems 2 and 4's connections over . . .

I find that statement to be ambiguous.

First possible interpretation --

Were the two leads, currently connected to modem #2, disconnected at the modem; the two leads, currently connected to modem #4, disconnected at the modem. Then the pair of leads, originally connected to modem #2, were connected to modem #4. Likewise the pair of leads, originally connected to modem #4, were connected to modem #2?

Second possible interpretation --

Were the two leads, currently from modem #2, disconnected at the NTE5 #2 and the small switch LAN port #2, respectively; the two leads, currently from modem #4, disconnected at the NTE5 #4 and the small switch LAN port #4, respectively. Then the two pairs of leads were reconnected #2 pair to #4 and #4 pair to #2.

Further possible interpretations result in  ???  followed by  :swoon:

I am having great trouble in trying to identify the item that appears to be the source of the intermittent fault.  :(
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 #168 on: December 29, 2020, 06:09:09 PM »

I’m not sure exactly what Janet did, because I didn’t see. I think that the modem 2 was reconnected to a different NTE 4 and modem 4 connected to NTE 2. Does that help?

Update AA has taken a brief look at the line but they have not yet replied to my email which is as expected as there will probably be high priority jobs that have come up in the holiday period leaving users with lines down and even no service at all. AA’s tests found no faults.

I reran a copper line test on line 4 tonight and twice it came up with a test failure report
BT Test xDSL Copper Test:Inconclusive More diagnostics required Line test failure. Algorithm unable to continue. Inconclusive More diagnostics required Line test failure. Algorithm unable to continue. DS05:Test Failure - Please Retry - if unsuccessful report problem to OR via a Trouble Report

I have absolutely no idea at all what is going on.

Line 4 itself is now outstandingly fast and very healthy.
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 #169 on: December 29, 2020, 08:02:57 PM »

I’m not sure exactly what Janet did, because I didn’t see. I think that the modem 2 was reconnected to a different NTE 4 and modem 4 connected to NTE 2. Does that help?

Ah, that is logical and is one of the possible interpretations that I did not try to spell out, above.

Quote
I reran a copper line test on line 4 tonight and twice it came up with a test failure report
BT Test xDSL Copper Test:Inconclusive More diagnostics required Line test failure. Algorithm unable to continue. Inconclusive More diagnostics required Line test failure. Algorithm unable to continue. DS05:Test Failure - Please Retry - if unsuccessful report problem to OR via a Trouble Report

All that the above tells us is that the auto-tester was unable to properly perform the test(s).
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 #170 on: December 29, 2020, 09:38:35 PM »

Does anyone know why DS05 test fail occurs?
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 #171 on: December 29, 2020, 09:52:38 PM »

That program I wrote was designed to check for incorrect corrections, such as modem n plugged into line m. This can be discovered because the program has access to a database of expected config information. When a modem pppoe-connects, it gets an announcement which fortunately contains the BBEU ID for the line that it is connected to. There is a table of such expected responses in the site config database, together with a list of PPP i/f identifiers and line index numbers and all of this is cross checked to see that observed reality matches the config database and detailed diagnostic messages are spat out if not. It’s very useful in the case where Janet plugs some cable into the wrong i/f or wrong unit as it then says exactly what is happening and what should be happening instead. The program has a slight delay while it checks all this config expectation info before it then displays a status report of which lines are up and which are down, BBEU IDs and so on as shown in the excerpt in the earlier post.
« Last Edit: December 29, 2020, 11:32:08 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 #172 on: December 29, 2020, 10:03:05 PM »

A very useful utility.  :)
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 #173 on: December 30, 2020, 03:50:00 AM »

There definitely was an OR network problem at one point because of the copper line test test failure report. I’m wondering if I should get rid of this particular modem, demote it to a backup unit.
Logged

tubaman

  • Senior Kitizen
  • ******
  • Posts: 12514
Re: Odd shaped SNR-vs-tone graph - line #4 fault again
« Reply #174 on: December 30, 2020, 07:32:15 AM »

I'm wondering if you have an intermittent modem cable, Do you know if you get a 'Dis in Network' fault if you unplug a modem from its line box? My logic is that as I believe you use a simple RJ11 (or RJ45?) socket as your line termination there is no capacitor and resistor across the line like there would be with the usual NTE box. If you had an open circuit modem cable there would then be nothing for the line test to see at the end of the line,
It's just a thought.
 :)
Logged
BT FTTC 55/10 Huawei Cab - Zyxel VMG8924-B10A

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 #175 on: December 30, 2020, 12:06:54 PM »

The DIS in Network thing has now gone away while the modem is plugged into the NTE5. It’s a brand new modem-NTE5 cable.



AA has told me that they cannot detect any other line faults with their own tests. So for now it seems that I’ve fixed it and we simply do not know how.
« Last Edit: January 02, 2021, 06:17:22 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 #176 on: January 02, 2021, 06:29:21 PM »

Oh no !  :o :wall: Here we go again, but with line #3 this time. Same problem, on 2020-12-31.

Wondering how to proceed. Swapping modems might be an idea as it worked before, but we just don’t know how. Tests do not indicate there’s a problem in the OR network, but I’m not sure that that means there is not a fault in OR-land.

Any help?
« Last Edit: January 02, 2021, 06:35:27 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 #177 on: January 02, 2021, 10:25:18 PM »

I am completely out of suggestions.  :o  :(

In case it might help, I called the associated telephone number of each of the four lines. As discovered previously, the two numbers
  • 014xx xxx275
  • 014xx xxx470
returned NU-tone, whilst the two numbers
  • 014xx xxx473
  • 014xx xxx714
returned ring-tone.
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 #178 on: January 02, 2021, 10:52:48 PM »

I’m thinking that this demolishes the earlier theory about burnout of modem cables or faceplates.

I think that I shall try swapping modem cables; swapping the modem ends of cables from NTE to modem over, at the modem end.
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 #179 on: January 03, 2021, 10:52:52 PM »

I haven’t tried swapping cables yet but the hollow SNRM phenomenon has noticeably improved on its own. It was very cold today compared with the previous couple of days, max 1.5 C.

Here is a graph of the more recent SNRM vs tones taken on 2021-01-04 showing some marked improvement from 2021-01-01 but still quite sickly shape :




And detailed stats:

Code: [Select]
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 328 Kbps, Downstream rate = 3176 Kbps
Bearer: 0, Upstream rate = 402 Kbps, Downstream rate = 2751 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.3 5.9
Attn(dB): 63.5 39.9
Pwr(dBm): 18.3 12.4

ADSL2 framing
Bearer 0
MSGc: 53 12
B: 18 5
M: 8 16
T: 5 8
R: 16 16
S: 1.7387 7.4667
L: 773 120
D: 1 4

Counters
Bearer 0
SF: 1110549 67635
SFErr: 3 0
RS: 40951523 993670
RSCorr: 15389 206
RSUnCorr: 3 0

ReXmt: 8466 0
ReXmtCorr: 8466 0
ReXmtUnCorr: 3 0

Bearer 0
HEC: 1 0
OCD: 0 0
LCD: 0 0
Total Cells: 116209504 17014407
Data Cells: 4044175 784796
Drop Cells: 0
Bit Errors: 280 0

ES: 36013 73
SES: 3706 0
UAS: 12117 9607
AS: 17914

Bearer 0
INP: 29.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 16.02 16.80
OR: 29.44 8.57
AgR: 2768.30 409.82

Bitswap: 5054/5054 232/232

Total time = 6 days 12 hours 55 min 58 sec
FEC: 2024327 5371
CRC: 324338 93
ES: 36013 73
SES: 3706 0
UAS: 12117 9607
LOS: 268 0
LOF: 629 0
LOM: 127 0
Latest 15 minutes time = 10 min 58 sec
FEC: 375 12
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: 509 6
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 = 12 hours 55 min 58 sec
FEC: 15435 730
CRC: 3 1
ES: 3 1
SES: 0 0
UAS: 54 54
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1162 1762
CRC: 2 33
ES: 2 15
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 4 hours 58 min 33 sec
FEC: 15389 206
CRC: 3 0
ES: 3 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
« Last Edit: January 04, 2021, 03:48:53 AM by Weaver »
Logged
Pages: 1 ... 10 11 [12]
 

anything