5100, 5200 and 5400 performance with R80.20

[Vladimir]

Can someone running the above mentioned models with R80.20 report on their performance after upgrade from R77.30 or R80.10?

Thank you,

Vladimir

[Kaspars_Zibarts]

Might be forced to upgrade soon or 5900s but obviously you're not interested in those  

[Vladimir]

Are you referring to the same reasons mentioned in  exchange between Timothy Hall‌ and myself?

The thing is, CP still lists the performance of the 5100 to 5400 as superior to the 4 core 3000 series appliances.

If Tim's hypothesis and my supposition are correct, that shall not be the case.

So I am looking for empirical data from those that are running these appliances with R80.20, preferably upgraded from R77.30 and have a baseline with which to compare their current performance.

It would be nice for someone from R&D to look into that discussion and let us know if we are getting something wrong.

[Kaspars_Zibarts]

Nah - we don't run HTTPS inspection on CP, it was too unreliable  we need to get "updatable objects" to be able to filter O365 traffic without any additional blades and no HTTPS inspection

[Vladimir]

That was the poll, the discussion was below. Here is what I am referring to:

Vladimir Yakovlev @ Timothy Hall on Nov 2, 2018 8:29 AM

Tim, can you elaborate if the x2 you are referring to is applicable to the 5600+ appliances or the smaller units?

I would imagine that this number would differ significantly between smaller units and those capable of AES-NI.

Additionally, I recall having a conversation while in CP HQ, in which I have stated that nothing with less than 4 cores should really be recommended in post R80.20 world.

Do you, perchance, recall in what context I could've come up with it?

Like • Show 0 Likes0Reply

 Actions 

• 

  Timothy Hall @ Vladimir Yakovlev on Nov 2, 2018 7:36 PM

  Hi Vladimir,

  AES-NI will certainly help, at least with websites utilizing that in their active cipher suite.  The x2 is a rough recommendation; frankly I wouldn't be comfortable doing HTTPS Inspection on a 5400 or smaller box at all unless Internet bandwidth was less than 50Mbps and ended up being the primary performance constraint.  Unless the <5400 box has a Falcon accelerator card in it course.  🙂  I doubt the HTTPS Inspection optimizations in R80.20 will help much on a 2-core firewall.

  The context of that "less than 4 cores" conversation concerned the fact that if CoreXL is enabled and a firewall has 2 cores, both of them will try to serve "double duty" by acting both as a SND/IRQ core and a Firewall Worker core.  This is much less efficient than having each core dedicated to only one function and defeats many of the gains provided by CPU fast caching, as the CPU caches thrash back and forth between the two functions.  In some cases disabling CoreXL completely on a 2-core firewall can actually improve the situation, as one core is dedicated to SND/IRQ functions and the other one is the solitary Firewall Worker.  No easy way to know for sure ahead of time if disabling CoreXL on a 2-core firewall will help or hurt, just have to try it...

[HeikoAnkenbrand]

Hi Vladimir,

Hi Tim,

An Advanced Encryption Standard instruction set is now integrated in to many processors. Tim has already described it well here " ". The purpose of the instruction set is to improve the speed, of applications performing encryption and decryption using Advanced Encryption Standard (AES). They are often implemented as instructions implementing a single round of AES along with a special version for the last round which has a slightly different method.

Crypto API is a cryptography framework in the Linux kernel, for various parts of the kernel that deal with cryptography, such as IPsec. It supports AES-NI. Therefore it is also used with Check Point software. The Crypto API was introduced in kernel version 2.5.45+ and has since expanded to include essentially all popular block ciphers and hash functions.
This API can be used for VPN connections (IPSec) and accelerates AES VPN connections on hardware level.

This is more problematic with https. OpenSSL is normally used here. OpenSSL also supports AES-NI. However https uses different chipers (DES, 3DES, AES, AES256,...). Unfortunately, we cannot control the chipers in a targeted way. Therefore AES is not always used. So the hardware acceleration for AES-NI is not used for every connection. Therefore the advantage and disadvantage for AES-NI is not really predictable for https.

My assessment of the topic AES-NI:

• VPN ->  I think AES-NI can be used for VPN connections specifically with AES/ AES256.

• https -> With https the targeted use of AES-NI will be very difficult.

Regards

Heiko

[Vladimir]

Heiko Ankenbrand‌, in regards to this set of appliances, I am more concerned with CoreXL performance on 2 core CPUs.

Tim's statement: "The context of that "less than 4 cores" conversation concerned the fact that if CoreXL is enabled and a firewall has 2 cores, both of them will try to serve "double duty" by acting both as a SND/IRQ core and a Firewall Worker core.  This is much less efficient than having each core dedicated to only one function and defeats many of the gains provided by CPU fast caching, as the CPU caches thrash back and forth between the two functions.  In some cases disabling CoreXL completely on a 2-core firewall can actually improve the situation, as one core is dedicated to SND/IRQ functions and the other one is the solitary Firewall Worker.  No easy way to know for sure ahead of time if disabling CoreXL on a 2-core firewall will help or hurt, just have to try it..."

sums up the discussion we've had in Tel Aviv and I am interested to learn if our concerns are unfounded.

[HeikoAnkenbrand]

Hi Vladimir,

I agree with you 100%.

I think that not only the number of cores is the question or if you turn off CoreXL. We also have to consider the load with VPN and https.

I see a better performance for a connection at https in recent years, as more secure chipers are used AES and thus support AES-NI. However, the number of https pages is increasing. This gives much more connections and the performance goes back to the basement:-(

So I wouldn't use https Inspection on smaller appliances.

On the subject of CoreXL on or off, you should always test what is better with 2 cores.

[Timothy_Hall]

> The thing is, CP still lists the performance of the 5100 to 5400 as superior to the 4 core 3000 series appliances.

> If Tim's hypothesis and my supposition are correct, that shall not be the case.

All cores are not created equal.  The processor used by the 3200 is a low-wattage 1x Intel Atom C2558 (Quad-core) which has a total CPU mark score of 2169.  The 5200 uses a Dual-core Celeron G1820 (CPUMark score 2758) and the 5400 uses a Dual-core Pentium G3420 (CPUMark score 3405).  So it is not just the number of cores, but the performance of each individual core that matters.  This is why the 5200 and 5400 have a SPU rating that is higher than the 3200 model. 

So the whole 2-core vs. 4-core argument is essentially moot in this case as we are comparing apples to oranges.  Yes the 3100/3200s support AES-NI but their individual cores are far slower than the 5200/5400 even though there are more of them.  So the improvement gained by having AES-NI on the 3100/3200 (and not on the 5200/5400) is going to be extremely variable depending on the cipher suites used, just as Heiko observed.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Vladimir]

Let's forget about HTTPS inspection and AES-NI for a moment and see it strictly from the point of view of CoreXL behavior on these units pre and post R80.20.

That is if there is someone who has upgraded already and has data to share.