FTTC Issues - excessive resyncs, unusable internet and lacking speed

[#1]

Quote from: Ronski

I've uploaded today's graphs to Drop Box, the SNR seems to do a wobbly after 11:00am, and a lot of DS_RScorr errors before 11:00am

Yup - RSCorr is showing the same thing as my previous analysis, but I don't think that is what lead to the resync - as the ES and RSUnCorr graphs are showing that not a lot was being reported at the time (ie every "apparent" fault was being corrected).
But, when the resync happened, there was indeed a large change in the downstream interleaving. The numbers there (B=34, N=43) look quite severe (34 bytes in 43 are your data, while 9 bytes in 43 are parity overhead - or 21%), suggesting heavy interleaving.
What stands out to me, that is new, is that the TX power for upstream has dropped dramatically (in the Ongoing stats), which shows in the Current stats too - mostly as a drop in the TX power for the U2 band.
The overall reduction in upstream capacity mostly shows in the "bit loading" graph, where we can see that there is very little data being carried in the U2 band (it used to use up to tone 2750 or so, but now includes up to tone 2200 only)

[#2]

Quote from: Ronski

I can try it without the UPS, although I think I'll wait until after the engineers been.

I can understand that.

Quote

It would be a bit tricky to get seperation on everything, I have moved the DECT phone out into the hallway about 3 meters away, this was done Saturday morning about 07:45. I had previously tried using the phone whilst monitoring the connection and it appeared to make no difference, and we generally use mobiles for calls, and there no calls during the two strange episodes of errors.

Apart from what the engineer will investigate, I suspect that what you can do is just gradually eliminate individual pieces of equipment from the puzzle. Either disconnect it or switch off until you get another batch of the RSCorr errors to eliminate it. Or (if you are present at the next batch) start turning things off to see if the errors stop without a resync.
My gut still suspects the modems, one way or another, because of the errors with no apparent change in SNR, and the fact that you return to a perfectly stable connection after a resync without much change in the sync speed, or a dramatic difference in the bit-loading graph.
Another thing I'd love to see is if, during the error phase, you are encountering any bitswaps. However, I don't know if we can get that information out of the modem.

[#3]

I've added scripts to my server to generate Current Stats graphs every hour, and also to generate the ongoing graphs at midnight everyday, these will be copied to my office PC and then uploaded to Dropbox daily.
I could relocate the server upstairs to my office, and also remove the UPS, even relocate the router with some long cables.
I have some lead at home, perhaps I'll make a sheild to stand in front of the modem - maintaining airflow of course, see if it has any impact.
I'll leave all this until after the engineer has been.
Need to prepare some graphs and other questions (as you've listed) for when he arrives.
PS. Had another resync at 6am this morning

[#4]

It has just struck me that you are using a HG612 connected to an ECI DSLAM.
Having monitored a few such connections, it appears that batches of massive RSCorr errors all together may just be a bit of a red-herring.
It seems to be typical behaviour for a HG612 connected to an ECI DSLAM.
At this time we don’t know if ECI modems are also affected in the same manner.
I have not really seen such a phenomenon from a HG612 connected to a Huawei DSLAM.
I understand that batch files cannot handle integer maths with values higher than 2^31. i.e. 2147483648.
Once the connections reach that sort of cumulative RSCorr value the values are simply too high for any batch file calculations at all, although cumulative totals are still recorded in the modem & in modem_stats.log.
It appears that when RSCorr cumulative values reach 2^32 i.e. 4294967296 without a resync, the HG612 resets RSCorr values to zero & starts all over again.
It does appear that “something” triggers a sudden increase in RSCorr errors on the connections I have monitored & once triggered, RSCorr errors tend to mount very quickly, only really ceasing when they are auto-reset to zero by the modem, or the connection resyncs of its own accord or manually.
With other help and advice, I am currently trying to rewrite the scripts using compiled ‘C’ code that can use much higher values & calculate “delta” one minute differences data much more efficiently.
These programs are not yet ready for public use or even public beta testing, but it is hoped they soon will be.
They are being written with the aim of re-using existing modem_stats.log files, but including even more data.
In the meantime, it may be wise to focus on other “problem” areas for any HG612 modems connected to ECI DSLAMS.
The 6 am resync may just have been due to DLM seeing some stability & low(ish) error counts, thus causing a resync to implement a lower Interleaving depth as seen in the graph?
Despite the above caveat regarding RSCorr error counts, something still seems physically “wrong” with your connection, or some external source is causing interference issues.

[#5]

The engineers just been, carried out quite a lot of tests - was here for about 90 minutes. He found no problems, he was going to carry out a lift and shift (change the pairs at the cab) but he was told not to by someone he phoned. They are going to reset the profile, but I don't think this will make any difference to the constant re-syncs (time will tell of course) or the strange episodes.
He didn't want to look at any graphs as he said it all went over his head  

[#6]

Just had a phone call from the engineer, on the way out the estate he passed the PCP/DSLAM and someone was working on it, so he stopped. Turns out it was a technical officer, remaking connections as there had been a lot of problems with that particular cabinet. So hopefully that will solve the problem, may also explain why the engineer didn't see any error faults in his tests. He did spot the modem resync (DSL light went off) when he first arrived, and the guy at the cabinet said that was about the time when he started working on it.

[#7]

Hope so! just to let you know that your ticket has also been updated.

[#8]

Very interesting!
When installing FTTC, the "ordinary" engineers only make the connections within the original PCP - they're not allowed into the FTTC cabinet at all. That means the presence of someone at the FTTC cabinet is significant indeed.
Also interesting, but not in a positive way, is what this shows in terms of "left hand not knowing what the right hand is doing". While it is nice to see that there is *someone* who oversees the FTTC deployment for common faults, it isn't so nice to see that this information doesn't percolate down to the customer-facing engineers, the customer-facing ISPs (like Plusnet) or the customers themselves.
Anyway, this probably means we just start monitoring afresh...

[#9]

I've noticed over the last few days that my connection has been behaving strangely.
The attainable DS speed is fluctuating up and down, and has increased, reaching over 60Mbps, and the US has halved to around 5Mbps.
I've had 4 resyncs this morning looking at my ping graph, interleaving dropping slightly perhaps, resyncs yesterday and Monday as well.
All my stats and graphs can be seen here
My connection has never been quite right, with substantially slower speeds than my neighbour - here's my original thread
The Bald Eagle has said it is certainly behaving very weird, hopefully you can convince OR to take a look at it, or even swap the pairs, there is certainly a fault somewhere even if they won't admit to it.
Tonight I will produce graphs for the entire duration I've had FTTC and upload them to Drop Box.
(I've PMed the above to Alex Rolls but forgot to click the check box to save a copy! Edit, I've found the option to automatically save PMs)

[#10]

Quote from: Ronski

I've had 4 resyncs this morning looking at my ping graph, interleaving dropping slightly perhaps, resyncs yesterday and Monday as well.

Just a quick note:-
If these resyncs were very quick (as is usually the case), they won't necessarily show in Plusnet's own logs i.e. if they were too quick to initiate a new PPP session.
However, I do know that you have your own  accurate & detailed raw statistical & graphical evidence should it be needed & subject to anyone at the provisioning end being willing to look at it.

[#11]

Yes that is correct Paul, I've got all the stats going back to about 20 minutes after I was connected.
I've uploaded a set of graphs to drop box showing the entire 150 days I've been connected, it would seem that the DS power has been increased, and the US power decreased looking at the graphs.
And today's static ping graph

[#12]

Hi, I've raised a ticket (69505543), as my modem resynced to fastpast on the 6 May at 47007kbps, but my Plus Net Line profile is still set at 42.2Mbps.
I have since rebooted the router (NOT modem), and even turned the router off for a short while to force a new PPOE session which is supposed to trigger an update of the PN line profile, but hasn't.
Full graphs for the entire period I've had fibre can be seen here on Dropbox
I've not been on fastpath since last September, and had recently updated the firmware, so perhaps that helped.
Although my line is still well under-performing for the distance from my cabinet (450 meter), it'll do for now, just need the PN line profile tweaking please 

[#13]

Hi Ronski,
I've updated your profile

[#14]

Thanks Chris