Router stats (errors) explained

[Saturday]

Your ADSL router constantly monitors your line and connection and stores the results. These results or stats can be very helpful in determining whether your connection is performing as it should and importantly, if things are changing over time. However, this information often isn't easy to access and can be even harder to understand.

For information on how to access connection information via your router's admin pages, please see here. That tutorial covers attenuation, sync and noise margin. This one looks a little deeper at the line errors reported in the stats.



What are line errors?

As you will have read in the previous tutorial, line noise significantly impacts your router's ability to hold a fast ADSL connection. Whilst an analysis of the sync speed in relation to the attenuation and noise margin will usually reveal the extent of this impact, a look at the line errors can be useful in quantifying what noise is present. Line errors are counts of specific types of transmission error.



Interpreting line errors

This is important: errors come and go, increase and decrease depending on the current line condition. Please ensure that your router has been up and connected for at least an hour or two before trying to asssess the error levels. Longer than that is even better,

Exactly which line errors are reported in your router (and their exact titles) will depend on your router model. Here is a list of the commonly reported errors and a brief explanation:


CRC (Cyclic Redundancy Check).

Data is transmitted as streams of packets through a network. A TCP module at the far end sends back an acknowledgement for packets which have been successfully received. It checks for damaged bytes by using a checksum. In simple terms, if any packets fail the check they will be recorded as CRC errors.

The number of CRC errors recorded must be looked at in relation to the total number of packets transmitted. If that data is not available then the number of CRC errors in a set time frame will do.

In any event CRC must not be looked at in isolation; it is quite possible for instance to have a "low" level of CRC but a high level of errored seconds/loss of signal and vice versa.

LOS (Loss of signal)

This sounds bad but a handful of these in any 15 minute period will probably go unnoticed in normal surfing/downloading. It's showing that connection to the exchange was lost momentarily but the connection will cope with this. A high level however, say more than 5% of the CRCs, indicates a fairly severe line problem, possibly noise spiking.

ES (Errored Seconds)

An Errored Second is a second in which one or more coding violations occurred OR one or more loss of signal defects occurred.

Again, as with CRC there is no standard formula which would indicate whether a given level of ES is acceptable or unacceptable. Anything other than a near perfect line will give some level of ES error. On really bad lines the ES number can actually equal the total seconds i.e. every second of connection experienced a coding violation or loss of signal.

In many ways, errored seconds are a better indicator of a line that is struggling than CRC. Severely errored seconds give an additional quantification.

SES (Severely Errored Seconds)

As the name suggests, a severely errored second is worse than an errored second. To be counted as errored only one event needs to occur. A severely errored second quantifies this. Typically a severely errored second is one where a threshold number of events is passed. Each router manufacturer will set their own threshold for what constitutes a severely errored second.


FEC (Forward Error Correction).

These are errors that have been corrected during transmission so, to an extent, are nothing to worry about as no retransmission was required, unlike say CRC which are uncorrected.

One key point: it's my understanding that the FEC count is kept at the DSLAM so rebooting your router will not clear them. So, you will probably see that the FEC count will seem high. That's because it will include previous connection data.



One last thing. A caveat on all the above:

Interpretation is down to subjective evaluation - you can't simply say "this is good - that's bad". The whole picture must be looked at.

When looking at the stats, particular attention must be paid to the noise margin levels during the stat measurement period. For example, if the noise margin had dropped down to less than 6db then even the best quality line would record errors. Similarly, if the noise margin had been boosted up so it was always above say 9db and the line showed errors, then the "real" error level will have been under reported.

Different consideration must be given to capped lines e.g. if comparing two lines both reporting similar error levels, where one is capped and one not, the capped line has a much bigger problem.