# Measuring gRPC Latency

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 <mark style="color:yellow;">grpc.ams.shyft.to,</mark> your server should be in Amsterdam. Same applies for all other regions. Once that’s in place, let’s address the latency question:

<mark style="color:yellow;">"Why am I getting 1s or more latency with gRPC. Isn't that slow?"</mark>

#### TLDR;

**You are not actually receiving data with \~1 s latency.**

This is a **perceived delay** caused by the lack of precision in Solana’s timestamp — as 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:

<mark style="color:yellow;">**gRPC latency = transaction receive time - transaction block time**</mark>

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 <mark style="color:yellow;">07:46:46.900</mark> are still recorded as <mark style="color:yellow;">07:46:46.000</mark>, making your measured latency seem much longer than it really is.

#### Example

Consider the following Solana blocks:

| Block                                           | Block Time |
| ----------------------------------------------- | ---------- |
| [319464973](https://solscan.io/block/319464973) | 07:46:46   |
| [319464974](https://solscan.io/block/319464974) | 07:46:46   |
| [319464975](https://solscan.io/block/319464975) | 07:46:47   |
| [319464976](https://solscan.io/block/319464976) | 07:46:47   |

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.