I gotta say this was at the very beginning when I had no SQM running, and with OpenWRT 19.07.
Now, with SQM and on OpenWRT 21.02, I only get effective 37 MBit/s down and about the same speed up. This is despite the broadband modem having a stable sync with data rates of 109 MBit/s down and 42 MBit/s up.
I am very sure that processing power is the bottleneck for me, because I see this in htop
while the speed test is running:
Note that CPU0 is saturated. This is the CPU core that receives all broadband modem interrupts, as can be seen from the vrx200_*
: interrupt counters:
root@router:~# cat /proc/interrupts
CPU0 CPU1
7: 183601493 133293651 MIPS 7 timer
8: 422814 395552 MIPS 0 IPI call
9: 3253833 15239590 MIPS 1 IPI resched
63: 29694735 0 icu 63 mei_cpe
72: 54743360 0 icu 72 vrx200_rx
73: 76305039 0 icu 73 vrx200_tx
75: 0 0 icu 75 vrx200_tx_2
96: 124697346 0 icu 96 ptm_mailbox_isr
112: 304 0 icu 112 asc_tx
(...)
ERR: 1
For what it's worth, due to not having reasonable CPU power, I am using the simplest SQM mode possible, as using e.g. queueing discipline cake
with SQM scripts piece_of_cake
or layer_cake
reduces the throughput to something around 20 MBit/s.
# Available queue disciplines: See directory /var/run/sqm/available_qdiscs
# Available SQM scripts: See directory /usr/lib/sqm
uci set sqm.eth1.qdisc='fq_codel'
uci set sqm.eth1.script='simplest_tbf.qos'
I have G.993.2 as well:
"mode": "G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)"
According to this web site, G.993.2 with profile 17a is not a known combination; also G.993.2 is supposed to not have vectoring and only have up to 50 MBit/s downstream.
Since it says Profile 17a, with down- and upstream vectoring
I am inclined to believe that this is a bug in the reporting, and it is really using G.993.5
instead.