He meant disconnect the router from the LAN, (and wireless links).

Hence why i deleted the post

I didn't know you had deleted it while I was drafting mine, and having seen you had done I thought mine added useful stuff for the OP.

Hey Zarjaz, that's exactly the point I've tried to make to PN - if the SNR has only been low since last Thursday, how is it possible that a low SNR could be the cause of the problem.

These are the router stats from yesterday morning:

Upstream 1155
Downstream 19099
SNR Margin(Upstream) 6.6
SNR Margin(Downstream) 3.1
Line Attenuation(Upstream) 10.6
Line Attenuation(Downstream) 20.0

The following is a link to the PN forums where the issue is also being discussed - http://community.plus.net/forum/index.php/topic,1286... and there are PN customer relations reps responding on that thread.

Hi all, thanks for contributing on this issue.

I've been looking for something "rogue" on my network since this problem started. I've had the wifi disabled on many occasions and I have tried three different routers (a cheap TP-Link, my usual Billion BiPac 7800N and the Technicolor router that plusnet kindly sent to try to help diagnose the problem). Some sort of torrent s/w causing the issue was suggested early on but I cannot find anything within my LAN that could be responsible.

here is what I suggest.

leave it for 24 hours with wifi off and NO devices connected, just the router online so tbb can ping.

if the issue remains in my opinion its congestion.

I would find it a very bizarre line issue to cause that, the stats you posted on plusnet's forum have a low error rate and errors would typically cause packet loss not high latency.

just had a look at your graph, you really need to have all cables disconnected of router for 24 hours and make sure wifi is off, as that graph looks like you saturating your own connection.

Edited by Chrysalis (Wed 01-Oct-14 18:18:00)

It would appear that the profile is now on 3db, hence the now 19 meg sync, it was 17 meg at 6db ....... so it's been sped up, or DLM has decided that your line is so pukka (cough) that it's gotta be super stable for a fair while for that to happen ....... and that ain't the case.

Is there any chance you might follow Chysalis' advice, just to 100% prove it ain't your kit ?

I'm not sure I understand the need for 24 hours with no wifi and no kit connected ... that's not really practical but I've had the wifi disabled overnight on a few occasions with no ethernet connections and also during the day with one laptop connected (a laptop that is not always connected and for example was not on the LAN today and is not usually connected overnight) and none of that has resolved the issue at those times. If the source of the problem was something on my own LAN it couldn't possibly be using the wifi and there is only ever really one laptop that I use via ethernet when I've disabled the wifi. I honestly wish it was something as simple as some kind of rogue torrent or something else saturating my own broadband as I'm pretty confident I'd have found the source by now.

Wifi was disabled and no devices attached via ethernet to the router overnight (12 till 7) but the ping graph this morning shows the thick blue columns. Hopefully that discounts anything on the LAN from being the cause.

Zarjaz, do you think BTO would have anything to investigate at the exchange on this issue? There was been work in the village to bring FTTC to parts of it so is it possible that something isn't working 100% where my EO line reaches the exchange?

If it's not REIN or the house internal wiring or something on the LAN and PN have so far found nothing out of the ordinary at their end, what else could it be?

Zarjaz, do you think BTO would have anything to investigate at the exchange on this issue? There was been work in the village to bring FTTC to parts of it so is it possible that something isn't working 100% where my EO line reaches the exchange?

The recently enabled FTTC cabinets, 1 and 2 should be having no affect on your circuit at all. As for an Openreach bod being able to prove anything, well the usual array of testing equipment has nothing to look at packet loss.

Is there any way PN can have you put on a different pipe/virtual path back to the exchange ?