How Quasar measures latency.
Every client in this space claims lower latency and none of them show their working. This page is the working. There are no benchmark numbers here, because honest ones need runs we have not published yet. What it does explain is the method, which is the part you can check against the client yourself.
Why the reported ping is not trustworthy
Minecraft shows a ping in the tab list, taken from what the server tells the client. A server is free to send whatever it likes there, and several large ones pin it to a flat 1ms for everybody.
That breaks more than a display. Anything derived from that number is derived from fiction, so a prediction budget or a tuning decision based on it is worthless exactly where it matters most.
Timing something the server cannot fake
Quasar measures instead. It records the moment you right-click a container and the moment the window packet arrives and the screen actually opens.
That round trip physically crossed the network twice. It cannot be spoofed by a value in a packet, because it is not a value in a packet, it is elapsed time. Round trips outside a sane window are discarded, and the result is what the Real Ping readout and the Stats HUD show. Until you open a menu it honestly shows two dashes rather than guessing.
Two pings, and the gap between them
A raw TCP connect is not the same measurement as a game round trip. Against a proxied or CDN-fronted server the connect terminates at a nearby edge, so it comes back fast and means very little about where the game actually is.
So the chart carries both, and the useful figure is the third one: what the client and protocol add on top of the raw socket. That gap is the only part of the total a client can honestly claim to work on.
What Auto-Tune decides
On joining a server, Auto-Tune holds you still for a few seconds, samples the link with real server-list pings, then classifies it. The thresholds are fixed and published rather than adaptive mystery:
- STABLEavg < 80ms, jitter < 15ms, no loss
- MODERATEavg < 200ms, jitter < 50ms, loss <= 10%
- UNSTABLEanything worse
- HIGH PING (stable)far away, but jitter < 50ms and loss <= 5%
The fourth one exists because a far-away link with low jitter and no loss is not unstable. It is just far away, and the client refuses to call it anything else.
The verdict picks a settings overlay for that session. It never writes your manual configuration, and it reverts when you disconnect. If you let it remember per server, the result is stored and re-applied next time rather than relearned.
Which numbers are exact and which are estimates
Block placements and breaks are exact. The server either confirms or contradicts each one, so the acceptance percentage is a fact, and it is the number that exposes why bridging fails on a bad connection.
Melee hit rate is not exact and is labelled with a tilde everywhere it appears. A hit is counted as landed when the target takes knockback or damage inside a window scaled to your ping, which means a genuine hit that produced no knockback can be missed. It is a good signal and a bad certainty, and the client says so.
- Place
- 98% exact
- Break
- 100% exact
- Hits
- ~64% estimate
- Ping
- 187/12 ms avg / jitter
- Rej
- 3 ghost blocks
- Corr
- 4rb 2tp rubber-bands / teleports
- Gaps
- 3t ticks
What none of this can do
It cannot lower your real ping. Distance and routing are physical, a client sits at one end of the link, and anyone claiming otherwise is selling something.
It also never drops, delays past its own tick, reorders or alters a packet. Socket tuning changes buffers and flags. Coalescing changes how many TCP segments a tick becomes. Combat priority changes when a flush happens, not what is in it. None of that can force through a hit the server rejected.