If an unfiltered phone was plugged in to a star-wired extention, the SNR would likely move when the phone was used. My point was that it could be anything causing the problem, and anybody perusing this thread may instantly jump to the wrong conclusion that it has to be a REIN issue !
A full circuit 'Health check' must be undertaken, before conclusions can be drawn. 
I'd agree with Black Sheep, but I have also noticed a couple of things from data posted in this thread and the one in the TBB forum.
Looking at your snapshot graphs, your Hlog graph doesn't immediately jump out as reporting any bridged taps that tend to negatively affect sync speeds.
It is a little 'wavy' in the D3 band, but I don't think it's sufficient to be concerned about.
Although being connected to a Huawei DSLAM, we unfortunately can't see any upstream data in the Hlog, QLN & SNR graphs.
Upstream data is 'sometimes' reported when using a HG612 connected to an ECI DSLAM.
There is a small dip in the bitloading graph for the upstream U2 band that
could indicate a slight issue though.
Your DS_OHF & US_OHF graphs look a little unusual.
Those spikes tend to be due to the harvesting program (HG612_stats.exe) taking longer than usual to harvest the data & calculate any differences from one minute to the next.
I have attached an example from my connection showing really steady DS_OHF data, apart from when my daily virus scan & virus definitions update kick in, more or less hogging all the PC's resources for a while.
When that happens, it can take much, much longer than the usual couple of seconds to harvest/calculate data before writing it to modem_stats.log.
So what spec is your PC & do you have a resource hungry program or programs running 24/7?
Take a look at maybe one hour's worth of data in the ERROR.LOG file (stored in the Ongoing_Stats folder)
Each minute's harvesting/logging event shouldn't take more than 3 seconds as an absolute maximum.
If the PC's spec is reasonable, no resource hungry programs are running & yet it still takes a long time for the harvesting etc, that may be some sort of a clue as to the cause (I don't know what it would point to though (yet)).
It does seem very strange that SNRM is affected to more or less the same extent in each of the 3 completely separated US frequency bands, yet the issue isn't there at all in the DS frequency bands that lie between the US bands (see the separate DS & US SNRM graphs near the bottom of your FULL_MONTY montage).
@ BS,Have you seen any similar issues where only US SNRM is affected on a VDSL2 connection & if so, was it diagnosed as line fault?
How close is the modem to the PC?
The PC itself, its monitor, router/modem power adapters etc. etc. could actually be the cause of the interference that results in lowered US SNRM.
How close is the modem to any other electrical equipment and/or mains power cables/sockets & how close is it to the master socket.
Does any of the timings coincide with switching lights on/off?
I believe LED or flourescent lights can occasionally cause problems.
I see that you are currently running the connection via a dangly ADSL filter plugged into the master test socket, yet the issue is still present.
I suppose that means that unless something else is wired from the wrong part of the master socket, we can rule out any other internal telephone wiring issues.
You did completely remove the whole faceplate to get to the main test socket didn't you?
EDIT:
One other thought........
Is your modem's power adapter plugged directly into a mains socket or an extension lead, possibly including some sort of surge protection?
Author
Topic: How long does DLM decide to change settings? (Read 19626 times)