LLU Line dropping under load.

Having an ongoing issue with my new Zen LLU broadband.

Moved from a Comms World BTW provided connection to Zen's LLU Adsl earlier in the month.
Now despite there being congestion on the BTW product (confirmed by my supplier) it was stable with many days uptime on a 6db profile on fast path. Syncing in the high 5000 to low 6000. It even switched down to a 3db profile where I was seeing high 6000/low 7000 syncs and fairly stable.

Now after the switch the first day I was seeing a high 5000 sync but the next day the line dropped down to mid to low 4000, many PPP drops (confirmed by the router log and Zen themselves) mainly when under load especially uploading ie iCloud and mostly at night when I plug my iphone or the other half does to charge. Not of the time the sync stays but connection drops, a few times it drops sync or the router need a reboot to reconnect. They have put interleaving on the line again with no difference (other than the latency)

Now I certainly never had that even when I used to hammer the connection in both ways, just peak time congestion which reduced my actual download speeds (not sync).

I've tried a old style filter faceplate, a VDSL mk2 faceplate, and currently using the test socket with nothing but the router & micro filter connected. No change at all. Changed the PSU for the Netgear 3300v2 router, changed the Adsl cable for a shielded, then a really short single core and then back to the original. No difference to the drops or sync speed.

On the advice of the Zen tech staff I've now changed the router to a Thompson 585n.
I've rechecked everything, the router & socket are in the same cupboard as an electrical main box but I've moved the router to about 1m away (it was 30cm away before I started having these issues with no problems!) I've also taken the opertunity to switch off everything in that cupboard like a vacuum charger, Philips hue router etc etc. No difference, my gas heating was on for a period but it's now off and again none of this has helped.

My stats on the Thompson are after about 6 hours of being on. (Note the uptime)

Uptime:
0 days, 0:57:13

DSL Type:
ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]:
981 / 4,583

Data Transferred (Sent/Received) [MB/MB]:
165.36 / 459.75

Output Power (Up/Down) [dBm]:
12.3 / 19.6

Line Attenuation (Up/Down) [dB]:
28.0 / 48.5

SN Margin (Up/Down) [dB]:
6.3 / 5.5

System Vendor ID (Local/Remote):
TMMB / ----

Chipset Vendor ID (Local/Remote):
BDCM / BDCM

Loss of Framing (Local/Remote):
71 / 0

Loss of Signal (Local/Remote):
8 / 0

Loss of Power (Local/Remote):
0 / 0

Loss of Link (Remote):
-

Error Seconds (Local/Remote):
164 / 0

FEC Errors (Up/Down):
0 / 574,712

CRC Errors (Up/Down):
0 / 0

HEC Errors (Up/Down):
0 / 0


And the ping monitor for the other day with the Netgear (I'll include one for the Thompson once it's done 24hours)
http://www.thinkbroadband.com/ping/share/6947435e7ab...

The Netgear stats (VDSL Mk2 faceplate) so little difference between routers.
ADSL Link Downstream Upstream
Connection Speed 4111 kbps 943 kbps
Line Attenuation 49.0 db 27.1 db
Noise Margin 6.0 db 6.0 db

Also I monitored the SNR for several hours and it was quite variable.

http://imgur.com/yxtryL1

We are due to get FTTC in a few months (via Digital Scotland) and BT have been blowing fibre outside our property but no FTTC can yet. I'm unsure if this has any relevance to this fault though.

Anyone experienced similar or had this type of thing fixed?
Zen are investigating a line issue but don't think moving to them would cause any psyical change to the line.. What is involved in moving from BTW to LLU but staying BT for phone line?
Anything else I can do?

Edited by Binary_Digit (Thu 01-Oct-15 23:20:51)

If plugging something in at your home is able to cause the problem then points to a noise issue somewhere in the property.

The exchange side will have seen you move from BT Wholesale DSLAM to the Zen DSLAM if using their SMPF network.

This is the routers log from tonight....

http://imgur.com/sgSk2kX

I've tried turning everything on and off. It made no difference. My heating or water heater doesn't effect it either. It doesnt appear to be REIN..

Literally only under load, especially upload it PPP drops.

Used exactly the same modem as before?

And if its only under high traffic conditions I don't understand why plugging in devices to charge would have an effect. An ADSL line when handling packets may show more errors and renegotiate the line when if it was otherwise idle would have not noticed the errors.

One possibility is to force the modem down to ADSL2 mode from ADSL2+ mode. Occasionally lines behave a bit odd around your attenuation, i.e. try to exploit some ADSL2+ frequencies but this causes more trouble than its worth.

No I was saying I eliminated them (all PSU's or electrical interference) from the equation in case it was them, it wasn't.

Yes the Netgear 3300v2 was used when I was with Commsworld & Zen. Everything was the same.

Hello,

Sounds a frustrating situation!

I can see you've already a conversation with our team - it's probably worth speaking to them again, having swapped the router with little difference made.

You can give our tech support team a call on 01706902001, or if you prefer, send me your contact details in a private message and I'll have someone get in touch soon.

Thank you,

Erin

You've got to figure that the obvious culprit is the exchange equipment, as that is what has changed.

Can you order a TPM for the OP ?

Reason for not saying exchange kit was this comment in the original post

mainly when under load especially uploading ie iCloud and mostly at night when I plug my iphone or the other half does to charge

ADSL DSLAM configurations are such that Be used to always give better speeds because of how they've configured the DSLAM. It is possible the noise pattern at times is such that the Zen kit is not handling in the most graceful fashion i.e. is too keen to resync rather than tolerate a higher error rate.

Sorry I didn't make that clear.. The cloud uploads start when you put an iPhone on charge, usually at night.

The thing is, it rarely resyncs. It drops the connection ie PPP.

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