fireperf is a command line tool for network benchmarks. It can test throughput and quality of a network between a fireperf client and fireperf server.
It is similar to IPerf/JPerf but is rewritten from scratch taking advantage of various features of the Linux kernel in order to create a maximum amount of traffic with as little resources possible.
Installation
fireperf can be installed with the Pakfire web interface or via the console:
pakfire install fireperf
Usage
There is no web interface for this Addon. To run this Addon open the client console or terminal and access the IPFire box via SSH.
To setup the server:
fireperf -s -P 10000 -p 63000:63010
To setup the client and test:
fireperf -c <IP address> -P 1 -x -p 63000:63010
fireperf -c <IP address> -P 10 -x -p 63000:63010
fireperf -c <IP address> -P 100 -x -p 63000:63010
fireperf -c <IP address> -P 1000 -x -p 63000:63010
fireperf -c <IP address> -P 10000 -x -p 63000:63010
Links
example results
| IPFire Enterprise Appliance | IPFire Business Appliance | IPFire Office Appliance | IPFire Mini Appliance | |
|---|---|---|---|---|
-P 1 |
||||
| Connections | N/A | N/A | ~5800 cps | ~3500 cps |
| Bandwidth | ~934 MBit/s | |||
-P 10 |
||||
| Connections | N/A | N/A | ~13000-18000 cps | ~5500 cps |
| Bandwidth | ~934 MBit/s | |||
-P 100 |
||||
| Connections | N/A | N/A | ~13000-18000 cps | ~5500 cps |
| Bandwidth | ~934 MBit/s | |||
-P 1000 |
||||
| Connections | N/A | N/A | ~16000-20000 cps | ~5500 cps |
| Bandwidth | ~934 MBit/s | |||
-P 10000 |
||||
| Connections | N/A | N/A | ~21000-26000 cps | ~5500 cps |
| Bandwidth | N/A1 |
| System | -P 1 | -P 10 | -P 100 | -P 1000 | -P 10000 |
|---|---|---|---|---|---|
| Raspberry Pi 3B | ~1000 cps | ~500-1500 cps | ~500-1500 cps | ~500-1500 cps | no result; Pi becomes unstable and need a reboot |
| LWL IPFire Mini | ~3500 cps | ~5500 cps | ~5500 cps | ~5500 cps | ~5500 cps |
| LWL IPFire Office | ~5800 cps | ~13000-18000 cps | ~13000-18000 cps | ~16000-20000 cps | ~21000-26000 cps |
| LWL IPFire Business | |||||
| LWL IPFire Enterprise | |||||
| example system1 | ~6000 cps | ~35000-40000 cps | ~53000 cps | ~53000 cps | ~52000 cps |
| example system2 | ~4000 cps | ~22000 cps | ~52000 cps | ~52000 cps | ~52000 cps |
| example system3 |
example system1 description: IPFire Core 154; Intel i7 4790; Intel 82571EB/GB 1GBit Nic
example system2 description: This system is an VM. The host is example system1. Debian 10.8 QEMU VM 4 cores assigned
example system3 system description: IPFire Core 153; Intel Celeron CPU J1900 @ 1.99GHz x4; I211 1GBit Nic
Of course, the CPU load must also be taken into account. The following table must be considered with reference to the previous one.
| System | -P 1 | -P 10 | -P 100 | -P 1000 | -P 10000 |
|---|---|---|---|---|---|
| Raspberry Pi 3B | 35-55% | 35-55% | 35-55% | 35-55% | no result; Pi becomes unstable and need a reboot |
| LWL IPFire Mini | ~100% on 1 core | ||||
| LWL IPFire Office | ~55-65% on 4 cores | ||||
| LWL IPFire Business | |||||
| LWL IPFire Enterprise | |||||
| example system1 | ~100% on 1 core | ||||
| example system2 | ~55% on 2 cores | ||||
| example system3 |
Supplements to Raspberry Pi 3B: It is noticeable that the Pi could never load a core to 100%. Therefore, the bottleneck must lie somewhere else.
Supplements to LWL IPFire Mini: The CPU utilization was limited to 1 cores and increased in sync with the cps.
Supplements to LWL IPFire Office: The CPU utilization was distributed to all 4 cores and increased in sync with the cps. In the last test the utilization was about 55-65% on all four cores.
Supplements to LWL IPFire Business:
Supplements to LWL IPFire Enterprise:
Supplements to example system2: The CPU utilization within the VM was limited to 2 cores and increased in sync with the cps. In the last test the utilization was about 55% on 2 cores. The CPU utilization on the host was in sync with the cps, too but about 2.5 times higher. So in the last test the utilization of the host was about 100% on 2 cores and about 50% on a third core.
In addition to the possible connections per second, the throughput must of course also be considered.
| System | -P 1 | -P 10 | -P 100 | -P 1000 | -P 10000 |
|---|---|---|---|---|---|
| Raspberry Pi 3B | ~93 MBit/s | ~93 MBit/s | ~93 MBit/s | ~93 MBit/s | no result; Pi becomes unstable and need a reboot |
| LWL IPFire Mini | ~934 MBit/s | ~934 MBit/s | ~934 MBit/s | ~934 MBit/s | no usable result; changes between 0 and 1700 MBit/s |
| LWL IPFire Office | |||||
| LWL IPFire Business | |||||
| LWL IPFire Enterprise | |||||
| example system1 | |||||
| example system2 | |||||
| example system3 |
And the corresponding CPU load.
| System | -P 1 | -P 10 | -P 100 | -P 1000 | -P 10000 |
|---|---|---|---|---|---|
| Raspberry Pi 3B | ~25% 1 core | ~25% 1 core | ~65% 1 core | ~75% 1 core | no result; Pi becomes unstable and need a reboot |
| LWL IPFire Mini | ~60% 1 core | ~65% 1 core | ~90% 1 core | ~100% 2 cores | no usable result; changes between 0 and 1700 MBit/s |
| LWL IPFire Office | |||||
| LWL IPFire Business | |||||
| LWL IPFire Enterprise | |||||
| example system1 | |||||
| example system2 | |||||
| example system3 |
-
no usable result; changes between 0 and 1700 MBit/s ↩