|
|
|
I have had BQM monitoring my line since 24 Aug when the last reset occurred that changed the IP. I've downloaded the XML data and merged (roughly) with my speedtest results
Tue 24/08/2021 07:31 45.30 Mbps 44.85 Mbps 7.11 Mbps 86.139.252.XXX BT
<record timestamp="2021-08-24T06:31:40Z" sent-polls="46" lost-polls="2" min-latency-ns="6951000" ave-latency-ns="7279000" max-latency-ns="7641000" score="201"/>
<record timestamp="2021-08-24T10:53:20Z" sent-polls="100" lost-polls="1" min-latency-ns="6876000" ave-latency-ns="11350000" max-latency-ns="91070000" score="201"/>
<record timestamp="2021-08-27T06:45:00Z" sent-polls="100" lost-polls="1" min-latency-ns="6817000" ave-latency-ns="7700000" max-latency-ns="42560000" score="201"/>
It looks like the line reset at 29 Aug 00:51 based on the number of lost polls, and I'm guessing this is when the up line rate dropped as well.
<record timestamp="2021-08-29T00:51:40Z" sent-polls="100" lost-polls="39" min-latency-ns="6870000" ave-latency-ns="7259000" max-latency-ns="7609000" score="301"/>
<record timestamp="2021-08-29T00:53:20Z" sent-polls="100" lost-polls="29" min-latency-ns="6990000" ave-latency-ns="7393000" max-latency-ns="7880000" score="301"/>
Fri 03/09/2021 16:05 46.20 Mbps 45.44 Mbps 3.80 Mbps 86.139.252.XXX BT
<record timestamp="2021-09-03T15:33:20Z" sent-polls="100" lost-polls="2" min-latency-ns="6945000" ave-latency-ns="16070000" max-latency-ns="88630000" score="201"/>
<record timestamp="2021-09-03T16:16:40Z" sent-polls="100" lost-polls="1" min-latency-ns="6905000" ave-latency-ns="13840000" max-latency-ns="91250000" score="201"/>
<record timestamp="2021-09-03T23:51:40Z" sent-polls="100" lost-polls="1" min-latency-ns="6894000" ave-latency-ns="7443000" max-latency-ns="10630000" score="201"/>
Another reset occurs on 5 Sep and the up line rate increases.
<record timestamp="2021-09-05T23:33:20Z" sent-polls="100" lost-polls="42" min-latency-ns="6855000" ave-latency-ns="7420000" max-latency-ns="11450000" score="301"/>
<record timestamp="2021-09-05T23:35:00Z" sent-polls="100" lost-polls="25" min-latency-ns="6892000" ave-latency-ns="7465000" max-latency-ns="20280000" score="301"/>
Thu 09/09/2021 17:15 47.67 Mbps 46.96 Mbps 7.41 Mbps 86.139.252.XXX BT
Is there anything else to look at in the BQM data?
|
|
|
You really need to be logging the line rates, not BQM data, ideally.
BT FTTC 54/8 (FTTP to be installed on 22nd September)
Cabinet 1 - Colaton Raleigh Exchange
|
|
|
|
Indeed it is. BQM is polling the link latency at Layer 3 (Network) whereas DLM is operating at a far more basic level down at Layer 1 (Physical).
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
I've got dslstats monitoring the line. It may capture info to educate the reasons for the next reset. Sods law says this won't happen for weeks.
The low upload rate isn't an issue as such. Just like to know why it happens.
|
|
|
Have you got a phone? If so, is there noise on it?
BT FTTC 54/8 (FTTP to be installed on 22nd September)
Cabinet 1 - Colaton Raleigh Exchange
|
|
|
Yep. Ahh, takes me back to my CompTIA days... The OSI Model...
BT FTTC 54/8 (FTTP to be installed on 22nd September)
Cabinet 1 - Colaton Raleigh Exchange
|
|
|
|
BT quiet line test is quiet.
I think I need t wait until the next reset. Hopefully the up rate will drop and dslstats will give a clue as to what was happening.
|
|
|
|
The line did a resync at approx 0030 last night. I've got a new IP and my rates have gone up. These are the highest speeds I have seen. Machine also applied MS patch Tuesday updates so dslstat was not running this morning. Looks like reset was performed before patch reboot so dslstats logs may be preserved. Perhaps it is DLM?
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 2.4 5.8
Attenuation (dB) 21.7 0.0
Output Power (dBm) 11.9 7.6
Attainable Rate (Kbps) 54044 10580
Rate (Kbps) 54997 9998
B (# of bytes in Mux Data Frame) 227 79
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 64
R (# of redundancy bytes in the RS codeword) 10 8
S (# of data symbols over which the RS code word spans) 0.1319 0.2542
L (# of bits transmitted in each data symbol) 14440 2769
D (interleaver depth) 4 1
I (interleaver block size in bytes) 238 88
N (RS codeword size) 238 88
Delay (msec) 0 0
INP (DMT symbol) 57.00 0.00
OH Frames 0 0
OH Frame Errors 20008 75
RS Words 766058928 398822278
RS Correctable Errors 23933053 1
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 2667742865 0
Data Cells 2964984 0
Bit Errors 0 0
Total ES 372 70
Total SES 280 0
Total UAS 758 483
Regards
|
|
|
|
It looks very much like your DSLAM rebooted last night.
You connected before other lines on the cabinet.
As you connected before other lines there is less crosstalk so you sync higher.
When the other lines connected a minute or so later this reduces your SNR Margin below the target.
Next time your line resyncs it should return to its usual rate.
Your line was already on a 3dB SNRM target on the downstream and 6dB on the upstream.
That's already the optimum DLM line profile.
None of the changes in sync posted in this thread have been DLM related.
|
|
|
|
Thanks j0hn83,
Could you tell me how you deduced your response from the line stats? Or perhaps its more knowledge / experience?
Besides the SNR, Atten, Output Power, Attain Rate and Rate I can see differences in following
B upstream fro 237 to 79
T upstream from 33 to 64
R upstream from 16 to 8
S uptream from 0.2542 to 0.8793
I upsteam from 127 to 88
N upstream from 254 to 88
INP downstream from 51 to 57
I'm hoping my next reset will show a upstream line rate of around 5000 Kbps because this would be related to my original post.
According to the BT Availability Checker I'm currently within the predicted speeds
VDSL Range A (Clean) 57.9 41.5 11.3 7.4
VDSL Range B (Impacted) 56.1 35 11 6.9
Regards
|