Re: Fireperf: first tests an results

[daniel.weismueller@ipfire.org]

[-- Attachment #1: Type: text/plain, Size: 7338 bytes --]

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(a)ipfire.org> schrieb:

> Hi,
> 
>> On 16 Feb 2021, at 12:16, Adolf Belka (ipfire-dev) <adolf.belka(a)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(a)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=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 <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