Dodgy connection

[#1]

I would be glad if someone could run a line test and let me know if there's a problem.

Download has gone from a norm of 3.5-4Mbps to <0.5Mbps and latency has become huge. A route trace shows <1ms to the router, but up to >1s for the next steps, and packet loss.

Nothing has moved inside the house. We use the only socket which is the test socket. Historical issues have been caused by wet joints on the poles down the valley, so I can imagine the recent wind and rain could have caused problems on the long journey back to the cabinet a mile or so away!

Taken just before posting this message:

My thanks for any help!

[#2]

@Fat_Leonard Looking at those stats, I would go straight down the 'Report a Fault' route - https://faults.plus.net .

[#3]

Have you used a telephone handset to do a quiet line test - dial 17070?

[#4]

Thank you both. Like an idiot I'd neglected the Quiet Line test. I'm now raising a fault (if the page loads!) as there was whirring and crackling on the QL.

[#5]

Curiouser and curiouser. After running the 'phone troubleshooter' to report noise on the line, with broadband at a crawl, the troubleshooter timed out. This was expected as the router had lost connection and the troubleshooter warned of the possibility of line problems during the test.

It's just come back, and a speedtest shows a ping of 40ms and 3.71/0.8 Mbps down/up! I don't see how a line problem fixes itself...

[#6]

Hi @Fat_Leonard

I'm really sorry about the connection problems you're having. I've just been running some line tests on this side and we're not seeing signs of any obvious issues.

The fault ticket you raised had closed for some reason so I've re-opened that just now and have added an update advising of what we can do next: https://www.plus.net/wizard/?p=view_question&id=222453021

[#7]

Thank you very much. I guess the timeout from the dropped connection interrupted the fault reporting process. It's tough when one's only means of reporting a fault is via the faulty object!

Current router status report is attached. The SNR margin and errors are somewhat out of whack compared to what I'm used to seeing but speedtest still reports ~35ms ping and >3.5Mbps download which is excellent!

[#8]

The act of testing a line can “fix” some issues (especially wet joints) for a short time. If that is what happened … it needs a proper fix which will be BT boots on the ground.

[#9]

The connection has been OK since my last message, except for a dropout this evening. After rebooting from the router's admin webpages, this is the status since reconnection.

[#10]

Yup you’ve got a problem Huston!

That line looks banded - is there noise on the line?

[#11]

I did a Quietline test during the Internet dropout and heard nothing. This evening playing games has been frustrated by fluctuating ping, often staying strangely stable at >300ms.

I understand automatic banding can be applied if the connection drops, perhaps that's what has happened. I'll consult the fault ticket.

[#12]

Hi there,

I'm really sorry to see you're still having issues.

I've also run a line test which isn't showing the cause for the problem, and your line's not banded, but I can see that the SNRM target has shot up to 12dB, which can generally cause latency issues, so I've brought it back down to 6dB.

I suspect we'll need to arrange an Openreach engineer visit to take a closer look, but from looking at the fault ticket, I believe you're looking at trying another router first which may be a good idea. I'll keep an eye on the ticket for you. 

Let me know how it goes. 

[#13]

Is the difference between being banded and having an elevated target SNRM semantics or expressly technical … but has the same consequence - a restricted speed?

[#14]

I think a bit of both.

Banding does raise the SNRM target, but if a line is chronically banded then it won't be removed by itself. 

[#15]

Not sure if edification of confusion is emerging here.

Your comment suggests two different methods might be used to attempt to keep a line stable

1. Elevate the target SNRM (in 3dB increments) - and allow the sync speed to be whatever is attainable at resync
2. Band (constrain) the sync speed - and allow the SNRM to be whatever it is
   1. non-chronic - if conditions improve the DLM will self adjust
   2. chronic - banding remains in place until the ISP takes action - BT boots on the ground or a SNRM reset

Seems a tad confusing that an elevated SNRM is not "banding" but chronic banding needs a SNRM reset ... hence the question semantics or a real technical difference?

Colloquially a line with a stuck elevated target SNRM is effectively (chronically) speed banded as it is not going to go faster until the cause of the elevated SNRM is fixed (or just removed by a reset).