Network Performance Issues on APU4c4

Thanks,

I don’t have any Firewall Roles, Proxy or QoS configured yet. I’m wondering why this CPU is not beeing able to handle only the half of the NIC-Speed.
Consumer ready routers like FritzBox and so on are much slower than the Jaguar chip. Would it be usefull to try a normal distribution like arch? I don’t need a webinterface.

Is there any significant improvement with a recent BIOS/Firmware? I don’t have checked the installed Version yet but I’ve in mind thate the version was lower than the version numbers I read in several forums.
Also I’ve read something about “coreboost”. Is that eventually not activated on my installation?

EDIT:
I’ve read about that the performance Problem could be PPPoE. This information is from pfSense which is BSD but could this also be the bottleneck in linux? What implementation is used in IPFire? The kernel ppp implementation or rp-pppoe? Could it be worth to test rp-pppoe? Nevertheless I will try it but if you say it will not have any impact I could save this time. :slight_smile:

EDIT2:
I gave OpenWRT a chance and what should I say. It works out of the box. Same downlink speed as with notebook directly attached to the modem. 533.22MBit at first test. I wonder why IPFire is not bee able to reach this values. It’s also linux based.

No, the bottleneck simply is the hardware. This one is optimised to consume little power and there have to be compromises somewhere.

I am not aware of any performance improvements through BIOS updates. Minor ones potentially, but nothing major.

That would be enabled in the version that LWL is shipping. However, it is best that that is not activating itself, because IPFire balances the load across all CPU cores which are much faster combined than a single one.

https://wiki.ipfire.org/hardware/mythbusters/single-core-performance

IPFire is using the kernel implementation which I consider the faster one.

But I am happy to be proven wrong.

It is hard to compare different distributions just like this.

IPFire filters packets by default. If OpenWRT does not do that your comparison is flawed. If you disable all features in IPFire, you might of course get more performance, but a network that is less secure and probably not as much fun to use.

But I never enabled any features in IPFire. Firewallrules where empty, no QoS, no VPN. All in all the same Configuration as in OpenWRT. With top I checked the load of the cpu. In IPFire one Core goes to 99% when the “maximum” speed is reached. OpenWRT 0%. I think it’s something NIC-Configuration related issue. But this is only a guess. The differences are so significant that I cannot believe in slow hardware only. I’m ok with OpenWRT but it is too bad for IPFire.

OpenWRT does not use any CPU? That cannot be true.

It might be true. I’ve run openWRT on a TP-Line MR-3020 - Atheros AR9331 CPU with 4 MB flash and 32 MB RAM. It runs an SPI firewall fairly responsively. The same software running on APU4c4 might well report < 1 % CPU utilisation.

But openWRT does not provide any of the additional firewalling capabilities of IPFire

But I had no firewall rules in IPFire at all. Firewall configuration was empty. Now I have some simple rules in OpenWRT for testing and have no performance impact. Even some port forwarding so NAT should be enabled.
What are the additional firewall capatibilities of IPFire I’ve missed?

IPFire performs many more things on a packet that it forwards than the standard ISP router. That is because we have so much more CPU power available (usually) and that allows us for deeper inspection of packets and many other things.

On PPPoE: The encapsulation of the packets will in both systems come from the Linux kernel. So there should be no difference in throughput unless you configured something differently.

is there any way to disable firewall in IPFire completely to do some tests? It would be interresting at all to look where the gap is. I think a 4C 1GHz System has to be able to handle a 500MBit Connection even with a better firewall. I only want to prove myself beeing wrong with this :smiley:
OpenWRT is not a standard ISP-Router at all. As far as I know OpenWRT and IPFire both using netfilter and iptables. I still think it is NIC-Configuration related due to the significant performance improvement I’ve made with pinning the NIC-IRQs to specific CPU Cores (that should not be the solution at all).
Digging deeper on this could lead to a massive improvement of IPFire.

@superdachs: maybe my problem is related to yours or vice versa

BTW: with running OpenVPN and active Firewall still over 500MBit in OpenWRT.

Have you tested basic nic speed with iperf2 and compared with the Wiki?
https://wiki.ipfire.org/hardware/pcengines/apu2b4
APU2 and 4 should have the same performance.

I can repeat the tests at next weekend if needed.

Not yet but I will next weekend.

I have repeatet the tests:
unidirektional 920Mbit from a client in green to red or vice versa and 730mBit bidirectional.

arne@thinkpad ~ $ iperf -c 192.168.200.80 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.200.80, TCP port 5001
TCP window size:  298 KByte (default)
------------------------------------------------------------
[  5] local 192.168.20.18 port 56386 connected with 192.168.200.80 port 5001
[  4] local 192.168.20.18 port 5001 connected with 192.168.200.80 port 59356
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec   872 MBytes   731 Mbits/sec
[  4]  0.0-10.0 sec   919 MBytes   770 Mbits/sec

Tested with an APU2B4 on core139 with a DNAT port5001 rule to the client ip of the client in green.

@superdachs, can you update about your APU4 adventures?
Speaking of OpenWRT and others (Mikrotik), I belive the main difference is the hardware acceleration. Those routers do not inspect every packet indeed. The typical cause of action: inspect the connection, once the connection is recognized as safe, the thing just dumps it into hardware and essentially forget about it.
At the same time, IRQ balancing inefficiency almost halves IPFire performance on low power CPUs. I’m not sure who to blame here. It looks more like a general Linux IRQ balancer daemon failure to properly allocate IRQ over cores. It loads a single core with all irqs instead of spreading it evenly.

IPFire also skip many things at processing of approved connections. (It’s a statefull firewall.)
Also irq and cpu-core pinning should done by IPFire since core160
But you can enable some features that need more processing power. (IPS, QoS …)

IPFire also skip many things at processing of approved connections. (It’s a statefull firewall.)

  • OpenWRT, Mikrotik and others skip the connection entirely. It gets offloaded to hardware. CPU isn’t bothered at all. Obviously, it prevents much traffic processing from being applied (QoS, IPS).
    In my case, the device is getting flooded with interrupts. Ksoftirqd processes overwhelm the CPU :frowning: . Can someone share about reducing the IRQ load. I’ve tried Intel “interrupt moderation” with little luck.

Also irq and cpu-core pinning should done by IPFire since core160

  • Maybe, yet it isn’t working for my hardware. Can you refer myself to the relevant documentation?

On some devices with integrated switch/nat engines this may true but not on an APU. The APU has independend PCIe Nics that cannot do nat offload. (only transmit and recieve or checksumming can offloaded to the hardware.)

Check if ethtool report multiple queues and ntuple feature.

Normal both should enabled at default.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8be8ac63cafef9952f35c4b87883135e1b33ca4d

1 Like

3 posts were split to a new topic: Download speed limitation on APU