Is drop in Target SNR Margin (6->3) normal after SNR reset? UPDATE

[#1]

Hi,
Following a couple of random (i.e. unexplained) triggered rises in Target SNR Margin in December from 6dB to 9dB and then to 12dB I did a couple of things here (replaced a very faulty dimmer switch, changed a fish tank pump and reflashed my Netgear 3500 with a revised firmware) and requested a SNR reset via the Help Assistant system. This was very efficient btw - requested 08:30 Wednesday, took place 14:20 Wednesday .
The Target SNR Margin went back to 6dB as requested on Wednesday (synced at 16610), but often crept up a fraction to 6.1-6.2dB. It never disconnected until today, when after 72 hours of unbroken connection since the reset I had to do a manual disconnection and a 10-15minute switch off to do a quick electrical job. I switched router back on and still had my target SNR Margin of 6.0, still creeping up to 6.1-6.2dB, synced at 16759. There were a total of 491 errored seconds over a 72 hour period prior to this and 13 severely errored seconds reported by the router.
However, this evening the router has disconnected and reconnected with a target SNR Margin of 3dB and a sync of 18778 kbps.
Is this just part of the training period (I have never had this happen following a SNR reset before)?
Furthermore, given that in a couple of hours I have already had 103 errored seconds and 6 severely errored seconds, is the system likely to raise it back to 6dB (not a problem if it does by the way)?
The reported SNR margin is actually at 2.7dB at present. The 'interleaving depth' reported by the router has risen from 96 bits to 320 bits.
Sorry for the rambling background information. I really just wondered if all this is the 'training period' doing it's thing?
Thanks.
As a footnote, the Plusnet Line speed hasn't changed for 9 days and is still at the speed from before all this happening!
Edit: Changed title

[#2]

Offbeatdave,
Sounds good to me.  If your line is stable, the training period will try to reduce the SNRm to deliver more speed.  The big question here is what is the difference between the PN reported speed and your STABLE synch speed?
Do you by any chance have connection with the offbeat brewery in Crewe?
Cheers,
Kevin

[#3]

Resetting target noise margin causes the line to re-enter a 10 day training period making DLM activity and disconnections more likely. However here it looks like the DLM decided line performance might support a 3dB target noise margin, so it is giving this a try. From your comments it doesn't look as this was a good idea, in which case the DLM will most likely raise the target to 6dB again in 24 hours.
The DLM on 21CN can be noticeably active - some might say aggressive. The main thing seems to be to leave it to 'get on with it' - trying to 'help' by forcing target SNRM or even restarting the router can be counter productive.
The problem with Plusnet's Current line speed not tracking the BT IP Profile in a timely manner has been ongoing for over a year. There are a (large) number of threads on this forum concerning this problem. When this happens either post on here to request it be updated or raise a ticket.
David

[#4]

Cheers for both the above responses. I shall just let it do it's thing. The good news is that the line itself seems stable under 'normal' conditions (i.e. target SNR Margin of 6dB)

Quote

...what is the difference between the PN reported speed and your STABLE synch speed?

The PN speed currently reports 15.6Mb from before the glitch and reset. The IP profile was 14.7 when the initial reset took place (but PN line speed remained unchanged). The IP profile is now up to 16.6, although this may be short lived if the target SNR Margin reverts back to 6db. Again just shows how glitchy the PN line speed system still is though..   I have found in the past that a quick visit to the Help Assistant sorts this out pretty rapidly.

Quote

Do you by any chance have connection with the offbeat brewery in Crewe?

Unfortunately (as I am a real ale fan), sadly not! I wish I did!
Sups his Bateman's (local ale)

[#5]

Just an update on the above really, mainly for my own benefit so I don't lose the details!
To recap:
Wednesday 2nd Jan @ 14:20, target SNR Margin reset, sync 16610kbps,
Interleaving Delay 8 ms, Interleaving Depth 96 bits
IP Profile 14.65Mb
Saturday 5th Jan - After 3 days, no disconnections, reconnections other than one forced by me after 72 hours
Errored seconds 491, Severely errored seconds 13 (after 72 hours)
Then late on Sat 5th Jan, system reconnected at target SNR Margin of 3db, settling around 2.5-2.8dB, sync 18779kbps
(Note: I am not artificially forcing this down - I guess the system thought the line looked nice and stable.)
Interleaving Delay 7 ms, Interleaving Depth 320 bits,
Errored seconds 103, Severely errored seconds 6 (after 2 hours)
IP Profile 16.56Mb
From Saturday evening until yesterday (Tuesday) evening, the line remained connected, wracking up an awful lot of errors.
Errored seconds 21618, Severely errored seconds 3119 (after 72 hours)
I presume this number of errors isn't a good thing. 
However, last night (and indeed on Monday) I seemed to be having big speed issues - the 'net would crawl at 1000kbps or stop altogether.
Last night I did a couple of disconnect-switch off-wait-reboot-cycles over a couple of hours.
This seems to have fixed it and I'm running up to speed again.
As a result of these forced reboots, I'mow synced a tad higher at 18864kbps.
Interleaving Depth has reduced to 96 bits.
The target SNR Margin is still 3db (still actually reported as 2.2-2.8dB)
Errored seconds 334, Severely errored seconds 29 after around 24 hours
IP Profile 16.64Mb
All in all, things seem to be running smoothly again at this low target SNR Margin. 
I will shortly be requesting a PN line speed nudge via the Help Assistant though, as it still hasn't changed to reflect even the first IP profile change a week ago!

[#6]

I've changed your profile to 16.6MB/s, so it's now correct according to your sync speed  and at the moment everything looks fine running at 3dB

[#7]

Thanks for that. I've closed the Help Assistant ticket.