The Server Room Blog

How Would You Like Your Benchmark?

C_Peters — Wed, 16 Jul 2008 06:25:22 GMT

Today, I met with Tim Denney (a summer intern here at Intel) who is working for our performance analysis team. Tim told me that he had built a tool allowing intel employees to compare performance of certain SPEC published benchmarks (www.spec.org) across a variety of processors.

Tim demonstrated this analysis tool that searches all the integer and floating point publications on www.spec.org across a range of architectures (Intel, AMD, UltraSPARC, Power). You can input different processors and then the tool returns the published results available and a simple graphical display of the best published results for the processors chosen.

After meeting with Tim, I thought about the numerous "Ask an Expert" questions I’ve received on OpenPort in the last 6-9 months where people have asked me where and how they can compare performance across a variety of processors (dual core to quad core, different speeds, 1S to 2S to 4S, etc).

In took me about a nano-second to realize that your input would be really helpful in developing an improved user interface. So here is your chance. I encourage you to try this performance comparison tool and respond back with your ideas on how we can improve the tool and user interface. I can’t guarantee that we can implement every suggestion, however, I do guarantee that we will listen.

So … How would you like your benchmark?

Got That Virtual Feeling?

C_Peters — Tue, 08 Jul 2008 16:54:00 GMT

Working in High Tech means that most of us don't ever slow down - if we do, we risk falling behind. As a result, I usually find myself more more stressed than relaxed (just ask my peers or my wife).

So when I find good humor, I like to share. I found this video snippet about virtualization at www.talesofitutopia.com and it put a smile on my face. It is a little scarry that i can relate to more than one of the characters (the boss, the IT guy and even to some extent the JINX). Which character do you relate to?

Virtilization anyone?

Datacenter Fabric Convergence; FCoE Can Help

BenHacker — Thu, 19 Jun 2008 18:30:12 GMT

Ethernet has been around a long time. It is a highly reliable and trusted means for interconnecting computing nodes, and above that, it has generally been the most commoditize (read: lowest cost) form of interconnect for quite some time. Broad deployment, administrator trust, and low cost have kept Ethernet as the mainstream fabric for LAN traffic for a long time.

However, despite Ethernet's strong connectivity credentials, it still comes up short in certain applications. Ethernet is what is referred to as a ‘best effort' network. This simply means that in the real world, you will generally get pretty good performance (throughput, latency, lack of dropped packets, etc), but from time to time when there is congestion, packet drops and performance degradation can be quite a nuisance. For many applications, this doesn't matter. If you are using email, browsing the web, or transferring files to a shared drive, the only thing you will notice is a decrease in performance, but everything will still ‘work', and transfer properly. For some applications like storage though, this non-deterministic performance is unacceptable. If packets are dropped, or arrive out of order, storage applications have a nasty tendency to hang or crash.

Because of this limitation of the standard, there have been separate fabrics used for Storage Area Networks (SANs) for quite a while. One of the main fabrics developed and used for high performance SANs is known as Fiber Channel. In order to create a Fiber Channel network, a server and storage target need to support a Fiber Channel Host Bus Adapter (FC HBA) to communicate via the Fiber Channel protocol. In addition, the switches that connect the Fiber Channel infrastructure must also be dedicated Fiber Channel switches; a standard Ethernet router cannot be used.

Once in place, this SAN architecture provides a very high performance, high reliability network that is ideal (and required) for high end storage traffic, but it comes at a cost:

1) Fiber Channel HBAs are generally more expensive than their Ethernet counterparts.

2) You have to have a separate fabric in your network which also adds to your infrastructure (switch costs, and cabling costs) as well as complicates IT management.

3) Servers connected to the SAN now need to have an Ethernet adapter AND a Fiber Channel adapter.

The upside to the additional cost and complexity is of course better performance, but the question has always been "Is there a better way?"

I believe there is a better way, and that Fiber Channel over Ethernet (FCoE) (and importantly, the standards in IEEE that are making it possible) seems to be the logical path to solve the issue of performance on lossless performance on Ethernet, while maintaining Ethernets historical core cost advantages.

