VDI “The Missing Questions” #1: Core Count vs. Core Speed

Choosing the right compute platform for your VDI environment requires both science and art. You have to balance CPU and memory characteristics against your expected workload profile and your desired density. At the end of the day, VDI has to meet some cost criteria in order to go from a fun science project to a funded program in your company. That means you can’t just throw the top bin CPU at the problem; you have to pick the right CPU. This is further complicated by the fact that there is not one CPU that is ideal for all VDI workloads. There is no magical bill of materials at the end of this series of blogs, but we will attempt to make your VDI decisions based more on science than art.

Strength in numbers? Or strength in speed? As Tony said in his introduction, we had several involved questions related to VDI that we honestly couldn’t answer… so we decided to start testing. This will be a series of blogs that attempts to answer practical questions like “when is processor A better than processor B?” And of course you then have to ask “when is processor B better than processer A?” In this first installment in the series, I will tackle the question of whether the number of cores or the core speed is more important when the goal is to achieve the best desktop density per host. Here is a handy guide to the other posts in this series:

The usual suspects. Throughout this series, we will focus on two processors. We picked them because they are popular and cost effective, yet quite different from each other. They are not top bin processors. Take a look at the table below for a comparison.

Note: Prices in this table are recommended prices published by Intel at http://ark.intel.com and may vary from actual prices you pay for each processor. The SPEC performance numbers are an average of SPEC results published by many OEMs (at http://www.spec.org/) across many platforms. These are not Cisco-specific SPEC numbers.

It’s good to be dense. If we cared more about maximum desktop performance and less about density, we might reach a different conclusion. Stay tuned and you will see this answered in a future blog. For now, let’s get back to density. A virtual desktop can only run as fast as the core on which it is running. Even if you run a single vCPU virtual machine on a server with 40 cores, that vCPU can only run as fast as the core on which it is running. That statement seems to favor the E5-2643 which has a clock speed roughly 37% faster than the E5-2665.

Not so fast! We tested servers with both processors with 1vCPU virtual machines and graphed the results below. To refresh your memory on the test methodology and the meaning of VSImax, refer back to Tony’s introduction. The graph shows latency on the Y axis and number of desktops on the X axis. As we increased the number of virtual machines (virtual desktops) per host, we found that latency as reported by LoginVSI was comparable up to around 40 or 50 desktops (we will analyze this part of the curve in more detail in a later post). At that point, the two curves began to diverge sharply. The E5-2643 based host exceeded VSImax at 81 virtual desktops while the E5-2665 based host had a very linear response to increased density past 100 virtual desktops. The E5-2665 based host did not exceed VSImax until 130 virtual desktops – 60% better density than the E5-2643 based system! This result strongly suggests that core count has a much greater impact on virtual desktop density than CPU speed.

What about 2vCPU virtual desktops? We tested that, too, since a fair number of our customer projects involve some number of users (an overwhelming minority) who require or who demand 2 vCPUs. Both systems obviously hit VSImax at a much lower density when each virtual desktop was allocated 2 vCPUs. You might expect to achieve half the density, but it was actually much better than that. In fact, the E5-2643 based system exceeded VSImax at 54 desktops while the E5-2665 based system exceeded VSImax at 93 desktops (72% more desktops than the E5-2643 based system). This result also strongly suggests that core count has a much greater impact on virtual desktop density than CPU speed.

The graphs show systems running at a full 1600MHz memory bus speed. For completeness, we ran the same tests at a slower 1066MHz memory bus speed and found the same trend at the lower bus speed: the system with more cores achieved significantly better density. The table below summarizes the results.

Answer: Core count is king – whether you are building 1vCPU or 2vCPU virtual desktops at maximum or minimum memory bus speed. CPU core speed certainly has some impact on density (that’s the “art” talking at this point), but the graphs show that core count drove greater virtual desktop density even at a lower clock speed (that’s the “science” talking).

Choosing the right compute platform for your VDI environment involves both science and art. The science shows that you should steer towards higher core count processors. That does not mean you should steer toward the E7 processors. At 10 cores per processor, the E7 based systems will certainly achieve greater density than E5 based systems, but that increased density comes at a cost that will probably stall your VDI program. At this point in the processor roadmap, look at E5 processors for the best performance-per-dollar, and look at higher core count E5 processors for the best density-per-dollar.

What’s next? Remember that this is just the first blog in a series focused on VDI. The next installment in the series will be written by Shawn Kaiser and will dive even deeper into CPU core speed. You can read it here.

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.