How to compare Solana ShredStream and gRPC latency

Compare the same data, on the same machine

A ping measures a network round trip. It does not measure when a Solana transaction or Shred reaches your application. A useful feed comparison pairs the same event from two sources and records each arrival on one receiver.

Run Shred-versus-Shred and gRPC-versus-gRPC tests separately. Raw packets and processed validator notifications represent different stages of the data pipeline; their arrival numbers are not interchangeable. These tools compare compatible feeds and apply no provider-specific time adjustment.

1. Compare two ShredStream feeds

Use one receiving server and two unused UDP ports. Configure each provider to deliver to the server's public IP with its own port. Allow those ports through your firewall. The local bind address 0.0.0.0 is not a destination to enter in the provider's console.

{
  "sources": [
    {"name": "feed-a", "bind": "0.0.0.0:21001"},
    {"name": "feed-b", "bind": "0.0.0.0:21002"}
  ]
}

Install Rust 1.89 or newer and a C toolchain. Clone and build the tool, then edit sources.local.json to match the ports before running:

git clone https://github.com/SolBrisk/solana-shred-latency.git
cd solana-shred-latency
cargo build --release --locked
cp examples/sources.json sources.local.json
# Edit sources.local.json before running.
./target/release/solana-shred-latency \
  --sources sources.local.json --warmup 5 \
  --duration 60 --output report.json

On Linux, the default uses SO_TIMESTAMPNS software kernel-ingress timestamps to reduce receiver-thread scheduling bias. On other platforms, or with userspace timing selected, the result includes application scheduling and queue delay. Keep that distinction in any published result.

Data Shreds are compared by default. The test warms up, measures for the selected duration, then allows a matching drain for already observed identities. Start a fresh timed run after every feed is active. The tool never shares an occupied port or changes your existing forwarding rules.

2. Compare two Yellowstone gRPC feeds

Authorize the same receiver with both providers. Use matching event types, commitment and filters. Each token file should contain only the relevant subscription token, with file permissions restricted to 600. Replace the .example hostname below with a real compatible endpoint before running.

{
  "sources": [
    {"name": "solbrisk-fra", "endpoint": "https://fra-grpc.solbrisk.com:443", "token_file": "fra-token.local"},
    {"name": "other-provider", "endpoint": "https://your-provider.example:443", "token_file": "other-token.local"}
  ]
}

git clone https://github.com/SolBrisk/solana-grpc-latency.git
cd solana-grpc-latency
cargo build --release --locked
cp examples/sources.json sources.local.json
# Edit sources.local.json and prepare private token files.
./target/release/solana-grpc-latency \
  --sources sources.local.json --kind transactions \
  --tx-include 11111111111111111111111111111111 \
  --commitment processed --warmup 5 \
  --duration 60 --output report.json

The system-program address is a valid transaction-filter example. Use the same addresses your application actually follows for a representative test. For a simple connectivity check, use --kind slots and omit transaction filter flags; slot notification timing is a different benchmark from transaction arrival.

A provider-supplied creation timestamp and your local wall clock are not necessarily synchronized. The comparison tool instead timestamps matching arrivals on one receiver. A reconnect, slow output or local backpressure can distort results, so retain those diagnostics.

3. Read arrival differences and coverage separately

The first configured source is the baseline. Both tools define the paired difference as:

arrival_difference_us = candidate arrival − baseline arrival

• Positive: the baseline arrived earlier. Negative: the candidate arrived earlier.
• p50, p95 and p99 describe the distribution of signed paired differences. They are not each provider's absolute latency from the leader.
• First-arrival percentages count matched events. Read the sample count and unmatched coverage alongside these percentages.
• baseline_without_match and candidate_without_match are events observed without a matching counterpart inside the window. They are not a verified network packet-loss rate.

For UDP, inspect kernel overflow counters, application queue drops, effective receive-buffer sizes and queue lag. Kernel socket drops are local receiver diagnostics, not a count of every packet lost along the network. For gRPC, inspect reconnects, backpressure, matching evictions and queue lag.

A clean_run=false result requires investigation before a performance claim. A clean run only means the tool's local checks passed; it does not prove complete upstream coverage, authenticate raw Shreds or certify a provider. Existing report files are not overwritten: choose a new output name for each run.

4. Make the result reproducible

Repeat across several times of day and enough matching events to support the percentiles you report. Change one variable at a time. Preserve the complete JSON report, not only a screenshot of a favorable number.

• Receiver location, operating system, tool version and timestamp mode.
• Source regions, baseline order, event kind, commitment and filters.
• Start time, warmup, duration, matching window, sample counts and sampling flags.
• Unmatched coverage, reconnects, drops, queue lag and the clean-run result. Remove credentials from anything you share.