‘Best Effort' is not good enough:
The bottom line for today's Ethernet is that it simply can't provide the ‘lossless' behavior that storage traffic demands; but this fact is changing. Below I will summarize at a high level some of the standards being developed in IEEE to improve the performance of Ethernet for storage applications, and how they help to mend some of the issues with Ethernet and how that helps to enable FCoE.

Bandwidth Sharing, Priority Flow Control and Pause:
This capability offers a method to assign priorities to different Ethernet traffic classes. From there, when congestion becomes an issue, traffic can be ‘paused' on a per-priority basis; allowing the lower priority traffic to be halted temporarily while keeping the top priority traffic like storage running smoothly. This per-priority pause capability is really the first basic step in allowing Ethernet to provide some ‘QoS like' Layer 2 guarantees.

Congestion Notification (or Backward Congestion Notification):
In addition to simply pausing individual low priority streams of traffic, congestion notification allows for a communication method to go upstream from the node and notify the offending traffic generator to throttle back its traffic and re-route as necessary. This capability is a key to the longer term development of FCoE because with only the pause capability the congestion is really just pushed up a single node in the network. In order to support FCoE storage across multiple nodes in a network, congestion notification is needed.

Shortest Path Bridging:
This capability is really an optimization for inter-node routing that defines the path within the network between switches. Using traditional spanning tree path algorithms will sometimes result in paths in the network that are non-optimal and incompatible with high performance storage traffic. A new algorithm to determine the shortest path between nodes will help to enable both less congestion in the network as well as fast delivery of critical packets for storage.

DCB Capability Exchange Protocol (DCBX):
This capability goes by several different names depending on who you talk to, but essentially what it will provide is the ability for switches on the network to exchange their capability sets with other nodes of the network. This allows for each switch to understand what others switches near it can use the Congestion Notification, Flow Control, or other features need to support this ‘Lossless Ethernet' capability.

While the list above is not meant to be all inclusive of all the new IEEE development under way for this new ‘Lossless Ethernet' initiative, it should provide a good overview of the general push taking place and how the goal of getting to near lossless performance is going to be accomplished.

Weren't we talking about Fiber Channel?
Astute users will realize that I haven't really addressed the Fiber Channel piece of this. The above features I described only allow for Ethernet to carry certain kinds of traffic (like Fiber Channel) that require very high reliability and performance; but how do you get the Fiber Channel data onto an Ethernet frame?

In today's environment, a Fiber channel initiator on a Server system will place Fiber Channel data onto an FC HBA to send over the SAN to a storage target. All of this data is transmitted over a fiber channel network. Under the FCoE model, what you will need is a Server system that has an FCoE initiator, and on the target side, the switch connected to the target must be able to convert the data from storage target and encapsulate it into Ethernet. Beyond that, the data is transmitted over the Ethernet fabric as normal, but the features that I described above allow for the performance of Ethernet to allow a Fiber Channel application stack to function properly.

This is certainly a capability that Intel has been supportive of. Ethernet is a critical piece of the computing platform, and FCoE provides a potential improvement for datacenter and storage network design. By consolidating the Fiber Channel data onto a single Ethernet wire, end user IT houses can also see several benefits:

1) Reduced the need for two physical network cards in each server. Now, a single NIC will connect to the SAN and to the normal TCP/IP data network.

2) Along with the consolidation in network cards, you also save in terms of cabling. One 10 Gigabit link can replace the old Fiber Channel fiber link and Ethernet links.

3) Reduces power consumption and cooling

4) The commoditized and low cost nature of Ethernet provides additional benefit by converging system I/O onto what will likely be the lowest cost interface over the coming years; 10 Gigabit.

In summary, FCoE may be in its infancy, but the standards in final, or in process. Products are available today, and the value proposition in here. Further performance improvements and cost reductions and the proliferation of 10 Gigabit networks, as well as more choices in the future, will only further the support and interest in Fiber Channel over Ethernet in datacenter SAN applications.

~ Ben Hacker

Links for further information:
http://ieee802.org/
http://www.open-fcoe.org/

Why 45nm ... What's Next (part 2)

C_Peters — Wed, 11 Jun 2008 21:40:20 GMT

Last week, the first part this video series focused on the energy efficiency benefits of 45nm. The 2nd part of this video (below) is focused on the benefits of 45nm for virtualization and the intel processor roadmap including what's next in 45nm processor technology - the Dunnington and Nehalem-EP products

