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.