Internet connection keeps dropping

[#1]

PNF,
A result - BTOR engineer appears to have installed a VDSL plate (I hope - two connection ports, one phone like, the other router like?) and also done a lift & shift which is a good step to eliminate exchange equipment issues.  If this is a VDSL plate, you will no longer need a dangling filter for your router / phones as the phone socket and any extension leads will now be filtered.
It is also excellent that the issues were present when the engineer was there, at least he has seen a problem and said he is going to pass this on to the REIN team.  This is where you need to watch the plot carefully with PN.  It is not normal for BTOR to 'hold' responsibility for an issue within BTOR - they more usually pass the issue back to the ISP for the ISP to arrange a further engineer visit.  The reasoning for that is the ISP owns the end user relationship and BTOR can take the view that it is down to them to arrange an appointment with that end user.
I might be proven wrong on this one (I sincerely would like that to be the case) as BTOR retaining responsibility is the approach I've always thought to be correct albeit not widely adopted.

Kevin

[#2]

The faceplate isn't a VDSL plate, it only has a telephone socket on the front, so I will still need to use a filter.  The new faceplate is an NTE5 faceplate with a bell circuit filter, whereas my old faceplate was a BT one without the bell circuit filter.
Yes, I was really pleased that the engineer spotted a problem.  Shortly before he arrived there was a 2dB rise on the line followed by a large drop and a resync which I was able to show him on my PC screen but at that point I thought he'd missed the 'morning event'.  The line has resynced three times since the engineer completed his work at the exchange.  I shall continue to monitor the line.  I don't know whether the work carried out at the exchange will cause the line to go through a 10 day training period, in which case that may result in resyncs.
When discussing the issues and the possible causes, the engineer said that interference could be caused within the exchange if a line on a similar frequency had been installed next to / near mine, hence the reason for moving my connection to another port. 
When calling me from the exchange, the engineer said that I should expect to get a call from the REIN team within 48 hours and indicated that they would come along with equipment that could be tuned to the same frequency as my line in order to firstly detect any interference and secondly attempt to determine its source.  I take note of your point about the issue normally being handed back to PN at this stage, so if I haven't heard from the REIN team after 48 hours I'll contact the PN team. I've added a note to my open fault ticket about what happened today to keep the PN team informed.  Thanks for your advice Kevin.

[#3]

Unfortunately, the engineer was unable to contact the REIN team whilst he was at the exchange and as a result a second engineer's visit is required in order to arrange an appointment with the REIN team.  A second engineer's visit is currently being arranged.
The problems still persist on the line since the engineer's visit.  Since 8th May the line has been on a 9dB profile and has been syncing at about 7900kbps, which is disappointing given that my line was faster than that on ADSL1.  However, despite this, and given that the noise margin is over 13dB for much of the time, the line still resyncs at unpredictable times. For example today, the line was syncing at 8151kbps @ 13.5dB when the noise margin dropped to 6.5dB before recovering to 8dB.  Shortly afterwards the line resynced to 7963kbps @ 10dB and then later the noise margin rose to 15dB, dropped to 7dB, settled at 10dB for a short while before rising to 15dB again.  It's currently at 13dB. (see graphs)

[#4]

A BTOR engineer visited today.  It was the same engineer that attended the last time, a very helpful chap.  He ran various tests on the line, all were OK as the problem was not presenting itself whilst he was here. He has fitted a VDSL faceplate and a radio frequency filter, a small circuit board that fitted inside the casing of the master socket.  Even though the problem was not present whilst he was here, he noted the huge variation in the noise margin, which in theory should have been fixed at 9dB following his last visit but varies between 2 and 15 dB.  He spoke to the REIN team and whilst he was talking to them he tuned a radio receiver to 612kHz and tested outside in the street, as a result of which a case has now been raised with the REIN team.  So that is really good news.
Note:  Just as I was previewing this post the line resynced and then when I clicked on post it resynced again.  Third time lucky?

[#5]

Quote from: pnf

which in theory should have been fixed at 9dB following his last visit but varies between 2 and 15 dB.

Hi,
I think we've covered this before. The 'fixed' SNRM is the target SNRM used when the line resynchs.  As REIN comes and goes, the actual SNRM will go up and down.
Sounds like BTOR has fitted a RF3 filter.  I had one of those fitted and subsequently removed!
It sounds like you've had a very good engineer, hopefully the REIN team will pick up the ball, be warned though that such investigations can be difficult. Keep up the RS logging.
Kevin

[#6]

Just wanted to echo what Townman has just said really - he beat me to posting
I'm glad you've had a good visit, keep us updated if you wouldn't mind so we can all see how we get on to try and resolve the problem for you.

[#7]

Thanks Kevin and Chris for your comments.  I'll be happy to keep you posted on how things progress from here.

[#8]

Excellent news!  The REIN team have been outside today and they have found the problem.  It was a neighbour's Freeview box which has now been switched off.  The engineer called at about 10:45 to say that he was outside investigating and at 12:30 he called back to give the good news that he had found the problem.  He has reset the profile on my line to 6dB and it is currently syncing at 14322kbps.  The engineer continued monitoring for a while before leaving and I will continue to do the same until I am certain that the line is stable.  But on the assumption that it is, I'd like to say thanks to those on the forum who have helped, particularly Kevin and Chris, to the PlusNet team who have been working behind the scenes and to the BTOR teams for sorting out such a difficult problem.

[#9]

Hi pnf,
This is a great result, one that you should take credit for too.  Without the RouterStats monitoring, this is one of those issues which would have been impossible to profile and therefore resolve.  You've also been blessed with good on the ground BTOR REIN investigation - this can be hard to obtain.
A Freeview box - that's a new one for the culprits list - and frankly one that I would not normally expect to register as your neighbour's has.  I guess most people do not switch off their FVB rather they just switch off the TV leaving the FVB switched on.  If they had not been switching it on and off, you might never have profiled the problem.
Some tidy up matters - a SNRM reset (rather than a fixed SNRM) would allow your line to determine for itself the best target - you might now even achieve 3dB.  That's a call for Chris - that might in fact be what BTOR did.  Also watch your current speed on the PN portal for that to update to 88.2% if your improved synch rate.
So to be sure, is your neighbour going to replace his FVB or when Mr Neighbour comes home and wants to watch the footsie, is your bb going to take a crash again?
I hope you'll hang around the forums and share your experience to help others!
Kevin

[#10]

Well this really is good news, I'm really please that the engineer has managed to get the issue sorted out for you.
REIN Cases can sometimes take a long time to resolve, but this seems to be an exception! You're absolutely welcome for the help from my side of things, that's what we're here for
@Townman - we probably could run the line on 3db, but it's not something I'm overly keen on putting lines on as it just leaves the line vulnerable if anything does spike again - happy to change it if requested though.

[#11]

Chris,
Sorry to be a pedant, but has this line now been FIXED to a TARGET SNRM of 6dB or has the SNRM been reset and left for the 10 day training period to take it where is might go?
I'm mindful that my knowledge might be blurred here on the semantics / practical aspects of a "RESET" (to let the line work out what it can do through training) and a "FIXING" of the SNRM at some value.  Or does one "Reset the line at some 'start' target SNRM"?

Cheers,
Kevin

[#12]

Hi Kevin,
The engineer has done an SNR Reset to 6db. It's not fixed at 6db as I don't think that adds any value and disregards DLM. The line is in a 10 day training period.
You can fix an SNR Target by changing DLM (RAG) values to ensure the lien is always 'Amber' so that DLM doesn't try to move the SNR Target, that's the only way you can fix the SNR Target. I don't usually go for this option as I think DLM is actually really important in most instances.
When we do a Line/SNR Reset, we set a value, say 6db and the line will train to that value initially. DLM will shift this about within the first 10 days if the line becomes unstable or will improve it if it finds that the line is error free and is stable.
I hope that makes sense

[#13]

Chris,
Thank you, yes your explanation makes a lot of sense.
SNRM Reset:  Set a SNRM 'base' value + set to 10 day training + RAG(green) = let DLM do its stuff to work out optimal TARGET SNRM
SNRM FIXED: Set a SNRM 'base' value + RAG(amber) = DLM locked down
SNRM 'base value' is usually 6dB but could be something else...

Nice to see this old dog can still learn new tricks!
Kevin

[#14]

Hi Kevin,
I would never have thought a Freeview box in someone else's property would cause the sort of problems I've had and it's quite amazing that the engineer was able to pinpoint the problem so quickly and precisely.  As you say, I think I have been fortunate in all sorts of ways, the fact that the Freeview box was being switched on and off and the fact that it was discovered so quickly once the problem had been identified as REIN.  You were right all along on that and your help has been invaluable.
With respect to the SNRM on my line, I think I will just see where it ends up after the 10 day training period.  If it remains where it is now I will be more than happy, it's on a 6dB profile syncing at over 14000kbps and that's faster than my line used to run on a 3dB profile.  It will be interesting to see how things pan out on that front.  I'll periodically check my line speed using both the BT Speedtester and the PN one to see that they are both reporting what should be expected in relation to what the router is telling me.
Time will tell whether my neighbour replaces the Freeview box or just switches it back on, but I suspect that most people are quite reasonable when they are informed of such things and will do the right thing.  I wasn't informed which of my neighbours it was, but I would have been happy to buy a Freeview box just to get rid of the problem.  I will continue to monitor my line for a while to see what shows up and I'm keeping my fingers crossed in the hope that it remains stable, although I know that I should expect a few resyncs given that the line is now in a 10 day training period.
I'll be happy to help out when I can on the forums.  Although I'm no expert, I'll be happy to chip in if what's happened here has any relevance.
 
Hi Chris,
Thanks for your offer of help I'm really grateful.  For now I'll see how DLM manages the line.  If it stays anywhere near where it is now I'll be very pleased.  If it settles on a 6dB profile with a lower than expected speed and if it looks as though it would be stable on a 3dB profile I would like to hold that option in obeyance should the need arise.  However, stability is more important to me than speed, and as long as the speed is within the expected margins for the line then that will be good enough for me.

Thanks both for the discussion regarding SNRM resets and the role of DLM, that's very useful to know.  I have one question, when DLM makes adjustments during the 10 day training period will any resyncs happen at roughly the same time each day or will they occur at indeterminate times?

[#15]

Hi pnf,
You're absolutely welcome. DLM on ADSL works 'on-the-fly' so it could happen at any time. It really depends on when the DLM feels like it needs to intervene.