Fritzbox 7520/7530 not full VDSL2 Supervectoring capable?

Hardware Questions and Recommendations
1

Hello OpenWRT Community,

I recently bought a fritzbox 7520 and repaced the original firmware with the latest snapshot openwrt build.

I am using on a 250/40 Mbits VDSL2 supervectoring line.
The setup was really easy, since the dsl firmware is now included in the builds. and connection was established on frist try, even with ds-lite.

I have the problem that the line is syncing at the correct high speeds for supervectoring, but doing multiple speedtests via GBE Ethernet, the download is capped at 160Mbps.

Is this a config issue, or is the device CPU not able to handle the load? (short time load goes up to 0.6)

Another fritzbox 7590 AX has no problems to provide 250Mbits in Download. The only difference I saw was G993.2 on the 7520 vs G993.5 on the 7590AX.

image
image1108×249 30 KB

image
image1084×434 34.6 KB

image

This is a comparison between the devices:

image
image1412×327 62.5 KB

2

You need to exteact non-distributable vectoring firmware from oem download file or files catalogued here:

vdsl and adsl is not same.

1 Like
3

I will try a different version.
But is this still needed even with https://github.com/openwrt/openwrt/pull/15550

4

IF the screen shot is correct this looks mostly cosmetic... "G993.5 describes vectoring, so G.993.2 (VDSL2, Profile 35b, with down- and upstream vectoring)" means that G.993.5 is in use...

