ERPC Deploys XDP Fast Path and Zero-Copy to Solana Geyser gRPC in New York (NY) Region — Observes ~530ms Delivery Latency Difference at p99

ELSOUL LABO B.V. (Headquarters: Amsterdam, the Netherlands; CEO: Fumitake Kawasaki), in collaboration with Validators DAO, announces that ERPC has deployed Solana v4 (Agave 4.x) XDP fast path and AF_XDP zero-copy to the shared Geyser gRPC endpoint in the New York (NY) region.

XDP fast path and AF_XDP zero-copy have transitioned from experimental features in Agave 4.x to officially supported functionalities, accessible via the launch flags --xdp-interface, --xdp-cpu-cores, and --xdp-zero-copy. ERPC has now implemented this network optimization—increasingly adopted in high-performance Solana validator environments—on the source validators powering the NY region’s Geyser gRPC service. Comparative benchmarking using slv check geyserbench from SLV, an open-source Solana operations tool, shows that the pre-optimization node in the same NY region lags behind the new configuration by p50 63ms, p95 490ms, and p99 530ms. These values represent latency differences, not absolute delivery times, with hundreds of milliseconds improvement observed in the tail latency regions (p95 and p99). This deployment is already live in production. Customers prioritizing first-arrival performance can now access the NY region Geyser gRPC via hourly billing or Crypto Pay (SOL / USDC / EURC).

ERPC Official Website: https://erpc.global/ja

ERPC Dashboard: https://dashboard.erpc.global/ja

Why the New York (NY) Region Geyser gRPC Matters

On Solana, block-producing leaders rotate frequently, causing communication origins to shift constantly. In this architecture, proximity to a network hub with high validator density is more impactful than physical closeness to a single point, directly affecting operational latency, retransmission rates, and failure rates.

The New York (NY) region is a critical hub during North American trading hours, concentrating demand for real-time on-chain data used in trading, indexing, monitoring, and analytics. Geyser gRPC delivers account, slot, block, and transaction updates via streaming rather than polling—where even a 1ms difference can directly impact trade execution opportunities and frontend responsiveness. Therefore, maintaining the NY region’s Geyser gRPC at the fastest possible performance level through both design and optimization is strategically essential.

Benchmark Results — Delivery Latency Difference Before and After Optimization via slv check geyserbench

Using SLV’s open-source tool slv check geyserbench, ERPC compared the new configuration (with XDP fast path and AF_XDP zero-copy enabled) against the pre-optimization source node in the same NY region. The results show the pre-optimization node lags behind the new configuration by:

p50 latency difference: 63ms

p95 latency difference: 490ms

p99 latency difference: 530ms

These figures are comparative, indicating how much slower the pre-optimization node was relative to the new setup—not the absolute latency of the optimized node.

Notably, in the tail latency regions (p95 and p99), differences reach hundreds of milliseconds. Tail latency represents the upper-end delays that occur under stress, directly impacting decision-making speed in first-arrival-sensitive applications like trading and real-time processing. The ~530ms p99 lag demonstrates that upstream ingestion and propagation paths significantly affect Geyser gRPC’s low-latency streaming quality.

The measurement methodology is open-source. Users can replicate the same slv check geyserbench test from their own endpoints to verify actual latency. Since delivery latency varies by client location, network path, time of day, and leader distribution, the value lies not in fixed numbers but in verifiable, transparent methodology. SLV provides full setup and execution instructions in its Getting Started guide. ERPC emphasizes demonstrating delivery quality through measurable, reproducible benchmarks rather than subjective claims.

SLV Official Website: https://slv.dev/ja

SLV Getting Started: https://slv.dev/ja/doc/general/getting-started/

What Are Solana v4’s XDP Fast Path and Zero-Copy?

XDP (eXpress Data Path) is a Linux kernel technology enabling high-performance network code to bypass most of the standard kernel packet processing pipeline. By minimizing data copying and context switching, XDP processes packets with far less overhead than the standard network stack.

In Agave (Solana’s validator client), XDP is applied to Turbine, the protocol responsible for block propagation across validators. Incoming shreds are processed by eBPF programs attached near the network interface card (NIC) and mapped directly into user-space buffers via AF_XDP. In zero-copy mode, received data is transferred directly without copying from kernel to user space. Outbound shreds are transmitted via XDP_TX, eliminating system calls and data copies on the hot path.

Anza introduced XDP for Turbine in Agave 3.x and carried it forward into Solana v4 (Agave 4.x). In Agave 4.x, XDP has moved beyond experimental status and is now a fully supported feature with official launch flags. According to Anza’s setup guide, large validators using XDP can approach 150,000 packets per second in transmission.

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

NY source validator