Is this a record?

[#1]

It's not any easy thing to monitor on 20CN because you don't get any other clues - from the stats you don't see variation in Upstream SNRM at all on 20CN as you do on 21CN and you'll need to be pretty OCD checking the Bits/Tone and Bit swaps with the shortest sampling time that you can.

[#2]

Incoming phone call at 17:53.

<173> Apr  2 17:53:10 xDSL linestate down 
<173> Apr  2 17:53:23 xDSL linestate up (ITU-T G.992.1; downstream: 7616 kbit/s, upstream: 832 kbit/s; output Power Down: 19.8 dBm, Up: 12.5 dBm; line Attenuation Down: 21.0 dB, Up: 13.5 dB; snr Margin Down: 6.1 dB, Up: 11.0 dB) 

I think this suggests it wasn't just the upstream that failed as the bit swaps are across the whole range.

[#3]

Can't remember if you are on a fixed IP, I think you are, so I don't know how easy it is for you to see if you lost PPP.
But in any event, that's by far an insignificant number of Bitswaps compared to what I saw in my tests, see attached - not that I think one can draw any significant conclusions as to what's happened in your situation (unless there was loss of PPP perhaps).
Have you had any ring-trips at all? I'm suspecting that if it's not an exchange or tie-pair fault, it's more likely to be an HR or partial Rectified Loop fault somewhere on the line which could well be intermittent unless it's happening with every call.

[#4]

It's a doddle to see if PPP is lost - there will be entries in the router log. Also if you look at the Visual Radius graphs from Plusnet there are no drops shown at times when the router log shows a drop in xDSL.
Even though I am not losing PPP it is causing me problems. The VPN times out and has to reconnect. If I am in the middle of a VoIP telephone call it drops.
Sync is lost for every incoming call, even if there is no actual phone plugged in to the filter. Outgoing calls don't cause a problem.

[#5]

Obviously the Vis Radius shows no previous losses of PPP, I was specifically referring to your last reported event and in the context of the Bitswaps. So I'm assuming from the tone of your reply, the router log showed no loss of PPP this time as well!
I presume your fault has been bounced back to BTw?

[#6]

Correct. No loss of PPP. I'm considering unplugging the router from the filter for half a minute or so to show you what appears in the log on a loss of PPP.
It can't be bounced back to BTw at the moment because of the open phone fault which BT think is between the CAB and me (that's what their remote test said). I'm going to let that run first to see if it makes any difference.

[#7]

Ok,so it's still ongoing. As far as the logs go I expect you'll be showing something like -
<132> Mar 11 06:00:15 PPP link down (Internet) [87.112.98.119]
<85> Mar 11 06:00:15 FIREWALL event (1 of 1): created rules
<85> Mar 11 06:00:15 FIREWALL event (1 of 1): modified rules
<39> Mar 11 06:00:31 PPP CHAP Receive challenge (rhost = ERX6.Reading2)
<39> Mar 11 06:00:31 PPP CHAP Receive challenge (rhost = ptw-ag04)
<35> Mar 11 06:00:32 PPP CHAP authentication failed (Internet)
<39> Mar 11 06:00:48 PPP CHAP Receive challenge (rhost = ERX6.Reading2)
<39> Mar 11 06:00:48 PPP CHAP Receive challenge (rhost = thn-ag03)
<35> Mar 11 06:01:06 PPP CHAP authentication failed (Internet)
<39> Mar 11 06:01:34 PPP CHAP Receive challenge (rhost = ERX6.Reading2)
<39> Mar 11 06:01:37 PPP CHAP Receive challenge (rhost = thn-ag03)
<35> Mar 11 06:02:04 PPP CHAP authentication failed (Internet)
Except yours will authenticate straight away, unless like me you left the password out (on purpose).

[#8]

Well I didn't see what I expected to see and I bet you wouldn't have guessed it either:

Quote

<173> Apr  2 21:31:17 xDSL linestate down <173> Apr  2 21:31:52 xDSL linestate up (ITU-T G.992.1; downstream: 7616 kbit/s, upstream: 832 kbit/s; output Power Down: 19.9 dBm, Up: 12.7 dBm; line Attenuation Down: 21.0 dB, Up: 13.5 dB; snr Margin Down: 6.1 dB, Up: 12.0 dB) <132> Apr  2 21:31:59 PPP link down (Internet) [80.229.*.*] <38> Apr  2 21:32:12 PPP CHAP Receive challenge from rhost ERX2.Reading2 (Internet) <38> Apr  2 21:32:12 PPP CHAP Receive challenge from rhost ptn-ag01 (Internet) <38> Apr  2 21:32:14 PPP CHAP Receive success (Internet) <132> Apr  2 21:32:14 PPP link up (Internet) [80.229.*.*]

I was expecting the PPP link down to be before the the xDSL linestate up. Perhaps I didn't leave it long enough.

[#9]

I see what you mean by surprising, but actually it's quite logical because when the sync is up it's finding no PPP session so it says "PPP link down". I've sent you a PM as well.

[#10]

The PSTN fault has now been cleared (joints checked and remade outside house and at the cabinet) so PN should be able to push the ADSL fault back to BTw now (it's still dropping on an incoming call).
One interesting point: The test head in the exchange is not working and apparently has not been for some time. It may be false results are being given from line tests. The engineer said this had been reported to the manager who'd done nothing about it! This is making the investigation more difficult for the engineers.

[#11]

SFI engineer expected in the morning - fingers crossed I will get somewhere!

[#12]

Well the engineer has been and done his worst:
Before: Sync typically 7616, Target SNR 6db, Fastpath
After: Sync 5632, Target SNR 15db, Interleaved
Oh, and I'm still losing sync on an incoming call.
The engineer alleged that it's because I'm on Max Premium and that when they dropped it to standard Max the problem went away. He didn't have a lot to say that when I told him I'd previously been on 20CN Max Premium on two different exchanges and I didn't have this issue!

[#13]

The engineer did say I should get back to normal speeds after a couple of hours. I knew that wasn't going to happen as the 20CN DLM isn't going to be quick in lowering my target SNR. I did ask him to request a SNR reset but that was over 5 hours ago - if one had been requested surely it should have kicked in by now?

[#14]

When Plusnet order a SNR reset on 20CN, how long should it take to complete?

[#15]

Up to15 minutes I think. I believe it's a log in and press-a-button task for Plusnet to initiate.