Skip to content
Get Started

Nanoconda Latency Overview

The following latency figures represent typical measurements from an optimized production deployment. Actual latency depends on hardware, CPU architecture, exchange connectivity, thread placement, cache state, and workload.

Overall Latency

Component Typical Round Trip Latency
Software (socket-to-socket) 1.0–1.5 µs
Solarflare EFVI / TCPDirect PCIe transfer ~1.5 µs (500–700 ns each direction)
CME Network ~1.0 µs (≈500 ns each direction)

Typical Wire-to-Wire Latency

  • Software processing: ~1.0–1.5 µs
  • PCIe transfer (EFVI/TCPDirect): ~1.5 µs
  • Total wire-to-wire latency inside the Nanoconda server: ~2.5–3.0 µs
  • Additional network latency to CME: ~1.0 µs round trip

Receive Path (Market Data)

Typical latency from market data arriving at the network card until it is available to the trading strategy.

Stage Typical Latency
Solarflare EFVI / PCIe transfer 500–700 ns
CME MDP 3.0 message parsing 200–400 ns
Shared memory transfer (cross-core) 300–400 ns

To get real-time latency from the API use the difference between nanoconda::writetime and nanoconda::receivetime;

Send Path (Order to Wire)

Typical latency from strategy decision until the order leaves the network interface.

Stage Typical Latency
In-memory pre-trade risk 70–200 ns
Shared memory transfer 80–200 ns
iLink message normalization 100–400 ns
Solarflare TCPDirect / PCIe transfer 400–700 ns

Typical order-to-wire latency: ~1.0 µs

You can retrieve real-time sending latency histogram in Nanoconda Dashboard or by using latencystats cli application.

How Nanoconda Achieves Low Latency

Nanoconda's low latency comes primarily from its single-machine, in-memory architecture.

The critical trading path remains entirely on one colocated server:

Exchange
    │
    ▼
Solarflare EFVI
    │
    ▼
Market Data Feed Handler
    │
    ▼
Shared Memory
    │
    ▼
Trading Strategy
    │
    ▼
In-Memory Pre-Trade Risk
    │
    ▼
Exchange Gateway
    │
    ▼
Solarflare TCPDirect
    │
    ▼
Exchange

Critical components all execute on the same physical machine, including:

  • Market data feed handler
  • Trading strategies
  • Pre-trade risk engine
  • Order gateway
  • Position management
  • Account management

Data remains in memory throughout the trading pipeline.

There are no network hops or remote services between market data reception, strategy execution, risk validation, and order transmission.

Performance Optimizations

Nanoconda achieves deterministic microsecond-level performance through:

  • Native C++ implementation
  • Single-machine architecture
  • Shared-memory communication
  • In-memory pre-trade risk
  • Kernel bypass networking
  • Solarflare/Xilinx EFVI
  • Solarflare TCPDirect
  • CPU affinity
  • NUMA-aware scheduling
  • Dedicated trading cores
  • Hardware timestamping
  • PTP synchronization
  • Lock-free data structures
  • Cache-friendly memory layout

Notes

These measurements represent optimized production deployments with:

  • Proper CPU pinning
  • Cache warming
  • Dedicated trading cores
  • Tuned operating system
  • Supported Solarflare/Xilinx networking hardware

Actual latency varies depending on hardware configuration, exchange connectivity, workload, and deployment environment.