Aventura, Florida · serving clients across the United States (305) 404-9404Toll-free (800) 767-8566Emergency? Get a call within 1 hour
Financial services, trading Illustrative engagement

A 100G colocation built for microseconds: PTP time, kernel-bypass and no surprises

A systematic hedge fund in New York and New Jersey, a leader in its segment.

Scale
2 colocation sites, 100 Gb/s links, sub-100 ns clock accuracy, microsecond-class software path
Engagement
Design, build and operation of two colocation footprints

The challenge

Trading strategies lived and died on latency and on knowing exactly when each packet arrived. The firm’s existing setup used general-purpose servers and best-effort time, so timestamps could not be trusted and delays were uneven.

For a systematic trading firm, the network is part of the strategy. The firm's existing setup used general-purpose servers and best-effort time, so timestamps could not be trusted and delays were uneven. The brief had three parts: make the path from the exchange handoff to the application as short and as consistent as possible, make time trustworthy across every machine, and keep the evidence to prove what happened. Consistency matters as much as speed, because the tail of the latency distribution is where money is lost.

The physical design is deliberately simple: fixed-length cross-connects, as few hops as possible, and cut-through 100 Gb/s QSFP28 switches that begin forwarding before a frame has fully arrived. On the servers, the kernel network stack is bypassed with user-space packet processing (DPDK or vendor user-space libraries), interrupts are pinned, cores are isolated for the trading process and memory is kept local to the network card's NUMA node. Time comes from a GNSS-disciplined grandmaster clock distributed over IEEE 1588 PTP with hardware timestamps on the network cards and boundary clocks in the switches, which is what makes timestamps comparable between machines.

The migration ran beside production. The new footprint was built and measured in parallel while the old one kept trading, and strategies moved one at a time after a week of shadow running in which both paths received the same market data and their timestamps were compared. Each move happened over a weekend, with a rollback that meant re-pointing a cross-connect. Less latency-critical traffic, such as research data and file transfers, was moved to a separate path over BGP-routed links with failover to the second site, so a bulk copy could never queue behind an order.

Measurement came before claims. Hardware capture on the switch mirror ports gave nanosecond timestamps for every frame, and we compared PTP offsets against a second, independent GNSS receiver to verify the clock itself. Tests included microbursts at line rate, deliberate PTP grandmaster failover, a cable pull on the primary path and an interrupt-affinity change that we confirmed showed up as a regression on the dashboard within minutes. Reports showed the latency histogram, with the 99th and 99.99th percentiles, not the average.

The outcome is a repeatable, measured path in which the median time from wire to application is in the low microseconds, clocks agree to well within a microsecond, and every packet can be replayed with a trustworthy timestamp. Copies of market-data and order traffic are timestamped in hardware and stored for replay and for best-execution evidence. The firm now watches its latency distribution on a dashboard and notices a regression the day it appears, not the quarter after.

What our team delivered

  • Cut-through 100 Gb/s switching (QSFP28) with short, fixed-length cross-connects to the exchange handoffs
  • IEEE 1588 Precision Time Protocol with hardware timestamping, a GNSS-disciplined grandmaster and boundary clocks, holding hosts within about 100 ns of the reference
  • Kernel-bypass networking on tuned servers (DPDK or vendor user-space stacks), CPU isolation, pinned interrupts and NUMA-aware memory
  • Hardware packet capture with nanosecond timestamps for every market-data feed and order, for replay and best-execution evidence
  • Redundant paths and a second site with BGP-based failover for non-latency-critical flows
  • Monitoring that measures latency distribution, not averages

Result

A repeatable, measured path in which the median time from wire to application is in the low microseconds, clocks agree to well within a microsecond, and every packet can be replayed with a trustworthy timestamp. The modeled build was commissioned in stages: cross-connect and fiber lengths were fixed and documented, clock offset between sites was measured continuously against the GNSS reference, and latency was tracked as a distribution (median, 99th and 99.99th percentile) rather than an average. Changes to the trading path went through a staging replica first, and a replayed capture reproduced any disputed order sequence with its original timestamps.

Round-trip times between seven cities

Round-trip time in milliseconds on direct paths between seven sites, close to what today's fibre routes deliver (light in glass covers about 100 km per millisecond one way, and real routes are longer than the map line). The darker the cell, the longer the round trip. Illustrative figures.

Round-trip times between seven citiesSeven by seven heat map of round-trip times in milliseconds. New York to Miami 27, to São Paulo 115, to London 70, to Frankfurt 80, to Singapore 225, to Tokyo 160. London to Frankfurt 14, the shortest. Singapore to Tokyo 70. Singapore to São Paulo 330, the longest.Round-trip time between sites (ms), direct pathsunder 3030 to 99100 to 149150 to 219220 and upNew YorkMiamiSão PauloLondonFrankfurtSingaporeTokyoNew York271157080225160Miami27110100115240155São Paulo115110190200330255London7010019014170220Frankfurt8011520014160230Singapore22524033017016070Tokyo16015525522023070Symmetric by construction. Singapore to São Paulo is the longest pair, close to the opposite side of the planet.

