Loss of ADSL Performance After Joining Plusnet

[#1]

@MisterW 

Bit of a rock and a hard place then!

I do have a BT NTE5 with a MK4 faceplate, but if I dis/reconnect then likely I risk another line quality/speed downgrade...

Can you clarify your QLT acronym please and advise over what duratiion I might have to monitor it to determine any improvement or not?

I'd happily report a line fault to PN again but I'm unlcear under what reason at this time.

PS the line here has NEVER been "silent" for as long as I've lived here - even BT specialist eng told me as much when he visited re a fault some time back. Its just a long, piece of aging wire!

[#2]

@jab1 

Sorry, can you clarify please - A silent line test might clear what exactly?

[#3]

'Noise' on a phone line can be temporarily cleared by the current sent down it, especially on a test, but it will not rectify the problem permanently.

[#4]

@jab1 

I see what you mean now - thanks.

[#5]

I do have a BT NTE5 with a MK4 faceplate, but if I dis/reconnect then likely I risk another line quality/speed downgrade..

@loomajoo  True, but if you leave it for 24 hrs , then do a single disconnect it shouldnt cause a downgrade.

QLT - Quiet line test

[#6]

@MisterW 

Good to know - thank you - and what I was thinking I might do.

Stupid Q: is there any way to sign out "elegantly" of a xDSL connection so that the exchange equipment recognises that its not a fault? I notice for instance that the HubOne has two Disconnect buttons available within its management software...

[#7]

Stupid Q: is there any way to sign out "elegantly" of a xDSL connection so that the exchange equipment recognises that its not a fault? I notice for instance that the HubOne has two Disconnect buttons available within its management software..

@loomajoo  The Disconnect button drops the PPP session but doesnt actually affect the DSL connection. I'm not sure that disconnecting the PPP session affects the DSL stats in any way. There's anecdotal evidence that powering down a router causes it to send a 'dying gasp' on the DSL which (in theory) is seen a a controlled DSL drop , rather than just disconnecting the line , which is uncontrolled.

Fortunately, I've been on FTTP long enough not to worry about any of this DSLAM rubbish...

[#8]

---

@MisterW wrote:There's anecdotal evidence that powering down a router causes it to send a 'dying gasp' on the DSL which (in theory) is seen a a controlled DSL drop , rather than just disconnecting the line , which is uncontrolled.

---

I could believe a dying gasp from a router with a soft on/off but my HubOne has a distinctly hard on/off power button...

---

@MisterW wrote:

Fortunately, I've been on FTTP long enough not to worry about any of this DSLAM rubbish...

---

You are indeed a lucky man! 🙂

The one year I tried FTTC (no FTTP here yet) it was a disaster right  from the day it went live.. Had BT Eng's in and out of here loads of times, eventually culminating with the Specialist when BTO couldnt fix things. It was him who told (showed!) me the line was not silent, and also that in my situation, I'd be better of sticking with ADSL.

Joy!

[#9]

A 42dB attenuated line is around 3km long and would be expected to do 8.2mbps at 6dB SNRM.  It would rather seem that this line is performing within expectations.  Yes, if the line is super quiet and stable a little more might be squeezed out of it.

[#10]

@Townman 

Thank you for your input - I would be very interested to know how you derived your speed estimate (for my own education and future use).

I can confirm that I have estimated the total loop length myself (I know where the cables run) at ~2.6km. I can also confirm that all the routers I've used in the last few years have each reported a downstream attenuation of ~40dB.

Anyway, assuming your estimate is correct, it certainly belies PN's "estimated 1.5-5.0Mbs", and which I consider unfairly pessimistic (giving PN CS an "easy out" when I last contacted them).

But when it's all said and done, I still go back to the fact that less than 2 months ago, the line had a thru-put of ~10Mbs with JLewis/PN, and had done so for the entire 12 month contract duration. Not to mention the ISPs prior to that (albeit all of them running at 3dB SNR), and of course the first ~3wks with PN itself...

However @MisterW and @jab1 have got me thinking that maybe I have a slightly compromised/intermittent line that isnt helping matters, and which I shall try to investigate further before deciding whether and/or how to progress the issue further with PN.

Meantime, all the advise and suggestions given thus far, by all contributors, is greatly appreciated.

[#11]

@Townman @MisterW @jab1 

Entirely FYI (and my own sanity !) I just remembered that I did capture some line traces using RouterStatsHub connected to the HubOne.

They are inline, below, and cover the ~23hr interval from 9AM Sun 27 Aug to 8AM Mon 28 Aug (representing days 6 and 7 of the new PN service).

Each of the four trace confirms (in the header info) the router had been up 3 days with an established sync rate of 11,196Mbs. Also in trace 1 over the interval.

Trace 2 shows a steady downstream attenuation ~42dB.

Trace 3 shows a slight drop in the downstream thru-put as the SNR reduces overnight.

Trace 4 shows the detailed downstream SNR droping from 3dB to ~2.5dB overnight.

IIRC the connection stayed pretty much this way for the first ~3wks before it all slowed down.

Reported Connection SpeedReported Line AttenuationReported Max Data Rate

[#12]

---

@loomajoo wrote:

@Townman 

Thank you for your input - I would be very interested to know how you derived your speed estimate (for my own education and future use).

I can confirm that I have estimated the total loop length myself (I know where the cables run) at ~2.6km. I can also confirm that all the routers I've used in the last few years have each reported a downstream attenuation of ~40dB.

Anyway, assuming your estimate is correct, it certainly belies PN's "estimated 1.5-5.0Mbs", and which I consider unfairly pessimistic (giving PN CS an "easy out" when I last contacted them).

But when it's all said and done, I still go back to the fact that less than 2 months ago, the line had a thru-put of ~10Mbs with JLewis/PN, and had done so for the entire 12 month contract duration. Not to mention the ISPs prior to that (albeit all of them running at 3dB SNR), and of course the first ~3wks with PN itself...

However @MisterW and @jab1 have got me thinking that maybe I have a slightly compromised/intermittent line that isnt helping matters, and which I shall try to investigate further before deciding whether and/or how to progress the issue further with PN.

Meantime, all the advise and suggestions given thus far, by all contributors, is greatly appreciated.

---

See ::. Kitz - Max speed calculator .::

It is the LINE attenuation not the signal attenuation which is of concern - one of the earlier posts reported it to be 42.5dB which calculates out to 3km.

The estimates are not PlusNet's but BT Openreach's and cynically might be considered sufficiently low so as to avoid the need to fix anything.

As to different speeds with different ISPs, that is somewhat a matter of a difference in the provisioning profile - speed vs stability.  I would suspect that JLP was provisioned on raw (but unstable) speed as that is what sells.  Plusnet tends to provision on stability, which might have a small cost in speed but offers higher stability.  At the margins, a higher sync speed can be detrimental to having optimal DATA speed.  If a high sync speed has a high error rate then the effective data speed will be much lower.

Those router stats tell a stark story!  Note that the only one of interest is the SNRM.  Sun rise / set is currently around 7am / 7pm and those are close to the horrible SNRM plot duration.  That is either AM continental radio interference (but that usually stops around 2am) or interference from IR CCTV illuminators.

I once had a horrible experience with broadband - it took months to sort, though there were a multitude of issues ... one of which was the CCTV PSU - when the IR illuminators turned on, the stress on the PSU caused it to blast out RFI.

Some of those spikes are large and will with a 3dB SNRM probably give rise to frequent disconnections.  The line needs to be checked for AC balance.

[#13]

@Townman 

I found the speed estimate calculator, thanks. I'd actually bookmarked it ages ago already but completely forgotten about it.

I believe just general changes in the stratosphere itself (and associated RF re/radiation) will cause the SNR dip at night, as well as the AM signals you mention.

My location is semi-rural and I'm not aware of any IR/CCTV interference sources anywhere nearby.

I monitored the HubOne's stats overnight and I see now that they are not entirely stable, so it does look like I have some degree of line issue to resolve.

---

@Townman wrote:
The line needs to be checked for AC balance.

---

Is this your take on what may be wrong with my line?

[#14]

Poor AC balance leads to an increased susceptibility to RFI.  See AC Balance issue... (kitz.co.uk) - Kitz is the font of all knowledge - there is some interesting detail in there worth read and raising with the BT engineer - especially the spilt pair condition.  See post #6 for the real cruncher - ask the engineer if there is any aluminium in your "copper" circuit.

With elevated susceptibility to RFI and the clear presence of night time disturbance there is a risk of an unstable connection at 3dB - if this circuit has been provisioned for stability over speed, then sticking the DS SNRM at 6dB (rather than 3dB) is to be expected.

To be clear it is not the changes in the atmosphere (be that troposphere, stratosphere or mesosphere) alone which cause the issue: those changes cause AM radio signals to travel much further by bouncing off the layers and thus follow the earth's curvature.  Couple that with those AM radio signals being in the same frequency range as ADLS signals ... and a susceptible circuit and you internet connection has a fair risk of going down the pan!

Revisiting the graphs changes: the max rate is not a sign of "improvement" as you put it but rather just an illustration of what the line might do if resync'd with the then present background noise.  The DS was running at 3dB is it the case that it is not at 6dB?  If yes, that suggests strongly that 3dB was found to be unstable.

[#15]

---

@Townman wrote:

Poor AC balance leads to an increased susceptibility to RFI.  See AC Balance issue... (kitz.co.uk) - Kitz is the font of all knowledge - there is some interesting detail in there worth read and raising with the BT engineer - especially the spilt pair condition.  See post #6 for the real cruncher - ask the engineer if there is any aluminium in your "copper" circuit.

Thanks for the link - Kitz is indeed a great website.

A local friend of mine used to work for BT and told me they had deployed aluminium wires all over this area. But how could I find out if they're part of my line, and how could I get BTO to do anything about it if they are?

The HubOne logged several notable wobbles in SNR late last night, with a couple of distinct but temporary dips in the early hours. However, none of it caused a re-sync. It ran stably all day today until I powered the router off, and removed the MK4 faceplate from the NTE5c. I repeated the QLT straight into the master socket but could not hear anything other than a very low level, but distinct mains hum. I do not know if that is acceptable or not!?

Once all re-assembled the HubOne resynced no problem (and quickly too) and has been running stably since then (@5PM) at similar rates & SNR as before I disconnected. I contine to monitor for the next 24hrs or so...

But right now I dont know where I am exactly!

There may be an intermittent line fault, and/or reduced AC line balance, and/or a noisy line.

I could contacting PN CS and try insisting they do another line test, even though the data connection is currently operating beyond their estimated capacity.

In any case, I've accepted (more or less) that the SNR is not going to be lowered below 6dB, so best case I can expect is a reduced download rate from what I've been used to.