Is this information useful to you? why or why not?

Chris

Quad-Core ROI Calculator

C_Peters — Mon, 09 Jun 2008 17:18:06 GMT

Using some data from our own IT group, we developed a simple ROI calculator. This tool provides an estimate of performance and IT cost savings of refreshing older servers with new ones. Below is a screen shot of the calculator that is now available on our new server tools section of the Server Room. Give it a try and let us know if these assessment tools are helpful?

Why 45nm ... What's Next

C_Peters — Wed, 04 Jun 2008 19:58:52 GMT

Following a recent interview I conducted with the Register on a related subject, I was asked to talk more about Intel's current 45nm technology and our roadmap for new technology later this year. Join me in a two part video series where I discuss 45nm and beyond.

Part 1 (below) discusses the technology and benefits that 45nm xeon processors deliver for IT today.

Tune in next week to hear Part 2 - what we have planned for future enhancements to today's xeon products - the Nehalem Processor and Intel QuickPath architecture.

Chris

Big Servers are Back!

bryceolson — Wed, 28 May 2008 20:05:23 GMT

One trend that is really starting to take shape in the server industry is that big servers are back! That doesn't mean big servers ever disappeared off the map. Historically bigger servers with 4 or more processor sockets have been 7-8% of the server market from a volume perspective. And bigger servers have always been used for scalable, data-demanding enterprise applications which IT values for it's performance, headroom and reliability. What we're seeing now is a greater shift in popularity towards these servers as IT invests more and more in this direction.

So, why is that? Well, check out this video and then let me know if you agree or disagree. After you watch it I'd also be curious to learn more about what you value as the most important buying criteria when you go big.

Servers: Burden or Benefit?

C_Peters — Wed, 21 May 2008 14:42:33 GMT

Join me for a discussion with industry leaders and IT professionals on this topic on the ArsTechnica webforum.

There is a lot of proof supporting both sides of this question. Maybe ... Just maybe ... new server technology can help turn today's IT burden's into tomorrow's business benefit?

Share your opinion or Tell us your experience.

Virtualization - Who Cares?

S_Poulin — Wed, 14 May 2008 00:26:17 GMT

I have visited a number of customers recently. The discussions are usually straight forward where I provide them with a download of our current products, I tell them about things that we are doing in the future and along the way I ask them some questions about trends that they are seeing with their businesses. It will come as no surprise that enterprises are trying to keep up with their current requirements while also squeezing out increasingly flat or dwindling budgets to do something new. Many are turning to virtualization as a way to do more.

So who cares? CFO's care. I went out to visit a leading Fortune 500 company based on the West Coast of the US. Keep in mind I am planning to discuss our server platforms, why I believe they are leadership on performance and power and also all of the great new virtualization features we have recently introduced or will intro in the future. Before we get started they proudly walk me through their new datacenter and I stop in front of a rack that has two servers in it. Two 2U two processor servers. It is right next to another rack that has four servers in it. I inquire as to why both racks are only partially full and I receive a response that says one is owned by Finance, one is owned by a business unit. IT just manages them. You can look at this two ways. The glass half empty way would be that they are wasting an incredible amount of datacenter space and they are hopeless. The glass half full way would be that this is a great opportunity to really deliver value to this company's bottom line by first convincing them that physical consolidation (full up their racks) is important, then showing them a path toward application consolidation and finally sharing a vision of datacenter virtualization that includes compute, storage and networking. Their CFO will care.

IT employees care. One theme that seems to be coming through loud and clear is that people who drive some form of virtualization are usually considered as innovators or leading edge thinkers within their company. I have heard the term "IT Hero" to refer to someone who has delivered on a high ROI project, usually these days through the use of virtualization. I have met a number of IT folks at conferences and during visits and it is uncanny how many are trying to dig for more product information and how eager they are to hear about what new features we're putting into CPUs, chipsets, networking devices. A quick search of Youtube found this case study (here) that sums up the sorts of things I have heard.

