Recurring fault: CRC errors from 4am every couple of days

My previously stable line has developed a fault. It runs with zero errors until 4am, then begins flooding with CRC errors. A resync stops the errors without changing any line characteristics: rate, margin, G.INP, bitswap all remain identical but the errors stop.

This would be okay if I could just resync every day and stop the errors, but over the course of a few weeks DLM responds by dropping the line rate. I dropped from 48 to 20Mbps and required an engineer visit to test the line and reset the DLM. It went back to 48 and started over. He couldn't find a fault but couldn't swap line pairs because the cabinet had no spare.

Any ideas how I get this resolved? I really don't want a monthly engineer visit just to reset DLM.

It sounds like either something electrical coming on or a router issue, seen as the problem dissapears after a router restart. When the issue arises, please can you complete a quiet line test by dialing 17070 and selecting option 2, if you use a cordless phone any distant hiss is normal, but it's best to use a corded phone if you can.

Please can you post your line stats from the router? It may be worth uploading (if you haven't already) to MDWS: https://www.mydslwebstats.co.uk

Edited by deleted (Sun 19-Mar-17 16:15:15)

I'm experiencing something similar, over the last month. In my case line speed has dropped from 40, down to 36, 32 and now 30 Mbps. QLT did not indicate any line noise. Happens about once a week but on different days, and occurs from a hour or so, to several days up to a week before the line stabilises (errors disappear altogether, up to 10% packet loss disappears and max and average latency return to the same as minimum, which stays unaltered throughout according to TBBQM). Only affects download.

My Broadband Ping

Haven't reported anything as the line is still usuable (although there can be what I assumed was a separate problem with DNS resolver), and only seems to drop when it stabilises. Router reboots when it's occurring make no difference.

Stats taken from Fritz!:
Line stable since 6am today
Negotiated Connection Properties
Receive Direction Send Direction
Max. DSLAM throughput kbit/s 30000 6000
Min. DSLAM throughput kbit/s 128 128
Attainable throughput kbit/s 29996 6507
Current throughput kbit/s 29996 6000
Seamless rate adaptation off off

Latency fast fast
Impulse Noise Protection (INP) 44 0
G.INP on off

Signal-to-noise ratio dB 12 7
Bitswap on on
Line attenuation dB 24 24

Profile 17a
G.Vector off off

Carrier record A43 A43

Error Counter
Seconds With Not Remediable Errors (CRC)
Errors (ES) Many
Errors (SES) per
Minute Last
15 Minutes
FRITZ!Box 0 0 0 0
Central exchange 17 0 0.03 3

Only difference when line is misbehaving is that download attenuation rises to 37 and errors accumulate in the up to hundreds per hour at the Fritz!. Historically (for 6 years) download SNR has been in the 9-11dB range, at a consistent 40Mbps download.

I assumed it was just the underground line suffering from damp as winter turns to spring, and that (new) G.Inp was reacting to the line conditions. I was therefore rather hoping that warmer weather would eventually sort it out.

Edited by deleted (Sun 19-Mar-17 18:16:03)

My Fritz!Box 7490 allows VDSL2 resync without a reboot. I tried the old Huawei and saw the same, so I'm back with Fritz since it's a far better solution.

During the errors the quiet line test is perfect; I have a wired phone just for this test.

I left the line erroring for the engineer to see, but as soon as he disconnected the router and connected his equipment the line bounced and the errors again cleared. The line test was perfect, but he changed the NTE as a matter of course.

Here's the outcome of the errors: ~5% packet loss until I resync.

https://community.plus.net/t5/image/serverpage/image...

Interesting that we both use Fritz!Box. Are you using a 7490 on the latest code (6.80)?

In reply to a post by DougM:

Interesting that we both use Fritz!Box. Are you using a 7490 on the latest code (6.80)?

Yes, to both.

I recall a widespread problem with the 7390 firmware a couple of years ago, when it was incompatible with some BT firmware modification? Upload speeds collapsed, but as I recall neither TBBQM nor the Fritz stats indicated anything untoward, merely the upload synch speed collapsed. I suppose we have to wait and see whether anyone else reports!

Edited by deleted (Sun 19-Mar-17 18:52:18)

I know. Sorry, I best leave this to the experts.

There is an advanced option to roll back the DSL to the previous firmware's implementation; I'm going to try that next.

I'll also use the in-built option to report the problem directly to AVM. It's the last tab of the DSL section.

I highly doubt that'll fix the issue, to say this is occuring at the same time of day. It's likely to be electrical interference from a device powering on.

Perhaps, but interesting that smurf46's problem also kicks off at 4am and is running identical hardware. Plus 4am's the time DLM seems to favour triggering changes.

Possibly a coincidence, but highly suspicious.