FTTC router resyncs

I have been having problems with my FTTC connection dropping.

I have unlocked the modem and I have the computer producing graphs from the stats, see link below...

http://www.sendspace.com/pro/dl/2xdepg

I was wondering if anyone may help by having a quick look and seeing if my thoughts below seem correct?

You will notice that the connection drops seem to tie in with the RS Corrected Errors graph. It appears that this graph only goes up to a figure of 4.5e +009 and then returns to zero. Maybe the modem flushes the log of corrected errors when it reaches this figure? Do you think the modem is sometimes dropping the connection in conjunction with this figure maxing out on the graph?

If those figures are correct the the number of corrected error is HUGE but the SRN hovering around 6dB presumably would indicate that the line is pretty stable.

Noise issue?

I personally think there is a high resistance fault where a repair was made to the D Side cables a couple of years back. All of the cables were severed and they were jointed under the pavement.

Whenever BT come and test my line the results are great on the JDSU however in practice I get loads of errors on the line. When I had ADSL 2+ I had attenuation of 38db and noise margin of 11.5db, but I could only get around 6 meg sync. I went to the neighbours house last night, they are still on ADSL and are getting exactly the same as I used to get.

Looking at the graphs though it seems that the errors can only reach a certain point before it resets to zero, and the resyncs usually tie in with it resetting to zero...

I think you'll find that the max reading is 4.29E09 is actually 2 to the power of 32 (the highest number that can be stored in 32 bits), it's just like an odometer rolling over to zero after 100000 miles on some older cars. I don't think the resyncs are coinciding with the roll-over anyway (sorry to spoil your theory).

Post deleted by asbokid

Edited by asbokid (Wed 13-Jun-12 02:00:51)

Well spotted, Al1264!

And that particular graph (second column, fourth row, labelled "RS" in that big montage) doesn't actually show errors. The graph is only showing the count of codewords passed to the Reed-Solomon (RS) error correction decoder.

Most of those codewords will have been transferred bit-perfect, but the decoder still increments its codeword counter.

When the RS decoder does encounter a codeword in error, it determines whether it can be corrected. The RS algorithm can correct only a finite number of errors per codeword. That correction limit is determined by the number of redundancy bytes added to the codeword.

Where the decoder finds that the error count for a codeword exceeds its correction capabilities, the whole codeword must be re-sent.

The RS decoder keeps count of Correctable errors under "RSCorr", and uncorrectable errors are counted under "RSUnCorr". All of the RS counters relate to the frame payload, and not the frame header.

Errors in the frame header are detected separately, using a CRC algorithm rather than Reed Solomon. CRC is only an error-detection algorithm, not an error-correction algorithm. When an error (just one) is discovered in a frame header, the whole frame must be re-sent.

There's another point that should be considered when viewing graphs of cumulative raw error counts - the depth of frame interleaving.

In interleaving, the data frames are broken up and spread out over time, by interleaving one frame with, say, 64 other frames. This creates a transmission latency, but it also improves the chances that the RS decoder will be able to correct a frame in error.

A brief burst of RFI noise caused, for example, by the neighbours turning on the bathroom extractor fan, might only last a couple of milliseconds. However, ordinarily, that event would still create too many errors in an affected frame for the decoder to be able to correct it. Interleaving essentially divides the frame error count, in this example, dividing it by 64. Now the decoder may be able to correct that smaller number of errors in the frame.

Ripley's interleaving depth did go up by a factor of 4, around 7am on Monday morning. That change would have been forced by the VTU-R (the cabinet DSLAM) in response to adverse line conditions - i.e. noise. An increase in vehicle movements at the start of the working week, perhaps? Who knows?

That said, your stats don't look at all bad.

cheers, a

A resync will zero some of the data counts, but data counts resetting to zero doesn't necessarily force a resync.

Do any of your fairly infrequenct resyncs occur simply by using the phone?

I had that issue for a while & it was cured by BT OR replacing the VDSL2 filtered faceplate.

A faulty pole top DP connection with the underground cable was also repaired at the same time which also cured the regular but unpredictable resyncs that my connection has endured for many months.

190 days stats

Even with evidence like my 190 day stats it took months before BT engineers finally found & resolved the issues.

I had already reported the dodgy DP joint back in early February. It was eventually fixed May 26th.

BTW, during these issues many/most of the usual tests have resulted in LTOK results so no further action required!

Thankfully though, SOME work was always carried out so I have never been charged for the engineer's visit - there really have been many of them.

P.S. I also had to diagnose the faulty faceplate myself too (by temporary use of a dangly filter) as that never showed as faulty on BT's line tests either.

On the whole though, your connection looks reasonably stable.
Continued logging may just identify patterns to the relatively infrequent but quite sudden disconnections.

Edited by Bald_Eagle1 (Wed 13-Jun-12 07:54:52)

In reply to a post by asbokid:

Well spotted, Al1264!

And that particular graph (second column, fourth row, labelled "RS" in that big montage) doesn't actually show errors. The graph is only showing the count of codewords passed to the Reed-Solomon (RS) error correction decoder.

Cheers asbokid.
That has reminded me to change some of the y axis labels for when I eventually release the updated scripts