Main | February 2008 »

January 2008

January 31, 2008

Virtualization and iSCSI simplify IT

Yesterday Dell completed its acquisition of Equal Logic, together with a quote from Michael Dell:

Virtualization and iSCSI are two keys to simplifying IT. Enterprises are creating data and consuming power at an exponential rate, driving up IT cost and complexity.

When you combine this with Dell's Veso announcement at the '07 VMworld, a picture of ubiquitous virtualization combined with simple easy to use (commoditized) iSCSI emerges. This environment is something that Solarflare has been actively supporting - our SFC4000 10GBASE-T controller has been designed specifically to support iSCSI within a virtualized environment. For some more details, see our see our  presentation  at the Xen Nov 07 summit.

-- Thanks to Robert Stonehouse

January 30, 2008

QoS and latency

Latency is the time taken for a message to travel from its source to its destination, including all overheads. In  networking terms, this would be: sender overhead + time of flight + transmission time + receiver overhead. 

Reported latencies are usually generated using a half round-trip measurement. Here the total elapsed time to send a small message back and forth between two endpoints is measured. The result is averaged over the number of iterations and divided by 2. Half round-trip latency is important where application performance depends on small message exchange particularly in the parallel compute arena.

However other applications such as streaming media and stock-update processing performed within the financial services community depend rather more critically on the performance of processing streams of messages. For these applications, one-way latency is a rather more useful measurement. Here the total elapsed time to transfer a large number of messages from a sender to a receiver is measured and averaged over the total number of messages.

At a glance, the reader might think that one-way latency and half round-trip latency should be equal. However this is not so because the system overheads will be very different when processing streams of messages compared with a single message. It's therefore a shame that one-way latency is often not reported in discussions of interconnect performance.

Recently latency has been used synonymously  with the other attributes (by my definition) of QoS, namely jitter and bandwidth. For example, as data sets have grown, the performance of some applications have increasingly become bottlenecked by the time taken to transfer this data back and forth. This time is actually dominated by bandwidth, but the problem is often reported as data latency.

Similarly, jitter (which is a measure of the variance of message transfer times) has been termed application latency.  A good example of an application where jitter is a critical metric would be the stock ticker feed. Put simply, any human perceivable jitter in the feed will cause traders to lose confidence in their information source and must be prevented at all cost.

The low-jitter property (rather than low-latency) of interconnects such as Infiniband is one of the main reasons that they have gained momentum in the financial services community. But ironically much of this jitter has been caused by OS interactions, particularly between the scheduler and the network stack. Recent work in this area has done much to reduce these issues and it is now possible to achieve low-jitter operation using classic Ethernet networks.

January 28, 2008

One small step for functional programming

If you've ever been exposed to functional programming and been struck by the power and simplicity of expression which is possible, then you'll be pleased to know that Microsoft Research has been active in this area for some time now with the F# language (pronounced FSharp).

The real beauty of the language is that the runtime has been integrated with the .NET framework. This means that building GUIs and other features such as distributed communication into an application with a functional core is now very easy.

It's down-loadable from here , is clean to install and comes with a nice set of sample programs - including a client/server socket program and a symbolic differentiator with graphical output.

I'd love to see the day that the language is included in Visual Studio

January 25, 2008

10GBASE-T power tradeoffs

This article was written in early 2007 and published by in Jan 2008. It predicted that the constraints of the 10GBASE-T PHY power requirements would mean that 2007 products would be restricted to single port 10GBASE-T NICs based around a low power controller architecture. This prediction has been born out - to date the only available 10GBASE-T NIC as product (not marketing hype) is the SMC10GPCIe-10BT.  The paper goes on to predict that the only  dual port 10GBASE-T NICs available in  2008 will also be based around low power controller architectures. We'll see about that one,  but a pattern emerges which isn't going to go away  until at least the 45nm process node in that significant care needs to be taken to balance the power requirements of both the PHY and the controller in order that major product intersections are not missed.

An interesting  corollary to these architectural challenges  has been the  deployment  of creative marketing to report the max power consumption of controller silicon.  Largely  this is reported  for a controller powered on,  but not  transferring  Ethernet frames. Given that  modern CPUs  employ  power  scaling features it should  be unsurprising that  this measurement is  much lower than for a CPU based network controller  under load.  My personal measurements show that >50% increases in power consumption  are not uncommon once  packets start to flow!

Some useful links on this topic include:

Rick Merritt's Blog (Jan 2008)

The Register (Feb 2007)

SMC8724-10BT (24 Port 10GBASE-T switch)

SMC 10GPCIe-10BT (10GBASE-T Server Adaptor Card)

 

10Gb/s Ethernet with commodity hardware

I'm still frequently asked whether 10Gb/s Ethernet is possible for everyday applications using commodity hardware.  The short answer is that it is. We published a paper in 2006 (which appeared as an editorial in the April 2007 ACM CCR)

Download ACM_CCR_ETHERNET_RETROSPECTIVE.PDF

Which showed commodity servers available on the street in mid-2006 hitting 10Gb/s performance with relative ease. Unsurprisingly, the situation has only got better since then and frankly todays servers are so IO bound at 1Gb/s that a wholesale shift to 10Gb/s is imminent.

Incidentally for those interested in a bit of history, the paper also presents a retrospective of the evolution of network interface architecture from programmed IO devices on the early workstations of the '80s to  modern devices sprouting vast numbers (of often irrelevant) hardware offloads.