It is also increasingly important that all of this stuff works well with the software, VMM and OS vendors product offerings. I know we are working closely with all of the ecosystem players because if we come out with an amazing new feature in our components it would be wasted if the VMM, OS or software didn't take advantage of it. There is some interesting banter here (here) about some of the pros and cons with virtualization. We are busy working on features that improve the performance and simplify the experience end users have when they virtualize. Why do you care about virtualization? What are you doing today that you couldn't do a year or two ago that has been made possible because of virtualization related technology?

Sun and Intel Announce Threading Building Blocks now Supported on Solaris, Sun Studio

whlea — Thu, 08 May 2008 17:06:24 GMT

As part of the Sun Microsystems and Intel alliance, the two companies have collaborated to bring open source Threading Building Blocks (TBB) support to the Solaris Operating System (OS) and Sun Studio software toolchain. Check out the SUN Blog for additional information. Click the video below for a short interview with Deepanker Bairagi, Principal Engineer for the Sun Studio.

Software parallelism can unleash the processing power that the newer multi-core architectures provide, including the Quad-Core Intel® Xeon® processors. For developers, multithreading offers a software parallelism model, but many existing solutions require a lot of low-level coding. Threading Building Blocks offers a rich approach to expressing parallelism in a C++ program by offering higher-level, task-based parallelism that abstracts platform details and threading mechanism for performance and scalability.

The Solaris OS is able to take advantage of multicore architectures, including the Intel Architecture, with features such as a lightweight processes (LWPs), load-balancing across cores, and processor affinities. Sun Studio software offers a complete integrated toolchain for Solaris and Linux platforms, including parallelizing compilers, performance and thread analysis tools, memory and code debuggers, NetBeans-based Integrated Development Environment, and more.

Combined with Threading Building Blocks, developers for the Solaris platform now have a fully loaded toolbox that simplifies the development of optimized multithreaded applications for multi-core Intel processors. Click here to learn more about Threading Building Blocks and optimizing performance for multi-core processors.

Would like to hear from the community on how you see this impacting the next generation of software development for Solaris running on Intel Architecture.

45nm and Beyond

C_Peters — Wed, 23 Apr 2008 15:45:18 GMT

Technology moves at such a rapid pace - it can often be mind-boggling. Even working directly with the product teams at Intel, I sometimes have difficulty keeping pace. The good news is that there is a tremendous opportunity today to be captured thanks to this rapid innovation, as well as a steady stream of advanced technology that IT can use to better support business and gain a competitive advantage. Recently I was interviewed by Tim Phillips from the Register about the current 45nm Quad-Core Intel Xeon products and the next generation Intel platforms based on the Nehalem processor.

A few years back, Intel fundamentally changed the way we design and develop our underlying micro-processor technology. We streamlined our innovation and accelerated it's pace. Internally, we call this new model Tick-Tock. I like to call it shrink and innovate.

