FTTC very slow upload

I'm some 900m from the cabinet and used to get around 28mbps downstream and 4mbps upstream; not great but acceptable.

But recently upstream has dropped to 800k. We've had a succession of Openreach engineers visit who can find no faults, and eventually blame crosstalk or REIN. Are there any clues in these stats?
https://www.flickr.com/photos/reentrant/14971278348/

Other than not many bits present in U1 (second block of upload bins).

Attenuations looks relatively sensible. So may just be cross talk/rein issue but one only impacting a small block of frequencies because D1 looks sensible.

I'm 1100m from the cabinet & I have gradually lost around 10Mbps on my DS sync speeds (from around 30 Mbps to around 20 Mbps), definitely due to increased crosstalk.

However, I do still get around 4 Mbps US sync speed.

Did this US sync speed reduction hit suddenly or was it in noticeable stages?


Your connection's attenuation is better than mine, but my QLN is better than yours.
Has your QLN deteriorated suddenly?



Do you have any older snapshot stats for comparison against what your connection currently achieves?


Also, do you have any 24/7 Ongoing stats where you could go back & determine exactly when things started to go wrong?

If so, it may point to increased crosstalk, but I'd be rather surprised to see it hit your US sync speed so much as it usually hits DS sync speeds more significantly.

Everything had been fine up to a complete loss of service at the end of July. Openreach came out, couldn't find anything wrong physically but did a reset and reported sync back to 28mbs as before - I never thought to check upstream at the time and only noticed it when sharing some photos a week or so later. He said the service loss was due to "it going so slow for some reason it stopped altogether". The line passes all BT tests and the slow upstream sync also happens with just the BT test box connected directly to the incoming pair.

I only got a spare modem and unlocked that a few weeks ago after OR failed to find the cause so I don't have any stats from before the problem, unfortunately.

One OR engineer measured upstream at several points between the cabinet and me - it drops gradually from 10 at the cab to 4.5 mb/s at the last access point about 40 metres away. He did say they can see some very specific noise which is also affecting several other houses nearby but no-one else has complained so there's little they can do. Maybe the others haven't even notice slow upload. But he did say he's never seen a case of crosstalk or REIN only affecting upload, and this severely, while not affecting download at all.

Working backwards...

As others noted, the thing that looks very different is that the bit loading graph show the U1 band to be heavily under-utilised compared to the surrounding D1-D2.

This will be as a result of the SNR/tone being low in U1, perhaps by 15-20dB.

This appears to be because the QLN in U1 is particularly high - probably 20-25dBm higher than a lot of people. I just looked through all the people currently using "mydslwebstats", and a large proportion are showing -130 to -135dBm in the U1 band.

My QLN graph for U1 shows a U-shape (an upside-down version of your QLN), with a broad low at -136. while yours is n-shaped with a broad high of 110 dBm.

This ties in with your engineer's report that he can see noise in U1 that doesn't affect downstream.

So what generates noise at precisely the U1 frequencies, but doesn't stray into D1 or D2???

The obvious culprit would be a VDSL2 modem ... those know how to transmit on this frequency band, don't they? Perhaps one is broken somewhere. Perhaps one is just transmitting at the wrong level.

This suggests a path of going around the houses near that access point 40m away, and talking to them all. Find out if they have FTTC (perhaps checking if it was installed at the end of July), and if they have low upstream speeds. If they don't, you may have found the culprit. If they do, then you get them to generate a complaint so that Openreach will pay more attention.

If you find a culprit, you could check by asking them to turn their modem off for a while, and see if your SNR/tone graph improves.

The upstream is totally affected from tone 950 to 1200 and partially from 870. Corresponds to about 3.7MHz (870), 4.2 MHz (950) and 5.2 MHz (1200). There does not appear to be anything affecting Downstream either side of the U1 block.

To me it suggests that any problem noise source is closer to the cabinet rather than at the OPs house.

