Slow ADSL upstream speed after line fault fixed

[#1]

Hi

I had a stable ADSL connection for several years running at good speeds - approx 16-18 Mbps download and 1-1.2 Mbps upload.  This was slightly faster than the 'attainable rate' figures and did clock up a number of errors in the stats but it was solid and didn't vary much.   I did notice, when it rained heavily, that the speeds dropped somewhat for a day or so but then reverted to previous higher levels.   Then, during the storms last weekend, the line almost dropped completely for the whole weekend - very noisy phone line and router unable to sustain a usable connection at all, even at very low speeds.  Minor improvement last Monday so I reported a fault.  Openreach came on Tuesday and discovered severe corrosion issues at the telegraph pole outside and fixed these.   Since then, stable connection at 15Mbps download and 0.4 Mbps upload with no drops and minimal errors in the stats - and a quiet phone line with no audible noise.   

My query is why is the upload speed now 1/3 of what it was before when the physical fault introducing noise has been fixed.  Is this likely to correct itself or has something in the background been auto-adjusted during the very noisy period when the router could not connect and this is restricting achieving a higher rate?   The download speed is fine but the much slower upload speed is causing issues with Zoom/Teams.

Current router stats are:

xDSL
Mode	ADSL_2plus
Traffic Type	ATM
Status	Up
Link Power State	L0
	Downstream	Upstream
Line Coding (Trellis)	On	On
SNR Margin (dB)	14.9	32.2
Attenuation (dB)	23.5	11.3
Output Power (dBm)	0.0	11.4
Attainable Rate (Kbps)	16248	888
Rate (Kbps)	15244	440

[#2]

@jdsmith Looking at that data, something is still not right - both the U/S and D/S SNR margins are way too high, the U/S unbelievably so. Effectively, you still have a fault somewhere.

[#3]

DLM has banded your line due to the issues you had - it should sort itself out given time - a week or two, or you could ask PN to reset the line.

[#4]

@Mustrum Looking at those figures, I think you are correct - but the SNR figures still look to be pointing to a continuing fault somewhere.

@jdsmith Just a suggestion - could you plug your router into the test socket (via a filter) and see if the figures change - to rule out any extension wiring?

[#5]

@jab1 There is no extension wiring - modem plugged directly into ADSL faceplate in NTE5c master socket (both parts replaced by Openreach on Tuesday as previous socket was quite old).   I tried using an old modem as well but got similar figures for speed and margin

[#6]

OK, @jdsmith - but humour me and try the test socket, it may not help, but it will confirm the problem is external to your home wiring or not.

I'll pick up  your response tomorrow.

[#7]

As 'Mustrum' pointed out - the main reason your speed is lower than you might expect, is almost certainly because your noise 'margin' is currently way higher than normal.

The higher noise margin is very likely a result of the recent line difficulties you experienced.

The fact that your router is reporting high noise margin is 'hopefully' a good sign - caveat; as long as the figures are relatively 'stable' - there being plenty of 'headroom' (safety 'margin') to work with signal vs noise.

The normal noise margin target is 6dB - that's just a target figure for initial router modem connection negotiation, and it rarely lands exactly on that figure even after router re-sync, an in most cases the figure will drift around/step change higher or lower with varying line and environmental conditions.

[Anecdote: My own ADSL line is generally very 'stable', such that, at a very early stage I requested the 'Downstream' target/profile on mine to be set lower to a just 3dB target - and furthermore, I've known mine to work fine for many weeks at a time with the noise margin having drifted down to around just below 1dB.]

Re your situation - [ideally] the DSLM automated line management should recognise, after a period of evaluation, whether or not the line is 'stable', and if seen to be 'stable' then it should 're-sync' the connection with a lower target noise margin (giving higher data speed).

As you might recall - we are typically warned that 'new' service connections might take take 7-10 days to settle - I would guess this probably applies similarly after there is some significant line disruption.

You could watch & wait a few days.

If you get impatient, you could re-boot your router and force a 're-sync' to see if there is any change - but don't do that too often in relatively short time interval, otherwise the exchange equipment might interpret this as being line faults and be counterproductive.

If the situation doesn't change after 7-10 days -  think I would resort to getting in touch with Plusnet help, and explain/ask them to reset your line/connection's noise margin target back to 'normal'.

Good luck - let us know.

---

[#8]

Hi @jdsmith 

I've had a quick look, and testing your line isn't showing any issues now, which is a good sign. I've submitted a DLM reset, which should improve your upload speed within the next 24 hours.

See how things go and let us know if you have any further issues.

[#9]

Thank you all for your input.

Before I got the chance to try the test socket without the faceplate the line reset appeared to kick in as router has reconnected: upstream SNR margin has reduced and upload speed has increased to 'attainable speed'.  Figures now are:

	Downstream	Upstream
Line Coding (Trellis)	On	On
SNR Margin (dB)	15.0	18.4
Attenuation (dB)	24.0	11.3
Output Power (dBm)	0.0	11.0
Attainable Rate (Kbps)	16180	888
Rate (Kbps)	15086	888

This is considerably better.   I will still try using test socket (when I can find an ADSL filter - been using filtered faceplate for so long I've misplaced the ones I used to use) to see if this makes any difference to the SNR.

I am still curious as to how the router was managing to sync at higher download and upload speeds than the 'attainable rate' before the dodgy connections on the line were fixed (I don't remeber the actual attainable figures but I remember noting that they were always lower than the actual sync speeds).   I was definitely getting actual 18 Mbps down / 1.2 Mbps up a fortnight ago before the problems began.  I don't understand how though given the physical issues with the line. 

[#10]

A steady upload speed of 888kbps is normally caused by interleaving, which is a form of error correction. This could have been applied automatically to the connection as a result of the fault and drops that were had. 

The lower download speed is possibly due to the high SNR, which in turn likely caused by the fault. 

Essentially, the connection trying to make things better by digitally slowing things down. 

If that’s the case, now the fault’s been fixed, we could remove interleaving, and reset the downstream SNR and see how things go. There’s a possibility it may make things unstable, but happy to give it a go if you’d like?

Definitely also worth trying the test socket if possible.

[#11]

@Gandalf   I would like to try your suggestions please.   It is useable as it is now but if it might be possible to get back to what I had before the fault then it is worth a try,  Presumably we can revert back if the line does become too unstable. 

I found a filter and tried the test socket; it makes a slight difference but not much...

	Downstream	Upstream
Line Coding (Trellis)	On	On
SNR Margin (dB)	14.1	17.8
Attenuation (dB)	24.0	11.3
Output Power (dBm)	0.0	12.4
Attainable Rate (Kbps)	16752	888
Rate (Kbps)	15451	888

[#12 · Accepted solution]

I've set the downstream SNRM target to 6dB, and placed an order to remove interleaving, which should take effect from tomorrow. Yeah if the line starts to become unstable again, we can put things back. 

[#13]

After a week since the changes, line has only done one spontaneous re-sync and it seems stable enough at:

	Downstream	Upstream
Line Coding (Trellis)	On	On
SNR Margin (dB)	5.7	6.7
Attenuation (dB)	23.0	11.2
Output Power (dBm)	0.0	12.3
Attainable Rate (Kbps)	20884	1292
Rate (Kbps)	20859	1275

A few more errors clock up than when syncing more slowly but they don't seem to amount to a significant issue so I'll play it by ear.   Thank you very much for your help.