Licence on Open Server - Physicals cores or Hyper-Threading (HT) cores

[Thiago_Mourao]

For Open Server do I need to license the amount of Physicals cores or Hyper-Threading (HT) cores? I mean, if the server has the 1x Intel® Xeon® Silver 4214 Processor the total of Physical Cores are 12, but if I enable the Hyper-Threading this will double to 24 Hyper-Threading (HT) cores. What should I use, 12 core or 24 core OpenServer License?

[Marcel_Gramalla]

If you want to use all 24 cores you will need the 24 core license. But you can also buy 8 or 16 cores (not all core have to be licensed).

[JanVC]

according to https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... HT is only supported on appliances and not open servers

i've seen conflicting information on the forum already, so no idea which is the correct statement 🙂

[Benedikt_Weissl]

I think thats only true for Gaia OS with 2.6 Kernel, see https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[JanVC]

so contradicting information, the SMT article says not supported and the article you linked says supported

I can even remember the discussion on this forum, that with HT enabled on open servers you only needed to license the physical cores and that this was a "limitation" on that current release, which was going to be corrected in the next release, meaning you need to license all cores

[Bob_Zimmerman]

The license is an application-level constraint, not an OS-level constraint. The OS will recognize all the cores which you physically have and which are enabled, and it will recognize cores with SMT as two logical cores.

The license controls how many CoreXL instances you are allowed to run. If I remember correctly, both dispatchers and workers count against this.

Going from four real cores to four hyperthreaded (eight logical) cores yields about a 15%-30% speedup for parallel workloads. This is less than you would get from extra real cores. It's important to note, though, that simply having hyperthreading enabled does not hurt per-core performance, it just gives the OS opportunities to schedule work in suboptimal ways. For peak packet-handling performance, you can enable hyperthreading and use affinity to force your dispatchers and workers onto real cores. Other work can use the hyperthreads opportunistically without necessarily slowing down the traffic processing.

[RamGuy239]

With R80.40 and the move to linux kernel 3.10 it seems like Check Point has changed their stance on SMT/Hyper-Threading:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Previously it was only enabled on high-end appliances by default. But with 3.10 kernel on the gateways that arrived with R80.40 (or R80.20 and R80.30 using those special, not widely recommended 3.10 releases) it's enabled by default.

There is no reason to think about open servers any different to appliances when it comes to SMT/Hyper-Threading. The main issue comes down to licensing. Licensing for open servers haven't changed with the move to 3.10 kernel. As SMT/Hyper-Threading is being treated by the operating system as regular cpu cores you have to license them as additional cores.

If you have an open server running an 8-core CPU it will be recognised as a 16-core CPU when SMT/Hyper-Threading is enabled. If you want to utilise these extra threads you will have to upgrade your license from 8-cores to 16-cores. In most cases this additional cost won't make much sense as the efficiency of these added threads won't be decent enough to compensate for the additional cost in licensing. And having SMT/Hyper-Threading enabled without paying for a bigger license is not ideal either as you have no control over whether CoreXL is utilising physical cores or threads so you are simply risking to get lower performance by enabling SMT/Hyper-Threading unless you get the appropriate license to have all cores+threads active.

One benefit that appliances have that open server doesn't have, at least not yet is the lack of CoreXL Split / Dynamic Balancing. As SMT/Hyper-Threading will basically double the number of threads you have available the use of CoreXL Split / Dynamic Balancing because more logical. As this is a feature that is exclusive to appliances at this point it just adds to the fact that from a cost perspective enabling SMT/Hyper-Threading doesn't make much sense for open servers at this point in time.

With 3.10 kernel it should work just fine. But the cost for licensing the additional threads and the lack of CoreXL Split / Dynamic Balancing makes it not making much sense unless you are in a very specific scenario where new hardware is out of the question and somehow your performance is lacking so the additional threads might make it worthwhile for you even with the additional licensing costs.