Kitz Forum
Chat => Chit Chat => Topic started by: burakkucat on October 22, 2021, 05:48:27 PM
-
I am really not that bothered with the results of throughput speed tests and very rarely perform one. If I check anything, it will be the xDSL synchronisation speed.
Here follows the output generated by an "xdslctl info --show" command for my circuit --
> xdslctl info --show
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 16174 Kbps, Downstream rate = 43845 Kbps
Bearer: 0, Upstream rate = 9997 Kbps, Downstream rate = 40000 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): 7.3 9.1
Attn(dB): 16.0 0.0
Pwr(dBm): 13.3 6.9
VDSL2 framing
Bearer 0
MSGc: -6 43
B: 178 31
M: 1 1
T: 0 64
R: 12 2
S: 0.0000 0.1017
L: 10727 2675
D: 16 1
I: 191 34
N: 191 34
Q: 16 0
V: 2 0
RxQueue: 21 0
TxQueue: 7 0
G.INP Framing: 18 0
G.INP lookback: 7 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 789893
OHFErr: 0 79
RS: 720723632 187496
RSCorr: 311 277
RSUnCorr: 0 0
Bearer 1
OHF: 1604171 0
OHFErr: 0 0
RS: 9624654 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 6189 0
rtx_c: 3 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 39991 0
errFreeBits: 15717867 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1982066721 0
Data Cells: 10916976 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: 0 77
SES: 0 0
UAS: 23 23
AS: 25772
Bearer 0
INP: 45.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 11.43
OR: 0.01 34.28
AgR: 40055.74 10031.40
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: 471/471 77/77
>
As can be seen, it is a VDSL2 service provisioned using the Openreach 40/10 Mbps product. The circuit is synchronised at 40.0/9.9 Mbps (i.e. its maximum) and there is SNRM to spare.
Our friend at "The Weaving Shed" introduced me to A&A's LibreSpeed (https://speedtest.aa.net.uk/) tester and, being curious, I tried it out. The result can be seen in the image, attached below.
How is it possible that I achieve a downstream throughput speed equal to the circuit's synchronisation speed? :-X
Am I, therefore, supposed to believe that the writer of that tool does not understand even the basic principals of xDSL technology? ::)
-
Interesting. I tried this a well and noted it didn’t report on multiple threads, reporting therefore only the bandwidth of one Dsl connection.
I don’t know the technology, but they seem quite nefarious in the results. fast.com always reports the highest on my circuits. As you point out only the synchronisation speed can be measured accurately.
-
I wonder about this. Perhaps the authors decided that sync speed is the number that users want to see, what they mean by ‘speed’, not real throughput measured as IP PDUs (ie byte count transferred includes IP headers). Or perhaps it’s just a bug. ;-)
In the past I’ve had wildly impossible upstream results very occasionally.
-
Interesting. I tried this a well and noted it didn’t report on multiple threads, reporting therefore only the bandwidth of one Dsl connection.
I don’t know the technology, but they seem quite nefarious in the results. fast.com always reports the highest on my circuits. As you point out only the synchronisation speed can be measured accurately.
It almost always reports the combined speed for me, it is of course possible for it not to due to the random possibility of every thread ending up on the same WAN, depending on how random background traffic is being allocated.
-
It does appear that libreSpeed compensates for the overhead on the circuit, which is why it's reporting results similar to your sync rates. See some discussion in this issue on github:
https://github.com/librespeed/speedtest/issues/75
Search for "overhead" in the following file to see the actual code:
https://github.com/librespeed/speedtest/blob/master/speedtest_worker.js
It looks like it's using a overheadCompensationFactor of 1.06.
EDIT: If anyone wants to see AAISP's settings, their copy of the above file is here:
https://speedtest.aa.net.uk/speedtest_worker.js
-
Just tried it and got an upload rate of 7.61Mbps against a sync of 6.76Mbps. :no:
-
One wonders if supplier supplied testers are designed to over state, for the obvious reasons!
-
One wonders if supplier supplied testers are designed to over state, for the obvious reasons!
I wouldn't read anything sinister into this from AAISP - they are just hosting an open-source speedchecker, and even provide a link to its source code right there on the speedchecker home page. It's completely transparent.
The decision to fudge the reported speed to try to take account of overheads seems to have been a design choice from the author of librespeed, although it could easily be disabled by AAISP - perhaps they're just not aware of it.