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 -P 1 -x -p 63000:63010 -> ~3500 cps fireperf -c -P 10 -x -p 63000:63010 -> ~5500 cps fireperf -c -P 100 -x -p 63000:63010 -> ~5500 cps fireperf -c -P 1000 -x -p 63000:63010 -> ~5500 cps fireperf -c -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 -P 1 -p 63000:63010 -> ~934 Mb/s | cpu utilization ~60% on 1 core fireperf -c -P 10 -p 63000:63010 -> ~934 Mb/s | cpu utilization switching between ~65% on 1 core / ~45%/20% on 2 cores fireperf -c -P 100 -p 63000:63010 -> ~934 Mb/s | cpu utilization switching between ~90% on 1 core / ~70%/20% on 2 cores fireperf -c -P 1000 -p 63000:63010 -> ~934 Mb/s | cpu utilization switching between ~100% on 2 cores / ~100%/50%/50% on 3 cores fireperf -c -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 -P 1 -x -p 63000:63010 -> ~1000 cps fireperf -c -P 10 -x -p 63000:63010 -> ~500-1500 cps strongly fluctuating fireperf -c -P 100 -x -p 63000:63010 -> ~500-1500 cps strongly fluctuating fireperf -c -P 1000 -x -p 63000:63010 -> ~500-1500 cps strongly fluctuating fireperf -c -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 -P 1 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~25% on 1 core fireperf -c -P 10 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~25% on 1 core fireperf -c -P 100 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~65% on 1 core fireperf -c -P 1000 -p 63000:63010 -> ~93 Mb/s | cpu utilization ~70% on 1 core fireperf -c -P 10000 -p 63000:63010 -> no result; Pi becomes unstable and need a reboot 16. Februar 2021 16:00, "Michael Tremer" schrieb: > Hi, > >> On 16 Feb 2021, at 12:16, Adolf Belka (ipfire-dev) wrote: >> >> Hi Michael, >> >> On 16/02/2021 12:48, Michael Tremer wrote: >>> Hi, >> >> On 12 Feb 2021, at 12:30, Adolf Belka (ipfire-dev) 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 -P 1 -x -p 63000:63010 where 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=0ec017a4da5e00c405d63782d34009f486dc9478 > >> 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(a)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 -P 1 -x -p 63000:63010 -> ~5000 cps >> >> fireperf -c -P 10 -x -p 63000:63010 -> ~30000-35000 cps >> >> fireperf -c -P 100 -x -p 63000:63010 -> ~35000-40000 cps >> >> fireperf -c -P 1000 -x -p 63000:63010 -> ~40000-45000 cps >> >> fireperf -c -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