A fabric with no single point of failure

Every leaf switch has a 100G QSFP28 uplink to every spine, servers attach at 25G or 10G through LACP pairs, and ECMP spreads flows across all spines. If a spine fails, the flows simply rehash onto the rest.

A fabric with no single point of failureA spine-leaf datacenter fabric. Two spine switches, each linked to four leaf switches by QSFP28 100G uplinks running an eBGP underlay. The leaves form two MLAG pairs. Servers connect at 25G SFP28 through LACP bonds split across both switches of a pair, and two legacy servers connect at 10G SFP+. Two traffic flows are hashed by ECMP, one through each spine. On a loop, spine 1 fails and its flow rehashes onto spine 2. Spine 1eBGP underlaySpine 2eBGP underlayLeaf 1Leaf 2Leaf 3Leaf 4MLAGMLAGLegacySFP+ 10GCompute A2 × SFP28 25G · LACPCompute B2 × SFP28 25G · LACPStorageSFP+ 10GQSFP28 100GSFP28 25GSFP+ 10Gflow 1 · hash Aflow 2 · hash BECMPspine down: ECMP rehash

The right module for every reach

From 10G SFP+ to 400G QSFP-DD, the module is chosen by distance and fibre: DAC or AOC inside the rack, short-reach optics on OM4 multimode in the hall, long-reach on OS2 single-mode between buildings and coherent 400ZR between datacenters. One 100G port can also break out into four 25G.

The right module for every reachA grid of optical and copper modules. Rows are 10G SFP+, 25G SFP28, 100G QSFP28 and 400G QSFP-DD. Columns are reach classes: in the rack with direct attach copper or active optical cables, in the hall with short-reach optics on OM4 multimode fibre, between buildings with long-reach optics on OS2 single-mode fibre, and metro or datacenter interconnect, where 400G uses coherent 400ZR. Packets move faster along faster rows. Below, a QSFP28 100G port splits through a breakout cable into four 25G SFP28 server links. IN RACKHALLCAMPUSMETRO · DCISFP+10GDACup to 7 mSR · OM4400 mLR · OS210 kmER · OS240 kmSFP2825GDACup to 5 mSR · OM4100 mLR · OS210 kmER · OS240 kmQSFP28100GDAC · AOC5 m · 100 mSR4 · OM4100 mLR4 · OS210 kmER4 · OS240 kmQSFP-DD400GDAC · AOC3 m · 100 mDR4 · OS2500 mFR4 · OS22 km400ZRcoherent · 120 kmBREAKOUTQSFP28100G portSFP28 25G1SFP28 25G2SFP28 25G3SFP28 25G4100G → 4 × 25G

Failover in under a second

ISP A fails at 300 ms. BFD (RFC 5880) with a 50 ms interval and multiplier 3 declares the session down 150 ms later, BGP withdraws the routes, and the forwarding table repoints to ISP B. Traffic is back at full rate in well under a second; without BFD the router would wait for the 90 s BGP hold timer. Illustrative figures.

Failover in under a secondLine chart over 1.2 seconds. ISP A carries 8 gigabits per second until 300 milliseconds, then drops to zero. ISP B carries nothing until about 650 milliseconds and reaches 8 gigabits per second at 720 milliseconds. Roughly 400 milliseconds of loss in between.Traffic per upstream during a link failureISP A (primary)ISP B (standby)04812Gb/s0200 ms400 ms600 ms800 ms1000 ms1200 msabout 400 ms of loss1 Link to ISP A fails2 BFD: 3 missed hellos (3 × 50 ms), session down3 Routes withdrawn, FIB repointed to ISP BWithout BFD, BGP would wait for the 90 s hold timer (30 s keepalives).

Frequently asked questions

Direct answers to the questions we hear most. Something else on your mind?

Send us a message
How accurate is the time on the hosts?

IEEE 1588 PTP with hardware timestamping, a GNSS-disciplined grandmaster and boundary clocks holds hosts within about 100 ns of the reference. Clocks agree to well within a microsecond. The previous best-effort time meant timestamps could not be trusted.

How is the software path kept fast?

Tuned servers use kernel-bypass networking (DPDK or vendor user-space stacks), CPU isolation, pinned interrupts and NUMA-aware memory. The network is cut-through 100 Gb/s QSFP28 switching with short, fixed-length cross-connects. The median wire-to-application time is in the low microseconds.

How are packets recorded and failures handled?

Hardware packet capture with nanosecond timestamps records every market-data feed and order for replay and best-execution evidence. A second site with BGP-based failover covers non-latency-critical flows. Monitoring measures latency distribution, not averages.

Do you know if your company is safe?

Speak with a security engineer today. The first assessment call is free and confidential.

CallFree assessment