Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tboneuk]

Hi all. I recently bought an ASUS RT-AX88U router and a second hand unlocked hg612 modem to replace my incredibly bad Plusnet Hub. Everything seemed great until I started looking into the stats from the modem. The line speed is apparently 79223 kbit/s, however I'm only ever able to get a max download speed of 73 mbps (wired) from the router connected to the modem. So somewhere between the modem and the router I'm losing 6 mbps and this is pretty consistent. Every test I run, the two numbers are always 6 mbps apart. Is it normal for there to be this sort of speed loss between the modem and a router or is there potentially something else causing this?

Here are the stats from my modem:

Code: [Select]

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 29112 Kbps, Downstream rate = 78744 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79223 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 12.4
Attn(dB): 13.4 0.0
Pwr(dBm): 2.6 2.6
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.0964 0.3771
L: 19912 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 3544102 966044
OHFErr: 19 1
RS: 0 2632342
RSCorr: 0 31
RSUnCorr: 0 0

Bearer 0
HEC: 187 0
OCD: 5 0
LCD: 5 0
Total Cells: 901207797 0
Data Cells: 68648651 0
Drop Cells: 0
Bit Errors: 0 0

ES: 58 3
SES: 27 0
UAS: 4650 4623
AS: 5918

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.66 6.15
OR: 114.98 202.87
AgR: 79338.08 20203.27

Bitswap: 1949/1950 0/0


[burakkucat]

Welcome to the Kitz forum. 

Looking at the statistics from the HG612 modem --

Bearer:   0, Upstream rate = 20000 Kbps, Downstream rate = 79223 Kbps

That is the synchronisation speed. The speed of the link between the modem and the cabinet DSLAM. It is not the data throughput speed. From that "Bearer:" line I can deduce that you are connected via the Openreach 80/20 Mbps product and are, effectively, at the upper limit of the product.

For the data throughput rate (speed), you will have to allow for all the various overheads. Hence it will always be less than the link synchronisation speed.

[Alex Atkin UK]

Getting around 74Mbit throughput from a 79Mbit sync sounds about right, the rest is overheads.

The maximum I ever saw was 74.7Mbit at full sync, and you are every so slightly below full sync.

[Weaver]

Indeed if you do not compare like with like, this can explain the fake discrepancy. Unfortunately one usually has to guess how speedtesters work as they are so vague about what protocols they use and what adjustments if any they have made. When some says ‘speed tester, my first reaction is always ‘speed of exactly what?’.

I think the following are the right TCP throughput figures for VDSL2 without G.INP set to ‘high’ + IP + TCP expressed as percentages of the sync rate:

DSL + TCP + IPv6 + TCP timestamps	92.048880%
DSL + TCP + IPv6	92.822400%
DSL + TCP + IPv4 + TCP timestamps	93.338080%
DSL + TCP + IPv4	94.111600%

Uses Kitz’s figures for VDSL2 protocol efficiency and assumes an IP PDU size of 1500 bytes.

So all together for DSL + TCP + IPv4 efficiency - TCP timestamps gives: 74.56 Mbps, or 73.95 Mbps with TCP timestamps, and IPv6 will be somewhat worse still. For the worst case IPv6 + TCP timestamps, I get a 6.3 Mbps discrepancy between sync rate and TCP payload rate.

[Alex Atkin UK]

This is further complicated by Virgin Media selling cable based on ACTUAL typical throughput.  I do believe however that FTTP is also shifting more to this, so hopefully going forward there will be much less confusion.

[tboneuk]

Thank you for the replies and the clarification!

Funnily enough I did have an Openreach engineer here last week to investigate consistent speed drops (down into the 0.x territory), and he mentioned that potentially my modem was on its way out due to the 6 mbps discrepancy but thought I'd ask here instead... So from what you've all said, it's pretty standard for there to be about a 6 mbps difference from the wall through the modem to the router just due to overhead like error detection and correction and other protocols?

[Weaver]

I don’t agree with such adjustments. The size of IP and TCP headers are not the only protocol overheads, TCP adds yet more slowness because it doesn’t drive the line to 100% usually. And which version of IP do you use, and what about the size of TCP headers, which is also variable? The user might not even be using TCP.

The figures quoted should IMHO exclude IP and TCP as they are just guesswork anyway, and the network providers should measure the true throughput in term of bytes sent in L3 PDUs that is where the cost of IP headers’ bytes are counted as part of the total bytes sent, and they should do this by fully saturating the line without using TCP at all. Different versions of TCP perform differently.

They can quote estimates for TCP throughput as well, but these should be a secondary item, needs to say exactly what it is "TCP payload in TCP/IPv6 with TCP timestamps" and they need ideally to have upper and lower boundaries for those figures, and point out that the TCP payload are very inaccurate figures that depend on the software you have at both ends.

[Alex Atkin UK]

I disagree, the figures should be a worst-case scenario of peak performance the end user can expect, if the service is provided by a means that guarantees the line rate such as DOCSIS and GPON.

As the end user cannot measure the line rate directly, accounting for overheads helps the end user have some idea if their connection is performing within spec or not.

[burakkucat]

. . . difference from the wall through the modem to the router just due to overhead like error detection and correction and other protocols?

Keeping things very simple, I'll say:  "Yes, you've got it. That is correct."