acceptable error seconds limit

hi people, was just wondering from the many learned people on here what a reasonable amount of error seconds per day
Reason im asking is ive just decided to try my line without interleaving on to get better pings, with interleaving was averaging about 150 es per 24hr period.
Nowthat i am on fast path as of yesterday this has shot up, which i expected, but what i was wondering is what amount would be classed as a problem to my line
ie- first day of fast path yesterday- 1600 es
today i have had 700, although i used dmt tool to connect at a higher snr
also yesterday i had 2 disconnections in evening and today had none,
I would prefer the better pings, 20ms to jolt on fast path, 40 interleaved, but stability of the line is quite important as well.
im about 3km from exchange, and sync at approx 5500, get a 4.5mb line from this, snr is about 6, but currently running it at 9, have 46db downstream attenuation
any help or thoughts please on whether my line is gonna be ok for fast path or not, gonna monitor it through the week but it would be nice to have some guidelines of what is good and bad

The final arbiter is whether or not the line is still usable for browsing etc. and whether or not the download throughput is better or worse than it was before.

I had to have interleave applied - without it the error rate over short periods was so high that sites were timing out. It isn't possible to give an acceptable number over a day because they won't be spread out - they'll come in clumps.

I agree it would be be useful to know what BT see as normal and where the amount of errors recorded will break a threshold.

That sounds like quite a lot or Error Seconds to me. I only see Error Seconds when the line is really bad - lately when there is a storm around.

