Is this the effect of Crosstalk?

Provider : BT FTTC
Modem : Zyxel VMG3925-B10B
Router : ASUS AC86U with Merlin firmware
Connection : Ethernet

I am on the end of a long rural line and have been noticing my Sync speeds slowly sagging over the past few months with a few modem resyncs, inevitably downwards. About six months ago I routinely saw a sync of around 9500 down. Over time it got worse to the current point where I sync at about 6400 and I am really struggling with even a single YouTube stream.

My TBB Speed Test this morning came in at 4.8Mbps down and 1.0Mbps up which is about the worst it has ever been. The BT Availability Checker for my line gives a range of 3.9 to 8.4 expected with a handback of 2.9 (and as the quality of the line sags, the handback value sags too).

http://www.dcoffey.co.uk/images/misc/BTChecker.jpg

Since I am using the Zyxel I am able to watch the line with tools such as DSLStats and I noticed that the Max Attainable was sagging at evening peak times with a corresponding drop in SNR. The modem was trying to make sure I still maintained a 6dB SNR at even the worst time of the evening which meant that I have been putting up with slow speeds but a very high SRN of 10dB to 11dB at off-peak times.

I watched the Max Attainable and SNR graphs for a full day and spotted something odd...

http://www.dcoffey.co.uk/images/misc/MaxAttainable.jpg
http://www.dcoffey.co.uk/images/misc/SNR.jpg

