Alas… the much anticipated FCS (First Customer Shipment) of the earth shattering Cisco 3548 Switch is now available. When your business depends on nanoseconds, this switch enables unprecedented advantages in lowest latency with a full feature set.
Customers should also bear in mind that in conjunction to announcing shipping units, our ecosystem partnership is more robust than ever. Our Nexus Engineering Team released a whitepaper detailing how the partnership validated end-to-end latency with real time NASDAQ market data from Universal E-Business Solutions, leveraged precise measurement tools from TS-Associates, Feed Handler processing from Enyx FPGA, and Network Test Access Points from Datacom Systems.
Read the whitepaper below in its entirety to see how Cisco continues to work with best of breed infrastructure vendors to deliver a complete solution in High Performance Trading.
Tags: Algo Boost, Algorithm Boost, Cisco, data center, high performance computing, high performance trading, High Performance Trading Fabric, High-Frequency Trading, HPC, latency, Nexus 3000, Nexus 3500, Nexus 3548, Nexus 3K, ultra-low latency, Unified Fabric
On October 5th I posted part 1 of the Algo Boost series with a fantastic discussion around the latency innovations on the Nexus 3548. Today, we announced that these units are now shipping to customers and the much anticipated wait is over to get this game changing technology! This is perfect timing as I introduce part 2 of the series with Errol Roberts, Distinguished System Engineer for the top Data Center accounts, to bring a customer perspective to the ultra-low latency Nexus 3548 in a High Performance Trading fabric.
[GD] I know that you spend a lot of your time talking with customers. What are our Financial Services customers telling you about their environments and requirements?
[ER] When meeting with these customers, I like to ask a single question – “What value can an infrastructure company provide to high-performance trading workloads”. Key points relating to the switching are captured by the following:
- First, customers ask for a network solution and architecture that provides them with the fastest end-to-end functionality. Providing the “Lowest latency possible” is one vector, another vector being a rich “feature-set” answering the different architecture and network requirements end-to-end. Naturally there is a need for speed while at the same time providing the features within the same device. For example in collocated High Frequency Trading environments; the lowest latency being key; it’s not the only factor; support for the routing protocol such as BGP, multicast with PIM Sparse mode, ultra low latency SPAN at linerate with multiple ports; this is achieved with the technology called Warp SPAN.
- Next, “Handle microbursts”. Volatility is correlated. When you are running cross-asset class, cross-liquidity venue strategies, there is often short-lived congestion that increases latency. These volatile periods are often the most opportunity rich.
- Also, “Unique features”. They want features like Network Address Translation to meet their business needs. You don’t want these features to add latency. In fact you don’t want to have any of the L4 or services applied on the network to add latency.
- Next, “Flexibility and Programmability”. They want to control their traffic flow, mirror relevant traffic, have fine-grained flexibility and also have reactivity on events. Python scripting language is a good example of automation. With Python script, you can have the switch react on different environmental changes such as a sanity check when the device comes online as well as for example triggering emails when the burst happening at the buffer level exceed for example 10 nanoseconds.
- In addition, facilitate “Precision Time”. You cannot control what you cannot measure. Without precision time, you invest in an infrastructure and just hope you get optimal performance. With precision time protocol you can keep all of your servers and network elements highly synchronized at the nanosecond level. You can even measure the accuracy of the tool through a 1 pulse per second output port. Also, the Nexus 3548 can timestamp traffic with IEEE 1588, which allows analyzers to replay events.
Read More »
Tags: Algo Boost, Algorithm Boost, data center, high performance computing, high performance trading, High Performance Trading Fabric, High-Frequency Trading, HPC, latency, Nexus 3000, Nexus 3500, Nexus 3548, Nexus 3K, ultra-low latency, Unified Fabric
A while ago, I posted “Why MPI is Good For You,” describing a one-byte change in Open MPI’s code base that fixed an incredibly subtle IPv6-based bug.
The point of that blog entry was that MPI represents an excellent layered design: it lets application developers focus on their applications while shielding them from all the complex wilderbeasts that roam under the covers in the implementation.
MPI implementors like me don’t know — and don’t really want to know — anything about complex numerical analysis, protein folding, seismic wave propagation, or any one of a hundred other HPC application areas. And I’m assuming that MPI application developers don’t know — and don’t want to know — about the tricky underpinnings of how modern MPI implementations work.
Today, I present another motivating example for this thesis.
Read More »
Tags: HPC, mpi, why-mpi-is-good-for-you
Jeff Hammond at Argonne tells me that there’s some confusion in the user community about MPI and C++. I explained how/why we got here in my first post; let Jeff (Hammond) and I now explain what this means to you.
The short version is: DON’T PANIC.
MPI implementations that provided the C++ bindings will likely continue to do so for quite a while. I know that we have no intention of removing them from Open MPI any time soon, for example. The MPICH guys have told me the same.
I’ll discuss below what this means to both applications that are written in C++, and applications that use the MPI C++ bindings. Read More »
Tags: HPC, mpi, MPI-3.0
Jeff Hammond at Argonne tells me that there’s some confusion in the user community about MPI and C++.
Let me see if I can clear up some of the issues.
In this blog entry, I’ll describe what has happened to the C++ bindings over time (up to and including their removal in MPI-3), and why. In a second blog entry, I’ll describe what this means to real-world C++ MPI applications.
Read More »
Tags: HPC, mpi, MPI-3.0