I had a laptop running DSLstats overnight showing the errors and snrm. The errors increase about 9pm and tail off about 4am. The connection has held. On ASDL the connection would drop at the start of incoming phone calls and during heavy showers where as with the fibre there is a 2db noise margin drop at the end of a call. Still a massive improvement as far as speed goes over the 2mb ASDL.
Definitely an improvement.
I'm also concerned about the ES count reaching as high as 2,000 in a 24 hour period. It won't take much of an extra "blip" for DLM to think that something further is needed.
On the positive side, DLM has only put an INP value of 43 in place so far. I suspect that, if it thinks you need it, it will change this value to something higher - we've seen it reach into the low 50's.
If we take the line length of 1.8Km into consideration then I suppose it's doing the best it can
It is doing surprisingly well for that distance. There must be a good portion of thicker copper involved in this connection...
I did read somewhere about a Billion 88ooNL syncing higher but with a higher error rate than an Openreach modem.
I was helping a guy on the TBB forums a week ago with an issue like this; the 8800NL gave better sync speeds, but a much worse error rate. He currently has an HG612 in place, which syncs at a lower speed, but gives him much fewer errors (including the all-important ES rate).
In that case, the high error rate was originally masked by the fact that G.INP was activated before the noise started. It only became apparent when the user swapped to a new ISP, which triggered a DLM reset.
After the reset, DLM *really* didn't like the errors, and put "old-style" intervention in place instead of G.INP retransmission; presumably it thought G.INP wouldn't cope. Once he put the HG612 in place, errors reduced, DLM relented its intervention, and then allowed retransmission to be re-activated. All is pretty quiet at present.
His stats can be seen on MyDslWebStats, where he has accumulated over a year of data. I've attached one snapshot as an example, where you can see the errors start up in November, and the switch of ISP near the end of April.
From the glimpses of graphs, your line isn't suffering anywhere near as badly. It would be good to see the graphs for rtx_tx, rtx_c and rtx_uc alongside the CRC and FEC graphs, as those should demonstrate the same kind of pattern.
One thing which I've just read in ~ Data Analysis [Step 1]
"Each of the 96 bins are checked to see if there has been user activity and marked active or dormant."
That's interesting. I'm not sure how much of an effect this has, but we will find out one day...
The errored seconds for the last 24hrs were about 1200 but I reset the Billion router stats not realising it would reset the telnet data so cannot post them. Anyway It's below 2880 and the DLM hasn't intervened since it enabled G.INP and the connection hasn't dropped after 3 days. So changing from the Hub One to the 8800NL has improved the speed and the stability
As I said above, I'm still worried that it won't take much of a nasty day to send your stats over the edge.
If you resync the line at a time of day when your SNRM is at its
lowest (any time between 11pm and 3am looks OK), then you'll likely sync at a slightly lower speed but will
probably get fewer errors.
If the error rate looks like it is increasing too much, remember that you have this tool in your arsenal. However, I suspect DLM might try increasing the INP value before attempting anything more drastic.