Large amount of FEC errors downstream

[#1]

Hi all,
Just wanted to ask if my experience is normal. I had my plusnet ADSL2+ broadband activated last week on Wednesday, and for the first day or so I got a maximum of 1.5 hours of  continuous connectivity, with the DSL connection often dropping and reconnecting every 10 seconds or so. Obviously this was unusable.
I went through the normal tests (connected to master socket, completely reset the router [technicolor 582n] and removed the phone, did both filters in a chain etc) and that didn't solve it. A couple of days later, the problem seemed to have settled down itself, though I'm still getting an enormous amount of FEC errors downstream, and line interleaving has been enabled on my line. I'm not sure whether line interleaving has helped or not. Plusnet sent a BT engineer around, and he said that our line was very good, and shouldn't have any transmission problems. Judging by the one-way nature of the problem (almost entirely downstream problems) it appears that he is right to some extent (surely a damaged line would affect both up and down stream connections?).
Anyone have any ideas what was causing it? And why I get so many FEC errors in one direction? I'd like to not have line interleaving on if possible. My Plusnet ticket has been returned to me saying that "the engineer cleared a slight issue" but the engineer said all was fine when he was here (according to my girlfriend, I wasn't in at the time).
Thanks.
PSan

Here's the link info since the engineer visited, not much changed from before. At least I'm getting uptimes that are longer now, but my ping is pretty enormous (~50ms at it's lowest it seems)

Link Information
Uptime: 1 day, 3:16:01
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 440 / 14.145
Data Transferred (Sent/Received) [MB/GB]: 66,37 / 1,10
Output Power (Up/Down) [dBm]: 12,4 / 0,0
Line Attenuation (Up/Down) [dB]: 12,3 / 27,0
SN Margin (Up/Down) [dB]: 30,8 / 7,1
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 17 / 0
Loss of Signal (Local/Remote): 2 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 33 / 0
FEC Errors (Up/Down): 105 / 91.939.627
CRC Errors (Up/Down): 0 / 61
HEC Errors (Up/Down): 0 / 152

[#2]

Rather then worry too much about the number of FEC errors recorded, it might be better to look at the figures, say, an hour apart and see how much they change in that time.  Some routers seem to keep an ongoing count through a reboot so the current rate may be nothing like what the total seems to indicate.

[#3]

Hi Walker23,
That's a fair point, the rate of change of FEC errors is the important thing, so I'll take another sample:
Uptime: 1 day, 3:45:38
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 440 / 14.145
Data Transferred (Sent/Received) [MB/GB]: 70,51 / 1,15
Output Power (Up/Down) [dBm]: 12,4 / 0,0
Line Attenuation (Up/Down) [dB]: 12,3 / 27,0
SN Margin (Up/Down) [dB]: 30,8 / 7,2
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 17 / 0
Loss of Signal (Local/Remote): 2 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 33 / 0
FEC Errors (Up/Down): 105 / 95.028.726
CRC Errors (Up/Down): 0 / 61
HEC Errors (Up/Down): 0 / 152

Original:
Uptime:  1 day, 3:16:01
FEC Errors (Up/Down):  105 / 91.939.627
Now:
Uptime: 1 day, 3:45:38
FEC Errors (Up/Down): 105 / 95.028.726
So that's just over 3 million FEC errors in half an hour (Down), 0 Up.
That seems unusual to me. As far as I'm aware, this router doesn't have a persistent statistic for FEC errors and it resets each time the link drops. At the current error rate that seems to be an okay assumption for this total.
Cheers,
PSan

[#4]

I'd take what the engineer said with a pinch of salt to a degree, your line ought to be performing slightly better looking at the stats, but the slightly poorer performance could be due to a multitude of things.
Errors in the downstream direction will always be much greater than upstream if everything is running correctly and the total number of FEC errors there whilst seeming rather large (I've seen larger) are not something to get too bothered about at this point. More Important are the CRC/ES/HEC errors and they seem quite reasonable for the uptime and usage. Some error figures are reset on a reboot whilst others only reset at a power down.
Now, to check out whether you are getting the best performance out of your line, there will be a few checks you need to do, but there is one precaution you must take if you want to swap things about or reboot/resync to avoid your speed being banded at a lower rate or you Target Noise margin being raised resulting in lower speed -
Use this Disconnect method -
Do a Disconnect of your PPP Internet session with the ISP - you need to login to the modem/router interface and look for the Disconnect button to click on. On the Thomson modem/routers you will typically find it in the box marked Internet as shown here. Now wait a few minutes, power down. Then wait 10 minutes (during this time swap any filters, modem/router, connect to test socket, etc. - it doesn't matter if you take longer than 10 minutes) and then power up again (You may need to login to the modem/router and click on Connect to re-establish the PPP Internet session). Check the stats immediately (The Noise Margin [SNRM] shown is usually the current Target Noise Margin).
I usually recommend you do this no more than 5 times in an hour, and then leave it alone for the rest of the day.  Remember the reason for this procedure is to help prevent the exchange DLM from thinking you have a dropping connection.
You can user the Disconnect/Connect (without a power down) to Gateway hop.
If you just want to reboot/resync make a cuppa in the intervening 10 minutes.
Which socket are you currently plugged into and was it the test socket you were plugged into in your initial checking you mention in your OP?
Do you have any fixed extension sockets and wiring? Are you using any extension leads between the socket and filter or filter and modem/router?

[#5]

Hi Anotherone, thanks for taking a look.
I'll heed your advice about disconnecting to prevent me from being banded at a lower rate.
I'm currently (and have been since I started testing) plugged into the test socket, and there is no internal extension from the master socket. I didn't notice any difference from switching between plugged into the master socket normally or plugged into the test socket. There are no extension leads. My phone is cordless, but I had tested disconnected and unplugging it from the mains, and still got disconnections before (it's fairly modern, so I'd hope that wouldn't be a problem too).

[#6]

Oh also, would you know what this means?:
"cleared h/r diss off line now test ok confirmed line working and sync with cust"
h/r diss?

[#7]

Hi psan,
Are you experiencing any difficulty with your connection or were you just wondering about the errors? I've just checked the line and I can't see anything obvious that would cause issues.
Jojo

[#8]

In simple terms, an hr dis is a bad joint, so a fault was fixed which was the obvious cause of your initial problems.
Good, re sockets etc. With the cordless, just try a check on the SN Margin Down (7.2 in your last stats) more commonly known as SNRM, check the figure and then turn the handset as well as the base station off and likewise with any mobiles. Refresh the stats page and hopefully you won't see any significant change in the SNRM. Post the stats if you are doubtful.
One other tip, when/if you want to reboot/resync (always using the Disconnect procedure) try to do it in daylight hours when noise levels are generally lower, gives you a chance of a better sync speed. By the way, the Disconnect procedure won't prevent Banding or raised Target Noise Margins, it significantly reduces the chance of it happening if you have a dropping connection, but in that case DRM can do it anyway if things are severe enough.

[#9]

Thanks Jojo,
I was getting disconnections repeatedly, which for the past few days haven't been happening. Line interleaving was switched on, and so my latency is quite high now (minimum of 50ms round trip it seems). I was wondering if an underlying fault had been fixed, meaning that line interleaving could be switched off. However, if that returns me to being repeatedly disconnected, then I'd like to keep the current set-up.
I've noted some webpages being slow to load, had a couple of disconnections with games, and wondered if they were due to a fault in my connection or a fault on their end. When I saw the error rate, I thought I should ask if this was normal, as I think I've done all in my power to resolve any problems here.
Cheers,
PSan
[also, just saw Anotherone's reply, thanks for that info. Good to know these things! If a bad joint was fixed, then that sounds like the problems I was having won't be likely to happen again soon (or at least that's one problem out of the way).]

[#10]

Try ping bbc.co.uk and ping ntp.plus.net at a Cmd prompt to get a better idea of your ping times that doesn't involve servers that you don't know about.

[#11]

Okay, results not looking great, thought I'd post the full results as you can see there's some timeouts (full info here http://pastebin.com/F7sWEWrf):
Pinging www.bbc.net.uk [212.58.246.91] with 32 bytes of data:
Ping statistics for 212.58.246.91:
    Packets: Sent = 20, Received = 18, Lost = 2 (10% loss),
Approximate round trip times in milli-seconds:
    Minimum = 49ms, Maximum = 975ms, Average = 102ms
Ping statistics for 212.159.13.49:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 48ms, Maximum = 80ms, Average = 50ms
I then followed this with a n=50 ping test of ntp.plus.net:
Ping statistics for 212.159.13.49:
    Packets: Sent = 50, Received = 33, Lost = 17 (34% loss),
Approximate round trip times in milli-seconds:
    Minimum = 48ms, Maximum = 64ms, Average = 51ms
However, I think due to this machine connecting wirelessly, there may be some trouble, so I telnet'd into the router and tried a ping to ntp.plus.net:
!!!!!
--- ping statistics ---
5 packet(s) transmitted, 5 successful, 0% loss
rtt min/avg/max = 46 / 46 / 46 ms
{pete}=>: ping proto=ip addr=212.159.13.49
Legend : Ping successful(!)
        Ping Timeout(.)
        Hit ctrl-g to abort...
!!!!!
--- ping statistics ---
5 packet(s) transmitted, 5 successful, 0% loss
rtt min/avg/max = 45 / 46 / 47 ms
{pete}=>: ping proto=ip addr=212.159.13.49
Legend : Ping successful(!)
        Ping Timeout(.)
        Hit ctrl-g to abort...
!!!!!
--- ping statistics ---
5 packet(s) transmitted, 5 successful, 0% loss
rtt min/avg/max = 45 / 47 / 50 ms
{pete}=>: ping proto=ip addr=212.159.13.49
Legend : Ping successful(!)
        Ping Timeout(.)
        Hit ctrl-g to abort...
!!!!!
--- ping statistics ---
5 packet(s) transmitted, 5 successful, 0% loss
rtt min/avg/max = 45 / 46 / 47 ms
{pete}=>: ping proto=ip addr=212.159.13.49
Legend : Ping successful(!)
        Ping Timeout(.)
        Hit ctrl-g to abort...
!!!!!
--- ping statistics ---
5 packet(s) transmitted, 5 successful, 0% loss
rtt min/avg/max = 46 / 46 / 47 ms
{pete}=>: ping proto=ip addr=212.159.13.49
Legend : Ping successful(!)
        Ping Timeout(.)
        Hit ctrl-g to abort...
!!!!!
--- ping statistics ---
5 packet(s) transmitted, 5 successful, 0% loss
rtt min/avg/max = 46 / 50 / 62 ms
{pete}=>
Similar results for bbc.co.uk.

[#12]

First lot wirelessly not so clever, maybe strong interference on that channel?
Last lot not so bad (for an interleaved line). Give your Exchange VP status a check out

[#13]

Hi psan,
I'd see how it goes overnight and if you want we can look at taking interleaving off and see what happens.
Jojo

[#14]

VP capacity: Green.
Yeah the wireless side of things doesn't look so great, I'll have to run an ethernet cable I guess, just bought one and fixtures for it.
Thanks Jojo, I'll see if we get any disconnections and  get back in contact tomorrow. I'd like it if my line was good enough for interleaving to be off, a low ping is always nice, but of course a stable line is better than a low latency one that's only up sometimes.
Thanks for both of your help,
Psan

[#15]

No probs with the help. If you want to try changing wireless channel see here. I'll leave you to it and see how it goes