Stats accumulated in DMT

After about four days of usage with my new router and a new edition of DMT, I've been looking at the statistics accumulated in the right-hand box of DMT. Trouble is, I've no idea what most of the abbreviations there stand for, eg. SF, RS, OCD, LCD, ES, SES, UAS, LOS, LOF. The only ones I recognise are HEC and CRC, of which I gather CRC is the most important. If I'm not mistaken, the line's dealing with about 500 CRC errors per day at present.

I'm trying to gauge whether the error-correcting is working well enough on my long, noisy line. My line works Interleaved and, having set up DMT to force the target SNR artificially high, the line's remained up. According to the router's telnetted stats (not available alternatively anywhere in the router's webpages), Trellis and Bitswap are both off.

Can anyone give me an explanation of these abbreviations?

Counters Down Up

SF: 20437009 20437152
SFErr: 435 11
RS: 694858326 173715792
RSCorr: 4153587 74
RSUnCorr: 2146 0

HEC: 388 8
OCD: 7 0
LCD: 0 0
Total Cells: 3015421136
Data Cells: 1498301
Drop Cells: 0
Bit Errors: 0 0

ES: 405 0
SES: 0 0
UAS: 318 0
AS: 347433

INP: 0.70 1.00
PER: 1.90 1.96
delay: 4.35 4.50
OR: 29.42 28.44

Bitswap: 0 0


Total time = 1 days 3hours 20min 25sec
SF = 20999276 CRC = 518
LOS = 0 LOF = 0 ES = 405

Latest 1 day time = 3hours 20min 25sec
SF = 707351 CRC = 16
LOS = 0 LOF = 0 ES = 13

Previous 1 day time = 24hours 0sec
SF = 5082260 CRC = 147
LOS = 0 LOF = 0 ES = 114

I'd have a look on wiki but from memory

SF: 20437009 20437152 super frame?
SFErr: 435 11 super frame error
RS: 694858326 173715792 reed solomon checksummed packets (interleave, FEC)
RSCorr: 4153587 74 FEC count (packets corrected by checksum data)
RSUnCorr: 2146 0 RS packets which were too corrupt to be corrected with checksum data

HEC: 388 8 ATM cell header error control errors
OCD: 7 0 ?
LCD: 0 0 ?
Total Cells: 3015421136 number of 53 byte ATM cells transmitted
Data Cells: 1498301
Drop Cells: 0
Bit Errors: 0 0

ES: 405 0 error seconds (try wiki)
SES: 0 0 severely errored seconds
UAS: 318 0 ?
AS: 347433 ?

INP: 0.70 1.00 ?
PER: 1.90 1.96 ?
delay: 4.35 4.50 ?
OR: 29.42 28.44 ?

Hi

To check what error correction is doing the RS figures are of interest:

RS: 694858326 173715792
RSCorr: 4153587 74
RSUnCorr: 2146 0

You can work out some percentages:

Total percentage of errors:
(RSCorr + RSUnCorr) / RS * 100 = 0.59% error rate

Total percentage of uncorrected errors, these are problems:
RSUnCorr / RS * 100 = Very small number not worth worrying about!

So every think looks fine, a very low error rate overall and the vast majority are corrected anyway.

Regards

Phil

Philip,

Does it matter that there are some that are NOT corrected (eg. RSUNcorr)? Surely, pretty well ALL packets ought to be corrected on downstream, as otherwise the Internet would be unreliable as a source of data? For instance, you wouldn't want to be downloading a new program or a Windows update if only 99.5% of the data was being received correctly, would you? Or am I missing a trick here?

So far, I've discovered that these are what some of the abbreviations stand for:

ES = error seconds
LOS = loss of signal
LOF = loss of framing

CRC is, of course, cyclic redundancy check.

You see, I'm wondering if I've got my router set up optimumly yet. My line, being long and noisy, characteristically is prone to a lot of packet errors. But I've been advised by one or two others to leave my router's error handling settings at their defaults. In my case, this happens to be with Trellis and Bitswap both off. In DMT, I was advised not to select ADSLv1 at all in the target SNR selection tab and to leave that selection blank, including leaving the bit correction settings there blank (neither on nor off). I found the router's default settings for Trellis and Bitswap by specifically telneting into the router's stats.

The router's a Netgear DG834v4.

Edited by deleted (Sun 25-Oct-09 16:59:41)

Pretty much all packets are being corrected.

2146 out of 694858326 downstream packets were corrupt and required retransmission.

i.e. 0.00030884% were corrupt and required a retransmission, 99.99969116% were not.

By the way ADSL is designed to achieve better than 1 bit error in 10,000,000 bits at a 6dB SNR margin.

In reply to a post by meditator:

Does it matter that there are some that are NOT corrected (eg. RSUNcorr)? Surely, pretty well ALL packets ought to be corrected on downstream, as otherwise the Internet would be unreliable as a source of data? For instance, you wouldn't want to be downloading a new program or a Windows update if only 99.5% of the data was being received correctly, would you? Or am I missing a trick here?

Uncorrected errors would be re-sent, the net result of which is to give an apparent reduction in throughput. One of the dangers of tweaking a connection for the highest sync speeds is that it can result in high-numbers of re-sent packets, which results in a lower overall throughput.

