Does R80.40 support HP DL380 G10 ?

[James_Liao]

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

[Sigbjorn]

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.)

[James_Liao]

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 ?

[_Val_]

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

[G_W_Albrecht]

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

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.

[Dorit_Dor]

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. 

[Dorit_Dor]

... and as indicated before

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

[_Val_]

@Dorit_Dor thanks a lot

[RickLin]

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?

[Andreas_Ahrnby]

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

[Danny_Yang]

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.

[Dorit_Dor]

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. 

[Marcel_Gramalla]

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?

[Daniel_Schlifka]

---

@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...

[_Val_]

@Daniel_Schlifka that is not a correct statement.

sk156793 actually has the answer that @Marcel_Gramalla is seeking. On 3.10 kernel based versions, license will count physical cores, allowing 16 HT cores to be used on 8 core CPU

[Guy_Israeli]

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

[Dale_Lobb]

  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

[PhoneBoy]

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.

[Dale_Lobb]

  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?

[PhoneBoy]

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.

[Magnus-Holmberg]

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.

[Timothy_Hall]

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.

[Magnus-Holmberg]

The question is not if HT gives extra performance. The question is if HT is more cost efficient then real cores on open servers.

[PhoneBoy]

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.

[Dorit_Dor]

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. 

[Mikael]

Bumping this thread as I found this SK which seems to indicate a different behaviour in regards to licensing:

Number of CPU cores in CoreXL license and in output of 'cplic print' do not match 

I would also have said that licenses is based on total number of cores (as visible in top)...

[_Val_]

And your question is..? @Mikael 

[Mikael]

The comment seems to have jumped around... 😀

My reply was to @PhoneBoy comment regarding licensing of cores. The SK I mentioned seems to indicate that an 8-core license would be valid for an open-server with a CPU with 8 cores and 16 threads, i.e for a system where top would show 16 processors...

I would normally have agreed with @PhoneBoy in the conclusion that a license doesn't consider if the core is "physical" or hyper-threaded but now I'm not so sure anymore...

I'm just trying to understand if that's the case or if the SK is wrong...

[_Val_]

SK is not wrong. With 3.10 based versions, license is for physical cores, allowing 16 virtual cores in cause you have 8 CPUs licensed.

[James_Liao]

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