Cisco Blogs

# VDI “The Missing Questions” #4: How much SPECint is enough

In the first few posts in this series, we have hopefully shown that not all cores are created equal and that not all GHz are created equal. This generates challenges when comparing two CPUs within a processor family and even greater challenges when comparing CPUs from different processor families. If you read a blog or a study that showed 175 desktops on a blade with dual E7-2870 processor, how many desktops can you expect from the E7-2803 processor? Or an E5 processor? Our assertion is that SPECint is a reasonable metric for predicting VDI density, and in this blog I intend to show you how much SPECint is enough [for the workload we tested].

You are here. As a quick recap, this is a series of blogs covering the topic of VDI, and here are the posts in this series:

Addition and subtraction versus multiplication and division. Shawn already explained the concept of SPEC in question 2, so I won’t repeat it. You’ve probably noticed that Shawn talked about “blended” SPEC whereas I’m covering SPECint (integer). As it turns out, the majority of task workers really exercise the integer portion of a processor rather than the floating point portion of a processor. Therefore, I’ll focus on SPECint in this post. If you know more about your users’ workload, you can skew your emphasis more or less towards SPECint or SPECfp and create your own blend.

The method to the madness. Let me take you on a short mathematical journey using the figure below. Starting at the top, we know each E5-2665 processor has a SPECint of 305. It doesn’t matter how many cores it has or how fast those cores are clocked. It has a SPECint score of 305 (as compared to 187.5 for the E5-2643 processor). Continuing down the figure below, each blade we tested had two processors, so the E5-2665 based blade has a SPECint of 2 x 305… or 610. The E5-2665 blade has a much higher SPECint of 610 than the E5-2643 blade with just 375. And it produced many more desktops as you can see from the graph embedded in the figure (the graph should look familiar to you from the first “question” in this series).

And now comes the simple math to get the SPECint requirement for each virtual desktop in each test system:

# Judge for yourself: Taking Dell to task on “holistic” security claims

In case you missed it, Network World’s Ellen Messmer published a rather surprising article on how Dell was going to “trump” Cisco in the information security market as a result of some recent acquisitions. Now certainly Dell is entitled to their beliefs. They’re in a difficult position right now, as Michael Dell and Silver Lake maneuver the company through a very complex set of buy-out related transactions. They need to give their customers assurance that they won’t be distracted through this process. And if you want to set a big impression with your customers, you might as well go after the market leader in security.  Be it as it may, we can’t just sit back and let these blatant statements go unchecked. So, in the spirit of “fair and balanced” reporting, we thought we’d issue our own little fact check and let you conclude for yourself.

• “Cisco is a great competitor but they don’t have our holistic view” – Acquiring assets and bundling them together doesn’t constitute a “holistic” approach.  Those assets must be closely integrated, which is the approach Cisco is delivering with its next generation security architecture. This architecture will be built on top of a multi-function security platform with deep network integration. There are many proof points today that demonstrate we are delivering against this strategy and architecture. Today our customers are deploying Cloud Web Security with their Cisco ISR G2 and ASA Next Generation Firewall through connectors built from Cloud Web Security. In addition we’ve brought market leading application, visibility and control to ASA, embedded deep in the firewall.  But it doesn’t stop here.
• Now what about Dell’s comment that Cisco “doesn’t have an identity business“?  Cisco’s Identity Services Engine provides the backbone of Cisco’s secure Unified Access solution. The real network security action is in delivering access privileges based on more than just user identity and group which is all Dell can do today with Quest. In the BYOD world customers also require action based on the type of device, posture of the device, and location. Cisco’s Identity Services Engine is the industry leading platform to deliver context based policy controls and then leveraging the network for distributed enforcement consistently across wired, wireless, and VPN access. This is a game-changer for the enterprise and our next generation end-to-end security architecture. Enterprises can now implement context-based policy from the access layer through the data center switching fabric without using brittle and costly network segmentation methods tied to VLANs and ACLs. This is real synergy, and it is delivering a holistic solution as opposed to a holistic press sound bite.  But don’t just take our word for it; check out Gartner’s latest Magic Quadrant for NAC.  Cisco’s ISE combines identity, device, and network with a market leading platform deployed in over 3000 customers.
• Just weeks ago we announced another key milestone with the introduction of ISE 1.2.  With this latest release we also became the first vendor in the industry to offer automated profiling feeds making us better and faster at identifying new devices and operating systems.  We’ve increased the speed and scalability of ISE to address the increasing demands brought on by the “Internet of Everything”.  And we’ve added a new set of partner APIs enabling integration into key MDM partners – SAP, AirWatch, Citrix, Mobile Iron and Good.  This expands the reach of ISE and enables customers to drive common context and identity management from the network all the way to the end point.  Dell talk’s about their direction to advance the “concept” of embedded security to virtually any type of device.  We’re not just talking about it, we’re doing it. Read More »

# Cisco and Citrix Join Forces to Bring New Mobile Device Management Services to Market

