From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel.weismueller@ipfire.org To: development@lists.ipfire.org Subject: Re: fireperf results Date: Wed, 17 Feb 2021 15:17:45 +0000 Message-ID: <7c2b4ed46305af54060f493d2f562ccc@ipfire.org> In-Reply-To: <3783c8a5-8f50-5935-1103-af4045d0411e@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8032321946676985536==" List-Id: --===============8032321946676985536== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Adolf, > Without suricata running on IPFire I got 55cps - 8000cps and very fluctuati= ng. I'm a little surprised because even the Pi 3 manages only a few connections p= er second, but reasonably constant. > I also found that on the server table it was showing mostly zero for Open C= onnections with > occasionally having a 1 or 2 This is ok because with -x the client opens and instantly close the connectio= n. > Without suricata and running fireperf -c -P 1 -x -p 63000:6301= 0 the server stayed at 0 > Open Connections. The client had a few secs going from 8000 down to 5800cps= then after around 10 > secs the rate went down to 0cps - 235cps fluctuating and stayed like that. Depending on the amount of available ram, IPFire sets the maximum number of a= vailable connections. For the Mini, for example, 65536 connections. This is good under normal conditions, but of course not very helpful for our = test. However, you can easily change this value temporarily. sysctl -w net.netfilter.nf_conntrack_max=3D262144 This should change this behavior. - Daniel 17. Februar 2021 15:36, "Adolf Belka (ipfire-dev)" = schrieb: > H Daniel, >=20 > On 17/02/2021 11:06, daniel.weismueller(a)ipfire.org wrote: >=20 >> Hi Adolf, >> 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. >=20 > I re-ran the results but they were not better. >=20 > As an example with fireperf -c -P 100 -x -p 63000:63010 >=20 > Without suricata running on IPFire I got 55cps - 8000cps and very fluctuati= ng. > I also found that on the server table it was showing mostly zero for Open C= onnections with > occasionally having a 1 or 2 >=20 > If I turned suricata back on and re-ran the same test I got 300cps - 8000cp= s and very fluctuating > but on the server I had 500-600 Open Connections. >=20 > I don't know what is expected to be seen on the client and on the server in= this test but the above > was what I found. >=20 > Without suricata and running fireperf -c -P 1 -x -p 63000:6301= 0 the server stayed at 0 > Open Connections. The client had a few secs going from 8000 down to 5800cps= then after around 10 > secs the rate went down to 0cps - 235cps fluctuating and stayed like that. >=20 > Regards, >=20 > Adolf >=20 >> Thanks, >> Daniel >> 16. Februar 2021 13:44, "Adolf Belka (ipfire-dev)" schrieb: >> Hi All, >>> Following are the fireperf results I obtained:- >>>=20 >>> 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 >>> Client: >>> fireperf -c -P 1 -x -p 63000:63010 -> 100 - 3000 cps strongl= y fluctuating. After a >>> couple of minutes the client cps went down to 0 and stayed there. I had t= o stop fireperf and >>> restart the terminal to get it working again. >>>=20 >>> fireperf -c -P 10 -x -p 63000:63010 ->250 - 500 cps fluctuat= ing >>>=20 >>> fireperf -c -P 100 -x -p 63000:63010 -> 220 - 1000 cps fluct= uating >>>=20 >>> fireperf -c -P 1000 -x -p 63000:63010 -> 1200 - 2500 cps flu= ctuating >>>=20 >>> fireperf -c -P 10000 -x -p 63000:63010 -> 0 - 7000 cps hugel= y fluctuating >>>=20 >>> In all cases the cpu utilisation was quite low on both IPFire and the Arc= h Linux desktop. >>>=20 >>> I then repeated the above tests removing the -x option so I could see the= data bandwidth. >>>=20 >>> fireperf -c -P 1 -p 63000:63010 -> 225Mb/s - 1 core at 100%,= rest around 30% to 40% >>>=20 >>> fireperf -c -P 10 -p 63000:63010 -> 185Mb/s - similar as abo= ve >>>=20 >>> fireperf -c -P 100 -p 63000:63010 -> 210Mb/s - similar to ab= ove >>>=20 >>> fireperf -c -P 1000 -p 63000:63010 -> 370 - 450Mb/s - 2 core= s at 100%, rest at 30% to >>> 40% >>>=20 >>> fireperf -c -P 10000 -p 63000:63010 -> 400Mb/s - 1Gb/s - 2 c= ores at 100%, rest at 40% >>> to 50% >>>=20 >>> I recently got my Glass Fibre Gigabit connection connected. The supplier = hooked his laptop directly >>> to the media converter and got around 950Mb/s >>>=20 >>> Using the same speed test as he used but going through my IPFire hardware= I get around 225Mb/s. >>>=20 >>> Although my hardware has four Intel I211 Gigabit NIC's, I have suspected = that their performance is >>> limited by the processor. >>>=20 >>> Regards, >>>=20 >>> Adolf. --===============8032321946676985536==--