and again a few results:
I configured an OpenVPN N2N and run fireperf through it.
Serverside: IPFire Core 153; Intel Xeon 1265L V2; Intel 82580 4x 1GBit Nic; Vodafone GigaCable 1000 MBit down / 50 MBit up Clientside: IPFire Core 154; Intel i7 4790; Intel 82571EB/GB 1GBit Nic; Vodafone ADSL2 16MBit down / 1 MBit up
Server: fireperf -s -P 10000 -p 63000:63010
Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 -> ~22 cps
fireperf -c <IP address> -P 10 -x -p 63000:63010 -> ~165-180 cps
fireperf -c <IP address> -P 100 -x -p 63000:63010 -> ~165-180 cps
fireperf -c <IP address> -P 1000 -x -p 63000:63010 -> ~165-180 cps
On both sides the CPU utilization was 1-3%.
-
Daniel 10. Februar 2021 10:51, daniel.weismueller@ipfire.org (mailto:daniel.weismueller@ipfire.org) schrieb:
A few more results:
I've installed a VM on my Test-IPFire and run the fireperf-server on it. server: Debian 10.8 QEMU VM 4 cores on IPFire Core 154; Intel i7 4790; Intel 82571EB/GB 1GBit Nic Client: Ubuntu 20.4; Intel i7 9700; Intel i219-V 1GBit Nic
So here my results:
Server: fireperf -s -P 10000 -p 63000:63010
Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 -> ~4000 cps
fireperf -c <IP address> -P 10 -x -p 63000:63010 -> ~22000 cps
fireperf -c <IP address> -P 100 -x -p 63000:63010 -> ~52000-53000 cps
fireperf -c <IP address> -P 1000 -x -p 63000:63010 -> ~52000 cps
fireperf -c <IP address> -P 10000 -x -p 63000:63010 -> ~52000 cps
The cpu utilization within the VM was limited to 2 cores and increased in sync with the cps. In my last test, the utilization was about 55% on both cores on the server.
The cpu utilization on the host was limited to 2 cores and increased in sync with the cps. In my last test, the utilization of ther server was about 100% on 2 cores and about 50% on an third core.
The cpu utilization on the client was limited to 2 cores and increased in sync with the cps. In my last test, the utilization was about 75% on one core. Because the measurement results with the VM differed significantly from the previous native ones, I rebooted my Test-IPFire and repeated the native tests. These are now more plausible. I think the reboot was probably necessary. ;-)
Here are the new results:
server: IPFire Core 154; Intel i7 4790; Intel 82571EB/GB 1GBit Nic Client: Ubuntu 20.4; Intel i7 9700; Intel i219-V 1GBit Nic
Server: fireperf -s -P 10000 -p 63000:63010
Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 -> ~6000 cps
fireperf -c <IP address> -P 10 -x -p 63000:63010 -> ~35000-40000 cps
fireperf -c <IP address> -P 100 -x -p 63000:63010 -> ~53000-54000 cps
fireperf -c <IP address> -P 1000 -x -p 63000:63010 -> ~53000 cps
fireperf -c <IP address> -P 10000 -x -p 63000:63010 -> ~52000 cps
The cpu utilization was limited to one core and increased in sync with the cps on both sides.
In the last test, the utilization of one core was about 85-100% on the server and 75% on the client. We see a very significant increase of the cpu utilization (+150%) on the server. Between running the server natively or in a VM. And also a reduction of the cps by 30% with only one connection and up to 55% with 10 connections. From 100 connections, the bottleneck is obviously somewhere else.
-
Daniel
10. Februar 2021 08:49, daniel.weismueller@ipfire.org (mailto:daniel.weismueller@ipfire.org) schrieb: Another day another result.
I've testet my old Raspberry Pi 3 B. ;-) 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 Here are the results:
Server: fireperf -s -P 10000 -p 63000:630010
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 -> crashed and the Pi needs 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.
In the next days I will test our mini and post the results here.
-
Daniel 9. Februar 2021 13:53, daniel.weismueller@ipfire.org (mailto:daniel.weismueller@ipfire.org) schrieb: 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
-
daniel.weismueller＠ipfire.org