Why is a "degraded" line not a faulty line?

Anotherone · ‎31-08-2007

Isn't that just typical! Oh well, looks like you are still lumbered until a new visit is arranged

hadden · ‎27-07-2007

Next visit book for tomorrow, 11/01/2013 between 08:00-13:00.
The note to the engineer includes every bit of wire between my socket and the exchange.

hadden · ‎27-07-2007

"Boost" visit has taken place today.
The engineer arrived about 10am and left about 5pm.
After listening to my verbal summary of previous actions and reading PN notes he tested at the master socket and could see significant CRC errors (about 15 over 5 minute test). He observed that the errors were not intermittent.
He then went away to test at the cabinet.
[On previous visits, at this stage, the engineer would leave a piece of equipment plugged into my master socket to allow testing to be carried out from wherever back to my master socket, but this engineer left my router/phone connected so that I could use it intermittently between his tests.]
He returned to report that the quality of the insulation of the wiring within the cabinet didn't look as good as it could. So he had tidied up the insulation and bridged a pair of wires past most of the other pairs where they were bundled in the cabinet. He also commented that he detected a low number of errors on the e-side from the cabinet.
Carrying out tests again at my master socket he detected a similar number of errors to his previous testing. He repeated the tests directly on the drop cable, with the NTE5 removed.
It was difficult to tell if there was any improvement over a shot time. He then consulted Chris at Plusnet (sorry about interrupting your lunch Chris). He was "encouraged" to continue investigating, therefore he left to check out the e-side.
He switched a pair on the e-side and returned to the cabinet to test. He said that he ran his tests 3 times and it had reported no errors. I expect this was the same test he ran at my master socket which takes about 5 minutes. He then returned and ran the test at my master socket.
Again, there was no significant improvement in errors.
It was now about 15:30, so he headed out to examine the distribution point at the top of the pole, before it got dark. He ran his test at that point and was detecting similar errors to what he detected at the master socket. However his records indicated that there were no free d-side pairs, so was not able to try switching a d-side pair. He was aware that there had been a previous d-side swap on a previous visit, so I think he may have consulted someone to ask about that.
We discussed what he had found and his deduction was pointing at an outstanding d-side problem.
At this stage the engineer contacted Chris at Plusnet again to discus the situation.
While there was still an impression of being efficient about taking action based upon observations, my impression of this visit was that the engineer was able to follow through on a sequence of checks and "fixes" without the distraction of fitting the job to a fixed time-scale and/or number of actions. Although this visit still hasn't resolved the issue, I think this type of visit covered more a similar scope to several of the previous visits, possibly more efficiently.
I am grateful to Chris at Plusnet for pushing for this Boost visit.
While the issue of the errors probably resulting from the d-side wiring is to be followed up, I will watch how the connection performs over the weekend.
Current Router Stats:


DOWNSTREAM (Rx)
Noise Margin:     5.8   dB
Connection Rate:  4803  Kbps
Line Attenuation: 53.0  dB
Power:            0.0   dBm
Max Rate:         5596  Kbps
 
SuperFrames:      765506
SF (CRC) Errors:  543
Reed Solomon:     0
RS Corrected:     0
RS Un-Corrected:  0
HEC:              436
Errored Seconds:  423
Severe ES:        0
Interleave Depth: 1
Bitswaps:         3134
UPSTREAM (Tx)
Noise Margin:     4.1   dB
Connection Rate:  979   Kbps
Line Attenuation: 33.0  dB
Power:            12.9  dBm
Max Rate:         968   Kbps
 
SuperFrames:      710723
SF (CRC) Errors:  65
Reed Solomon:     0
RS Corrected:     0
RS Un-Corrected:  0
HEC:              51
Errored Seconds:  45
Severe ES:        0
Interleave Depth: 1
Bitswaps:         251
TOTALS
Total Uptimes (From SF counts):
 WAN:   0 days, 03:36:53
 LAN:   0 days, 00:00:00
 
CRC:            543             0
ES:             423             45
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0

and the current graphs for Noise Margin and Bits/Tone

Anotherone · ‎31-08-2007

So things at least look good at the cabinet with no errors now. I don't suppose he said what sort of sync speed he was getting at the cab?
The 'D' side certainly seems to be the major problem at the moment and judging by what a previous engineer said about corrosion on the connections at the top of the pole and particularly as there are no spare pairs, it would seem as though the 'D' side cable ought to be replaced. No noticeable change in the bits/tone allocations as a result of the 'E' side swap though

