Measuring gRPC Latency
Learn how to measure Solana Yellowstone geyser gRPC latency the right way.
Before testing Yellowstone gRPC latency, make sure you follow this rule of thumb:
Your server should be in the same region as the gRPC endpoint you are connecting to.
For example, if you are connecting to grpc.ams.shyft.to, your server should be in Amsterdam. Same applies for all other regions. Once that’s in place, let’s address the latency question:
"Why am I getting 1s or more latency with gRPC. Isn't that slow?"
TLDR;
You are not actually receiving data with ~1 s latency.
This is a perceived delay caused by lack of precision in Solana’s timestamp — Solana stores blockTime only in seconds, without milliseconds. Because of this, when you calculate latency using blockTime, your result appears inflated (1s or more).
Why it Happen?
Developers commonly use:
gRPC latency = transaction receive time - transaction block time
However, it overlooks an important detail — Solana’s blockTime values are recorded only in seconds, with no millisecond precision. This means every transaction that occurs within the same second is assigned the same timestamp, even if they actually happened hundreds of milliseconds apart.
For example, transactions happening at 07:46:46.900 are still recorded as 07:46:46.000, making your measured latency seem much longer than it really is.
Example
Consider the following Solana blocks:
Solana typically produces 2–3 blocks per second. In reality, those blocks are spread across the full second (e.g., 07:46:46.100, 07:46:46.500, 07:46:46.900).
But since milliseconds are not stored, all are recorded as 07:46:46:000.
If a transaction actually occurred at 07:46:46.900 and your client received it at 07:46:47.200, the calculated latency would be:
07:46:47.200 − 07:46:46.000 = 1.2 s
The true latency, however, is only about 300 ms.
Key points
The gRPC stream is not delivering data late.
The ~1 s gap seen in benchmarks is a timestamp precision issue, not a performance issue.
Last updated
Was this helpful?