Even though my line is fairly noisy with sometimes a few 1000 CRC/HECs in a day and often 1/2 million FECs(I'm Interleaved), it always worries me if I see any Error Seconds.

I think I would be concerned that BT will raise your target SNR if the errors continue.

Unless I'm wrong the only thing that will get your margin increased is frequent forced resyncs. Unless the DSLAM is inspecting the traffic so it knows which packets are retransmits or querying your router (both of which I seriously doubt) it isn't going to have any idea at all whether or not the packet got through OK.

Not sure about that...

I recently had my SNR put back from 9 to 6dB. Although the connection was rock solid and didn't resync once, my Target SNR went back to 9 after a couple of days. The only thing that I think it could be is the number of errors.

John.

Maybe but I've had the opposite experience. Huge numbers of errors and no change in target. I even had to ask for interleave to be applied manually. OTOH I do know that resyncs get your target raised - I started out on Max with the abysmal Draytek 2600 and my target was up to 12dB by the time I realised it was useless and replaced it.

I wish my SNR had stayed down. It was only when I swapped router that I realized that my target SNR had been raised. I finally got a reasonably steady snr trace to I could see it!

It could well be that, when BT dropped it back to 6dB, it didn't "stick" for some reason (maybe the engineer forgot to hit the Save button!). Whatever the reason, my ISP says I now have virtually no chance of getting BT to do it again.

My current stats on 9dB after 160 (WAN) hours are:

SF: 33995799
SF Errors: 2592
Reed Solomon: 2311714378
RS Corrected: 33924126
RS Un-Corrected: 27569
HEC: 2331
Errored Seconds: 4449
Severe ES: 49
Interleave Depth: 16

Unfortunately, I wasn't on 6dB long enough to get around to noting the errors!

John.

I'm not sure how useful 'errored seconds' really is.

I've seen it defined as 'the number of seconds in which at least one error occurred'. One errored second could contain a single error or thousands of errors.

A line with a hundred errored seconds during one hour could be perfectly acceptable if each second only had one error. On the other hand a line with ten errored seconds could be awful if every second contained thousands of errors.

...and there of course is another one which some routers report "Severe ES: 49". Without some definition of what that means it probably isn't a lot of use but I'd take it to mean that there were so many errors in the second that very little data actually made it unscathed.

i definitely seem to get more errors on a lower snr settting, on 6 it was 1600 a day, yesterday i used dmt tool to increase snr to 9 and i got half of that, to test it out again ive let the normal snr happen today and ive got 1100 error seconds with 4hr of day left, had 1 d/c today and none yesterday with the higher snr.
I may just have to accept a slightly lower speed on line if im gonna stay on fast path,
1/2 mb drop vs good pings hmmmmm

It's noise spikes that corrupt the data so higher noise margins (less noise in relation to the signal) will reduce the number of errors.

Unless you have some specific need for low latency (eg you're a gamer) then interleave will give you better stability and higher throughput on downloads.

I do a fair bit of game playing but im not a hardened gamer by any stretch of the imagination, just thought the the lower pings would be better for me, i ping about 40 to 60 on uk servers interleaved, and approx 20-30 on fast path.
To be really honest though cant see much difference in the lower pings,lol
May go back to interleaved, will give it a few more days

I think it depends on the router as some routers notably the speedtouch misreport errors.

My speedtouch on adsl1 will typically show an average of about 900 crc errors an hour. However I get no packet loss and retransmits.

My experience on interleaving is different however, when I last used interleaving whenever I got a crc error there was a tcp retransmit.

Surely it depends on whether or not the error occurs in a data packet rather than a null packet. If you have a crc error in a data packet it has to be retransmtted - unless you have "holes" in web pages and downloads of course.

>>Unfortunately, I wasn't on 6dB long enough to get around to noting the errors!

If only there was some s/w that could monitor and record things

I know. It's embarassing !

John.

PRTG or MRTG on Linux can be used to monitor any counter that the router makes availble to SNMP but I've not found one that does that for errors it's mostly only bandwith data.
http://www.paessler.com/prtg
http://oss.oetiker.ch/mrtg/


Possibly the routerstats program could be persuaded to graph them somehow but that is really geared to a varying value like snr rather than an accumulating one like error counts. Probably just using it to monitor snr would be a good indicator though as the errors are mostly going to happen when the noise margin falls.
http://www.vwlowen.co.uk/internet/files.htm

I dont know, I can be utilising my full download bandwidth which would surely mean every packet been transmitted is valuable and still have no impact at all from crc errors reported by the router. I dont get issues such as missing images. On interleaving however although the error rate is massively reduced, the errors on that seem to be real errors impacting the connection.

Also my experience with interleaving is actually worse than fast path, I have never tried interleave on ukonline LLU yet, but when I was last using it on entanet I had occasional loss/retransmits whilst a comparable synch rate on fast path there was no loss. My conclusion from that was interleaving seemed to impact bitswapping where the router didnt bitswap anywhere near as agressive as it does on fast path so more tones had negative snr margins, I dont get any tones with negative snr margins on ukonline fast path.

Edited by Chrysalis (Thu 10-Jul-08 10:57:19)

I can't see how you can get a crc without the data having to be retransmitted. Either you aren't seeing those retransmits for some reason or the error reports are incorrect. I'm inclined to favour the former possibility. Then again its your line and you know what works best for you.

IIRC DMT versions that haven't had the tweaking disabled can write it to the (csv) log file. Not got my computer with v8.05/7? on at the moment though.

As you say SNMP doesn't make much in the way of error stats available on domestic routers.

With MRTG you don't have to use SNMP, you can have your own counters.

I wrote some scripts to examine /proc/avalanche/avsar_modem_stats every 5 minutes and return the upstream/downstream FEC and CRC errors. I then used MRTG to graph the history. I was wondering if there was any pattern in errors over time - there wasn't.

kwikbreaks - I was teasing!
Perhaps you haven't noticed by I was replying to John_ON the writer of the excellent RouterStats!

NB. RouterStats can record various bits of info not just SNR - I capture FECs and Error Seconds for example.

Fair enough but I'd no idea who wrote routerstats much less that it was the poster you responded to. I did try it with a non-netgear router with some success some time ago but as most of my troubles were down to that very router I haven't used it since changing it.

its the latter, the errored seconds dont go up with the crc errors. If I am on fast path and the crc and errored second count goes up then I get a retransmit, if the crc count goes up but errored seconds doesnt budge then there is no affect on my connection. I have also read somewhere that even without FEC there is some kind of error correction alogrithm so it maybe these crc occur but get corrected and the ones that dont get corrected are errored seconds. I usually get 5-10 errored seconds on the first few days of synch then after that pretty much 0 nearly every day.

Edited by Chrysalis (Thu 10-Jul-08 16:23:47)

I vaguely recall reading somewhere that single bit errors (over some size chunk which escapes me) are correctable on fast path. Usually a noise spike would wipe out several bits which is why interleave jumbles the datastream up converting (say) a 5 bit error into 5 single bit errors which are correctable.

HEC, CRC, and FEC counts accumulate for idle as well as data ATM cells. If you are doing general browsing, as opposed to P2P say, most of the transmitted packets will be idle ATM cells. There is no retransmission required if there are HEC or CRC errors on idle cells.

Total time = 1 days 18hours 7min 49sec
SF = 18757272 CRC = 19653
LOS = 4 LOF = 36 ES = 5158

Latest 1 day time = 18hours 7min 49sec
SF = 3839307 CRC = 1513
LOS = 0 LOF = 0 ES = 764

Previous 1 day time = 24hours 0sec
SF = 5078067 CRC = 8826
LOS = 1 LOF = 9 ES = 1266

this is latest stats from dmt today, is it possible to interpret whether my line is ok from any of this, i know basics but not enough to understand all the cec errors etc

please check what I said, it also is the same when I am downloading at full throttle. I dont think many cells will be idle then. I think what kwikbreaks said regarding single bit errors is the most likely explanation.

I am now using a billion 7402R2 on adsl2 which is currently showing 0 crc errors, not sure I believe that either. Since plugging in the billion I am getting some ping variance (no loss but varying ping latency) but tcp seems fine.

In reply to:

---

I think it depends on the router as some routers notably the speedtouch misreport errors.

---

That's not my experience:

Uptime: 28 days, 6:15:25
Modulation: G.992.1 Annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 / 3,520
Data Transferred (Sent/Received) [MB/GB]: 703.00 / 10.48
Output Power (Up/Down) [dBm]: 11.5 / 18.0
Line Attenuation (Up/Down) [dB]: 31.5 / 55.0
SN Margin (Up/Down) [dB]: 18.0 / 8.5
Vendor ID (Local/Remote): TMMB / 
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 17,201 / 0
FEC Errors (Up/Down): 4,148 / 5,878,531
CRC Errors (Up/Down): 2,258 / 59,541
HEC Errors (Up/Down): 1,580 / 52,508


If I force my SpeedTouch to sync at 4000+ (using the DMT tool) then the error rates do rise substantially as my SNR margin drops around 3 dB

In my stats (above), the error rates are all relatively low for a 55 dB attenuated line.

This is mine on a very similar line to CurlyWhirly on st 585v6 with filtered nte5 faceplate, firmware 6.1.4.3

Uptime: 9 days, 20:31:05
Modulation: G.992.1 Annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 /4,160
Data Transferred (Sent/Received) [GB/GB]: 2.42 / 9.60
Output Power (Up/Down) [dBm]: 11.5 / 18.5
Line Attenuation (Up/Down) [dB]: 31.5 / 55.0
SN Margin (Up/Down) [dB]: 17.0 / 8.5
Vendor ID (Local/Remote): TMMB / 
Loss of Framing (Local/Remote): 4 / 0
Loss of Signal (Local/Remote): 1 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 311 / 0
FEC Errors (Up/Down): 2,400 / 502,924
CRC Errors (Up/Down): 0 / 599
HEC Errors (Up/Down): 0 / 453

Just to show what I had before I fitted the filtered faceplate

Uptime 8 days 3 hours

snr margin 9db sync rate 4160
Error Seconds (Local/Remote): 562 / 0
FEC Errors (Up/Down): 530 / 706,574
CRC Errors (Up/Down): 10 / 5195
HEC Errors (Up/Down): 4 / 4871

Edited by deleted (Sun 13-Jul-08 09:02:26)

In reply to:

---

]ust to show what I had before I fitted the filtered faceplate

---

Yes the filtered faceplate makes a difference.

p.s. your line is better than mine as you have the same attenuation as me and can sync 512 Kb higher and still have the same SNR margin as me!

I never said error rates dont increase with higher speeds, of course they do I just said they known to misreport exact error counts.

If I synch extremely low on the speedtouch, about 1mbit instead of 5mbit crc errors then go down to maybe a few dozen a day but there is no noticeable difference on anything other than slower downloads.

Incidently my billion 7402 that I am using now has some weird error counts as well.

crc errors for both upstream and downstream on atm are both reported as 0.

errors on the ppp interface is approx 30% of what I got on the speedtouch on adsl1 for the same synch, however there is considerably more upstream errors reported. I am not sure if these are the proper crc errors tho but when they do go up I seem to get restransmits (unlike the speedtouch). Also unlike the speedtouch these ppp errors go up depending on what bandwidth I am using, eg. my upstream errors I had 0 for many hours, then during a single upload speedtest on thinkbroadband there was approx 30 errors. Downloading seems to also increase the downstream error count in the same manner. Of course to make it more confusing on this router the ethernet page reports errors as well.

Your upstream errors look high curly considering your upstream is interleaved, you have 18db noise margin and only synched at 448kbit.

In reply to:

---

Your upstream errors look high curly considering your upstream is interleaved, you have 18db noise margin and only synched at 448kbit.

---

I know that my upstream channel is interleaved but even so are the upstream errors high on an uptime of 30 days (latest router stats)


Uptime: 30 days, 1:37:10
Modulation: G.992.1 Annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 / 3,520
Data Transferred (Sent/Received) [MB/GB]: 750.02 / 11.05
Output Power (Up/Down) [dBm]: 11.5 / 18.0
Line Attenuation (Up/Down) [dB]: 31.5 / 55.0
SN Margin (Up/Down) [dB]: 18.0 / 8.5
Vendor ID (Local/Remote): TMMB / 
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 18,117 / 0
FEC Errors (Up/Down): 4,352 / 6,138,875
CRC Errors (Up/Down): 2,416 / 60,859
HEC Errors (Up/Down): 1,702 / 53,667


p.s. I think they are quite low because of the 30 days uptime, should they be lower than this then?

yeah all my adsl1 synchs on ukonline I had 0 crc errors, and of course 0 fec as no interleaving on a 768kbit synch with 13db noise margin. Thats with the 6.2.29.2 firmware, I know on 6.1.4.3 I did get some upstream errors but they werent in the thousands.

However you got 0 remote errored seconds which I consider a more accurate figure than the crc errors on the speedtouch.

Edited by Chrysalis (Mon 14-Jul-08 19:03:22)

In reply to:

---

yeah all my adsl1 synchs on ukonline I had 0 crc errors, and of course 0 fec as no interleaving on a 768kbit synch with 13db noise margin. Thats with the 6.2.29.2 firmware

---

I wonder if the SpeedTouch firmware is correctly showing the CRC errors as surely you would have some upstream CRC errors?

In reply to:

---

However you got 0 remote errored seconds which I consider a more accurate figure than the crc errors on the speedtouch.

---

I don't think that I've seen anyone with remote errored seconds

I believe the upstream CRC and HEC errors and also the upstream FEC errors and, as these are corrected, there's nothing to worry about (I think so anyway)

well I would actually find it unusual having upstream crc errors because it is 10db+ snrm on a part of the line that should typically not be affected by am radio.

On the billion I have now found the proper error counts in the cli, from what I see even on a 950kbit upstream I have no crc errors, I am getting approx 200 crc errors per hour tho during the night on the downstream. On the billion the errored seconds appear to be going up whenever there is a crc error, there is also a seperate severely errored seconds counter which is staying on 0.

At the end of the day if the connection is fine, no packet loss, no missing images on pages etc. its best just to ignore the errors because they always going to be there and what matters is how the connection performs.