Pettitto · ‎26-11-2011

BT Openreach have retained this issue which is important. I'm happy that an issue has been identified on a particular part of the network as we can now spend some more time identifying where the fault is on the network. As I stated previously, I will keep working until we resolve this issue.
I'm having a day off as its my birthday today!

I'll be back in touch on Monday

hadden · ‎27-07-2007

Many happy returns!
It may not seem like much, but I notice that there are a few tones around 931KHz that are staying around now.
These are the stats after being connected for 16h 45m:

DOWNSTREAM (Rx)
Noise Margin:     6.4   dB
Connection Rate:  4803  Kbps
Line Attenuation: 53.0  dB
Power:            0.0   dBm
Max Rate:         5764  Kbps
 
SuperFrames:      3544355
SF (CRC) Errors:  1466
Reed Solomon:     0
RS Corrected:     0
RS Un-Corrected:  0
HEC:              1162
Errored Seconds:  1205
Severe ES:        0
Interleave Depth: 1
Bitswaps:         13463
UPSTREAM (Tx)
Noise Margin:     6.0   dB
Connection Rate:  979   Kbps
Line Attenuation: 33.0  dB
Power:            12.9  dBm
Max Rate:         976   Kbps
 
SuperFrames:      412697
SF (CRC) Errors:  121
Reed Solomon:     0
RS Corrected:     0
RS Un-Corrected:  0
HEC:              79
Errored Seconds:  87
Severe ES:        0
Interleave Depth: 1
Bitswaps:         1031

Total Uptimes (From SF counts):
 WAN:   0 days, 16:45:16
 LAN:   0 days, 00:00:00

So I did a disconnect/reconnect and was reconnected at 5027kbps downstream.
This was ADSL2 so, as an experiment, I forced a reconnect at ADSL1 and was reconnected at 5120kbps.
I then forced a reconnect at ADSL2+ and was reconnected at 5195 kbps.
I then did a final reconnect and allowed the connection to return to ADSL2 with a downstream of 5039kbps.

Anotherone · ‎31-08-2007

I'd have stopped at the ADSL2+ stage as that had given you the slightly better sync speed, unless the error rate was significantly higher.
The modem/router may have been doing a lot of bit swapping after dark, but it might have had a few more tones to play with.
Let's hope it a least remains stable with fewer errors than before.

hadden · ‎27-07-2007

