Fastest Solana shredstream providers
There is no honest universal fastest provider: packet arrival depends on source placement, peering, the receiving host, and the work after the socket. This page gives you the measurements that produce a defensible ranking.
| Signal | What to capture | Why it matters |
|---|---|---|
| Ingress arrival | Timestamp packets at the kernel or socket, not at the decoded transaction. | Lower p50 and p99 arrival time from the same host. |
| Useful-data latency | Measure from packet arrival to a reconstructed entry or transaction your application can use. | A fast provider can still lose if the receiver or decoder becomes the bottleneck. |
| Tail behavior | Capture p95, p99, burst behavior, and late packets over a meaningful window. | Trading systems usually feel the tail, not the average. |
| Route and placement | Run the test from the production machine and record the provider source region. | A provider can be fast in one region and slow in another. |
The test protocol
- 01
Use the same production host, port, firewall rules, and receiver settings. - 02
Capture each provider separately with synchronized clocks and a fixed window. - 03
Report p50, p95, p99, loss, duplicates, recovery, and useful output—not one average. - 04
Repeat during quiet and busy periods before declaring a winner.
Fastest does not mean the lowest ping.
A ping measures a control packet to an endpoint. It does not measure the provider’s shred ingress, the route used for production datagrams, kernel queueing, socket delivery, deshredding, or the time your application needs to make a decision. Measure the actual UDP payload and keep every boundary visible.
Solana shreds are block fragments sent through Turbine. The protocol creates data and coding shreds early, and the network propagates them through a fanout tree. That means a provider’s location and upstream path can change arrival time even when two providers use the same UDP label. Read the Turbine design and the shred specification before choosing what “arrival” means.
Build a latency budget, not a leaderboard
| Stage | Timestamp | Failure it exposes |
|---|---|---|
| Provider to NIC | Packet capture or hardware timestamp | Source route, peering, congestion, or region choice |
| NIC to socket | SO_TIMESTAMP or receive-loop timestamp | IRQ placement, ring pressure, kernel backlog, socket drops |
| Socket to shred metadata | After header validation | Slow copy, allocation, parser work, or CPU contention |
| Shred to useful entry | After FEC/reassembly | Missing shreds, late coding shreds, or decoder backlog |
| Entry to strategy | At the application decision point | Your own queue, locks, parsing, or downstream RPC |
Tune the receiver before blaming the provider
A raw UDP feed has no ordering, retransmission, or backpressure. The first receive loop should do as little as possible: drain the socket, record a timestamp and source, copy or hand off the datagram, and return for the next packet. Do not run transaction parsing, network calls, or unbounded logging in that hot path.
Linux exposes socket receive drops through the SO_RXQ_OVFL ancillary counter. The kernel’s RSS, RPS, and RFS guidance explains how receive work is distributed across queues and CPUs. Test one configuration at a time: larger buffers can hide bursts, while poor IRQ or CPU placement can add tail latency even when no packets are lost.
Compare providers only after the same receiver is stable. Otherwise the ranking measures which test machine happened to have more headroom, not which source delivered the best packet path.