What are RX CRC errors?

Started by klipp, Sep 09, 2010, 21:45:25

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

klipp

...and more to the point are they bad news?


Steve

Received cyclical redundancy check

I'm not up on the maths or the network technolgy to give a complete explanation but its a method of verifying the integrity of a piece of data. In simplistic terms is the piece of data that's arrived (at the router in your case) the same as the data that I am expecting. Does it matter? Well no if it is only a small percentage of the data received. If the CRC are a high percentage, I have read greater than 1% then throughput will be reduced as that piece of data which is wrong has to be re requested.


I hope that's clearer than mud ;D
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

klipp

Thanks Steve for your explanation.  So what you're saying is, of the 150 million RX cells I've received, 176 had an issue of some kind?

Steve

Yes and it's very small percentage.
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

klipp

Okies, I'll ignore it then.  I should stop looking for problems really LOL.  I was checking if my SNR had been lowered yet (it has!!  ;D), when I spotted the RX CRC errors and it got me wondering.  Thanks Steve.

DorsetBoy

I see a problem in your image straight away , you are running on Adsl2 mode G.992.3  where your connection will surely be ADSL2+ which is G.992.5 .

You can either manually set G992.5 mode or go to Multimode which should select ADSL2+ for you.

Steve

Perhaps that's why it's 'stable'?  ;)
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

Steve

Not sure whether I'd advise correcting the adsl mode "If it aint broke don't fix it springs to mind" especially after your line troubles recently.
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

DorsetBoy

On the other hand the router will never negotiate the line correctly if it is set in the wrong mode..........

Steve

I not disagreeing Dorset but I've seen a few posts on the net where people on long lines have gained stability on ADSL2+ by using ADSL2 mode. I suppose the answer is to try the correct mode knowing there is something perhaps to fall back on.
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

DorsetBoy

You are right Steve, in fact on the Sky forum a staff member suggested using GDMT on long lines where ADSL2+ was a pain due to noise/instability, he said to use the Max settings to get a lower stable synch.

It's just that people often say their speed/synch are not what they should be or were, often it is just the mode setting being wrong, ADSL2 and 2+ are quite different in throughput.

klipp

Hi,

Yes I'd noticed already that I have ADSL2 rather than ADSL2+.  This is what multimode decides I should be using.  I tried manually overriding it by selecting ADSL2+ but I kept losing sync and also my Line Attenuation jumped from 53db to 57db.  After putting it back onto multimode again my Line Attenuation dropped back to 53db but my SNR rose to 15db which is why my downstream rate is kinda low.  It looks like my SNR has finally dropped back down now and things seem to be stable again.  I might try a restart later on to see if I get a better sync rate.

Rik

Do it tomorrow morning, klipp, later is bad for speed. :)
Rik
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.

klipp

Well Rik, my SNR increases to 4db~5db during the day right now, but from kinda 10pm onwards it drops to 2db~3db.  Would it be better (stability wise) to try a resync at the higher or lower SNR value?  Or wouldn't it make any difference?

Rik

If you want stability, resync on the lowest NM. If you want speed, do it on the highest (usually morning).
Rik
--------------------

This post reflects my own views, opinions and experience, not those of IDNet.