Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant

Does R80.40 support HP DL380 G10 ?

Hardware Compatibility List do not show anything about R80.40 , do I need to open case for the answer ?

 

 

snap327.jpg

0 Kudos
27 Replies
Highlighted
Advisor

R80.40 is 3.10 kernel only, so I think its a safe bet to look at R80.30 3.10 support.

(But for production, I'd probably wait for the official HCL update.)

0 Kudos
Highlighted
Participant

Thanks for answer , but I want get the answer ASAP , because I need to tell our customer which version I will use , so, how to push official HCL update ?

0 Kudos
Highlighted
Admin
Admin

I suspect the table is not yet updated with R80.40. If you need an immediate and official answer, please open a support request.

0 Kudos
Highlighted
Champion
Champion

Your question maybe too early, see the R80.40 Release Notes : 😎

Open Server Hardware Requirements

 

 

Important - R80.40 for Open Servers is supported only for Security Management Servers .

Security Gateways and Standalone configurations for Open Servers is expected with R80.40 Jumbo Hotfix Accumulator.

Highlighted
Employee+
Employee+

for full transparency

r80.40 is kernel 3.10 and is good for open server except that while enabling hyper threading on open server for first time, we noticed few bugs (mainly licensing related). 

being VERY careful on quality we chose to list it as known limitation till one of the jumbo that fixes all bugs.

bottom line: the base works and if urgent, we can deal w issues as one off. Otherwise in very first jumbo’s will fix the few bugs and list it as supported. 

Highlighted
Employee+
Employee+

... and as indicated before

management is fine.
Gw still have some known issue w hyper threading 

Highlighted
Admin
Admin

@Dorit_Dor thanks a lot

0 Kudos
Advisor

Does the issue also relate to HP DL380 G9 ?!

CPUSE 1858 verify results tell me it's allowed to Clean Install. 

Can I clean isntall successfully when I disable HT in BIOS?

image.png

0 Kudos
Highlighted
Contributor

So you planning to support SMT (HT) on open servers beginning from R80.40? @Dorit_Dor 

0 Kudos
Highlighted
Employee++
Employee++

Hi James,

 

If there are many customers need to upgrade to R80.40 for gateway use, please collect all the opportunities to me and I can escalate this requirement to our RnD team.

Or we can discuss for which version should be better to fulfill your demand in case R80.40 still need so time to fix the issues as Dorit mentioned.

0 Kudos
Highlighted
Employee+
Employee+

Yes, open-servers will have SMT enabled for new installations and open-servers upgrades with 3.10/GOGO

For open-servers upgrading 2.6.18, we’ve found a solution to avoid SMT changes to provide stable/smoother upgrade.

Nothing is specific to HP, its true to all open server. 

R80.40 technically works on open server in GA except few bugs related to side topics like licensing.   We call it not supported because we were asked to be very sensitive to quality... the fixes should all come in first or second jumbo and the release will become the default  only when open server problems will be resolved. So i think its a non issue. 

anyway, if r80.40 needs to urgently be installed on open server even before its the default version, they can call us and will get list of “known limitation” that i assume they can live with... this is really not an issue. 

Highlighted
Contributor

Hi,

great to hear that SMT will be supported for open server. I wonder how the licensing will be? Do we have to purchase the licence based on the physical cores or the logical cores?

Example: 8 Core license - can we use 8 physical cores without SMT (as it is today) or 8 physical cores with 16 threads?

0 Kudos
Highlighted
Contributor


@Marcel_Gramalla wrote:

Hi,

great to hear that SMT will be supported for open server. I wonder how the licensing will be? Do we have to purchase the licence based on the physical cores or the logical cores?

Example: 8 Core license - can we use 8 physical cores without SMT (as it is today) or 8 physical cores with 16 threads?


The kernel doesn't make a difference here and considers 16Threads as 16 Cores, independent from being a physical or just a logical core. The Core Count of the license  is  bound to CoreXL. 
If you want to utilize 16 Cores for CoreXL you need a 16C license,
Oversubscription is possible with VSX. You can run multiple fwk-instances on one cpu core, but thats risky when one instance starts draining resources which are shared with another instance. Especially when running Blades like IPS and Content Inspection.

When you run 8 Cores for FW Workers you also need to consider some cores for System I/O.
System I/O cores are not bound to that limitation(. If you have 8fw worker threads you should usually take some Cores into account for System, it depends a bit on throughput and enabled blades.
refer:
sk98348
Timothy Halls Max Power Book
https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/R80-x-Performance-Tuning-Tip-Mult...





Highlighted
Employee
Employee

Hi Marcel

Customers can keep SMT off and continue with the same license.

If customer would like the enjoy the SMT benefit, they should purchase license per virtual cores

 

Thanks, Guy

Highlighted
Collaborator

  What does it mean to "purchase license per virtual cores"?

  Is that license the same as a full core?  If so, then it's pretty much a useless proposition.  SMT cores are only about as good as 60% of a full hardware core.  What would be the point of purchasing extra expensive core licenses for SMT?  That seems like an extremely poor use of money when full hardware cores are so cheap.  Maybe it would be worthwhile in a few corner cases where someone cannot immediately upgrade CPUs, but I bet it would use would be extremely rare.

 

Best Regards,

Dale

0 Kudos
Highlighted
Admin
Admin

What it means is, from a licensing point of view, we count SMT cores the same as physical ones.
As such, they need to be licensed to be used on Open Server Gateways.
Previously, SMT was not allowed on Open Server Gateways at all.
0 Kudos
Highlighted
Collaborator

  Unfortunately, that's what I feared.

  In that case, my guess is that no one will ever use full core licenses for SMT, except in very rare cases.  It seems like a lot of work on CheckPoint's part for something that won't see very much use.

  Maybe I'm wrong, but really see no use for it if the license costs the same as a full core.  I just don't see that as economical: If I need more cores, I can buy CPU upgrades pretty cheap to use with the licenses, and that way I get the full benefit of the cores.  Yes, there are likely rare corner cases where it might make sense temporarily, but since it takes days to get a quote for new licenses and days more to execute a purchase, one could easily get new CPUs fast shipped to go with the new licenses in the time it takes to get the new license.  I just think that SMT won't see much use unless the licenses to go with it are cost substantially less than full core licenses.

  But maybe I'm not seeing something here. What do others say?  Do you see a need for SMT on your open servers if the license costs the same as a full core?

 

0 Kudos
Highlighted
Admin
Admin

Whether SMT will be a benefit to you or not depends quite a lot on the traffic flows, enabled blades, etc.
If I remember previous discussion correctly (and I'm sure @Timothy_Hall will correct me if I'm wrong), SMT may provide benefit if a lot of your traffic is in PXL, but not so much if it's mostly fully accelerated.

It's possible we will re-evaluate the licensing rules around SMT cores on Open Servers in the future.

0 Kudos
Highlighted

HT has not been supported for a long time on open servers. Also maximum core licens on open servers are currently 32 cores.

I do only see one benefit with it.
The cpu clock rate is much higher on a a new 4 core cpu, then for example a 8 core one.

So there may be benefit for it when running 2x4 core cpu with high clockrate with HT instead of 2x8 core cpu that then will then have a lower clock speed.
https://www.youtube.com/c/MagnusHolmberg-NetSec
0 Kudos
Highlighted
Champion
Champion

For gateways with the "typical" blades enabled (APCL, URLF, TP, etc.) SMT/Hyperthreading improves performance since the bulk of traffic tends to end up in the PSLXL path, and to a lesser degree the CPASXL path.  Processing in these paths tends to be operations that wait or block often for some event to occur such as the next packet in an inspected stream to arrive.  This type of workload benefits from SMT, as once a worker instance on a physical core blocks, another worker instance can hop onto the same physical core via the other thread to get its work done. As such SMT is enabled by default on all Check Point appliances since it is beneficial to performance in most  deployments.

But the workload of the SND/IRQ cores is quite different and consists of fast, efficient, rapid-fire operations that are over quickly and perform very little waiting/blocking.  If a large percentage of traffic is fully accelerated by SND/SecureXL via tuning adjustments, use of minimal blades (such as only Firewall and IPSec VPN), or utilization of fast_accel, under high load with SMT enabled the two SND/IRQ instances tend to fight each other for the same physical core and decrease performance.  In the third edition of my book I state that if 70% or more of traffic is fully accelerated, it is essentially a no-brainer to turn off SMT; however I've seen noticeable improvement even down to only 50% or so of fully accelerated traffic.  The percentage of fully accelerated traffic can be assessed by running fwaccel stat and looking at the "Accelerated pkts/Total pkts" line.

Note that if the percentage of fully accelerated traffic changes substantially due to configuration changes it may be desirable to turn SMT back on.

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
0 Kudos
Highlighted

The question is not if HT gives extra performance. The question is if HT is more cost efficient then real cores on open servers.
https://www.youtube.com/c/MagnusHolmberg-NetSec
0 Kudos
Highlighted
Admin
Admin

I suspect in the case of a gateway doing mostly fully accelerated traffic, real cores will be better.
In the majority PXL case, real cores may still be better, but I suspect the difference between the two will be less drastic.
0 Kudos
Highlighted
Employee+
Employee+

As users of open server you are all in full control of the Bios in open server and you can take off HT if you dont like it 

R80.40 GA needed to handle HT bugs post upgrade for the case that you had it enabled before (but not active because old gaia kernel didnt support it) and you will have it therefore active post upgrade to new kernel. ,,, But if you choose to disable it, no one will force you to use it and your license doesnt change. 

0 Kudos
Highlighted
Participant

Hello @Danny_Yang ,

    Do you recommend use R80.40 for MGMT and R80.30 as GW ? that is because I need to run LS unicast  mode and I don't want change customer's PC environment setting for Smartconsole

0 Kudos
Highlighted
Employee++
Employee++

Hello, @James_Liao 

You can deploy MGMT in R80.40 and keep the GW as R80.30 current.

R80.30 ClusterXL supported LS mode based on JHF T76 above. 

 

Jumbo Hotfix Accumulator for R80.30 (R80_30_jumbo_hf)

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

 

ClusterXL Load Sharing mode in R80.20 and above

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

 

0 Kudos
Highlighted

We as a partner were involved in R80.40 EA program and the bugs mentioned regarding hyper threading and licensing on open servers were discovered in our specific environment.

From my perspective I don't see real blocking issues with R80.40 on open server besides it not being officially supported. So if you really have a specific need to upgrade to R80.40 on open server, I would get in touch with the local SE team to speak about how to handle the support! 

0 Kudos
Highlighted
Employee+
Employee+

Officially: we recommend R80.40 already for everyone that needs the new features and we dont yet “push everyone” (make it default) till we have wide adoption. 

By now we have nice adoption and good indications but it will take us few more weeks before we make it default. 

Mgmt is usually less sensitive than GW so deciding to use now R80.40 mgmt with R80.30 gw is a good form of risk mgmt.