If there is 4.5 Mbps available at the last access point, only 40m away (I assume that means the DP), yet drastically impaired at the bare wires of the incoming cable, that would suggest either the drop cable is 'damaged' or has a poor connection.

Alternatively, it could somehow be picking up severe interference within those 40m.

Did the engineer dismantle the master socket & clip his tester's cables to the bare wires or use an adapter plugged into the faceplate?

If it was the latter method, it is feasible that the faceplate itself is defective.



We had a couple of severe thunderstorms at the back end of July in my area (Oldham).

Following one of these thunderstorms, I still had a VDSL2 service, but the landline was completely dead.

I temporarily got around this by removing the faceplate & plugging an old ADSL microfilter directly into the master test socket.

That reinstated my landline service & my VDSL2 connection continued to operate as normal.


An engineer eventually visited & replaced the faceplate after testing everything at the bare incoming wires & explained that a number of users in my area had eperienced similar issues, with some losing landline, some losing VDSL2 & some losing both services.

He also confirmed that a small number of users also ended up with fried routers/modems & in one case the PC itself was fried.
It was assumed that those users must have been directly underneath the storm.


Do you have an old ADSL microfilter that you could try from the master socket, just to see if that makes any difference?

If it makes no difference, it would at least eliminate the SSFP as the culprit & more or less confirm the problem lies within the 40m of drop cable.


BTOR may be (should be) willing to replace or at least check the connections at each end of that cable.

My own drop cable was replaced a couple of years ago in an attempt to cure my intermittent disconnection & really low speed connection (it was actually also rerouted round the back of the house).

The issue on my connection ended up being a corroded connection between the underground cable & the drop wire that wasn't spotted when the drop cable was replaced.

What components exist on the backplate of the master?

That is, between the screw-connectors for the incoming twisted pair and the output pins of the test socket on the backplate.

If lightning could affect the SSFP, could it not also/instead affect the backplate?

The fact that the engineer can get 4.5Mbps only 40m away drives me to believe the problem is somewhere in that last 40m.

That is pretty much the original speed, and the 40m shouldn't make that much difference.

But if the noise level was that high, close to the house, it would also affect the downstream signals which are already 40dB (or more) lower. The downstream graphs don't suggest a major localised noise issue.

In reply to a post by WWWombat:

What components exist on the backplate of the master?

That is, between the screw-connectors for the incoming twisted pair and the output pins of the test socket on the backplate.

If lightning could affect the SSFP, could it not also/instead affect the backplate?

Actually, thining back to the engineer's visit, he did replace the whole shebang rather than waste time testing each part of the master socket's build-up.

I'm not sure what components exist on the backplate but just for reference, the connections are IDC rather than screwed.


I may have a photo somewhere from when my whole master socket was replaced a couple of years ago.
I'll post a link if I can find it.

That's what's making me think it is more of a physical cable/connection problem rather than noise.

I've had three faceplate / backbox changes. Also at least two of the OR engineers have attached their test unit directly at the old GPO pattress where my underground cables come into the house (and are gel-crimp-connected to the cable that goes to the master socket) so it's not that.

Come to think of it, the complete fail that I mentioned was a day or so after the thunderstorms. Maybe a neighbour's VDSL modem is to blame ...

O.K. So more & more potential sources of the problem are being eliminated bit by bit.

It may seem quite extreme, but to completely eliminate anything interference-wise being generated in your home you could try this:-


Make up an adapter with a suitably sized plug to fit the modem's power socket & bare wires at the other end.

