From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Adolf Belka (ipfire-dev)" To: development@lists.ipfire.org Subject: Re: fireperf results Date: Wed, 17 Feb 2021 15:36:32 +0100 Message-ID: <3783c8a5-8f50-5935-1103-af4045d0411e@ipfire.org> In-Reply-To: <0a8ff9c51dcbeccefcb0f5b9064b563c@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5159495210919470034==" List-Id: --===============5159495210919470034== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable H Daniel, On 17/02/2021 11:06, daniel.weismueller(a)ipfire.org wrote: > Hi Adolf, >=20 > could you please retest your system with suricata disabled. > I think surucata will also have a strong impact on cps. > I will post the results to the wiki. I re-ran the results but they were not better. As an example with fireperf -c -P 100 -x -p 63000:63010 Without suricata running on IPFire I got 55cps - 8000cps and very fluctuating. I also found that on the server table it was showing mostly zero for Open Con= nections with occasionally having a 1 or 2 If I turned suricata back on and re-ran the same test I got 300cps - 8000cps = and very fluctuating but on the server I had 500-600 Open Connections. I don't know what is expected to be seen on the client and on the server in t= his test but the above was what I found. Without suricata and running fireperf -c -P 1 -x -p 63000:63010 = the server stayed at 0 Open Connections. The client had a few secs going fro= m 8000 down to 5800cps then after around 10 secs the rate went down to 0cps -= 235cps fluctuating and stayed like that. Regards, Adolf >=20 > Thanks, > Daniel >=20 > 16. Februar 2021 13:44, "Adolf Belka (ipfire-dev)" schrieb: >=20 >> Hi All, >> >> Following are the fireperf results I obtained:- >> >> server: IPFire 2.25 - Core Update 153; Intel Celeron CPU J1900 @ 1.99GHz x= 4; 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 -P 1 -x -p 63000:63010 -> 100 - 3000 cps strongly= fluctuating. After a >> couple of minutes the client cps went down to 0 and stayed there. I had to= stop fireperf and >> restart the terminal to get it working again. >> >> fireperf -c -P 10 -x -p 63000:63010 ->250 - 500 cps fluctuati= ng >> >> fireperf -c -P 100 -x -p 63000:63010 -> 220 - 1000 cps fluctu= ating >> >> fireperf -c -P 1000 -x -p 63000:63010 -> 1200 - 2500 cps fluc= tuating >> >> fireperf -c -P 10000 -x -p 63000:63010 -> 0 - 7000 cps hugely= fluctuating >> >> In all cases the cpu utilisation was quite low on both IPFire and the Arch= Linux desktop. >> >> I then repeated the above tests removing the -x option so I could see the = data bandwidth. >> >> fireperf -c -P 1 -p 63000:63010 -> 225Mb/s - 1 core at 100%, = rest around 30% to 40% >> >> fireperf -c -P 10 -p 63000:63010 -> 185Mb/s - similar as above >> >> fireperf -c -P 100 -p 63000:63010 -> 210Mb/s - similar to abo= ve >> >> fireperf -c -P 1000 -p 63000:63010 -> 370 - 450Mb/s - 2 cores= at 100%, rest at 30% to >> 40% >> >> fireperf -c -P 10000 -p 63000:63010 -> 400Mb/s - 1Gb/s - 2 co= res at 100%, rest at 40% >> to 50% >> >> I recently got my Glass Fibre Gigabit connection connected. The supplier h= ooked his laptop directly >> to the media converter and got around 950Mb/s >> >> Using the same speed test as he used but going through my IPFire hardware = I get around 225Mb/s. >> >> Although my hardware has four Intel I211 Gigabit NIC's, I have suspected t= hat their performance is >> limited by the processor. >> >> Regards, >> >> Adolf. --===============5159495210919470034==--