Re: Fireperf: first tests an results

Re: Fireperf: first tests an results

[Michael Tremer]

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

Hello Daniel,

Thank you very much for testing fireperf and publishing your results. I hope we can collect many more.

> On 9 Feb 2021, at 12: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 far, that is the theory. The rationale behind this is that any connection that is opened by a user space program on Linux has a source port between usually 32768 and 60999:

[root(a)fw01 ~]# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768	60999

That leaves you with being able to open up to 28231 connections to the same server on the same port. Obviously this is not enough for more than 28k connections and therefore it is necessary to open more listening sockets on the server side. Each will give you another 28231 connections.

However, my system got slower and slower with each connection that was opened - presumably because it takes some time to find a free source port. Therefore I would recommend to open more ports on the server side than strictly necessary.

I have not empirically tested this yet, but about 5000 connections per port intuitively sounds like a good value.

> 
> 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.

Yes, I would like to see more performance benchmarks with the LWL appliance range. I have tested them with a couple of pre-releases of fireperf, but they were all in different environments and it would be good to test them all under reproducible conditions.

I would also like to see this tested on weaker hardware. Hopefully we will see any bottlenecks earlier than on 10G sixteen core 19” rack-mountable enterprise system. :) Anyone up for that?

Best,
-Michael

> -
> 
> Daniel
> 

Re: Fireperf: first tests an results

[Adolf Belka (ipfire-dev)]

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

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.

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.

I looked in the log (journalctl) but there were no messages at all related to fireperf just the command being run.


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
>

Re: Fireperf: first tests an results

[Adolf Belka (ipfire-dev)]

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

Forgot to add that I built it on my Arch Linux system with the following commands:-

./autogen.sh

/configure CFLAGS='-g -O0' --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib (This was recommended to be used after autogen was run)

make

sudo make install


Regards,

Adolf.


On 12/02/2021 13: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.
>
> 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.
>
> I looked in the log (journalctl) but there were no messages at all related to fireperf just the command being run.
>
>
> 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
>>

Re: Fireperf: first tests an results

[Michael Tremer]

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

Hi,

> On 12 Feb 2021, at 12:34, Adolf Belka (ipfire-dev) <adolf.belka(a)ipfire.org> wrote:
> 
> Forgot to add that I built it on my Arch Linux system with the following commands:-
> 
> ./autogen.sh
> 
> /configure CFLAGS='-g -O0' --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib (This was recommended to be used after autogen was run)
> 
> make
> 
> sudo make install

That’s correct.

The CFLAGS disable any optimisation (-O0) and enable generation of debugging sections (-g) which are useful for gdb.

You probably don’t need this, so you can build it without those flags.

Do you know what the process is that we could provide packages for Arch and any derivatives?

In general, I want to make things like libloc and fireperf available and do that as easy as possible.

-Michael

> Regards,
> 
> Adolf.
> 
> 
> On 12/02/2021 13: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.
>> 
>> 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.
>> 
>> I looked in the log (journalctl) but there were no messages at all related to fireperf just the command being run.
>> 
>> 
>> 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
>>> 

Re: Fireperf:

[Adolf Belka]

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


Hi Michael,
On 15/02/2021 17:08, Michael Tremer wrote:
> Hi,
> 
>> On 12 Feb 2021, at 12:34, Adolf Belka (ipfire-dev) <adolf.belka(a)ipfire.org> wrote:
>>
>> Forgot to add that I built it on my Arch Linux system with the following commands:-
>>
>> ./autogen.sh
>>
>> /configure CFLAGS='-g -O0' --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib (This was recommended to be used after autogen was run)
>>
>> make
>>
>> sudo make install
> 
> That’s correct.
> 
> The CFLAGS disable any optimisation (-O0) and enable generation of debugging sections (-g) which are useful for gdb.
> 
> You probably don’t need this, so you can build it without those flags.
> 
> Do you know what the process is that we could provide packages for Arch and any derivatives?
I realised that I never did anything further regarding your question 
about how to get fireperf into arch linux.

So more than a year later I thought I should do something about it. Arch 
Linux has something called the AUR (Arch User Repository) which is a 
community-driven repository for Arch users. It contains package 
descriptions (PKGBUILDs) that allow you to compile a package from source 
with makepkg and then install it via pacman, the package management tool 
in Arch.

If packages in the AUR get enough votes and there is a TU (Trusted User) 
willing to pick up the package then it can be moved into the community 
repository so users wouldn't need to do their own makepkg compiling.

I have been looking at what is involved in getting a package into the 
AUR and I have created a PKGBUILD file and tested it with makepkg and 
getting the resultant package installed with pacman. Everything worked 
well. I have used some arch tests to confirm that the PKGBUILD and 
resultant package meet the arch linux standards.

I have an account on the AUR and I have modified it to give me ssh 
access into the AUR and created a git repo clone for fireperf on my 
computer. Each package in the AUR has its own git repo in the Arch system.

The last thing to do now is to do a git push of the fireperf package 
from my git repo to the AUR. Before I do that I just want to confirm 
that you still want to go ahead with that, as it is more than a year 
since the idea was raised.

I will be the maintainer of the package in the AUR which basically means 
I will ensure it stays up to date and deal with any problems people 
might have with compiling and installing it, although this is a very 
simple package in terms of that.

Regards,

Adolf.
> 
> In general, I want to make things like libloc and fireperf available and do that as easy as possible.
> 
> -Michael
> 
>> Regards,
>>
>> Adolf.
>>
>>
>> On 12/02/2021 13: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.
>>>
>>> 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.
>>>
>>> I looked in the log (journalctl) but there were no messages at all related to fireperf just the command being run.
>>>
>>>
>>> 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
>>>>
> 

-- 
Sent from my laptop

Re: Fireperf: first tests an results

[Michael Tremer]

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

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 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
>> 

Re: Fireperf: first tests an results

[Adolf Belka (ipfire-dev)]

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

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.

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
>>>
> 

Re: Fireperf: first tests an results

[Michael Tremer]

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

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

Re: Fireperf: first tests an results

[daniel.weismueller]

[-- 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