The sync looks fine (close to or even at full sync, that is as high as the ISP's sync limit allows), the bigger question is what is that poor 7520 doing? Is this just acting as bridged modem or do you operate it as full fledged WiFi-router?

5

This is not your issue, without a vectoring firmware, the GUI would not say "with down- and upstream vectoring" and more drastically the DSLAM/MSAN would assign you to the fall back profile for non-vectoring capable devices, which only uses the first 512 carriers (up to 2.2 MHz), resulting in ~20 Mbps Download sync and at best 3 Mbps for Upload.

The default firmwares for the vrx518 devices (if you follow the instructions from the OpenWrt wiki for the installation) are vectoring capable.

No, not to get vectoring. I can not rule out that other firmewares work better in some dimensions, but from the limited data you posted it is not clear whether you are limited by the DSL link at all....

6

Hi there, thanks for your quick help!

I updated the firmware from:
xcpe_8D1507_8D0901.bin (which was delivered in the the snapshot release without manual steps)
to:
xcpe_8D1F17_8D1012.bin (from a vigor modem)

The Noise Margin and the speed has increased a little bit.
Before the Noise Margin was around 8.4/8.9db
Now it is at 9.6/9.2dB.
(This seems to be even better than the Fritz 7590 AX which has 9.8/7.4db.)

This is also reflected in slightly but consistent faster download and upload while doing a speedtest from a LAN client.
before 161.5/42.8 Mbps vs after 170.4 / 43.3 Mbps.

The device is currently being used as a modem and router with only one LAN client and wifi disabled.
The One-Minute Load peaks at 0.4 while doing a speedtest.
I do not think this is an CPU issue.
Since the new firmware shows different performance I more leaning to the DSL side.

Is there anything I can provide to analyze this further?

7

Is there anything I can provide to analyze this further?

I guess just as a test if you had a usb ethernet adapter and support for it in your openwrt build you could then test if it's a dsl<>ethernet issue
if the speed stays the same then it's just dsl maaaybe, but if it's suddenly over 170mbit/s then hmm
seems totally unlikely that it would, but hey just an idea

You probably should rule out the cpu though, maybe it would help to see what the individual cores are doing and if one is getting overloaded. Even if you just ssh in and keep that window open while you do a speed test, the usual 'top' doesn't show each core so maybe you'd need your build to have htop or btop or something. If cpu0 is getting maxxed out when you are doing a test you can try an irq affinity script, you don't even need to do a firmware upgrade you can just install the script in the right place and reboot

8

I did some speedtests with htop and btop open.
CPU0 is always at a 100% while downloading. The other 3 cores are idling at 5-10%.
But there is no user process shown that has 100% usage.

After installing irqbalance and enabling it with standard config, I was able to achieve 180Mbps.
So it might be the CPU. I have to check out the irqbalance page more to find out how to distribute the load.

9

Try to enable receive packet steering in the firewall as well, which might help...

Softinterrupt context, heavily used by the kernel's networking code, is by default not shown in htop. But you can enable detailled CPU time reporting somewhere in the settings... this is one of the first things I do with htop on a new machine :wink:

10

You see the dispatch of CPU times better in HTOP -> F2 Setup -> enable CPU detail and unhide kernel threads. red is hardware interrupts pink is soft interrupts eg firewall and qos.
Much simpler speedtest from a wired client is

iperf3 --bidir -c <server>

Just to assess how much data SoC can forward simultaneously.

If steering works the load has to be nearly evenly spread across CPUs.
If all CPUs are at 100% and not reaching full subscribed up/down speed enable soft offloading (no hardware offloading support in your device) which will reduce softirq CPU hunger 2-3x and just maybe permit that forwarding speed. Slightly weaker mt7621 SoC would forward gigabit back and gigabit forth all at once with hardware offload.

11

I tried iperf3 and openspeedtest without offloading or irqbalance.

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-10.00  sec  47.0 MBytes  39.4 Mbits/sec    0             sender
[  5][TX-C]   0.00-10.06  sec  45.8 MBytes  38.2 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec   155 MBytes   130 Mbits/sec  149             sender
[  7][RX-C]   0.00-10.06  sec   147 MBytes   123 Mbits/sec                  receiver

CPU0 is 100% used by ksoftirqd.
I checked the /proc/interrupts table and the following interrupts are the only ones that seem to only use CPU0. All others are shared among the CPUs.
Also these sound like they are related to the DSL interface.

 65:      39657          0          0          0   PCI-MSI 524289 Edge      mei_cpe
 66:     180108          0          0          0   PCI-MSI 524290 Edge      aca-txo
 67:     126611          0          0          0   PCI-MSI 524291 Edge      aca-rxo

After Googling them I found this site, which lists the interrupts in the original oem firmware example, which is also only using CPU0.

But the affinity of these interrutps is already set to "f" which should use all CPUs, right?

root@OpenWrt:~# cat /proc/irq/64/smp_affinity
f
root@OpenWrt:~# cat /proc/irq/65/smp_affinity
f
root@OpenWrt:~# cat /proc/irq/66/smp_affinity
f
root@OpenWrt:~# cat /proc/irq/66/smp_affinity
f

Is there some way to get them spread across CPUs?

Edit:
With packet steering enabled the load is shared better and the speed test is better, but not perfect.
The results stay nearly the same with software offload.
CPU usage is not a 100% on all cores.

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-10.00  sec  48.4 MBytes  40.6 Mbits/sec    0             sender
[  5][TX-C]   0.00-10.05  sec  47.6 MBytes  39.7 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec   245 MBytes   206 Mbits/sec    0             sender
[  7][RX-C]   0.00-10.05  sec   234 MBytes   196 Mbits/sec                  receiver

But in the end the three interrupts from above alws stay on CPU0 :frowning:

12

You can do some testing manually, basically you can:

cat /proc/interrupts

and then look for the interrupt number
you can then set it to a specific cpu eg...

echo 3 > /proc/irq/64/smp_affinity_list
echo 2 > /proc/irq/65/smp_affinity_list
echo 1 > /proc/irq/66/smp_affinity_list

puts irq 64 onto the 4th cpu
puts irq 65 onto the 3rd cpu
puts irq 66 onto the 2nd cpu
etc

I think with these modem devices though, it won't let you move them anyway and even then it seems standard practice to have specific rx and tx lines set to the same cpu anyway.

13

run irqbalance -d -o 2>&1 | tee -a /tmp/irq.log and check if it undertakes any balancing activity. And enable it in /etc/config/irqbalance if it does.
On non-raspbery non-x86 it is usually confused with cpu topology.

You might want to try next release, it has more speedups, at least new packet steering and it is on by default. https://mirror-03.infra.openwrt.org/releases/24.10-SNAPSHOT/targets/

14

echo 1 > /sys/class/net/dsl0/threaded

appears to be a command that is accepted too, for what that's worth
how that works in combination with packet steering, not sure
i.e whether its better to use threaded with packet steering on or off or whether it's better to specifically turn off packet steering on the dsl0 interface but leave it on the ethernet ones etc

to turn off packet steering specifically for the dsl0 interface

echo 0 > /sys/class/net/dsl0/queues/rx-0/rps_cpus

to put it back on

echo f > /sys/class/net/dsl0/queues/rx-0/rps_cpus

15

Answer is 2 tests and a checkbox away.
Any success with irqbalance?

16

One other thing, are you using a build with the 'bridger' daemon present ?

bridger1
bridger11365×698 94.2 KB

bridger2
bridger21386×648 96.9 KB

17

Why would one in sane mind build already prebuilt packages?

18

I do it just to make sure it's all solid, but sure selecting "Use host LLVM toolchain" is probably fine, as long as you choose one or the other then you'll be able to choose to build 'bridger' in the base section

19

The tunnelling involved with DS-Lite adds extra in-kernel processing load; you're not the first to encounter this (see this post and replies).

It may be something that is improving with time but my experience is that the kernel irq scheduler uses the lowest number cpu in the affinity mask at least on on arm targets with OpenWrt kernel configs. For your use case, anywhere you encounter a cpu affinity mask of "f" I think "e" (which excludes cpu0 from the mask) is likely to give you better results (though then loading up cpu1). More specific irq cpu affinity masks are likely to be required for some irqs/options to optimise performance.

20

Sorry, Work and sleep came in the way of testing all these cool insights!

This evening I did a comparison of most of these variants.
It seems the original firmware has something that OpenWRT is missing. Maybe they have some kind of hardware offload? According to their Webinterfacce the CPU load never exceeded 20%.
Packet Steering on all CPUs was the most effective measure for OpenWRT.

OpenSpeedTest Download Upload Ping Comment
DSL Sync 292 46
OpenWRT Standard Snapshot 27.11. 152 44 24 100% ksoftirqd CPU0, other CPU aound 10-30%
Packetsteering Enabled - Flow Standard 173 44 25 100% ksoftirqd CPU0, other CPU aound 10-30%
Packetsteering Enabled (all CPU) - Flow Nonce 220 45 24 CPU0 70% CPU2 100% ksoftirqd
Packetsteering Enabled (all CPU) - Flow 128 215 45 23 CPU0 70% CPU2 100% ksoftirqd
Packetsteering Enabled (all CPU) - Flow 256 213 45 23 CPU0 70% CPU2 100% ksoftirqd
IRQbalance enabled default 186 45 23 100% ksoftirqd CPU0, other CPU aound 10-30%
1 > /sys/class/net/dsl0/threaded 185 45 23 100% ksoftirqd CPU0, other CPU around 50% dsl0 process
DSL threaded + PS all CPU 211 45 23 CPU0 70% CPU2 100% ksoftirqd
Standard Firmware FritzOS 8.0 270 41 21 No SSH access,maybe I can get serial

I guess will try what happens when I use this as a Modem only next.