testing packet rates and CPU load without firewall
David Rowe
To improve the packet rate performance Elektra suggested we try running
without the firewall code in the kernel. Here are some preliminary
results:
I have run a few tests with new image to look at the effects of no
firewall. I have:
x86 - NS2 A - MP01 B - NS2 C - x86
I am running iperf on the x86s to generate a constant packet rate
stream. On the client x86:
$ iperf -c 10.30.3.3 -t30 -u -b2M -l 144
For B, I have two MP01s. One is running the earlier firmware that
includes firewall support. The other is running your latest firmware.
The MP01 is left on-hook, but Asterisk and all the drivers are running.
I still have the firewall code running on Nanostation A to force a two
hop link.
1/ With 1 Mbit/s traffic (about 900 packets/s) I ran top on the MP01 and
measured some values:
#142 old firmware irq=15% softirq=70%
#144 new firmware irq=2% softirq=70%
2/ The new firmware would support a maximum packet rate (< 1% PER) of
1900 packets/, the old 900-1300 packets/s. I had some trouble with
repeatability of the PER results with the old firmware MP01 #142.
These are V1.1 MP01s with slightly messed up calibration so the radio
performance may not be consistent. The power tables are offset by about
10dB, so setting 5dBm actually gives you 15dBm. I have tried to work
around this by setting the power from Linux at boot time. Not sure if
this hack is working properly.
BTW on the new firmware "wlanconfig ath0 list" still gives me 36M for
all entries, I have sent unicast traffic to all the MACs.
3/ The best I can get from a two hop link (NS2 - NS2) is 1900 packets a
second.
Some thoughts:
a) The old-firmware repeatability is a problem, not sure why it's
happening. Makes it hard to draw firm conclusions. But the "top"
irq/softirq and new firmware packet rate results were consistent across
several tests. So it looks like a significant improvement - well
done :-)
b) The Nanostation firmware still contains a bunch of firewall modules,
and I am running a MAC firewall on A. It could be that the Nanostations
are now the bottleneck. Some new firmware and static routing would help
test this.
c) Based on previous measurements with ping the Ethernet load might be
significant on the Nanostations. Not much we can do about this, as we
need Ethernet connectivity at the gateway node.
Due to a few other tasks I can't put more time into this work right now,
but perhaps we can revisit it a little later in the project. Feel free
to try a few tests of your own.
Cheers,
David
Corinna Elektra Aichele
> Some thoughts:
>
> a) The old-firmware repeatability is a problem, not sure why it's
> happening. Makes it hard to draw firm conclusions. But the "top"
> irq/softirq and new firmware packet rate results were consistent across
> several tests. So it looks like a significant improvement - well
> done :-)
Thanks.
> b) The Nanostation firmware still contains a bunch of firewall modules,
> and I am running a MAC firewall on A. It could be that the Nanostations
> are now the bottleneck. Some new firmware and static routing would help
> test this.
The Nanostations have the same 180MHz Mips 4K CPU core in their AR2315 chip
like the MPs with their AR2317 chip AFAIK. So it is likely that the NS2 CPU
load with firewall and ethernet load will affect the performance.
If you find the time to run the tests again without firewall you can do the
following:
Delete/move all entries in /etc/modules.d/ of the NS2 that are related to
iptables/netfilter modules.
Reboot.
Stop batmand:
/etc/init.d/batmand stop
In NS2-A (assuming the IP is 1.1.1.1):
ip r add 1.1.1.3/32 via 1.1.1.2 dev ath0
In NS2-C (assuming the IP is 1.1.1.3)
ip r add 1.1.1.1/32 via 1.1.1.2 dev ath0
I'm assuming that the MP in the middle is 1.1.1.2
Cheers,
Elektra