Originally, I assumed that the devices would exhaust the available bandwidth at all times, but tests show that this is not the case. Sorry for that. Therefore, I now provide the results of the bandwidth measurement. Unfortunately, I don't have a LWL "IPFire Office Appliance" available anymore, so I'll have to provide the bandwidth measurement for it later.
I'll compile and tabulate the results in the wiki. https://wiki.ipfire.org/addons/fireperf-playground
Server: Lightning Wire Labs Mini Appliance; IPFire Core 154; AMD GX-412TC; Intel i211 AT 1GBit Nic Client: Debian 10.8; Lenovo Thinkpad T440; Intel i5-4300U; Intel I218-LM 1GBit Nic
Server: fireperf -s -P 10000 -p 63000:63010
cps measurement: Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 -> ~3500 cps
fireperf -c <IP address> -P 10 -x -p 63000:63010 -> ~5500 cps
fireperf -c <IP address> -P 100 -x -p 63000:63010 -> ~5500 cps
fireperf -c <IP address> -P 1000 -x -p 63000:63010 -> ~5500 cps
fireperf -c <IP address> -P 10000 -x -p 63000:63010 -> ~5500 cps
In the last test, the utilization was about 100% on one core on the server.
bandwidth measurement: Client: fireperf -c <IP address> -P 1 -p 63000:63010 -> ~934 Mb/s | cpu utilization ~60% on 1 core
fireperf -c <IP address> -P 10 -p 63000:63010 -> ~934 Mb/s | cpu utilization switching between ~65% on 1 core / ~45%/20% on 2 cores
fireperf -c <IP address> -P 100 -p 63000:63010 -> ~934 Mb/s | cpu utilization switching between ~90% on 1 core / ~70%/20% on 2 cores
fireperf -c <IP address> -P 1000 -p 63000:63010 -> ~934 Mb/s | cpu utilization switching between ~100% on 2 cores / ~100%/50%/50% on 3 cores
fireperf -c <IP address> -P 10000 -p 63000:63010 -> no usable result; changes between 0 and 1700 MBit/s
######
server: IPFire Core 154; Raspberry Pi 3 B; integrated Microchip LAN9514 100 MBit Nic Client: Debian 10.8; Lenovo T440; Intel i5-4300U; Intel I218-LM 1GBit Nic
Server: fireperf -s -P 10000 -p 63000:630010
cps measurement: Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 -> ~1000 cps
fireperf -c <IP address> -P 10 -x -p 63000:63010 -> ~500-1500 cps strongly fluctuating
fireperf -c <IP address> -P 100 -x -p 63000:63010 -> ~500-1500 cps strongly fluctuating
fireperf -c <IP address> -P 1000 -x -p 63000:63010 -> ~500-1500 cps strongly fluctuating
fireperf -c <IP address> -P 10000 -x -p 63000:63010 -> no result; Pi becomes unstable and need a reboot
The cpu utilization was limited to one core.
In all my tests, the utilization was about 35-55% on the server and 10-15% on the client. It is noticeable that the Pi could never load a core to 100%. Therefore, the bottleneck must lie somewhere else.
bandwidth measurement: Client: fireperf -c <IP address> -P 1 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~25% on 1 core
fireperf -c <IP address> -P 10 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~25% on 1 core
fireperf -c <IP address> -P 100 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~65% on 1 core
fireperf -c <IP address> -P 1000 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~70% on 1 core
fireperf -c <IP address> -P 10000 -p 63000:63010 -> no result; Pi becomes unstable and need a reboot
16. Februar 2021 16:00, "Michael Tremer" michael.tremer@ipfire.org schrieb:
Hi,
On 16 Feb 2021, at 12:16, Adolf Belka (ipfire-dev) adolf.belka@ipfire.org wrote:
Hi Michael,
On 16/02/2021 12:48, Michael Tremer wrote:
Hi,
On 12 Feb 2021, at 12:30, Adolf Belka (ipfire-dev) adolf.belka@ipfire.org wrote:
Hi all,
I tried to also test this out on my system.
As I am not familiar with what all the command options do I just followed Daniels commands.
There is a man page for it: https://man-pages.ipfire.org/fireperf/fireperf.html
server: IPFire 2.25 - Core Update 153; Intel Celeron CPU J1900 @ 1.99GHz x4; I211 Gigabit Network Connection
client: Arch Linux; Intel Core i5-8400 CPU @ 2.80GHz 6 core; 1GBit nic
Server: fireperf -s -P 10000 -p 63000:630010
Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 where <IP address> was replaced with the IP address of my IPFire Green connection.
I started the server fireperf and there was the table updating regularly.
I started the client and got "Could not open socket: Address family not supported by protocol" scrolling up the screen.
That is interesting. Could you please start the same thing again with strace? strace -o strace.log fireperf -c ... Please send the log file to me and hopefully I will be able to find something.
I didn't need to do that. Searching found that message sometimes related to IPV6 and I had IPV6 disabled on my boot command line for Arch Linux. So I removed that and rebooted and fireperf worked.
I had disabled IPV6 in the past with Arch Linux as I had lots of warnings in my logs about packages not being able to work with IPV6.
Ah yes, that makes sense. In order to support IPv6, I map IPv4 addresses into IPv6 so that I do not have to care later about it.
It would be nice if the command took hostnames, too, but that didn’t work in my tests and so I reverted the commit:
https://git.ipfire.org/?p=fireperf.git;a=commitdiff;h=0ec017a4da5e00c405d637...
Having now removed the IPV6 disable my logs have stayed clear of any messages after the reboot so it looks like the problems I used to have a couple of years ago have been resolved by the package upstream developers.
I will send a separate email with the results I found.
Regards,
Adolf.
I looked in the log (journalctl) but there were no messages at all related to fireperf just the command being run.
Fireperf does not log to syslog at all at the moment. Earlier it did, but I didn’t see any point in doing so.
Any thoughts on what I am missing to have setup or installed?
Regards,
Adolf.
On 09/02/2021 13:53, daniel.weismueller@ipfire.org wrote:
Hi guys,
today I installed fireperf on my testing IPFire and my Ubuntu PC.
server: IPFire Core 154; Intel i7 4790; Intel 82571EB/GB 1GBit Nic Client: Ubuntu 20.4; Intel i7 9700; Intel i219-V 1GBit Nic
Michael and I agreed that one more port should be opened per 5000 expected connection per second (cps)
So here my results:
Server: fireperf -s -P 10000 -p 63000:630010
Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 -> ~5000 cps
fireperf -c <IP address> -P 10 -x -p 63000:63010 -> ~30000-35000 cps
fireperf -c <IP address> -P 100 -x -p 63000:63010 -> ~35000-40000 cps
fireperf -c <IP address> -P 1000 -x -p 63000:63010 -> ~40000-45000 cps
fireperf -c <IP address> -P 10000 -x -p 63000:63010 -> ~46000-48000 cps
The cpu utilization was limited to one core and increased in sync with the cps on both sides.
In my last test, the utilization was about 85-100% on the server and 75-95% on the client.
In the next days I will test our mini and post the results here.
Daniel