In answer to a question in your previous post, I run Norton Internet Security 2013 pretty much on at its default settings. It does run “idle time scans” but there is no fixed scheduled time for running these – Norton decides when to run. I have looked at the Norton logs and, as far as I can see, there are no Norton tasks running regularly between 02:00 and 03:00 hours. Also there are no Windows system tasks scheduled at that time and nothing in the Windows system logs jumps out at me.
I believe I have found a workaround that seems to deal with 'other' PC activities causing the data harvesting process to slow down.
Ronski has just started looking into how to automate it for W8, W7 & Vista users. It doesn't seem to affect XP users.
I'm planning to release an update to the programs quite soon, so hopefully it can be incorporated.
It doesn't actually cause any connection issues & if data harvesting is completed within the minute, it doesn't affect the harvested data or the operation of the programs.
Occasionally, the slowdown would cause harvesting to take more than one minute on my system (as opposed to the usual 2 seconds or so), which did cause a very slight issue now & then.
Having said that, I note from the graphs that the number of US_RSCorr errors dramatically increases at 9:00pm every day (see attached graphs). This is replicated in the previous set of graphs (ie at 9:00 pm on 4/10/13) that I posted. It suggests to me that there is some external event happening which is creating interference? Am I wrong in inferring this from the data? I cannot think of anything electrical in the home that switches on/off at this time of day that might cause this.
That's an interesting observation, especially as it does appear to occur at exactly 21:00 each night.
As to its cause, I don't know what it could be other than something on a timer.
If it's nothing in your house, it might be at a neighbour's house, sending a spike of interference down the mains power cable at VDSL2 US frequencies that is detected at your end.
(Maybe for example central heating switching off - causing some arcing that isn't present when it switches on?
??)
The fact that they are RSCorr errors shows that the modem is dealing with them & not needing the same data to be retransmitted.
It doesn't seem to be sufficient to have caused DLM to intervene by applying US Interleaving across the board (so far).
The graphs make sense as my US speeds seem to be the path that is deteriorating the fastest. I’m currently trying to plot the data from previous speed tests to determine if there is a definite trend in that area. Using the BT retail speedtest website today at 13:07 produced a figure of 5.44 for the US speed which is ridiculous – historically it is normally over 15. This is not the the first time I have observed this behaviour.
As there is nothing of note in the connection's data/graphs from around that time, I can only put it down to the router or external network congestion.
If you are using a HomeHub as the router, I read a while ago that some users who experienced similar issues factory reset it a number of times in quick succession which seemed to permanently resolve the issue.
I notice from your prevous 'snapshot' graphs that your power in the U1 band is -18.5dBm, which isn't captured in the version of graphpd.exe that you are using.
It will be included in the updates, but in the meantime you may wish to use the attached graphpd.exe in place of the one you have stored in the Scripts folder.
The Power Y axis now goes down to -36dBm for both DS & US power.
By all means, feel free to zip the modem_stats.log & ERROR.LOG that are stored in the Ongoing_Stats folder & post them as attachments.
I'll take a closer look at the data at my end.
TBH though, I can't see much wrong with your connection at all.
I believe the DS & US speeds look about right for the line length & it does appear to be very, very steady.
It's a shame that unlike ECI DSLAMS, Huawei DSLAMS never report US Hlog, QLN & SNR.
However, one user has provided proof that his band plan tones have recently changed & US data can now actually be seen in his graphs.
This may be BTOR trialling something at his DSLAM or it could be the start of an update for all users.
The previous change to DS tones from 3939 to 3959 wasn't announced at all by BTOR, but users started to see it over a period of a few months.
(see the attached 'snapshot' montage & spot the difference in the graphs (US shown in green) & the revised band plan tones in the pbParams data).
