In our latest article, Measuring SmartX ECP Performance for Low-Latency Trading: Validation from a Futures Company, we show how SmartX ECP supports low-latency trading and how a futures firm validated its performance in an AMD environment.
Below, we will share three additional validations from the securities industry, covering Intel-based low-latency and HA scenarios, long-term production validation for ultra-fast market data and trading, and an end-to-end performance comparison between an AMD-based SmartX ECP environment and an overclocked Intel physical server.
Case Study 1: Validating Low Latency Performance and HA on Intel-based Servers
In brokerage colocation and low-latency trading, many workloads run on Intel x86 servers. Virtualization must address two key questions: whether VM network latency on general-purpose x86 hardware can be kept under control, and whether services can recover quickly after host, process, or NIC failures.
Securities company A built a three-node SmartX ECP cluster on Intel general-purpose servers. Using Solarflare low-latency NICs, SR-IOV NIC virtualization, and the Onload high-performance network stack, the firm validated network performance, trading counter penetration latency, and VM HA failover capabilities.
Validation Environment
| Item |
Test Environment |
| Cluster scale |
3-node SmartX ECP cluster running ELF (SmartX native Hypervisor) with VM HA enabled |
| Server |
Inspur NF5280M5; Intel 6248R 3.0 GHz, 24-core CPU |
| Memory |
DDR4 256 GB |
| Storage |
1.92 TB SSD × 2; 18 TB HDD × 8 |
| Network |
Solarflare x2522 low-latency NIC × 2; VM interfaces for low-latency market data and trading connected to a Cisco 3548 low-latency switch |
| NIC virtualization |
Physical ports partitioned into multiple VF virtual ports through SR-IOV for use by multiple business VMs |
Test Data
| Network test item | Traditional physical machine | SR-IOV VMs running on SmartX ECP | Difference |
| Maximum network bandwidth | 9.42Gbps | 9.42Gbps | Same |
| Trading counter penetration latency | 3~4μs | 3.3~4.3μs | About +0.3μs |
| Low Latency – Onload/size | 64TCP | 128TCP | 64UDP | 128UDP |
| Traditional physical machine | 1.805μs | 1.874μs | 1.708μs | 1.778μs |
| SR-IOV VMs running on SmartX ECP | 1.820μs | 1.891μs | 1.709μs | 1.778μs |
- TCP: SR-IOV VMs running on SmartX ECP showed slightly higher latency than the physical server, but the difference was negligible, with a maximum gap of jμst 0.017μs.
- UDP: The two environments’ performance was almost identical. The gap was only 0.001μs for 64 UDP, and the 128 UDP results were exactly the same.
| Low Latency – TcpDirect /size | 64TCP | 128TCP | 64UDP | 128UDP |
| Traditional physical machine | 1.542μs | 1.628μs | 1.449μs | 1.539μs |
| SR-IOV VMs running on SmartX ECP | 1.542μs | 1.634μs | 1.449μs | 1.536μs |
- TCP: Latency was identical for 64TCP. For 128TCP, the VM was 0.006μs higher than the physical
- UDP: Latency was identical for 64UDP. For 128UDP, the VM was 0.003μs lower than the physical server.
| HA scenario | Failure type | Observed behavior |
| Scenario 1 | A single host was fully powered off while VMs using SR-IOV NICs were running. | The VMs restarted on the remaining nodes and their SR-IOV NICs were reattached. After restart, latency returned to the baseline level. |
| Scenario 2 | Hardware failure of a single Solarflare NIC | With dual-NIC link redundancy, traffic switched to the standby NIC. The VM did not restart, and the business service was not interrupted. |
Validation Results
|
+0.003~0.006μs Network latency difference Under both Onload and TcpDirect acceleration, VM network latency was virtually identical to that of traditional physical machines. |
9.42Gbps
Full 10GbE bandwidth Both physical machines and VMs reached 9.42 Gbps. |
| +0.3μs
Trading counter penetration latency Physical machine: 3~4 μs; VM: 3.3~4.3 μs. |
0ms Link-failure interruption Dual-NIC redundancy enables switchover with no service interruption. |
The validation shows that, on general-purpose Intel servers, SmartX ECP combined with Solarflare low-latency NICs, SR-IOV, and Onload/TcpDirect technologies can keep virtualization-related network overhead low while maintaining 10GbE throughput. The HA tests also show that, with SR-IOV NICs, a three-node cluster can restore VMs on another node following a host or process failure; with dual SR-IOV NIC redundancy, a single NIC failure can trigger a traffic switchover without business interruption.
For securities firms that still run large numbers of Intel x86 workloads, this validation provides a more practical path forward: preserve existing hardware and networking investments, gradually validate the ability of virtualization to support low-latency workloads, and leverage cluster HA to improve continuity for critical services.
Case Study 2: Validating Low-Latency Market Data and Trading Performance on SmartX ECP
Securities firm B had long relied on physical strategy machines and dedicated low-latency NICs for low-latency market data reception, strategy computation, and trading connectivity. As its customer base grew, cabinet space, power capacity, and hardware resource utilization in the colocation data center increasingly constrained further expansion.
To assess the feasibility of running low-latency market data and trading systems on VMs, the firm conducted a long-term validation on SmartX ECP with real production data.
>>Learn more about the configurations and test results: What is Kernel Bypass NIC and How Does It Perform in HCI?
Test Data
| Test Item | Result | Notes |
| Long-term live market data | PCI-passthrough-enabled VMs had continuously handled live stock exchange FPGA UDP multicast market data for six months, with zero packet loss throughout daytime trading sessions. | Validates the stability of virtualization in a production market data path. |
| Extreme market data stress | Under SR-IOV, a single NIC supported four VMs with no packet loss during 10× market data replay. At 20× replay speed, instantaneous NIC traffic exceeded 1Gb/s, still with no packet loss. | Under the test conditions, the solution provides traffic headroom beyond historical peak levels. |
| Network round-trip latency | Bidirectional round-trip latency between SR-IOV VMs was <2μs. | Trading NIC latency reached the same level as physical machines in this test environment. |
| Bandwidth throughput | No packet loss under a 2Gbps TCP traffic stress test. | Covers low-bandwidth securities trading needs. |
Validation Results
|
6 months Live trading validation Zero packet loss throughout daytime trading sessions while handling stock exchange FPGA UDP multicast market data for six months. |
20×
Market data replay Even when instantaneous NIC traffic exceeded 1Gb/s under extreme load, no packet loss occurred. |
| <2μs
Bidirectional round-trip latency SR-IOV VM network round-trip latency met the requirements of low-latency trading links. |
2Gbps TCP stress traffic No packet loss was observed during the bandwidth stress test, covering the low-bandwidth requirements in securities trading. |
The validation shows that whether virtualization can be introduced into production links for low-latency securities market data and trading depends not only on the virtualization platform itself, but also on engineering considerations such as low-latency NIC compatibility, OpenOnload acceleration, NUMA affinity, dedicated CPUs, path isolation, and stress testing.
Through validation across the complete production links, long-term live trading, and high-speed market data replay, SmartX ECP demonstrated its feasibility for running low-latency securities workloads. In specific, PCI passthrough is better suited to market data links that are extremely latency-sensitive and require exclusive access to hardware resources, while SR-IOV is better suited to trading paths and scenarios where multiple VMs share a NIC, helping improve both NIC and server resource utilization.
Case Study 3: Performance Comparison Between AMD-Based SmartX ECP and an Overclocked Intel Physical Server
To validate whether a virtualized environment can support the nanosecond- and microsecond-level performance required for quantitative private-fund services, securities firm C compared the end-to-end low-latency trading performance of AMD-based SmartX ECP with an overclocked Intel physical machine.
Only one business VM was deployed in the first round. If the validation met the target, the environment could later be expanded into a cluster, allowing a single server to host strategy machines for multiple customers, improving resource utilization while reducing deployment costs.
Validation Environment
| Comparison | Strategy Machine on AMD-Based SmartX ECP | Overclocked Intel Physical Machine |
| Compute platform | CPU: AMD 7985WX, 64 cores; all-core frequency fixed at 4.8GHz, up to 5.1GHz single-core; Memory: DDR5 512 GB | CPU: Intel i9-14900KS, 24 cores; all-core frequency fixed at 5.8GHz, up to 6.2GHz single-core; Memory: DDR5 128 GB |
| Network | Solarflare x2522 × 2; Mellanox MCX512A-ACAT × 2 |
Solarflare x2522 |
| Resource configuration | VM: 8 vCPU | 96 GB | SR-IOV NIC | NIC passthrough | Same configuration on the physical machine |
The VM was configured with four functionally isolated NICs:
- Solarflare PCI passthrough NIC for receiving stock exchange UDP multicast L2 market data.
- Solarflare SR-IOV vNIC for ultra-fast order submission.
- Mellanox SR-IOV vNIC for high-precision PTP time synchronization.
- Virtio general-purpose NIC for in-band remote management and operations.
Four metrics were measured: stock exchange L2 market data reception latency, local strategy computation time, end-to-end order acknowledgment latency, and VM vCPU performance attainment relative to a physical CPU. Together, these metrics cover the overall latency of market data reception, strategy computation, order submission and acknowledgment, as well as CPU and memory performance overhead at the virtualization layer.
Test Data
| Test Item | Overclocked Intel Physical Machine | AMD-Based SmartX ECP | Difference |
| Median market data reception latency difference | Baseline | +192ns | +192ns |
| Median local strategy computation time | 0.7~1.018μs | 3~3.535μs | +2~3μs |
| Median end-to-end order acknowledgment latency | 3576μs | 3927μs | 91% attainment |
| Test Item | AMD Physical Machine | AMD-Based SmartX ECP | Difference |
| Sysbench single-thread CPU score | 57897 | 57706 | -0.33% |
| Sysbench 4-thread CPU score | 14470 | 14426 | -0.3% |
| Random memory read/write bandwidth | 3740MiB/s | 3685MiB/s | -1.47% |
Validation Result: The Main Bottleneck Was CPU Frequency, Not the Virtualization Overhead
|
Only +192 ns Market data reception difference Median market data reception latency increased by only 192 ns from the physical-machine baseline, with extremely low network-layer overhead. |
91% End-to-end path With tunning in NUMA, CPU isolation, and fixed-frequency, end-to-end performance attainment reached 91%. |
|
+2~3μs Strategy computation difference VM strategy computation time was 2–3 µs higher, mainly because of the CPU frequency difference. |
0.3%~3% Virtualization-layer overhead CPU and memory benchmarks showed only a small gap between the AMD VM and an equivalently configured Intel physical machine. |
The validation shows that, in low-latency trading scenarios, SmartX ECP can keep network-layer overhead extremely low and narrow the end-to-end business latency gap to an acceptable range through configurations such as PCI passthrough, SR-IOV, NUMA binding, CPU isolation, and disabling power-saving features.
The higher strategy computation time on the VM was primarily caused by the CPU frequency difference between the AMD host running at 4.8GHz across all cores and the overclocked Intel physical machine running at 5.8GHz. In the tests, a higher-frequency AMD 9950X physical machine on the same architecture delivered computation times close to those of the overclocked Intel machine, further confirming that CPU frequency, rather than the virtualization architecture itself, was the key variable affecting strategy computation latency.
Enterprise users can evaluate performance from an end-to-end business perspective. While individual components—including networking, virtualization, and compute—showed some performance differences compared with the physical server, the end-to-end median latency was 91% of the physical baseline, meeting the overall target. With the CPU frequency matched to that of the physical server, SmartX ECP VM performance would come even closer to bare-metal performance.
The Overall Value of SmartX ECP for Low-Latency Trading
Based on test data across all scenarios, SmartX ECP delivers the following core advantages over traditional physical server architectures for low-latency trading, spanning performance, resource utilization, cost efficiency, operations, availability, and compliance:
- Performance: Additional network latency increased by only 0.02~0.04μs, and full-link business latency increase was kept within 1μs, meeting production admission standards for ultra-fast securities and futures trading.
- Resource utilization: Server and NIC hardware resources can be pooled and shared. A single physical server can host multiple trading strategy VMs, addressing the issue of underutilized physical server resources.
- Cost reduction: Hardware procurement costs can be reduced by more than 50%, colocation rack space by 50%, and whole-server power consumption in the data center by over 30%, reducing fixed data center spending.
- Operational agility: VM templates enable one-click deployment, reducing host provisioning time from hours to minutes and allowing fast response to new customer onboarding, temporary capacity expansion, and workload retirement.
- High availability and disaster recovery: Native VM HA and SR-IOV dual-NIC link redundancy provide automatic failover capabilities that physical servers do not offer, improving overall continuity for trading workloads.
- ITAI transformation and compliance: SmartX ECP is fully compatible with Intel, AMD, Hygon, Kunpeng, and other chip platforms, helping financial institutions reduce reliance on foreign virtualization vendors and meet requirements for independently controllable infrastructure transformation.
References:
Financial Services Cloud & IT Infrastructure – SmartX ECP
Recommended Readings:
Measuring SmartX ECP Performance for Low-Latency Trading: Validation from a Futures Company
What is Kernel Bypass NIC and How Does It Perform in HCI?
SmartX ECP in Financial Services: Securities and Futures Customer Stories
