You say it rarely resyncs, but your log snippet seems to show the line state doing down then the PPP being reported as down.

Are there actually times when the message preceding the PPP link down that are not xDSL linestate down.

In the log you posted with some routers after modifying things like firewall rules (the log indicates this happened) that the connection is totally dropped and rebuilt to ensure that changes to the ruleset are fully loaded.

Is this the same router hardware as the previous ISP, as it might even be a software bug in the router, i.e. handling the traffic combined with the other activity like Wi-Fi calling causing it to fall over.

The PPP drops, Internet cannot be like used but the line stays synced speed wise.

I'm using a Thompson 585n now but only as Zen asked me to try another router as part of the diagnostics. If anything there are more PPP drops with the 585.

However I was using the same equipment when these problems started to come about.

So we can rule out router quirks or software bugs. We can rule out filter issues too. Tried the original BTOR faceplate (what was originally fitted) then a VSDL MK2 and now a dangly microfilter via test socket. No difference.

Then there is the issue I've lost around 2000 Kbps in speed since the change over. 6 db BTW vs 6db Zen LLU same equipment.

Not according the log you posted which said Line State down

So most likely thing is just the difference in how ADSL is configured at the DSLAM end or someone has messed up the wiring and something intermittent at the exchange. A lift and shift to try a different line card port at the exchange maybe.

Zen have so far have stated that it's unlikely a physical change thats caused it (other than an coincidental line fault of course)

Is there any physical changes on the line going from BTW to LLU i.e. jumpers or the like or is it just a change on a database to where the backhaul or connection goes?

I have noticed that in the logs, but i've watched it whilst this happened and unless the Thompson reports it on the GUI different;y to the Netgear i'd expect the sync to zero if down, it just reports the same speed before, during and after the " line state down" event. Which if I'm honest are starting to increase in frequency compared to the PPP down.

The Downstream Noise Margin is also jumping around from 4.5 to 6.4 within a few seconds, does this indicate anything?

Move from BT Wholesale to a LLU DSLAM will involve physical wiring changes

On the web interface, depends on how often the interface updates. Log files which should be sequential should be more reliable.

Noise margin jumping around is generally not good if the changes are large in a short period of time.

Zen should have records off your line sync drop and PPP drops.

Watching it just now It's jumping between 4.5 & 6.4 currently every couple of seconds....

http://imgur.com/1VYyo5n

Earlier..

No detail on the snr jumping around but a number of PPP link up down and firewall alerts

Hi,

The line stats you've posted indicate you're on a fairly long 48db line that's been set to use ADSL2+

I'd recommend contacting Zen tech support and asking them to set your conection to ADSL1 (at 48db the line won't see any of the benefits of ADSL2+). This should be a fairly straightforward change to request (caveat: it's been a few years since I worked in Zen TS) and in most cases this will stabilise the conection.

If it doesn't - ask for a copy of the radius graph for your line from Zen tech support to try and identify patterns for when the connection drops to see if they tie-in to anything local at your side (though it sounds like you've done pretty thorough diagnostics regarding this already) - this can be a really useful tool for diagnosing unusual intermittency faults.

PPP and/or sync drops due to bandwidth usage are extremely rare in my own experience, so it's unlikely that this is the cause - let us know how you get on on here, and good luck

Edited by deleted (Mon 05-Oct-15 14:12:42)

I've been having similar issues (as have many others) and from my experience in building network equipment then running stress tests to see where they fall over, the problem you are describing suggests the exchange MUX/DEMUX is overheating.
This will slow down data packets and in severe cases cause complete loss of sync which will drop the data connection. You need to raise this with your ISP and ask them to get BT to check the exchange cabinets have effective cooling. I am aware that some new equipment is definitely not properly cooled, merely having individual server processors with on-chip fans and no overall cabinet fans whatsoever.
This means that discrete components are operating well beyond their ideal temperature limits, effecting a massive reduction in data throughput. The Thinkbroadband flash speed test may show this up as a reasonable TTB download but ridiculously reduced HHTPx6 speed.
Charging devices does not affect data transfer at all unless your system PSU is well below par. If that were the case, your whole system would crash, not the PPP connection!

In reply to a post by pbsolo:

I've been having similar issues (as have many others) and from my experience in building network equipment then running stress tests to see where they fall over, the problem you are describing suggests the exchange MUX/DEMUX is overheating.
This will slow down data packets and in severe cases cause complete loss of sync which will drop the data connection. You need to raise this with your ISP and ask them to get BT to check the exchange cabinets have effective cooling. I am aware that some new equipment is definitely not properly cooled, merely having individual server processors with on-chip fans and no overall cabinet fans whatsoever.
This means that discrete components are operating well beyond their ideal temperature limits, effecting a massive reduction in data throughput. The Thinkbroadband flash speed test may show this up as a reasonable TTB download but ridiculously reduced HHTPx6 speed.
Charging devices does not affect data transfer at all unless your system PSU is well below par. If that were the case, your whole system would crash, not the PPP connection!

Some FTTC cabs can experience problems with heat buildup due to limited space and/or the location of the cab. I've never personally knowingly come across any heat-related issues for ADSL lines such as the one detailed in this thread; exchange-located equipment tends to be adequately ventilated.

Charging devices plugged in near phone lines or phone sockets can definitely affect the stability and speed of a connection, especially inexpensive power supplies and chargers - think of the copper phone line acting as an aerial that can pick up nearby EM/RF interference. The 'giveaway' for this tends to be lots of errors on the high-frequency (and hence more 'fragile') downstream part of the DSL signal, as well as a connection that only drops/slows down when the device causing the interference is powered up. For a more detailed explanation see http://www.kitz.co.uk/adsl/rein.htm