From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Fireperf: first tests an results Date: Tue, 09 Feb 2021 14:53:11 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4987769952337762832==" List-Id: --===============4987769952337762832== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: >=20 >=20 > Hi guys, >=20 > today I installed fireperf on my testing IPFire and my Ubuntu PC. >=20 > server: IPFire Core 154; Intel i7 4790; Intel 82571EB/GB 1GBit Nic > Client: Ubuntu 20.4; Intel i7 9700; Intel i219-V 1GBit Nic >=20 > 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 usu= ally 32768 and 60999: [root(a)fw01 ~]# sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range =3D 32768 60999 That leaves you with being able to open up to 28231 connections to the same s= erver on the same port. Obviously this is not enough for more than 28k connec= tions and therefore it is necessary to open more listening sockets on the ser= ver 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. Therefor= e I would recommend to open more ports on the server side than strictly neces= sary. I have not empirically tested this yet, but about 5000 connections per port i= ntuitively sounds like a good value. >=20 > So here my results: >=20 >=20 > Server: > fireperf -s -P 10000 -p 63000:630010 >=20 > Client: > fireperf -c -P 1 -x -p 63000:63010 -> ~5000 cps >=20 > fireperf -c -P 10 -x -p 63000:63010 -> ~30000-35000 cps >=20 > fireperf -c -P 100 -x -p 63000:63010 -> ~35000-40000 cps >=20 > fireperf -c -P 1000 -x -p 63000:63010 -> ~40000-45000 cps >=20 > fireperf -c -P 10000 -x -p 63000:63010 -> ~46000-48000 cps >=20 > The cpu utilization was limited to one core and increased in sync with the = cps on both sides. >=20 > In my last test, the utilization was about 85-100% on the server and 75-95%= on the client. >=20 > 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 r= ange. 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 unde= r reproducible conditions. I would also like to see this tested on weaker hardware. Hopefully we will se= e any bottlenecks earlier than on 10G sixteen core 19=E2=80=9D rack-mountable= enterprise system. :) Anyone up for that? Best, -Michael > - >=20 > Daniel >=20 --===============4987769952337762832==--