Set up a laptop with a fixed Network Controller IP address within the same range as the modem.
(I have previously done this using 192.168.1.1 for the laptop's fixed IP address)

Turn off all your mains power at the consumer unit.

Connect the laptop's NIC to the HG612's LAN2 port via a good quality ethernet cable.

Connect the power adapter cable to a 12v battery, ensuring correct polarity.

Connect the HG612's DSL cable to the main test socket using an ADSL microfilter.

When the DSL light is steady on the HG612, access the HG612 from the laptop via a telnet session, using 'telnet 192.168.1.1' (without the quotes) in a Windows CMD window.

Enter 'admin' for Login & 'admin' for password (without the quotes).

Enter 'sh' to get into BusyBox (no quotes)

Enter 'xdslcmd info --stats' (without the quotes) & wait for the results

Enter 'xdslcmd info pbParams' (without the quotes) & wait for the results.


Copy all the telnet output data & post it in this forum thread or paste it to a text file & upload it somewhere we can access it.



If the 'interference' was actually being generated from within your house, you may not see increased sync speeds in the telnet output as DLM may need time to react, but you should be able to see significantly increased US (& maybe DS) SNRM values.



If there is indeed a noticeable improvement, whilst still powering the HG612 from a battery, you could try tuning the power back on, circuit by circuit until the 'offending' circuit is identified.

You would need to keep re-running the telnet commands to check for any changes as each mains circuit is switched back on again.


If an offending circuit is identified, try switching off/unplugging ALL appliances on that circuit & then switch them back on one at a time, re-checking the telnet output until the offending appliance is identified.


If there is a deterioration only when the modem's usual power adapter is plugged in, that could be the source of your problems.




If nothing improves at all with ALL the mains power off, at least something else will have been eliminated & it might be useful to explain what you did to your ISP and/or the next visiting engineer.


Of course, if it really is an interference problem, the source could be somewhere in a neighbour's house or even a defective street light, arcing underground mains cable etc. etc. etc.


All this does seem to be quite a rigmarole, but it's possibly the only way you will be able to convince anyone that you are not causing the problem yourself.


Good luck & please keep us posted.

The OP does mention it is affecting several other houses close by.

A physical connection issue would also manifest itself on the downstream, which I hope you will agree, looks reasonable.

Laptop - no problem; that's how I flashed the modem. I think I have a 12v motorbike battery somewhere, but It might be easier to try with all upstairs MCB's off, and again with all downstairs MCB's off and power the modem via an extension lead plugged in upstairs.

In reply to a post by MHC:

The OP does mention it is affecting several other houses close by.

Yes, but if they are ADSL users (we don't know one way or the other as it wasn't specifically mentioned), they probably wouln't notice anyway as the frequencies in question are not used for ADSL.

In reply to a post by Reentrant:

but It might be easier to try with all upstairs MCB's off, and again with all downstairs MCB's off and power the modem via an extension lead plugged in upstairs.

It might be worth a try doing it that way, unless it's down to mains borne interference.

My hunch is still related to a possibly defective cable from the last access point or a dodgy connection joint.

Amateur radio nearby?

In reply to a post by MrSaffron:

Amateur radio nearby?

Not that I'm aware of; no new obvious aerials have appeared recently. All phone cables round here are underground - would that make them less susceptible to RFI than pole-strung?

I can't find a suitable 12v supply so I've ordered a car inverter. It will be a few days before I can get the telnet stats.

OK here's my telnet stats and pbparams; firstly "normal" with mains on and usual household stuff running, then from around line 126 with mains off, modem powered by a car battery and connected to test socket via a microfilter.

************************************************************************************
* NORMAL - MAINS ON *
************************************************************************************


xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 853 Kbps, Downstream rate = 29464 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 29466 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.2 5.8
Attn(dB): 22.2 0.0
Pwr(dBm): 13.0 -9.7
VDSL2 framing
Bearer 0
MSGc: 20 90
B: 239 30
M: 1 1
T: 64 18
R: 14 10
S: 0.2592 1.2043
L: 7840 279
D: 1 1
I: 254 42
N: 254 42
Counters
Bearer 0
OHF: 111598036 714508
OHFErr: 292 70
RS: 2847291679 1047259
RSCorr: 2547 67
RSUnCorr: 1243 0

Bearer 0
HEC: 843 0
OCD: 58 0
LCD: 58 0
Total Cells: 528494771 0
Data Cells: 79619546 0
Drop Cells: 0
Bit Errors: 0 0

ES: 404 83
SES: 21 0
UAS: 86 65
AS: 464602

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 4.16 16.32
OR: 49.96 47.05
AgR: 29516.19 846.97

Bitswap: 145197/145197 73/73

Total time = 1 days 1 hours 1 min 7 sec
FEC: 3903 78
CRC: 2769 88
ES: 404 83
SES: 21 0
UAS: 86 65
LOS: 2 0
LOF: 20 0
LOM: 0 0
Latest 15 minutes time = 1 min 7 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 11 4
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 1 min 7 sec
FEC: 101 4
CRC: 9 2
ES: 4 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 375 12
CRC: 47 6
ES: 42 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 days 9 hours 3 min 21 sec
FEC: 2547 67
CRC: 292 70
ES: 236 60
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

************************************************************************************
* MAINS OFF, TEST SOCKET, MODEM ON BATTERY *
************************************************************************************

xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 853 Kbps, Downstream rate = 29464 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 29466 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205)
DS: (33,859) (1216,1961)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 853 kbps 29464 kbps
Actual Aggregate Tx Power: - 9.7 dBm 13.0 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 6.3 38.1 N/A N/A N/A 17.0 47.0 74.6
Signal Attenuation(dB): 6.3 36.0 N/A N/A N/A 22.5 46.6 N/A
SNR Margin(dB): 5.8 5.9 N/A N/A N/A 6.1 6.2 N/A
TX Power(dBm): -15.1 -11.2 N/A N/A N/A 11.5 7.6 N/A







# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 859 Kbps, Downstream rate = 29548 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 29682 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 6.1
Attn(dB): 22.2 0.0
Pwr(dBm): 13.0 -9.1
VDSL2 framing
Bearer 0
MSGc: 20 118
B: 241 29
M: 1 1
T: 64 14
R: 12 10
S: 0.2594 1.1873
L: 7832 283
D: 1 1
I: 254 42
N: 254 42
Counters
Bearer 0
OHF: 11037 2711
OHFErr: 0 0
RS: 691082 151840
RSCorr: 0 0
RSUnCorr: 0 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2611260 0
Data Cells: 58 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 22 22
AS: 46

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 4.16 16.68
OR: 49.91 59.44
AgR: 29731.79 859.12

Bitswap: 8/8 1/1

Total time = 1 min 8 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 1 min 8 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 min 8 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 45 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#


xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 853 Kbps, Downstream rate = 29464 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 29466 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205)
DS: (33,859) (1216,1961)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 853 kbps 29464 kbps
Actual Aggregate Tx Power: - 9.7 dBm 13.0 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 6.3 38.1 N/A N/A N/A 17.0 47.0 74.6
Signal Attenuation(dB): 6.3 36.0 N/A N/A N/A 22.5 46.6 N/A
SNR Margin(dB): 5.8 5.9 N/A N/A N/A 6.1 6.2 N/A
TX Power(dBm): -15.1 -11.2 N/A N/A N/A 11.5 7.6 N/A
#

It looks like you posted the same pbParams data twice.

However, regardless of that, there seems to be very little difference when running from the battery.

Was ALL the mains power switched off for the battery driven test?

If so, it does appear that you have at least eliminated any potential sources of interference from within your house.



It's certainly an odd problem.
At least the 4 Mbps that you previously achieved looks about right at that distance & with those DS speeds, attenuation levels etc.


These are my stats from an 1100m connection:-

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 2223 24