Uncorrected errors just means that the packet was so badly corrupted that the error-correction algorithm in the router wasn't able to reconstitute the original data. The packet will be discarded and requested again.

Too many resend requests will eventually have an impact on the throughput speed but I think it's safe to assume that the router will set itself up with the optimal values. The only meaningful tweak is to adjust the target SNR for either improved sync speed or improved reliability. Either way, it's a tweak away from the optimal.

For instance, even if a line maintains the connection with a "forced" higher sync speed (by tweaking the target snr lower), it doesn't necessarily mean you will automatically get higher throughput because, along with the increase in sync speed, there may also be an increase in uncorrected errors (requiring the entire packet to be resent) which could actually result in a reduction in throughput.

John.

Ah, I'd assumed that Uncorrected Errors referred to bit errors that were never corrected. If instead they're packet errors and they get requested again and re-sent, then obviously all should work out well in the wash.

One of the nice things about my former router, a Speedtouch 546v5, was that its Web interface readily gave you the three main on-going error stats - HEC errors, FEC errors and CRC errors, but you can't get a nice, simple summary like that with this new DG834.

I take on board that any tweak to a router is, in one sense, a move away from the router's optimal setting. But it seems, from my observations, that routers' default settings for running a line assume 'an average line'. But mine's certainly not an average line.

I agree with you all, in what you say about tweaking up the sync speed not necessarily gaining you much, if anything, in many circumstances. In my case, I know that my line is long and gets subjected to periods of quite large amounts of noise that are outside my control. The noise has often exceeded 6dB in amplitude. This means that, during any one day, I can never run at the BT Wholesale default SNR of 6dB for very long and so, to avoid continual disconnections, I use DMT from the outset to push the target SNR right up to 12 - 15dB. This then makes the line stable, though even then occasionally noise will momentarily pull this down to below 6dB and the router will disconnect.The downside to this, of course, is that I have to run at a lower sync speed. But this has always made good sense to me. I'd rather have a stable connection, with relatively few bit errors and re-sent packets, than a fast connection with lots of bit and packet errors.

With this new router, stability seems slightly better than with my old Speedtouch. With the Speedtouch, though, DMT was always set with Trellis and Bitswap both on. With this DG834, they're both off (and, as yet, not set to either on or off in DMT), and I keep wondering if I'd be better off with them both on. Others have advised me to leave those settings in DMT just as they are, though. I do wonder, though, whether that advice is based on a more average line and average router. Perhaps I could achieve even better error figures than those above? But, without turning Trellis and Bitswap on, I'll obviously never know.

With the DG834, my target SNR, as set with DMT, was 14dB and even during the day the SNR drops to 11.5dB. But possibly setting Trellis and Bitswap on might allow the SNR to rise a bit more, back toward 14dB again. What d'ya think? Personally, I can't see what permanent harm can be done by specifically setting them on; after all, you can turn them off again if the results aren't satisfactory. Or is there some bug in DMT that doesn't allow this to work properly?

It sounds like you may have an intermittent line/exchange issue (not dissimilar to mine, as it happens). You say you're on a long noisy line, what are your line stats like (the bit you missed off the top of your first post, i.e. your attenuation, power and sync rates ??

I've been sufering intermittent snrm in a similar fashion to that you describe, and I'm now waiting for my ISP/BT OR to fully replace my line from NTE to exchange

No, I don't think there's an intermittent line fault. A certain amount of the interference on my line is simply crosstalk, of which you'd anticipate more in the evenings. That's something that neither I nor BT can do anything about, except for having my whole line, from house to exchange, renewed - and they sure ain't gonna do that! This is an urban situation, with the line running underground with masses of other BT lines. I suppose they could try me on a different pair but I somehow doubt that that'd make much difference in this instance.

No, from the years I've observed its effects, this is a case of a noisy electrical source, somewhere along my line, being turned on at certain times of the day. It could be the line passing in the vicinity of a garage workshop, the local train station, a bad streetlamp, or something like that. It could just as easily be a resident somewhere unwittingly running heavy, unsuppressed electrical gear. With the line being 3.4km long and running through a dense urban environment, almost anything's possible. It's something I've had to learn to live with.

In the not-so-distant past, there have been some problems at the exchange end, right at the exchange. That was a case where the DSLAM for some reason decided to drop my sync speed to just over 2M bps and there it stayed. My ISP got BT to investigate. They came and checked things out at my end first, putting their own ADSL analyser on the line. But it transpired that that particular problem was being caused by a DSLAM/cabling problem in the exchange (the Openreach engineer didn't expand, at the time) and, once that was discovered and corrected, I got my normal speed back (just under 4M bps). Over the last year or so, the speed has slowly crept down, as more and more residents around here have signed up to ADSL (more crosstalk, especially at the exchange end). This includes my nextdoor-neighbour, whose line shares the same exterior cable as mine.

Current stats are:-

Line length: 3.4km (actual line length)
Down line attenuation: 51dB
Current Down sync speed: 3680K bps
Down SNR: 11dB - 14dB (depends on time of day), target SNR initially set by me in DMT, at 14dB
Up sync speed: 448K bps
Up line attenuation: 31.5dB
Up SNR: 18dB

Haven't got the Up and Down power figures, as this router doesn't readily give you them, but I recall that the former router gave them as the 'standard' figures.

Edited by deleted (Tue 27-Oct-09 12:12:12)