Horizon 8 CPU Specs # of cores vs Higher clock rates:

[Jeff KTG]

Hello!

We are looking into upgrading our hardware for Horizon and a question arose in regards to CPU's. Should we be looking for higher clock rates on cores vs # of cores? Is more physical cores better than clock rate per core?

Currently we are hosting an average of 30 sessions per host that have 2 CPU's with 20 cores per socket for a total of 40 cores. 

I'm leaning toward more cores vs clock speed but I would like some other opinions.

Thanks

Jeff

[Robin Harmsen]

We are currently also in the process of refreshing hardware.

I have not got time yet to fully read on all aspects involved around CPU cores vs speed.
As far as I know it also depends on what applications would require.
Also I got the recomendation to get a high clock speed as that would bennefit the overall performance.

As for the core counts you would want to look into a overcommit of no more than 1:3 including overhead. (so 1 core vs 3 vcores) And if performance is crusial you might want to look into even going to 1:2 or lower.
Depending of the amount of users and the available CPU's that might mean you will need to buy a lot more CPU's/servers, compared to aiming at 1:3

 

[StephenWagner7]

If you're doing a hardware refresh, and are familiar with the workload, I'd recommend taking a look at your existing environment and see what your CPU RDY times are, and also talkin to the application owners to see if the workloads are SMP aware or if they require less cores with higher frequency.

Some workloads like lower clock speed with higher core counts, whereas others like higher clock speed, with lower core counts. It also depends on if you're running persistent or non-persistent.

Non-Persistent environments with generic workloads, you can achieve crazy higher density with super high physical to virtual core ratios, but every workload is different, and every environment is different.

Just watch those CPU RDY percentages, someone correct me if I'm wrong, but in the good-old days, you never wanted to have a RDY% higher than 3% or users would start to notice it.

[Gerard Strouth]

Seems like most Windows apps are still single threaded so higher clock rate seems to be a better idea. Also might need to take licensing into account as vSphere is based on cores now if you are using that.

[BenTrojahn]

On 9/4/2024 at 7:49 AM, Jeff KTG said:

Currently we are hosting an average of 30 sessions per host that have 2 CPU's with 20 cores per socket for a total of of 40 cores. Jeff

That just shows how every environment has unique workflows and most importantly license$$ agreements!  My first reaction was 1.3 pcores/session is REALLY terrible.  But it may be where you're at, IDK.  I echo the others that you need to do a perf test and load up one of those servers while monitoring CPU RDY %. 

Since everything is now licensed by core, I'd look for the most cost effective which is *usually* the highest wattage = fastest base clock (all core turbo) cores in the fewest sockets/servers.  For us, the special high freq cpus were prohibitively too expensive, nor could I justify the large cache cpus for our workflows.  A spreadsheet racing will tell you which cpu wins at cost per session. 

Edited September 5 by BenTrojahn

[StephenWagner7]

32 minutes ago, BenTrojahn said:

That just shows how every environment has unique workflows and most importantly license$$ agreements!  My first reaction was 1.3 pcores/session is REALLY terrible.  But it may be where your at, IDK.  I echo the others that you need to do a perf test and load up one of those servers while monitoring CPU RDY %. 

Since everything is now licensed by core, I'd look for the most cost effective which is *usually* the highest wattage = fastest base clock (all core turbo) cores in the fewest sockets/servers.  For us, the special high freq cpus were prohibitively too expensive, nor could I justify the large cache cpus for our workflows.  A spreadsheet racing will tell you which cpu wins at cost per session. 

Keep in mind, Omnissa (and VVF for VDI) is still based off concurrent users and not core count.

EDIT/ADDITION: The only thing you'd need to be worried about core counts, is if you were using your existing vSphere licensing for your server infrastructure (and mixing environments) instead of having a separate VDI environment, utilizing VVF for VDI (formerly known as vSphere for Desktop).

Edited September 5 by StephenWagner7

[Jeff KTG]

Thanks everyone for their comments. 

 

What is the normal or recommended pcores/session? I know that CPU RDY% is what you should use to verify but I'm interested what others are running.

[StephenWagner7]

31 minutes ago, Jeff KTG said:

Thanks everyone for their comments. 

 

What is the normal or recommended pcores/session? I know that CPU RDY% is what you should use to verify but I'm interested what others are running.

This is another tough question that goes back to the conversation about workload specifics. It varies depending on workload.

[Jeff KTG]

Here is one of our hosts for the past 24 hrs. Even outside of production hours, CPU RDY % is high on the host without hardly any VM's running on it. This doesn't make sense!unning on it.

[BenTrojahn]

True,  i had vpshere/ms server licensing  on my brain.  Still, even with the all in one price from Omnissa, I'm pretty sure you are still paying the piper… you have no idea how much, yet.  of course everyone's contract price is different so YMMV 😉  

[Jeff KTG]

Here is a host in our DR environment with 5 VM's powered on. 

[StephenWagner7]

10 minutes ago, Jeff KTG said:

Here is one of our hosts for the past 24 hrs. Even outside of production hours, CPU RDY % is high on the host without hardly any VM's running on it. This doesn't make sense!unning on it.

You're looking at CPU RDY as a measurement of time. I'd recommend looking at the CPU RDY % which is a percentage. I usually view this from esxtop, however you can used advanced performance metrics.

[Gerard Strouth]

4 hours ago, StephenWagner7 said:

Keep in mind, Omnissa (and VVF for VDI) is still based off concurrent users and not core count.

EDIT/ADDITION: The only thing you'd need to be worried about core counts, is if you were using your existing vSphere licensing for your server infrastructure (and mixing environments) instead of having a separate VDI environment, utilizing VVF for VDI (formerly known as vSphere for Desktop).

@StephenWagner7 Since it is VVF though the VSAN licensing is pretty limited

[Jeff KTG]

Good Day!

@StephenWagner7

I don't see a metric that show that in advanced performance metrics. This is what I see. Maybe I'm missing something.

[StephenWagner7]

10 minutes ago, Jeff KTG said:

Good Day!

@StephenWagner7

I don't see a metric that show that in advanced performance metrics. This is what I see. Maybe I'm missing something.

I'm not sure why you don't have "Readiness" as a %, but on mine I do (I'm running 8U3).

Like I said above, I'd recommend using "esxtop" via CLI to view/sample ready %'s during prod hours. If you're using charts, it may average/smooth out spikes, whereas using esxtop you can view it live and see if you have any VMs running with high RDY %s

[Sean Massey-1]

ESXTop, which you would need to run from an SSH session on each host, or a 3rd-party monitoring tool like Liquidware Stratusphere or ControlUp are probably the best tools to grab performance information on your existing hardware. 

Even if you don't see the option in your vCenter performance charts, there is a method for converting between CPU Ready Summation and CPU Ready %: https://knowledge.broadcom.com/external/article/306576/converting-between-cpu-summation-and-cpu.html

CPU RDY is one of two metrics you want to be looking at.  Co-Stop % is another metric to consider when sizing as it will determine how often the scheduler is stopping a core on a VM so it doesn't drift too far from the other core.

That said, the recommendation I've given in the past is that Core Speed trumps number of cores.  As @Gerard Strouthsaid, a lot of Windows applications, and even Windows processes, are single-threaded and they benefit from having higher core speeds.  Having a lot of lower-speed cores doesn't do you a lot of good if they're all taking longer to complete tasks.

Ideally, you'd want to have at least 3 GHz per core base clock speed for Windows 10 or Windows 11 virtual desktops.   Note that is BASE clock speed.