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, 16 Feb 2021 15:00:33 +0000 Message-ID: <8F9506AA-CCC7-4076-B73A-D7CEAB02DDCC@ipfire.org> In-Reply-To: <9a5081fe-ca81-8b13-9789-9b36420019e4@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1814688316987872109==" List-Id: --===============1814688316987872109== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 16 Feb 2021, at 12:16, Adolf Belka (ipfire-dev) wrote: >=20 > Hi Michael, >=20 > On 16/02/2021 12:48, Michael Tremer wrote: >> Hi, >>> On 12 Feb 2021, at 12:30, Adolf Belka (ipfire-dev) wrote: >>>=20 >>> Hi all, >>>=20 >>> I tried to also test this out on my system. >>>=20 >>> 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 >>>=20 >>> client: Arch Linux; Intel Core i5-8400 CPU @ 2.80GHz 6 core; 1GBit nic >>>=20 >>> Server: >>> fireperf -s -P 10000 -p 63000:630010 >>>=20 >>>=20 >>> Client: >>> fireperf -c -P 1 -x -p 63000:63010 where was re= placed with the IP address of my IPFire Green connection. >>>=20 >>>=20 >>> I started the server fireperf and there was the table updating regularly. >>>=20 >>> I started the client and got "Could not open socket: Address family not s= upported by protocol" scrolling up the screen. >> That is interesting. Could you please start the same thing again with stra= ce? >> strace -o strace.log fireperf -c ... >> Please send the log file to me and hopefully I will be able to find someth= ing. >=20 > 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. >=20 > I had disabled IPV6 in the past with Arch Linux as I had lots of warnings i= n 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=E2=80=99t = work in my tests and so I reverted the commit: https://git.ipfire.org/?p=3Dfireperf.git;a=3Dcommitdiff;h=3D0ec017a4da5e00c40= 5d63782d34009f486dc9478 > Having now removed the IPV6 disable my logs have stayed clear of any messag= es 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. >=20 > I will send a separate email with the results I found. >=20 > Regards, >=20 > Adolf. >>>=20 >>> I looked in the log (journalctl) but there were no messages at all relate= d to fireperf just the command being run. >> Fireperf does not log to syslog at all at the moment. >> Earlier it did, but I didn=E2=80=99t see any point in doing so. >>> Any thoughts on what I am missing to have setup or installed? >>>=20 >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>=20 >>>=20 >>> On 09/02/2021 13: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 expect= ed connection per second (cps) >>>>=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 t= he 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. >>>>=20 >>>> - >>>>=20 >>>> Daniel --===============1814688316987872109==--