Employees, and many business, want to allow personal devices to be used at work, and potentially for work. However, balancing that with corporate policies for information security, clear rights-of-use, liability, and then bounding it within an acceptable IT cost structure is no small feat. Cisco joined forces with leading MDM vendors to link together a solution that starts at day zero – when an employee first buys a new device and tries to use it at work. It includes self-service onboarding to the network, offering a choice of using a device as a guest or work asset, and forced enrollment in (and compliance with) MDM when business policy must be enforced.

Citrix recently acquired Zenprise to add top-tier MDM to their mobile workspace and application management solution. The good news is Zenprise is an early MDM partner with Cisco, and Citrix inherits the integration work. The tight linkage of Cisco’s Unified Access Solution, and the Cisco Identity Services Engine, to what is now Citrix XenMobile MDM, is a powerful combination for customers to deploy since it brings quite a bit more to the table than standalone MDM.

# VDI “The Missing Questions” #3: Realistic Virtual Desktop Limits

So this is the Million Dollar Question, right? You, along with the executives sponsoring your particular VDI project wanna know: How many desktops can I run on that blade? It’s funny how such an “it depends” question becomes a benchmark for various vendors blades, including said vendor here.

Well, for the purpose of this discussion series, the goal here is not to reach some maximum number by spending hours in the lab tweaking various knobs and dials of the underlying infrastructure. The goal of this overall series is to see what happens to the number of sessions as we change various aspects of the compute: CPU Speed/Cores, Memory Speed and capacity. Our series posts are as follows:

But for the purpose of this question, let’s look simply at the scaling numbers at the appropriate amount of RAM for the the VDI count we will achieve (e.g. no memory overcommit) and maximum allowed memory speed (1600MHz).

As Doron already revealed in question 1, we did find some maximum numbers in our test environment. Other than the customized Cisco ESX build on the hosts, and tuning our Windows 7 template per VMware’s View Optimization Guide for Windows 7, the VMware View 5.1.1 environment was a fairly default build out designed for simplicity of testing, not massive scale. We kept unlogged VMs in reserve like you would in the real world to facilitate the ability for users to login in quickly…yes that may affect some theoretical maximum number you could get out of the system, but again…not the goal.

And the overall test results look a little something like this:

 E5-2643 Virtual Desktops E5-2665 Virtual Desktops 1vCPU, 1600MHz 81 130 2vCPU, 1600MHz 54 93

As explained in Question 1, cores really do matter…but even then, surprisingly the two CPUs are neck and neck in the race until around 40 VM mark. Then the 2 vCPU desktops on the quad core CPU really take a turn for the worse:

Why?

Co-scheduling!

When a VM has two (or more) vCPUs, the hypervisor must find two (or more) physical cores to plant the VM on for execution within a fairly strict timeframe to keep that VM’s multiple vCPUs in sync.

MULTIPLE vCPU VMS ARE NOT FREE!

Multiple vCPUs create a constraint that takes time for the hypervisor to sort out every time it makes a scheduling decision, not to mention you simply have more cores allocated for hypervisor to schedule for the same number of sessions: DOUBLE that of the one vCPU VM. Only way to fix this issue is with more cores.

That said: the 2 vCPU VMs continue to scale consistently on the E5-2665 with its double core count to the E5-2643. At around the 85 session mark, the even the E5-2665 can no longer provide a consistent experience with 2vCPU VDI sessions running. I’ll stop here and jump off that soap box…we’ll dig more into the multiple vCPU virtual desktop configuration in a later question (hint hint hint)…

Now let’s take a look at the more traditional VDI desktop: the 1 vCPU VM:

With the quad-core E5-2643, performance holds strong until around the 60 session mark, then latency quickly builds as the 4000ms threshold is hit at 81 sessions. But look at the trooper that the E5-2665 is though! Follow its 1 vCPU scaling line in the chart and all those cores show a very consistent latency line up to around the 100 session mark, where then it becomes somewhat less consistent to the 4000ms VSImax of 130. 130 responsive systems on a single server! I remember when it was awesome to get 15 or so systems going on a dual socket box 10 or so years ago, and we are at 10x the quantity today!

Let’s say you want to impose harsher limits to your environment. You’ve got a pool of users that are a bit more sensitive to response time than others (like your executive sponsors!). 4000ms response time may be too much and you want to halve that to 2000ms. According to our test scenario, the E5-2665 can STILL sustain around 100 sessions before the scaling becomes a bit more erratic in this workload simulation.

Logic would suggest half the response time may mean half the sessions, but that simply isn’t the case as shown here. We reach Point of Chaos (POC!) where there is very inconsistent response times and behaviors as we continue to add sessions. In other words: It does not take many more desktop sessions in a well running environment that is close to the “compute cliff” before the latency doubles and your end users are not happy. But on the plus side, and assuming storage I/O latency isn’t an issue, our testing shows that you do not need to drop that many sessions from each individual server in your cluster to rapidly recover session response time as well.

So in conclusion, the E5-2643, with its high clock speed and lower core count, is best suited for smaller deployments of less than 80 desktops per blade. The E5-2665, with its moderate clock speed and higher core count, is best suited for larger deployments of greater than 100 desktops per blade.

Next up…what is the minimum amount of normalized CPU SPEC does a virtual desktop need?

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