Who is fastest switch in the west?

[#1]

So why settle for microseconds when you can have nanoseconds?

The more work you can get done in each second, the more productive you are—especially if you are in the financial services or high-performance computing industries.  Switches that deliver transactions in terms of nanoseconds are 10 times more productive than their microsecond counterparts.

If speed in nanoseconds is the goal, how do you find the fastest switch in this category?  There are several dimensions that should be taken into consideration:  latency, jitter, and multicast. 

Latency considerations include packet size and throughput.  How fast can a switch transmit each packet size at wire speed and not drop anything?  To really understand how a switch behaves under stress, you need to test all ports at the same time using 100% unicast traffic throughput in a fully meshed pattern using RFC 2544 and RFC 1242 (for cut through switches).

It is very easy to go fast on the freeway when there are no other cars.  So you need to look at how fast a switch transmits at wire speed through all ports with full traffic load.  Anything less than less than 100% line rate traffic and full mesh to all ports is wimpy.

Jitter is about consistency of behavior and the amount of deviation between the slowest and fastest times for any one packet size.  Since switches transmit traffic constantly, you need to see what the variation is across a wide sample of transmissions.  If you get a big spread between your slowest and fastest packets, you have high jitter.  This is not good for applications like video or transaction processing where consistent rate of traffic is required for the applications to perform correctly.

Multicast has two dimensions – the number of groups that can function at any one point in time and the speed at which a port can join a session.  What matters here is the speed and throughput of the multicast packets.  This is measured by RFC 3918.  What you want to see is if the unicast latency and the multicast latency are different. (Unicast latency will be the lowest)  Multicast latency will affect anything that has to do with one-to-many traffic patterns, such as broadcast video and financial trading systems.  If multicast packets are slower, get dropped or have high jitter, they affect application performance adversely.

After all, it’s easy to go fast on the freeway when there are no other cars.  So you need to look at how fast a switch transmits at wire speed through all ports with a full traffic load.  Anything less than 100% line-rate traffic and full mesh to all ports is not a true test.

Jitter is about consistency of behavior and the amount of deviation between the slowest and fastest times for any one packet size.  Since switches transmit traffic constantly, you need to see what the variation is across a wide sample of transmissions.  If you get a big spread between your slowest and fastest packets, you have high jitter.  This is not good for applications like video or transaction processing, where consistent traffic rates are required for the applications to perform correctly.

Multicast has two dimensions: the number of groups that can function at any one point in time; and the speed at which a port can join a session.  What matters here is the speed and throughput of the multicast packets, which is measured by RFC 3918.  What you want to determine is whether the unicast latency and the multicast latency are different (unicast latency will be the lowest).  Multicast latency will affect anything that has to do with one-to-many traffic patterns, such as broadcast video and financial trading systems.  If multicast packets are slower, if they get dropped or if they have high jitter, they affect application performance adversely.

So how does the new Juniper QFX3500 Switch measure up as a low-latency switch?  Let’s look at two different third-party reports, one from Network Test that features RFC test results and a STAC Highlights report that shows how a switch performs in a simulated financial services environment under extreme load.  This is a proxy for how a combination of switch, NIC, middleware and servers deliver financial transactions.

Let’s look for nanoseconds for both unicast and multicast performance.  In Figure 2 of the Network Test report, we see that the average latency for L2 unicast packets never exceeds 920 nanoseconds, and that was with wire-speed traffic.  How about multicast?  In Figure 5, we see a comparison between unicast and multicast latency, and there is no difference between the two—they are both under 1 microsecond.

What happens when a nanosecond switch meets a high-performance NIC, a server and some middleware?  Very fast transactions.  If we look at the graph on page 7 of the STAC report, we see a summary of key metrics.  The mean and average latencies for the transaction of 1 producer to 5 consumers was 9 microseconds with a 99% of 11 microseconds.  Other available STAC reports show these numbers at 14 microseconds for mean and 33 for max, with a 99% of 17 microseconds.  So how many transactions occurred?  For the QFX3500, there were 1,500,000 messages per second; with other products, there were 1,300,000 messages per second. 

The two tests are very revealing about the vital statistics of the new QFX3500 Switch, both as a standalone device and as part of a transaction processing solution.

So who is the fastest switch in the west? I think we have the answer. 

Learn more about QFabric from my colleagues David Yen and Andy Ingram.

[#2]

Gizza fiver mate