Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Alex Atkin UK on October 13, 2017, 12:44:06 PM
-
Can anyone make head nor tail of what has happened to my line?
Its been rock-solid stable for years, I used to get 100Mbit on Digital Region and a solid 80Mbit on BT when I had to move over. I had noticed recently a slow decline in attainable speed and INP got turned on for downstream due to creeping errors, but suddenly I'm down to 63Mbit.
It seems on the 19th September between 12:00 and 13:00, something happened to cause my line stats to deteriorate quite badly but it wasn't until yesterday that the drop in SNRm (which unknown to me had been lingering around 0.6 since then) finally caused a resync.
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 28858 kbps 88124 kbps
Actual Aggregate Tx Power: 5.0 dBm 13.7 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 4.2 16.8 25.3 N/A N/A 8.1 20.3 32.1
Signal Attenuation(dB): 4.0 16.6 25.2 N/A N/A 10.1 20.2 32.0
SNR Margin(dB): 12.8 11.6 10.4 N/A N/A 4.8 4.7 4.7
TX Power(dBm): -5.9 -27.9 4.6 N/A N/A 10.8 7.4 7.4
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 28003 kbps 72468 kbps
Actual Aggregate Tx Power: 5.0 dBm 13.7 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 4.2 16.8 25.3 N/A N/A 8.1 20.3 32.1
Signal Attenuation(dB): 4.0 16.6 25.2 N/A N/A 10.3 20.1 32.0
SNR Margin(dB): 13.2 11.4 9.5 N/A N/A 0.6 0.6 0.6
TX Power(dBm): -5.9 -27.9 4.6 N/A N/A 10.8 7.4 7.4
Zen don't want to do anything due to being above 55Mbit, which is odd as that is the Impacted rate but I'm fairly sure my line has always been considered Clean. Does a climb in crosstalk suddenly re-classify a line as Impacted? From the BTW page it sounds like Impacted is only if the physical line has issues, which mine does not.
(https://server.csdprojects.co.uk/xdsl/stats/2017-09-19/12%3A00_SNR_Declined.png)
You can see that there was a massive reduction in SNRm for all downstream frequencies between 12:00 (green) and 13:00 (red). At the time bitswapping clearly compensated causing the shift in bits per carrier and thus why the connection didn't drop.
When it finally resynced you can see the extent of the issue, blue being the current stats:
(https://server.csdprojects.co.uk/xdsl/stats/2017-09-19/12%3A00_SNR_Declined_resync.png)
Can also be seen on MDWS user alexatkin.
-
This post only focusses on the theory element ...
Zen don't want to do anything due to being above 55Mbit, which is odd as that is the Impacted rate but I'm fairly sure my line has always been considered Clean.
This classification is confusing, as it really doesn't have anything to do with the actual state of your line, and more to do with the trust in the state of your line. From then on, it really only relates to what guarantees an ISP is willing to honour.
The way in which the state can be trusted is by getting the installation done by an engineer. At which point the ISP (and Openreach) will trust that the line is clean, and willing to send engineers out to look at the line when it gets to the handback speed of the clean line.
The distinction came into being when Openreach allowed self-install to take place. Lines that are self-installed are not trusted to be clean; the quid-pro-quo for a cheap installation would be that the ISP (and Openreach) would then only honour the "impacted" speed, and send out engineers when the lower threshold is hit. Note that the line might actually be clean, but no-one knows. And because the subscriber chose not to pay for the engineer installation, there is no basis to trust whether it is clean.
Move on a couple of years, and the position now is a little muddier. Some ISPs quote the clean speeds (eg Plusnet), while some quote the impacted speeds (eg TalkTalk), while some quote the entire range of clean and impacted (eg AAISP). Nowadays, all that really matters is what range the ISP chose to use when "guaranteeing" your speed were first installed.
Of course, migrations muddy this picture even further. An engineer installation with Plusnet, migrated to TalkTalk, does not necessarily take the "trust" with it. And, while an engineer visit might change a line from actually-impacted to actually-clean, it doesn't necessarily change the ISP's trust level for future faults.
However, I don't know what Zen does with either installation or with the personalised speed estimates on signing up. But it likely fits into the above picture well.
From the BTW page it sounds like Impacted is only if the physical line has issues, which mine does not.
The distinction arose at the time self-install was introduced. The *real* problem that BT wanted to avoid was allowing a cheap self-install happen, but then being called out because of bad house wiring. My starting point is to think that "impacted" = bad wiring inside the home.
Does a climb in crosstalk suddenly re-classify a line as Impacted?
No. The range in speed (on both clean and impacted) is meant to cover the variation caused by crosstalk.
Each range, incidentally, is meant to reflect the 20th and 80th percentiles - so 20% are faster than the top, and 20% are slower than the bottom.
The handback speed is meant to represent the bottom 10%, which represents the cases where BT are willing to send an engineer (in cases when the only evidence is the slow speed; they'll send engineers where line tests fail irrespective of speed).
-
So much for theory, now on to the practice...
You can see that there was a massive reduction in SNRm for all downstream frequencies between 12:00 (green) and 13:00 (red). At the time bitswapping clearly compensated causing the shift in bits per carrier and thus why the connection didn't drop.
An nice way to visualize the change. It clearly shows the increase in noise (or, I guess, drop in signal) over all the downstream frequencies above the ADSL2+ band.
A really clear picture of what can happen from one or more new subscribers adding crosstalk.
Yes - it really can hit speeds *a lot*. I think we've seen 3dB changes before, this is approx 4dB.
When it finally resynced you can see the extent of the issue, blue being the current stats:
This time, because there has been a resync, you can also see the change reflected in the QLN graph. It also portrays the effect of crosstalk, though this time obvious in the upstream too.
I don't know why upstream changes didn't show in the first graph though.
Can also be seen on MDWS user alexatkin.
This shows you were already on an interleaved profile before the change, and have stayed that way throughout. You were getting some FEC errors beforehand, with few CRCs.
As crosstalk increased, you ended up with a lot of FEC errors ... but they seem to have all been fixed, as you ended up with relatively few CRC and ESs.
In terms of DLM, it seems like no harm done. But it is still a hefty drop in speed.
-
So it seems all I can do is wait until the speed drops below 55Mbit so Zen can raise it with BT? :'(
Sadly there is little hope of anything improving such as vectoring, its an ECI cabinet. :no:
Guess I will be power cycling in the early morning in the hope of recovering a little bit of speed. Its frustrating that it was so stable with a REALLY low SNRm but insists are targeting 6dB.
-
So it seems all I can do is wait until the speed drops below 55Mbit so Zen can raise it with BT? :'(
Worse than that ... BT would likely attend, and say there's nothing they can do. Your line isn't showing any signs of faults ... just signs of other users.
Sadly there is little hope of anything improving such as vectoring, its an ECI cabinet. :no:
There's scope to get back to 80Mbps, but it will need your line changing from the current interleaved setting to a G.INP retransmission one. If BT ever start/complete that rollout.
If they do, your line would likely also cope with lower target SNRM levels too, so there's more headroom available in future. If that rollout happens.
-
I was gutted (but not at all shocked) that I'm not in one of the G.fast areas in Sheffield. Typically they seemed to have only picked areas with competition from Virgin Media.
I was actually okay with that, until now.
-
I see that today, DLM seems to have put you onto fastpath. Presumably because of the big drop in errors since you went back to running at 6dB margin.
I guess the issue now will be where the ES rate ends up, and whether DLM reacts.
-
Had a big power cut yesterday in Sheffield which has completely restored my speed.
I'm guessing its temporary until something goes wrong as its sat with a 3dB SNRM. It does prove it was crosstalk that caused the issue though.
I wonder if the person who's line caused the problem is away for the holidays with their modem/router off. I assume DLM wouldn't reset if the exchange lost power?
-
Curse you DLM:
This is to let you know that a resync/restart occurred on your line at 10:39 on Sunday 31st December 2017 local time (+/- 1 minute).
Reason: 1 Remote Defect Indicator/DLM
Current Downstream Sync Rate is now 69892kbps @ 6.2db SNRM. Attainable is 69892kbps
Current Upstream Sync Rate is now 20000kbps @ 12.4db SNRM. Attainable is 29398kbps
as measured at the time of this email.
To be fair, looking at the graphs I can see my OHF drastically increased when I resynced at full speed after the power cut, so I can see the logic in what its doing here. Its just frustrating as despite the errors, the sync was stable and I did not notice any detrimental effects.
-
Looking at your graph I dont know what DLM has done.
No interleaving or (obvious) banding in effect. (assuming there is still no 70mbit banding profile).
I wonder if one such action of DLM is it detects errors alongside a low SNRM it will simply force a resync without changing profile, or you may be 74mbit banded but not noticeable as syncing below it. Based on previous behaviour on my line I observed that DLM will favour banding if at the time of instability the SNRM is significantly below the target.
If you can please ask your isp to check your line profile, it wouldnt surprise me if its 74 banded now, but if it is its not service affecting, so not a reason to raise a fault.
-
Or the resync wasn't the DLM's doing.
-
Can RDI be given as the reason when its not dslam initiated?
-
I don't see why not, per G.993.2 the Remote Defect Indicator bit is for reporting a far-end SEF to the other end.
After all the noise/crosstalk resumed after the power cut, it was then running at a lower SNRM, so then of course it's easier for a burst of noise to knock out the connection. I don't really think you can declare it stable at that speed and SNRM after only 1 day.
-
ok thanks for the explanation ejs.
-
Could be, the graph did seem to show a HUGE spike in errors which is certainly something you would expect to drop the connection.
The strange thing is my latency seems very slightly higher, but maybe my PPP session is on a different node at Zen?
What is a 74Mbit banded profile? Does it basically just throttle throughput to 74Mbit rather than the usual 76Mbit? Its obviously a none-issue if I'm only syncing at 69.9 anyway.
[EDIT]
Latency was PPP session related:
64 bytes from 8.8.8.8: icmp_seq=22 ttl=60 time=18.0 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=60 time=18.4 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=60 time=17.9 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=60 time=17.8 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=60 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=60 time=18.0 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=60 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=60 time=17.8 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=60 time=18.0 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=60 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=60 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=60 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=60 time=17.9 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=60 time=17.9 ms
Force a reconnect:
64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=14.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=14.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=14.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=60 time=14.5 ms
-
just a thought.. assuming you are still on hg612. I found on my eci line the 612 whilst being stable would give the lowest sync when compared to other devices like zyxel and billion in bridge mode. have you ever tried a different modem to see if it improves ds sync..
-
I only ever tried the ECI modem and as I used to get full sync it obviously made no difference.
Perhaps I should have a another look into it, I was actually planning to find those instructions for flashing OpenWRT on the ECI modem so that would seem like a good time to look into it.
I do also have a Home Hub 5 with LEDE installed but apparently the modem driver they use isn't capable of full speed there anyway.
I would be loath to pay for anything else unless it was G.fast compatible so it was a little future proof.
[EDIT]
Tested the Home Hub 5 and I think whoever said its lacking was thinking when using it as a fully router. I tried it in bridge mode and it seemed like it might work, but there is some weird stability issues where traffic would stop flowing properly, plus it doesn't support baby-jumbo frames on the Switch so that's a drag.
Sync wise though it does look like my line has a little leeway with other modems with a gain of nearly 2Mbit, although not close to enough to be worth spending money on.
Status: UP
Line State: showtime_tc_sync [0x801]
Line Mode: G.993.2 (VDSL2)
Annex: B
Profile: 17a
Data Rate: 71.889 Mb/s / 20.000 Mb/s
Max. Attainable Data Rate (ATTNDR): 72.137 Mb/s / 28.506 Mb/s
Latency: 0.0 ms / 0.0 ms
Line Attenuation (LATN): 12.9 dB / 15.5 dB
Signal Attenuation (SATN): 12.9 dB / 15.3 dB
Noise Margin (SNR): 6 dB / 12 dB
Aggregate Transmit Power(ACTATP): 6.2 dB / 13.8 dB
Forward Error Correction Seconds (FECS): 188 / 57278
Errored seconds (ES): 5 / 9888
Severely Errored Seconds (SES): 0 / 2
Loss of Signal Seconds (LOSS): 0 / 0
Unavailable Seconds (UAS): 35 / 35
Header Error Code Errors (HEC): 0 / 0
Non Pre-emtive CRC errors (CRC_P): 3 / 0
Pre-emtive CRC errors (CRCP_P): 0 / 0
Line Uptime: 1h 24m 22s
ATU-C System Vendor ID: Infineon 208.134
Power Management Mode: L0 - Synchronized