I followed up your suggestion by trying a few days on ADSL2 then a few days on ADSL2+, to compare errors, etc.
Below are the resulting router stats at the end of each test time. The two most significant difference appeared to be the downstream attenuation and sync speed.
(I fitted this in test just before a follow up Boost visit yesterday to look at the d-side, which I'll post about next.)

	ADSL2	ADSL2+
Total Uptimes (From SF counts):	3 days, 06:35:49	2 days, 22:21:31


DOWNSTREAM (Rx)
Noise Margin:	5.9 dB	5.9 dB
Connection Rate:	5039 Kbps	5143 Kbps
Line Attenuation:	52.5 dB	56.0 dB
Power:	0.0 dBm	0.0 dBm
Max Rate:	5784 Kbps	5884 Kbps

SuperFrames:	16644100	14899475
SF (CRC) Errors:	11508	11495
Reed Solomon:	0	0
RS Corrected:	0	0
RS Un-Corrected:	0	0
HEC:	9632	9675
Errored Seconds:	8636	8945
Severe ES:	13	11

Interleave Depth:	1	1
Bitswaps:	49663	45393


UPSTREAM (Tx)
Noise Margin:	4.6 dB	5.5 dB
Connection Rate:	995 Kbps	967 Kbps
Line Attenuation:	32.9 dB	32.9 dB
Power:	12.8 dBm	12.9 dBm
Max Rate:	940 Kbps	964 Kbps

SuperFrames:	66469	345495
SF (CRC) Errors:	1344	692
Reed Solomon:	0	0
RS Corrected:	0	0
RS Un-Corrected:	0	0
HEC:	1027	403
Errored Seconds:	852	524
Severe ES:	4	0

Interleave Depth:	1	1
Bitswaps:	14037	9075

hadden · ‎27-07-2007

OK, another Boost visit to follow up the d-side diagnosis form the previous Boost visit...
The visit was booked for 09/01/13 13:00-18:00 but the engineer was a no show and I reported that to Plusnet.
However I was out on 10/01/13 and came home to find an Openreach dropcard through my letterbox from an engineer who have visited at about 2pm. I also had a missed call from an unknown mobile at about the same time. This may have been intended to make up for the missed visit but, if I had known, I could have arranged for someone to be in.
So it was rearranged for 18/01/1308:00 to 13:00.
The engineer arrived shortly after 8am and listened to my description of the history. He had also read previous job notes.
He spent some time running tests at my master socket. He could see the CRC errors, but ran tests to see if there were clues in the physical tests.
He observed that the battery voltage on the B wire was occasionally a little high, but not enough to trigger a test fail on it's own.
He also found an intermittent fail due to the difference in resistance of the A and B wires. The resistance difference was up to about 18 ohm.
So, as the source of the CRC errors was unknown, he planned to check the wires and joints aiming to improve these two parameters and see if that reduced the errors.
He aimed to start at the cabinet and then the joints between there and my house.
On return he reported that two of the manholes had been too frozen to open. However, his tests at the cabinet had reported significant e-side errors. Although he was aware of the previous work that should have eliminated the e-side as a source of problems, he felt that he had to investigate the e-side.
He had a discussion with a colleague about the situation. The colleague was familiar with the e-side cables here and advised that I was not on the best cable. So the engineer swap my pair for a pair in what was reckoned the be the "best" cable.
This swap resulted in the downtream attenuation dropping from 55.5dB to 51dB. This was an improvement that had been requested several engineers ago, as suggested by Anotherone.
More testing was carried out at my master socket, there was no significant improvement in CRC errors or sync speed (approx 5100kbps).
My router was configured to connect with ADSL2+, so I removed the restriction and allowed it to connect with ADSL2. The attenuation dropped to 47.5dB which is where it was on ADSL2 before the first engineer carried out the first e-side swap.
As there were still significant errors, the engineer went to the exchange to investigate and consult BT Wholesale. He advised me, from the exchange, that he wanted to try increasing the Noise Margin to 9dB. I agreed for testing but was not happy about it being permanent as it would have a detrimental effect on the throughput and my line had been happy on 6dB before the line degradation that is the subject of my ticket.
At this stage my sync speed was 4983kbps.
So, BT Wholesale tried setting a 9dB Noise Margin and they found that the number of CRC errors increased. They then tried a Noise Margin of 12dB and the number of CRC errors increased again. This is the opposite of what was expected, so they returned the Noise margin to 6dB.
On my router I could see the Noise Margin increasing and saw my sync speed drop at each stage first to 4470kbps and then just under 3968kbps.
When the Noise Margin returned to 6dB my sync speed increased to 5177kbps. At the same time interleaving had also been enabled.
After 10 minutes, these were the router stats:

Noise Margin:     6.3   dB
Connection Rate:  5177  Kbps
Line Attenuation: 50.5  dB
Power:            0.0   dBm
Max Rate:         6288  Kbps
 
SuperFrames:      35482
SF (CRC) Errors:  0
Reed Solomon:     2306372
RS Corrected:     730
RS Un-Corrected:  0
HEC:              0
Errored Seconds:  18
Severe ES:        18
Interleave Depth: 32
Bitswaps:         67

Noise Margin:     5.6   dB
Connection Rate:  961   Kbps
Line Attenuation: 27.7  dB
Power:            13.0  dBm
Max Rate:         960   Kbps
 
SuperFrames:      32159
SF (CRC) Errors:  2
Reed Solomon:     385368
RS Corrected:     63
RS Un-Corrected:  0
HEC:              2
Errored Seconds:  17
Severe ES:        0
Interleave Depth: 4
Bitswaps:         8

Total Uptimes (From SF counts):
 WAN:   0 days, 00:10:03

So, there were no CRC errors over 10 minutes. Ignore the Errored Seconds as this does not seem to reset with a re-connect. I have to remember to zero it manually (and I forgot on this occasion). However the attenuation had increased again to 50.5dB.
The engineer discussed the situation with me and we agreed to leave things for a few days to see how table the situation was. He would also then try, dependant upon the weather, if he could open the frozen manhole covers and take a look inside for a junction.
I thought that was the end of the matter but, shortly afterwards, I received a message that he was going to take another look at the cabinet. The result was that the attenuation dropped back to 47.5dB.
The engineer spoke with Chris at Plusnet several times during the day and it was also good that the engineer was quite open with me about the logic of his approach to the problem. He spent a full day on the situation and followed several leads.
I saved the router stats and Bits/Tone graphs at many stages through the day, but here are the Router Stats at 20:16 - 3h 40m after the engineer finished. I've also attached a graph below with Bits/Tone saved at the same time.

Noise Margin:     5.4   dB
Connection Rate:  5078  Kbps
Line Attenuation: 47.5  dB
Power:            0.0   dBm
Max Rate:         5892  Kbps
 
SuperFrames:      779943
SF (CRC) Errors:  71
Reed Solomon:     50696320
RS Corrected:     27567
RS Un-Corrected:  844
HEC:              63
Errored Seconds:  39
Severe ES:        0
Interleave Depth: 32
Bitswaps:         2286

Noise Margin:     5.9   dB
Connection Rate:  980   Kbps
Line Attenuation: 27.7  dB
Power:            13.0  dBm
Max Rate:         988   Kbps
 
SuperFrames:      705804
SF (CRC) Errors:  39
Reed Solomon:     4172385
RS Corrected:     245
RS Un-Corrected:  0
HEC:              41
Errored Seconds:  32
Severe ES:        0
Interleave Depth: 4
Bitswaps:         57

Total Uptimes (From SF counts):
 WAN:   0 days, 03:40:59

I had previously been collecting a graph of cumulative CRC errors, so I then also started collecting a graph of RS-Uncorrected errors.
Given the time of day of the last reconnect and potential of the Max Rate I'd seen in the stats during the day, I intended to do a disconnect/reconnect late morning the next day and was optimistic of something a little better and that will be the next post.
Below are graphs showing the Noise Margin, Sync Speed and Attenuation changes during the day.

hadden · ‎27-07-2007

Today I was going to do a disconnect/reconnect late morning to see if there were any gains from the engineering work. I intend to repeat the comparison I had tried on a previous day when I quickly tried connections with ADSL1, ADSL2 and ADSL2+. On that occasion I was only looking at the sync speed so only stayed connected for as long as it took to note stats. This simte I was going to stay connected for 10 minutes each time and note the error stats.
These are the initial router stats at 10:42 (18h52m since the last engineer action).


DOWNSTREAM (Rx)
Noise Margin:     7.3   dB
Connection Rate:  5078  Kbps
Line Attenuation: 47.5  dB
Power:            0.0   dBm
Max Rate:         6188  Kbps
 
SuperFrames:      3997483
SF (CRC) Errors:  130
Reed Solomon:     259836408
RS Corrected:     84867
RS Un-Corrected:  1482
HEC:              113
Errored Seconds:  83
Severe ES:        0
Interleave Depth: 32
Bitswaps:         9367
UPSTREAM (Tx)
Noise Margin:     5.8   dB
Connection Rate:  980   Kbps
Line Attenuation: 27.7  dB
Power:            13.0  dBm
Max Rate:         984   Kbps
 
SuperFrames:      802275
SF (CRC) Errors:  165
Reed Solomon:     447553
RS Corrected:     1076
RS Un-Corrected:  0
HEC:              123
Errored Seconds:  128
Severe ES:        0
Interleave Depth: 4
Bitswaps:         451

Total Uptimes (From SF counts):
 WAN:   0 days, 18:52:37

These are the router stats after connecting with ADSL2, ADSL1 and ADSL2+ and waiting about 10 minutes each time.

	10:55 ADSL2	11:07 ADSL1	11:20 - ADSL2+
Total Uptimes (From SF counts):	10m37s	10m04s	10m24s


DOWNSTREAM (Rx)
Noise Margin:	6.4 dB	5.5 dB	6.3 dB
Connection Rate:	5298 Kbps	5696 Kbps	5270 Kbps
Line Attenuation:	47.5 dB	48.0 dB	50.5 dB
Power:	0.0 dBm	19.6 dBm	0.0 dBm
Max Rate:	6500 Kbps	5984 Kbps	6444 Kbps

SuperFrames:	37473	35577	36757
SF (CRC) Errors:	0	65	0
Reed Solomon:	2435750	2419236	2389196
RS Corrected:	639	8884	1286
RS Un-Corrected:	0	1320	0
HEC:	0	63	0
Errored Seconds:	0	16	0
Severe ES:	0	0	0

Interleave Depth:	32	32	32
Bitswaps:	45	105	69


UPSTREAM (Tx)
Noise Margin:	6.0 dB	7.0 dB	5.9 dB
Connection Rate:	937 Kbps	832 Kbps	957 Kbps
Line Attenuation:	27.7 dB	27.5 dB	27.7 dB
Power:	13.0 dBm	12.5 dBm	12.9 dBm
Max Rate:	944 Kbps	1024 Kbps	960 Kbps

SuperFrames:	34489	35517	33165
SF (CRC) Errors:	0	7	0
Reed Solomon:	293035	301894	397805
RS Corrected:	3	4	33
RS Un-Corrected:	0	0	0
HEC:	0	5	0
Errored Seconds:	0	0	0
Severe ES:	0	0	0

Interleave Depth:	2	2	4
Bitswaps:	6	7	0

That ADSL1 sync speed at 5696kbps is better than before my "degradation" began and I was tempted to leave my connection there if it weren't for the error counts. However, I completed the test sequence and left my connection on ADSL2+.
These are the current stats after 7h31m on ADSL2+

DOWNSTREAM (Rx)
Noise Margin:     5.4   dB
Connection Rate:  5273  Kbps
Line Attenuation: 51.0  dB
Power:            0.0   dBm
Max Rate:         6116  Kbps
 
SuperFrames:      1592325
SF (CRC) Errors:  299
Reed Solomon:     103501160
RS Corrected:     59053
RS Un-Corrected:  5674
HEC:              261
Errored Seconds:  83
Severe ES:        3
Interleave Depth: 32
Bitswaps:         4011

UPSTREAM (Tx)
Noise Margin:     5.2   dB
Connection Rate:  988   Kbps
Line Attenuation: 27.7  dB
Power:            12.9  dBm
Max Rate:         980   Kbps
 
SuperFrames:      505676
SF (CRC) Errors:  135
Reed Solomon:     226468
RS Corrected:     793
RS Un-Corrected:  0
HEC:              103
Errored Seconds:  106
Severe ES:        0
Interleave Depth: 4
Bitswaps:         272
TOTALS
Total Uptimes (From SF counts):
 WAN:   0 days, 07:31:09

The CRC error count includes a single jump of about 200. The graphs below show a comparison of the CRC errors over the last 3 days. The 1st is typical of the last few weeks with constant errors.. The 2nd shows the effect of the engineering work and the last shows today with intermittent CRC errors.
Is there anything about the stats that I should note?
Is ADSL1 good enough to try?
And the big question... is my line fixed?

Anotherone · ‎31-08-2007

OK, a brief comment on the data pre-Boost engineers visit - there seems little to chose between ADSL2+ & 2 with the exception that the US seemed to fair somewhat better on 2+, there were much lower errors, but whether that was just down to the 0.9dB extra Noise Margin and slightly lower US sync is impossible to say.
Similarly post-boost engineer - little to choose DS between ADSL2+ & 2 perhaps marginally better on 2 (less RS corrected errors) and a similar picture for US, this based on your 10 minute test comparisons. ADSL1 was considerably worse with significantly higher errors, this does seem to be a little contrary to what one might expect, as did the Boost engineers tests with different Target SNRMs.
But looking at the stats for 3hrs 40mins after the engineer finished, the Bits/tone (2016), and the overnight stats 18hrs 52mins, this looks as though ADSL2 was automatically selected (from Bits/tone & attenuation) and the errors both DS & US are significantly better than you'd been having prior to the engineer.
Also looking at those later ADSL2+ stats 7hrs 31min, the previous ADSL2 stats are considerably better especially when you take into account they are for nearly 2½ times longer!
You've forgotten to attach the CRC graphs, but on the basis of all the above stats, I would stick with ADSL2 in the present circumstances,. I don't think I would even consider ADSL1 with the rate of errors it was showing. The difference in profile between them (based on the typical sync speeds from the tests) is only about 350kbps higher on ADSL1 but I would expect actual throughput to be somewhat less than ADSL2 as a result of all the errors!
So in answer to the question "Is ADSL1 good enough to try" I would say no at this time. When the DS SNRM is next stable at ~6.5 or higher, I would switch mode to ADSL2 and try that for a while.
It's a little bit of a mystery as to why the E-side errors were again high at the cab compared to the previous engineers final tests. If it was due to varying characteristics of the cable your were on (not the best) then that should now be eliminated as you've now been put on the "best" cable. The E-side should now be left alone IMHO.
As IIRC you've had at least one "Lift and Shift", if this was to a different port on the same card, then it could be that the whole card is faulty especially when you consider the strange results from the raised Target SNRM tests.
I suppose the other possibility not to lose sight of, was this intermittent interference located near the cab (which possibly seems connected to that previous electrical work there) but I'd expect this to have a greater effect at your end as we are expecting the D-side cable to be in poor condition from previous tests & inspection at your pole, especially if it's also the cause of the intermittent difference in resistance of the A & B wires, the latter would result in some imbalance leading to greater susceptibility to interference.
The Big question - is your line fixed? I am by no means convinced that it is. The D-side needs to be thoroughly checked out and for future reference if you can discover if the L&S was another port on the same card, that may be relevant if problems continue after the D-side is resolved..

hadden · ‎27-07-2007

Sorry, here are the CRC graphs for the 3 days covering before and after the engineer's visit.
The range of Noise margin results has been less since the last Boost visit. I've attached the current graph. Over the last 3 days, it peaks just over 6.5dB and drops to just below 5.5dB in the early evening. So, I'll go for a reconnect shortly and let it connect with ADSL2.
These are the current stats after 3d1h27 on ADSL2+:

Noise Margin:     6.5   dB
Connection Rate:  5273  Kbps
Line Attenuation: 51.0  dB
Power:            0.0   dBm
Max Rate:         6252  Kbps
 
SuperFrames:      15555804
SF (CRC) Errors:  1044
Reed Solomon:     1011127322
RS Corrected:     394923
RS Un-Corrected:  15021
HEC:              853
Errored Seconds:  509
Severe ES:        6
Interleave Depth: 32
Bitswaps:         41162

Noise Margin:     6.0   dB
Connection Rate:  988   Kbps
Line Attenuation: 27.7  dB
Power:            12.9  dBm
Max Rate:         1000  Kbps
 
SuperFrames:      939070
SF (CRC) Errors:  938
Reed Solomon:     2538792
RS Corrected:     11455
RS Un-Corrected:  0
HEC:              629
Errored Seconds:  659
Severe ES:        0
Interleave Depth: 4
Bitswaps:         3385

Total Uptimes (From SF counts):
 WAN:   3 days, 01:27:28

hadden · ‎27-07-2007

From Anotherone's analysis of the various ADSL modes comparison, the logical deduction is that the router/exchange negotiation would be correct to choose ADSL2 during the connection negotiation, if I let it.
So, I had it in my mind to trust that negotiation and let my router connect with the mode selection unrestricted. Based upon previous reconnects, this has been ADSL2. However when I carried out the reconnect at 9:22 this morning, the router chose to connect with ADSL2+ , on its own.

This puts me in a quandary. I was going to trust the system and the testing the other day seemed to indicate that was going to be ADSL2.
Maybe my connection has crossed some threshold that makes the router/exchange think that ADSL2+ is worth trying.
These are the stats after 1 hour.

DOWNSTREAM (Rx)
Noise Margin:     6.4   dB
Connection Rate:  5381  Kbps
Line Attenuation: 50.5  dB
Power:            0.0   dBm
Max Rate:         6556  Kbps
 
SuperFrames:      212372
SF (CRC) Errors:  29
Reed Solomon:     13804206
RS Corrected:     7632
RS Un-Corrected:  282
HEC:              20
Errored Seconds:  14
Severe ES:        0
Interleave Depth: 32
Bitswaps:         331
UPSTREAM (Tx)
Noise Margin:     5.6   dB
Connection Rate:  964   Kbps
Line Attenuation: 27.8  dB
Power:            12.9  dBm
Max Rate:         968   Kbps
 
SuperFrames:      192743
SF (CRC) Errors:  38
Reed Solomon:     2309942
RS Corrected:     278
RS Un-Corrected:  0
HEC:              30
Errored Seconds:  23
Severe ES:        0
Interleave Depth: 4
Bitswaps:         49

Total Uptimes (From SF counts):
 WAN:   0 days, 01:00:10

Below are the current Noise Margin and Bits/Tone graphs.

Pettitto · ‎26-11-2011

The line has improved massively, however, we're going to get the D-side investigated further as not all of it could be looked at on the day. I'll let you know once hear more back regarding that.
I would advise leaving your connection for the time being so we can see how it fairs out.

hadden · ‎27-07-2007

Thanks Chris. I'll leave things alone.
You know I can be patient

Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?

Re: Why is a "degraded" line not a faulty line?