This was the test I most eagerly anticipated because of the lack of information on the web regarding running a Xeon-based system at a reduced memory speed. Here I am at Cisco, the company that produces one of the only blades in the industry capable of supporting both the top bin E5-2690 processor and 24 DIMMs (HP and Dell can’t say the same), yet I didn’t know the performance impact for using all 24 DIMM slots. Sure, technically I could tell you that the E5-26xx memory bus runs at 1600MHz at two DIMMs per channel (16 DIMMs) and a slower speed at three DIMMs per channel (24 DIMMs), but how does a change in MHz on a memory bus affect the entire system? Keep reading to find out.
Speaking of memory, don’t forget that this blog is just one in a series of blogs covering VDI:
Join us for a free webinar on March 27 discussing this blog series. Register here.
The situation. As you can see in the 2-socket block diagram below, the E5-2600 family of processors has four memory channels and supports three DIMMs per channel. For a 2-socket blade, that’s 24 DIMMs. That’s a lot of DIMMs. If you populate either 8 or 16 DIMMs (1 or 2 DIMMs per channel), the memory bus runs at the full 1600MHz (when using the appropriately rated DIMMs). But when you add a third DIMM to each channel (for 24 DIMMs), the bus slows down. When we performed this testing, going from 16 to 24 DIMMs slowed the entire memory bus to 1066MHz, so that’s what you’ll see in the results. Cisco has since qualified running the memory bus at 1333MHz in UCSM maintenance releases 2.0(5a) and 2.1(1b), so running updated UCSM firmware should yield even better results than we saw in our testing.
As we’ve done in all of our tests, we looked at two different blades with two very different processors. Let’s start with the results for the E5-2665 processor. The following graph summarizes the results from four different test runs. Let’s focus on the blue lines. We tested 1vCPU virtual desktops with the memory bus running at 1600MHz (the solid blue line) and 1066MHz (the dotted blue line). The test at 1600MHz achieved greater density, but only 4% greater density. That is effectively negligible considering that the load is random in these tests. LoginVSI is designed to randomize the load.
Lockheed Martin has a vision for the cloud that delivers reliable and secure functionality, yet is developed to fit customer-specific business models. To do so seamlessly and as efficiently as possible, the IT provider turned to Cisco, Intel, NetApp, and VMware to integrate technologies to enable this vision.
Lockheed Martin’s solutions-as-a-service cloud approach is called SolaS™, and it is more than just a general service. Lockheed Martin takes the time to identify the objectives of the client’s mission and determine what the best innovation and solutions are that fit those objectives. With the FlexPod™ architecture, developed by the aforementioned technology partners, a solution can be rapidly deployed and then adjusted according to customer needs.
A four-step process to implementing SolaS ensures that each cloud model is developed according to differentiated customer purposes. You can read more about Lockheed Martin’s SolaS approach and how the service is delivered on the Unleashing IT website.
Coming up: Thought leaders from Cisco, Intel, NetApp, and Microsoft are coming together to explain how your business can gain a competitive advantage using FlexPod with Microsoft Private Cloud. They’ll share stories of others’ success by choosing the right technology and infrastructure to make the most of their private cloud environment. Join Cisco for this executive roundtable discussion on April 17, 2013.
In this week’s episode of Engineers Unplugged, Cisco’s Dominick Delfino (@domdelfino) and VCE’s Trey Layton (@treylayton) take on a number of announcements from VCE, and trending in the data center space. Roll the tape:
So, we wrapped up our day with the Networking Field Day crew last week with a free form discussion on where we go next with SDN. To be honest, the session did not go quite as I envisioned, but, in retrospect, I would not changed anything. As Ethan Banks (of PacketPushers fame) noted in Twitter, this session was more about shooting the unicorns than letting them run free. It seems that if we are going to convert our SDN unicorns into SDN plough horses, we are going to shed a little blood. At the end of the day, the market will be served by frank conversations—we need to move beyond painting SDN acolytes as starry-eyed and SDN detractors as being heretical and reactionary.
In the interest of keeping the conversation going, here are some of the things I walked away with after the conversation on Wednesday (in no particular order):
Is Hardware Innovation is Over?
This industry has always been one big pendulum and, currently, the pendulum is firmly in the software camp. Today, many of the truly interesting things in networking are going on with software. While most would agree we are at an inflection point with programmability, there are no clear directions for the evolution of SDN. Certainly there are pieces in place like OpenFlow and OpenStack, but OF 1.3 in unlikely to be the zenith of OF evolution let alone SDN evolution—current technologies will continue to mature and new ones will inevitably emerge. More importantly, the “how we do things” and “what do want to accomplish” of SDN will most certainly continue to evolve and as long as that is the case, software will rule because it’s simply easier and faster to experiment with software. But, once some clear directions begin to emerge, I guarantee you the action will swing back towards the hardware because doing things in hardware tends to be faster and more efficient. I could point to Cisco examples of this, but instead look at what Intel, the poster child for general purpose processors, has done with VT extensions to support virtualization or QuickSync for video transcoding.
Is OpenFlow Ready for PrimeTime?
One of the more contentious points yesterday is if OpenFlow is production ready. I think it’s a flawed “do these jeans make me e look fat” kind of question. There are certainly folks out there using OF to handle production traffic—for example, some of the cool things Brent Salisbury is doing. So, it’s not a binary question, but more a matter of assessing scope and scale. The better question to ask is what is the operational and performance envelope of OpenFlow and how does that match my needs, priorities, and capabilities. The risk with any emerging technology is that, often, the only way you find the edge of the envelope is once you’re on the other side, usually with colorful and memorable results. Regardless, I don’t see this question existing in another year or so.
If you missed our webcast on the upcoming Nexus 1000V release for Microsoft Hyper-V, you missed the announcement that we are now making available a beta version to the general public, as of March 6. (Note: Everyone asks, so, no, we haven’t announced the availability date for the GA version yet, but it’s coming soon). This should be great news for the large number of folks that we had to turn away that we couldn’t support in our earlier alpha and high-touch beta releases.
In the webcast, Damian Flynn, a 2012 Microsoft MVP for Data Center and Cloud, and IT Architect for Lionbridge Technologies in Ireland, who was one of the early beta-testers for the Nexus 1000V Hyper-V version, gave an outstanding overview of the Nexus 1000V in a Hyper-V and System Center environment. It’s worth listening to the webcast replay if you have the time. Damian had some really exciting things to say about his experiences. The webcast was admirably co-hosted by our own Appaji Malla, product manager for Nexus 1000V for Hyper-V.
The new beta version is available to anyone with a valid email address, and who provide their company name and contact address. Beta users must be willing to test the product and provide constructive feedback. Beta users are also encouraged to participate in the discussion forums and contribute to the Nexus 1000V beta community site.
As described in this week’s webcast (download the slides here; or watch the replay here), the beta process starts with an email to: beta-n1kv-hyperv@cisco.com. A link to a beta site will be sent in an email invitation (you must have a userID on Cisco.com to access this site). You will then be prompted to accept the beta agreement, and then get access to the beta code and documentation. Please use the available discussion forums for support, questions and feedback. Read More »
The new beta version is available to anyone with a valid email address, and who provide their company name and contact address. Beta users must be willing to test the product and provide constructive feedback. Beta users are also encouraged to participate in the discussion forums and contribute to the Nexus 1000V beta community site.