xdslcmd info --pbParams xdslcmd: ADSL driver and PHY statusStatus: Showtime Retrain Reason: 1Last initialization procedure status:   0 Max:    Upstream rate = 3915 Kbps, Downstream rate = 21292 KbpsBearer: 0, Upstream rate = 4165 Kbps, Downstream rate = 21488 Kbps  Discovery Phase (Initial) Band Plan US: (7,32) (871,1205) (1972,2782) DS: (33,859) (1216,1961) (2793,3970) Medley Phase (Final) Band PlanUS: (7,32) (871,1196) DS: (33,859) (1216,1646)           VDSL Port Details               Upstream                Downstream Attainable Net Data Rate:            3915 kbps              21292 kbpsActual Aggregate Tx Power:             7.0 dBm               12.4 dBm ====================================================================================  VDSL Band Status       U0      U1      U2      U3      U4      D1      D2      D3   Line Attenuation(dB):  8.3     55.4     N/A     N/A     N/A    22.0    68.1     N/A   Signal Attenuation(dB):  8.3     54.8     N/A     N/A     N/A    31.3    68.1     N/A           SNR Margin(dB):  5.6     5.6      N/A     N/A     N/A    6.1     6.1      N/A            TX Power(dBm):  0.7     5.8      N/A     N/A     N/A    11.3    5.8      N/A   .

Apparently DSL can operate on just 1 leg of the pair, at reduced speeds.

However, I'm sure the leg balance will have been tested as O.K., otherwise an engineer would have mentioned it & investigated accordingly.

It would probably also clobber your DS speeds.


Do you have another HG612 modem to try or maybe even borrow one?

It seems far too much of a reduction to be down to crosstalk.

I suspect a loose/corroded joint somewhere that could be a HR issue for your connection, maybe even causing interference for other users?

Edited by deleted (Thu 11-Sep-14 21:48:42)

Many thanks.

I'm pretty sure I didn't duplicate the pbParams test. I'm not even sure I could doing copy/paste from the clipboard with stats inbetween. Maybe it just didn't change. I can try again (when I have the house to myself).

Mains was off at the master earth leakage breaker.

This is my third modem; I bought a spare on eBay, and later an OR engineer swapped that one.

One engineer did comment that the leg balances were surprisingly similar.

Is HR high resistance? That's been checked too, though I don't know if they test at different frequencies.
My ISP is almost as frustrated as I am with BTO, who just dismiss this as crosstalk / REIN beyond their control even though the engineers that visit privately admit it can't be.

In reply to a post by Reentrant:

Many thanks.

I'm pretty sure I didn't duplicate the pbParams test. I'm not even sure I could doing copy/paste from the clipboard with stats inbetween. Maybe it just didn't change. I can try again (when I have the house to myself).

The Max & Bearer data is identical in your pbParams data, yet your 2nd xdslcmd info --stats data does indeed show different speeds.

Mains was off at the master earth leakage breaker.

Okay.

This is my third modem; I bought a spare on eBay, and later an OR engineer swapped that one.

I only asked as I wondered if it could possibly be a defective modem (clutching at straws for some sort of explanation).

One engineer did comment that the leg balances were surprisingly similar.

It does now start to be sounding more like an 'interference' issue again.

Is HR high resistance? That's been checked too, though I don't know if they test at different frequencies.

Yes. HR = High Resistance

My ISP is almost as frustrated as I am with BTO, who just dismiss this as crosstalk / REIN beyond their control even though the engineers that visit privately admit it can't be.

I can't quite accept it as being REIN/crosstalk (yet).

I do hope you update us with the actual cause (when/if it ever gets fixed).

In reply to a post by Bald_Eagle1:

I do hope you update us with the actual cause (when/if it ever gets fixed).

Will do ....

Hmm. I'm not aware of any BTO activity around here, and neither is my ISP. But two days ago I noticed that "max upstream" had increased to around 2000kbps and yesterday to around 3000kbps, although actual upstream rate was still well under 900kbps. Today I get:

Max: Upstream rate = 3912 Kbps, Downstream rate = 29376 Kbps
Bearer: 0, Upstream rate = 1999 Kbps, Downstream rate = 29376 Kbps

The previous gap in the tone map between around 950-1200 is now filled. I have no idea what - if anything - has changed nearby but it's a definite improvement.

Upstream has been slowly improving every day and is now just about back to my normal 4mbps. Apparently BTO did detect REIN from a nearby property and left a card for the owner to contact them.; that's all I know.