In the futures and securities industry, low-latency trading, market data feeds, and algorithmic strategy execution are extremely sensitive to network and compute latency; even microsecond-level latency differences can affect trading efficiency and system performance. While a traditional physical architecture can meet the performance and low-latency requirements, it presents clear challenges in areas such as operating costs:

  • Low space and resource utilization: Exchange cabinet space and power are limited, and physical servers are underutilized, driving up colocation costs and wasting resources.
  • Difficulty in customization: Different trading systems require different server types, significantly increasing procurement costs.
  • Difficulty in ITAI transformation: Retrofitting a traditional physical architecture with domestic technology is difficult and costly, making it hard to keep pace with the trend toward self-controlled infrastructure.

This raises a key question: Can hyperconvergence, a more cost-effective architecture, support low-latency trading?

Recently, SmartX worked with several financial institutions to validate the performance of SmartX ECP in low-latency trading across multiple dimensions. This article focuses on a low-latency trading performance validation by a futures firm based on an AMD environment. 

The results show that VM network latency increased by only about 0.02–0.03 µs compared with physical machines, network throughput matched that of physical machines, and trading counter penetration latency increased by only 1–2 µs.

How SmartX ECP Supports Low-Latency Trading

For low-latency trading use cases, SmartX ECP optimizes full-stack performance across compute, networking, and storage, while ensuring high performance, low latency, and high availability for critical trading:

  • Compute efficiency: Dedicated CPU, vCPU pinning, NUMA affinity, and Boost mode improve compute performance and compute resource utilization.
  • Storage performance: Enable Boost mode and RDMA on demand, combined with I/O localization and high-performance hardware to achieve low I/O latency.
  • Low-latency networking: PCIe NIC passthrough and SR-IOV NIC partitioning help bypass the virtual network path and reduce latency jitter.
  • High availability: Support for HA of VMs with SR-IOV NICs, combined with anti-affinity and dual-NIC redundancy to improve availability.

Based on these capabilities, enterprises can validate and optimize performance for different business scenarios through different technical paths: 

  • Prioritize PCI NIC passthrough for the market data reception path.
  • Use SR-IOV for the order submission path to balance low latency with NIC resource sharing.
  • Isolate PTP and management networks.
  • Reduce resource contention for critical VMs through dedicated CPU, NUMA affinity, and anti-affinity policies.

Validation of Low-Latency Trading on AMD-based SmartX ECP at a Futures Firm

A futures firm needed to deliver low-latency strategy machines to different customers, with high requirements for network latency, compute performance, resource isolation, and delivery efficiency. However, as its customer base grew, the traditional physical-machine model led to poor resource utilization, tight cabinet space, and long delivery cycles.

To evaluate the feasibility of SmartX ECP in futures colocation trading, the firm used fourth-generation AMD servers to compare performance baselines between SmartX ECP (VMs) and physical machine environments, focusing on compute performance, network latency, network bandwidth, and trading counter penetration latency. 

The tests used the same fourth-generation AMD server hardware: a physical environment was first deployed to establish a performance baseline, then SMTX OS was deployed to run the same data.

Test Environment

Items Configurations
Cluster scale 3-node ECP cluster of fourth-generation AMD servers
Server AMD 9354 3.25 GHz, 32 Cores
Memory DDR5 512 GB
Storage 3.84 TB SSD × 4
Network Solarflare x2522 × 1
VM configuration 8C/16G | SR-IOV NIC

Test Data

Benchmark Performance

Test items AMD physical server SmartX ECP Difference
UnixBench single-thread 2666.8 2332.7 -12.7%
UnixBench 8-thread 16075.3 14319.5 -10.9%
Network bandwidth 9.41 Gbps 9.41 Gbps Same
Trading counter penetration latency 3–4 µs ~5 µs +1–2 µs

Stress Test – sfnt-pingpong

TCP latency/size 1 16 32 64 128 512
AMD physical machine 1.724 µs 1.738 µs 1.751 µs 1.789 µs 1.869 µs 2.105 µs
SmartX ECP 1.757 µs 1.769 µs 1.782 µs 1.813 µs 1.895 µs 2.136 µs
UDP latency/size 1 16 32 64 128 512
AMD physical machine 1.620 µs 1.620 µs 1.649 µs 1.677 µs 1.747 µs 1.994 µs
SmartX ECP 1.639 µs 1.640 µs 1.674 µs 1.702 µs 1.767 µs 2.022 µs

Key Results

+0.02–0.03 µs

network latency increase

VM TCP/UDP latency is only slightly higher than physical machines.

9.41 Gbps

consistent bandwidth

Both physical machines and VMs saturate 10 GbE bandwidth.

+10.9%–12.7%

CPU baseline gap

VM and physical machine CPU benchmark performance differ by only about 12%, while the virtualization platform can host more workloads.

+1–2 µs

trading counter penetration latency

Compared with physical machines, VMs’ counter penetration latency increases by only 1–2 µs, making the incremental impact on the business path quantifiable.

The results show that VMs have comparable throughput but lower network overhead compared with physical machines. VM network latency increases by only about 0.02–0.03 µs versus physical machines, network throughput matches physical machines, CPU benchmark performance differs by about 10%, and trading counter penetration latency increases by about 1–2 µs. 

Based on these results, the customer has started a pilot run on SmartX ECP and plans to host medium/low-frequency colocation business after scaling out.

  • Lesson learned: Virtualizing low-latency workloads requires joint validation of CPU frequency, NIC mode, network isolation, and the business load model; phased testing plus gradual rollout can improve infrastructure resource utilization and delivery agility under controlled risk.

Conclusion

In low-latency trading scenarios, virtualization is not the performance bottleneck; CPU frequency, NIC networking mode, and underlying hardware configuration are the core variables that determine latency.

Leveraging full-stack low-latency capabilities across compute, networking, and storage, the SmartX ECP platform challenges the financial industry’s long-held belief that “core trading must run on physical machines,” allowing hyperconverged VMs to host nanosecond/microsecond-level low-latency trading workloads with near-zero overhead. 

Compared with the traditional siloed physical machine model, SmartX ECP delivers bare-metal-comparable low-latency performance while also providing elastic resource pooling, automated disaster recovery, simplified operations, lower cost, and domestic technology compliance.

References:

Recommended Readings:

Continue Reading