A "Tick" is a manufacturing process shrink that delivers smaller silicon with higher speeds, more transistors and lower power consumption (example: moving from 65nm to 45nm process technology). The 45nm quad-core xeon processors (available since Nov '07) utilize unique materials (a high-k, dielectric) that are delivering industry leading performance / watt as measured by the industry's first and only standard benchmark, SPECPower

A "Tock" represents a more extensive architectural innovation (ex. Intel Core Microarchitecture) introducing new micro-architecture features and functionality fully utilizing the higher transistor count set up by the shrink. For Intel Xeon-based servers, the next "tock" is Nehalem. In addition to the new micro-architecture based on 45nm, a system re-design will incorporate next generation memory, I/O and virtualization technology for high performance, high bandwidth solutions compatible with today's leading software solutions

Listen to my podcast interview to learn more about the benefits of using today's products and the timing of next generation Intel technology featuring Nehalem. Is this information useful to you? If so ... how? Have any questions?

I'd be happy to hear from you. Chris

http://www.podtech.net/home/5105/45nm-and-beyond-with-christopher-peters

10 Gigabit Ethernet – Alphabet Soup Never Tasted So Good!

BenHacker — Wed, 26 Mar 2008 21:25:26 GMT

Sometimes you get so deep into something that you don't realize how crazy it is until you take a step back. Like most technology companies, Intel has an inherent love for acronyms. The cacophony of standards bodies, advanced technologies, and intense rates of change in our industry necessitates the use of abbreviation just to be able to communicate clearly and briefly. However, while I am at least as much of a techno-phyliac as most of the folks in the technology jungle, even I sometimes run into an acronym wall. I thought to help myself and others it might be a good idea to decode one of the newer sets of network technologies that I work closely with and to decipher some of the associated names and acronyms that come along with it.

10 Gigabit Ethernet: It's here, it's real, and it's growing fast.

Ethernet (IEEE 802.x) has evolved over the years from a new standard linking computers together at slow rates and has moved from 10 Megabit per second (Mbps), to 100Mbps, to 1 Gigabit per second (Gbps), and a few years ago to 10GbE unidirectional throughput. Over time there have been several physical connection types for Ethernet. The most common is copper (Cat 3/4/5/6/7 cabling is used as the physical medium) but Fiber has also been prevalent as well as some other more esoteric (such as BNC Coax) physical media types. The most common 10GbE adapter (until very recently) has been Optical only due the difficulty of making 10GbE function properly over copper cabling.

But this post isn't meant to discuss the past, but more to decode the present and future as it relates to 10Gig Ethernet and the variety of flavors that are available. Below I'll cover a number of acronyms for 10GbE IEEE standards that are often lumped together as '10 Gigabit' and discuss some of the differences and usages for each. After that, I'll also try to clear up some of the confusion about ‘form factor' standards for optical modules (which are separate from IEEE) and some of terms and technologies in that realm:

10GBase-T (aka: IEEE 802.3an):

This is a 10GbE standard for copper-based networking deployments. Networking silicon and adapters that follow this specification are designed to communicate over CAT6 (or 6a/7) copper cabling up to 100 meters in length. To enable this capability, a 10GbE MAC (media access controller) and a PHY (Physical Layer) designed for copper connections work in tandem.

10GBase-T is viewed as the holy grail for 10GbE because it will work within the most prevalent Cat 6/7 based infrastructure that is already in place. For this flexibility, 10GBase-T trades off higher power, and higher latency.

10Gbase-KX4 (aka: IEEE 802.3ap):

This is a pair of standards that are targeted toward the use of 10GbE silicon in backplane applications (such as a blade design). The specifically is designed for an environment where lower power is required and shorter distances (up to only 40 inches) are sufficient.

10GBase-SR (aka: IEEE 802.3ae):

This specification is for 10GbE with optical cabling over short ranges (SR = _S_hort _R_ange) with multi-mode fiber. Depending on the kinds of fiber, SR in this instance can mean anything between 26 - 82 meters on older fiber (50-62um fiber). On the latest fiber technology, SR can reach distances of 300m. To be able to physically support a connection of the cable, any network silicon or adapter that support 10GBase-SR would need to have a 10GbE MAC connected to an Optics module designed for multi-mode fiber. (We'll discuss optics modules in more depth further down in this post.)

10GBase-SR is often the standard of choice to use inside the datacenters where fiber is already deployed and widely used.

10GBase-LR (aka: IEEE 802.3ae, Clause 49):

LR is very similar to the SR specification except that it is for _L_ong _R_ange connections over single-mode fiber. Long Range in this spec is defined as 10km, but distances above that (as much as 25km) can often be obtained.

10GBase-LR is used sparsely and really only deployed where ultra long distances are absolutely required.

10GBase-LRM (aka: IEEE 802.3aq):

LRM stands for _L_ong _R_ange over _M_ultimode and allows distances of up to 220 meters on older standard (50-62um) multi-mode fiber.

10GBase-LRM is targeted for those customers who have older fiber already in place but need extra reach for their network.

10GBase-CX4 (aka: IEEE 802.3ak):

This standard of 10GbE connection uses the CX4 connector/cabling that is used in Inifinband^TM^* networks. CX4 is a lower power standard that can be supported without a standalone PHY or optics module (the signals can be routed directly from a CX4 capable 10GbE MAC to the CX4 connector). Due to the physical specification for CX4 based 10 Gigabit, it provides a lower latency than comparable 10GBase-T copper PHY solutions. With the use of CX4 passive (copper) cables, the nominal distance you can expect between your 10GbE links is ~10-15m. There are also amplified 'active' (but still copper) cables with nominal distances up near 30m.

Below is an image of a standard CX4 based socket that would be on a 10GBase-CX4 NIC:

There are also what referred to as ‘active optical' cables are for CX4, which actually have an optics module in the termination of the cable, and the cable body is fiber. This kind of active design increases cable reach and improves flexibility (fiber is smaller than copper pairs) but also increases cost. These active cables can increase reach up to 100m.

Intel has recently released our own series of active optical CX4 cables.

For short distances (such as inside the rack in a datacenter), CX4 offers one of the lowest cost ways to deploy 10GbE from switch to server. Because of its design, CX4 also achieves very low latencies as well.

</end of IEEE standards ramble>

Ok, so we've summarized the majority of the IEEE 10GbE standards. But the immediate question arises: "Why are there so many?" Is the IEEE standards body for 10GbE just throwing out all these standards for every possible niche application? The answer is no. For any new standard IEEE phy interface standard to be approved, it must pass on several criteria including "distinct identity" and "broad market potential". While all of these standards certainly won't apply to any given institution's network, they all do all meet real market needs.

X2, XFP, SFP+... say what?

A final mystery that I've alluded to above has to do with the various optical module form factors that are available for 10GbE. XENPAK, X2, XPAK, XFP and SFP+ are standard optics module form factors that are used by both switch and NIC vendors in the industry. These modules that go along with the 10GbE networking products are an interesting beast. They are not specified by IEEE, but are standardized by a group of industry participants through what is known as a Multi-Source Agreement (MSA).

XENPAK, XPAK and X2 are the older module standards originally used for 1GbE, followed by XFP which shrunk the form factor of the actual module as well as the fiber cable pairs. SFP+ is a newer form factor that is now gaining momentum with switch and NIC vendors. An SFP+ optics module can use the same fiber pairs used with XFP (no new fiber cable needed), but the form factor of the cage in the switch or NIC as well as the optics module itself are smaller. The key advantage of using SFP+ is the new form factor can drive lower costs, lower thermals, and higher densities at the switch.

Here is an image of an older X2 optics module:

And here is a comparison of the size of XFP (right) relative to SFP+ (left):

The optics modules are driven by a low power interface from the 10GbE MAC. The interfaces are XAUI (for X2 modules), XFI (for XFP modules), and SFI (for SFP+ modules). These interfaces generally are supplied directly from the 10GbE based MAC to the module cage. One of the things the module MSA standards bodies agree on is not only a form factor for the module itself but also the electrical specifications of the driver interface that can be accepted from the MAC.

The key thing I want to hammer home here is that IEEE specification (such as 10GBase-SR) is separate from the module form factor used.

For example, you can have a Short Range optical NIC that uses X2, XFP, or SFP+. So asking for an "SFP+ NIC" isn't actually specific enough, because that could mean a lot of different things. You'd have to specify a 10GBase-SR NIC, with SFP+ optics.

SFP+Direct Attach:

Now that I've thoroughly confused everyone, I'll take it one step further. Not only can each module form factor be used with different IEEE MAC specifications, but each module doesn't even need to be used for a fiber connection at all. An interesting example of using an ‘optics' module form factor for a non-optical design is SFP+Direct Attach.

SFP+DA is similar in concept to CX4 but provides a bit more flexibility. Normally, you may have a switch or NIC that is designed to be able to support the addition of SFP+ based optics modules for a 10GbE fiber connection. Direct Attach allows for passive Twin-Axial (2 pair copper) cables to be plugged directly into the SFP+ cage (in place of an optical module) to carry the serial signal from the MAC directly over the cable to another SFP+ form factor enabled NIC or switch.

Again, the downside is that without either a standalone PHY, or optics module to send the signal over a long distance, a passive cable with SFP+DA has a reach in the ~10-15m range. The real advantage for SPF+DA over CX4 is that on the switch side the SFP+ module design allows higher density switches than CX4 can provide.

For a top of the rack switch, SFP+DA will likely provide excellent cost, power and latency characteristic and still have enough reach to be very feasible inside the rack.

10GbE - The Infrastructure is Ready!

I hope that I've lifted a little bit of the fog that surrounds the 10GbE market and the related technologies. The last thing I want to leave you with is the fact that 10GbE infrastructure is now starting to roll into the mainstream. CX4 switches are available broadly in the market today and SFP+ type designs for both optical modules as well as Direct Attach connections have been demonstrated and will be getting rolled out very soon by various vendors.

Intel is already selling a wide variety of NICs and silicon to meet the various form factors and standards based market needs I listed above along with other vendors in the market place.

After years of anticipation, 10GbE is finally hitting its stride. Next stop... 10_0_GbE...

50W Quad-Core: How would you use them?

C_Peters — Tue, 25 Mar 2008 18:09:14 GMT

Today, Intel launched 50W low power versions of the 45nm Quad-Core Xeon processors (the L5400 series).
The 2 new SKUs are listed below:

Quad-Core Xeon L5420 2.50 GHz, 12MB L2, 1333MHz
Quad-Core Xeon L5410 2.33 GHz, 12MB L2, 1333MHz

These products offer IT and business users 2 primary benefits:

45nm 50W quad-core brings 25% improved performance over previous generation 65nm 50W quad-core processors
They also run 30W cooler than mainstream 80W quad-core processors delivering the same performance at the same frequency.

We have seen strong interest for these 50W quad-core products and I'd like to hear from you on where you would use low power quad-core and why?

Which Xeon is right for me?

C_Peters — Sat, 08 Mar 2008 07:01:36 GMT

I recently found this simple animation that breaks down the Xeon processor family into bite-sized chunks and explains which Xeon-based servers are best suited to meet common IT and business needs.

I shared it last week when traveling with customers in Taiwan and it was well received.

What do you think of this video?

I/O Bottlenecks due to Virtualization? VMDq to the Rescue!

BenHacker — Fri, 29 Feb 2008 17:59:02 GMT

Virtualization is without a doubt a very hot topic these days. Companies continue to look to server virtualization to increase the utilization rates of their systems and lower overall deployment and management costs. The basic model of a virtualized server is depicted below:

Essentially, you have a VMM (Virtual Machine Monitor) SW layer that talks between hardware and software and allows each virtual machine to successfully use what it thinks is one network port. This is a pretty straightforward model and it directly addresses the general reason for virtualization which is that generally the server may not be utilizing its processing power in full and is thus wasting CPU cycles.

There is an interesting result of this consolidation onto a single physical box with several Virtual Machines. In addition to consolidating CPU processes, you also effectively consolidate I/O bandwidth and switch processing capabilities onto the same platform. The overhead of this switching limits your bandwidth, adds CPU overhead, and effectively reduces the benefits of server virtualization. In some cases you may have a new problem in having created an I/O bottleneck.

This makes a lot of sense if you think about the fact that in essence, what you are doing is merging 5-10 machines that each had 1 or 2 ports of Gigabit Ethernet (all connected via a switch) into a single machine. This new server probably needs to have at least 6 ports or more of Gigabit Ethernet and may even require 10 Gigabit connections just to be able to support the new consolidated workload.

Enter Virtual Machine Device Queues (VMDq):

In order to help the I/O congestion associated with the additional VMM software switching in a virtualized environment, Intel implemented a technology called VMDq in our latest Ethernet NICs and silicon. VMDq is a technology specifically designed to offload some of the switching that was done in the VMM to networking hardware specifically designed for this function. This drastically reduces the overhead associated with I/O switching in the VMM which greatly improves throughput and overall system performance.

Below is a diagram that summarizes the new virtualized server stack with VMDq enabled:

On the receive path, VMDq provides a hardware ‘sorter' or classifier that essentially does the pre-work for the VMM of directing which end VM the packets should go to. The NIC or LAN silicon is performing a hardware assist for the VMM layer.

On the transmit side, the packets are serviced round robin style to avoid "head of line" blocking and alleviate potential quality of service (QoS) issues.

The immediate question I expect is "So, don't the VMM vendors have to support this?" And the answer is yes. Intel is supporting this feature today on shipping platforms, but you do need to work closely with the VMM vendor to make sure the whole stack works as designed.

Just this week Intel announced that our VMDq capability will be supported in VMware's upcoming ESX release. This is certainly a big step towards wide support of network virtualization performance enhancing features.

Ethernet technology has grown and become more important over the last 25 years, and the trend appears to be continuing on course.

Ben Hacker

For more details on VMDq, there is a VMDq Whitepaper, and an Intel® VT for Connectivity Datasheet located on our website.