You will see that the day starts off at about 8500 Max Attainable and 10dB SNR. It remains very steady all throughout the day until about 8PM where it begins to sag. By 1AM it is down to a 7000 Max Attainable and around 7dB SNR (which is the low point so is probably why my Modem won't resync any higher throughout the day) but here is the oddity. It STAYS low until WAY after the peak time is over. It doesn't really start to recover until 4AM.

Is the BT peak period really that long?

Do you think this is simple crosstalk at peak time or is something else happening here?

I took the graph over a Saturday night but the weekly pattern is pretty much the same too.

Those graphs show a sag overnight and propogation of radio waves in the MF and HF bands is improved at night. This means a lot of stray radiation could be picked up by your line and thus cause an increase in noise. It is NOT down to BT peak usage periods.

Can you get some "bits per tone" plots taken at say 18:00, 21:00, 00:00, 03:00 amd 06:00. Putt them in a single image and see how they compare.

Hmm... Interference is not something I had considered.

It is a line that runs underground for the first kilometer or so then pops up and runs along the usual poles for another couple of kilometers. There are large overhead pylons in the vicinity as well as local overhead three-phase lines.

Can DSLStats record the Bits over time or do I have to manually take a screenshot at specific times?

I believe you need to do a screenshot - or DSL stats can do its own capture, I believe although not sure if it can do it timed. You can also add the SNR/tone to Bits/tone in general settings (from memory).

There is an optional Bitswaps per Minute graph and Bitswaps per tone graph as well as the usual Bitloading one. Oh, and I see SRN per tone too.

Which would be useful here?

Thanks for the tip - I have got DSLStats snapshotting at any interval I want. I can certainly do a 3-hourly snapshot without intervention but have I got the graph set up in a way that would be useful?

I ended up with this...

http://www.dcoffey.co.uk/images/misc/Bitloading-2019...

If you think this is useful I will leave it running overnight and we can see what it gets.

Whilst the OH peer stuff can provide noise, it is extremely unlikely to the cause of this, and certainly nothing you might get anything done about.

Do you have an SSFP on your NTE ? They have a built in RF filter.

Our socket is an Openreach Mk4 Master Socket 5C. Is that what you mean?

That is the graph - snapshots would be useful.

There really is something amiss with that already - from tone 290 at around 1.2 Mhz to to 520 at 2.2 Mhz there is a total void.

There are a lot of frequecy blocks arround there that are "free to use and unlicenced" including cordless phones, remote controls, ...

edit to add:

http://static.ofcom.org.uk/static/spectrum/fat.html and put 1 - 3 Mhz in te search

Edited by MHC (Sun 11-Aug-19 13:24:51)

Do you think there is a fault here then that might be remedied with an OR visit or are we stuck with it?

From talking to my neighbours, we all have similar speed test results but none of the others are bothered about improving it.

I will take three-hourly snapshots overnight and list them tomorrow.

To be honest, don't think there is a fault, just a lot of interference.

That is my initial guess.

With the bulging detachable front plate, with a phone jack and one for the router ?

Yes, that is correct.

I managed to get a few snapshots during the night. DSLStats seemed to want to do hourly snapshots which was fine but it stopped before midnight which was a shame. I will have another go tonight if these shots are not enough to get to the root of the issue.

Max Attainable Speed was around 8500 up to 7PM then started to sag just after 8PM and by 10PM was about 7500. I reckon it hit its trough at about 1AM and was still climbing back out on the SNR graph from 4AM to 5AM and was back to normal at 6AM.

6PM : http://www.dcoffey.co.uk/images/misc/Bitloading-2019...
7PM : http://www.dcoffey.co.uk/images/misc/Bitloading-2019...
8PM : http://www.dcoffey.co.uk/images/misc/Bitloading-2019...
9PM : http://www.dcoffey.co.uk/images/misc/Bitloading-2019...
10PM : http://www.dcoffey.co.uk/images/misc/Bitloading-2019...
11PM : http://www.dcoffey.co.uk/images/misc/Bitloading-2019...

Opinions?

Look at them in sequence and you will see teh SNR line in reasonable "smooth" up until the 21:00 image where it starts to become a lot rougher and more so at 22:00 and 23:00. That, to me suggests pick up from radio waves and look, for example, how the notch at tone 602 (2.5-2.6MHz) gets significantly worse.

The real oddity, still, is the total lack of any usable tones from 300 to 520 ...

I realise this is only speculation and may not be how it works in the real world but... up until six months or so ago my connection was more stable and synced at around 8500. Then OR decided to remove a section of the rural poles and bury the cable on about half the run from the cabinet to our cluster, leaving the remaining half above ground on the old poles. From roughly that date onwards, my connection suffered these slowdowns.

I am wondering if the work they did effectively "tuned" the remaining cable to be a better shortwave antenna?

I appreciate there is probably nothing we can do about this issue but do you think it is worth booking a chargeable OR engineer visit to have the tone range and the nighttime degredation looked at?

It could be ... RFI is a "black art" and often not predicatable.

As for a visit, I don't know what it would achieve, apart from seeing what you have. There are a coupe of BT Techs on here who may have a little more idea about what might/could be done.

Don�t bother booking the visit ....

A fair percentage of Openreach staff won�t take anything other than polite interest in your theories.

As long as their PQ test is good, and it tests OK on FT2 (their internal test system) then it�s Goodnight Vienna.

Any thoughts on what might be the cause? Especially that total blank block?

Hmmm ....

A first hunch might be some strange mask or profile, option two, an iffy DSLAM port ?

Course, it could be the OP�s kit not making full use of the tones couldn�t it ?

If there was astrange mask/profile, or failure to use ports then I would still expect to see an SNR value rather than 0 ...

I do still have my HH6 but I don't think it is possible for a home user to view the tones on the HH6?

I could put the HH6 on overnight and query it through its user screen to view the current sync speed and max attainable as we enter the nightly trough. If the behaviour on the HH6 matched the behaviour on my Zyxel, we could presumably eliminate the Zyxel as being faulty?

Not had time to chase this down, but just wondering if your bin to frequency figures are correct, as I thought this was VDSL2 and should start at around 2.2 MHz and you've been talking about ADSL2+ type frequencies

Maybe need more coffee at this end, but just wanted to mention

FTTC still starts down at 25kHz (or there abouts) ... Up0 uses tones 6 or 7 to 32; Dn1 tones 33 to 850 (ish)

Tone 0 is at 0Hz and tone 7 at around 30KHz

If FTTC was to start down at 25 KHz it would be stomping all over ADSL and ADSL2+ where ADSL is 25 KHz to 1.1 MHz and ADSL2+ is 25 KHz to 2.2 MHz

UK is Profile 17a for VDSL2

So are you saying that VDSL2 is operating in the ADSL spectrum, if so it should pretty much have ADSL length and speed performance which it does not.

I can confirm that I am on VDSL2 Profile 17a according to DSLStats.

When I look at the Bits graph I see the green (upload?) band is from tones 5 to 32 (21.5kHz to 138kHz) and the red (download) tones start from 47 to 295 (202.7kHz to 1272kHz) and then 522 to 647 (2251kHz to 2790kHz).

Brain was not fully working, there is some use down at that end but the ANFP power mask is used to avoid trashing ADSL/ADSL2+ signals via cross talk.

Performance wise VDSL2 only kicks in at 2.2 MHz once clear of the ADSL/ADSL2+ frequencies.

The power mask in use on that cabinet may go towards explaining why some blocks are not in use.

Yes, it does start down at 25kHz.

https://images.slideplayer.com/11/3315602/slides/sli... shows the spectrum usage.

But like most online resources they don't reflect the impact the ANFP in the UK has on VDSL2

The power mask in use on that cabinet may go towards explaining why some blocks are not in use.

�A first hunch might be some strange mask or profile�

Ooooh, do I win anything ?

Not crosstalk.
DLM has capped/banded the downstream at 6.4Mb.

The stats suggest the line will sync higher if the cap wasn't in place.

Can you post the full output of the Telnet Data > Connection Stats tab on DslStats?

Here we go...

xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1169 Kbps, Downstream rate = 8478 Kbps
Bearer: 0, Upstream rate = 1169 Kbps, Downstream rate = 6399 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 10.1 6.3
Attn(dB): 36.2 0.0
Pwr(dBm): 4.0 10.4

VDSL2 framing
Bearer 0
MSGc: -6 26
B: 65 31
M: 1 1
T: 0 54
R: 6 0
S: 0.3238 0.8562
L: 1779 299
D: 2 1
I: 72 32
N: 72 32
Q: 2 0
V: 0 0
RxQueue: 108 0
TxQueue: 27 0
G.INP Framing: 18 0
G.INP lookback: 27 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 6388503
OHFErr: 57 0
RS: 908276026 344799940
RSCorr: 128628 0
RSUnCorr: 0 0
Bearer 1
OHF: 4595050 0
OHFErr: 0 0
RS: 27569930 0
RSCorr: 951 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 89293 0
rtx_c: 67685 0
rtx_uc: 1666 0

G.INP Counters
LEFTRS: 10 0
minEFTR: 6398 0
errFreeBits: 7158503 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 908106937 0
Data Cells: 40634600 0
Drop Cells: 0
Bit Errors: 0 0

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

ES: 33 0
SES: 2 0
UAS: 28 28
AS: 73819

Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 11.60
OR: 0.01 22.06
AgR: 6497.61 1191.34

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

Bitswap: 50782/50783 0/0

Total time = 20 hours 30 min 47 sec
FEC: 128628 0
CRC: 57 0
ES: 33 0
SES: 2 0
UAS: 28 28
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Latest 15 minutes time = 47 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
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Previous 15 minutes time = 15 min 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
Retr: N/A
HostInitRetr: N/A
FailedRetr: N/A
Latest 1 day time = 20 hours 30 min 47 sec
FEC: 128628 0
CRC: 57 0
ES: 33 0
SES: 2 0
UAS: 28 28
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 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
Retr: 0
HostInitRetr: 0
FailedRetr: 0
Since Link time = 20 hours 30 min 17 sec
FEC: 128628 0
CRC: 57 0
ES: 33 0
SES: 2 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
$

The line should sync at the max attainable figure, or just slightly under it.

It's a Huawei cabinet with G.INP enabled so the max attainable is pretty accurate (unlike with INP/Interleaving enabled).

DLM caps the line for too many resyncs in a set time period.
So anything that caused the power to go on/off repeatedly or perhaps rebooting the modem repeatedly.

I'm not sure if ISP's still have the ability to request a remote DLM reset as that scheme was coming to an end.

It might need an on site OpenReach engineer to reset the DLM but it's not easy to convince the ISP to send 1 out when you are within the estimates.

The line is definitely capped at 6.4Mb though.
Every resync will result in a 6399 sync with SNRM above 6dB.

If you can't get the DLM reset then my advice is leave the modem in sync at all times. This makes it more likely DLM will remove the cap.

Tinkering/rebooting the router makes no difference to the DLM but rebooting the modem is treated as the line being unstable.

Edited by j0hn83 (Tue 13-Aug-19 14:33:30)

I have a feeling it was the recent summer thunderstorms. We had power outages, lightning strikes and similar in the area for a few days.

I have reset the modem about three times in the past week and noticed the 6399 remained so I guess I am capped until it stabilizes.

Still stuck at 6399 down at the moment despite an automatic resync last night when the upload speed nudged down a couple of bytes. Fingers crossed the DLM will unbunch its panties in a couple of days.

I have a scheduled all-day powercut on next Monday so if it hasn't released the speed by the end of that I will have to phone it in. My TBB Speed Test results are down to 4.8Mbps down, 0.9 up with 80ms latency which is the worst they have ever been.

https://www.thinkbroadband.com/_assets/speedtest/but...