4294966051 Upstream Packet Errors in 26 days.. normal?

The TP-Link W9980 I use on BT's Infinity 2 package apparently incorrectly showed 0 packet errors permanently for around a year.

A few months back I updated the firmware (after noticing the changelog says they fixed the error counter!) and I have seen pretty similar error numbers as mentioned in this post's title.

So the number of upstream packet errors seem incomprehensibly huge to myself, I don't really understand what is happening and if such a large number is to be considered normal.

The line has been connected for 26days with no disconnections or re-syncs according to the device logs (normally accurate as far as I know!)

The history of the line was 2-3years of full 80mbit running on a old HomeHub before it went nuts disconnecting AND rebooting multiple times per day for several weeks and losing 20mbit of sync.

This forced us to buy the TP-Link unit which solved all the stability issues yet well over a year later my sync speed has never recovered.

So discovering the error count has been pretty surprising, is this some sort of line fault which the TP-Link unit is somehow dealing better with than the old HomeHub could?

Image of sync speed + number of error's http://i.imgur.com/B32NY8D.png

Anyone?

is this some sort of line fault which the TP-Link unit is somehow dealing better with than the old HomeHub could?

Yes

You really need a modem/router compatible the dslstats or hg612 Modem stats http://forum.kitz.co.uk/index.php?board=46.0 and post some more detaild stats.

Are these upstream erros fec,crc,hec or error seconds?

Thanks ian007jen.

Digging into the HTML side of things the error count variable names seem to be "ATUCCRCErrors" for upstream and "CRCErrors" for downstream.

I rebooted not long after my original post and cleared the stats, they sit like this now:

ATUCCRCErrors=618
CRCErrors=4999

I will see if I can get anything more in-depth via your link thanks again.

Any of this stuff useful? Complex sounding stuff...

upstreamCurrRate=20000
downstreamCurrRate=67000
upstreamMaxRate=21434
downstreamMaxRate=68431
upstreamNoiseMargin=62
downstreamNoiseMargin=63
upstreamAttenuation=85
downstreamAttenuation=106
upstreamPower=-18
downstreamPower=-19
totalStart=356326
showtimeStart=578


cellDelin=0
linkRetrain=0
initErrors=0
initTimeouts=0
lossOfFraming=0
erroredSecs=0
X_TPLINK_US_ErroredSecs=0
severelyErroredSecs=0
X_TPLINK_US_SeverelyErroredSecs=0


FECErrors=46851
ATUCFECErrors=9633
HECErrors=0
ATUCHECErrors=0
CRCErrors=5002
ATUCCRCErrors=619

If uploads behave fine, then probably just a bug in how the web UI displays the figures.

4294966051 is suspiciously close to the maximum value a 32 bit unsigned value can hold. As a programmer I'd have to say that I'd mistrust it on general principals. It looks to me like a negative number or an underflow.

The same issue has been seen many times before, and as you say, probably a negative number, normally starting at the largest magnitude (most negative) and then slowly incrementing with each error towards zero and for a low error line that could take a long, long time.

Thats an interesting thought, since there was originally a bug with the error counter permanently reading 0 for so long it doesn't inspire much confidence.

I might try and record the stats daily or something to get a better understanding of what might be happening.

The family does complain of some intermittent page stalling but I understand that could easily be on the web sever side of things. I regularly have issues in YouTube videos while trying to skip parts of the video - often forcing me to fully refresh the page.

I was browsing on some public BT WiFi yesterday and was amazed at how snappy it felt vs my own even via Ethernet.

Perhaps a factory reset before trying to record my stats might be a good idea?