FAQ

Real-world game latency rankings. Players run the pingrank CLI while they play; it measures latency, jitter, and loss to the game servers they actually connect to, and — only when they choose to — submits those stats. Every ranking row combines many players on one ISP; nothing about an individual player is published.

Each session is split into per-server segments with their own latency percentiles. The p50, p95, jitter, and loss figures blend only measurement methods we can vouch for:

direct

The classic ping: a tiny “are you there?” packet sent to the game server, timed until the reply comes back.

protocol

A question asked in the game's own server protocol — a Source-engine server query, for example — sent over the same UDP path and port the match itself uses. Preferred over a plain ping because it times the exact route your game traffic takes.

tcp-estats

For games that talk to their server over TCP, Windows already keeps a live round-trip estimate for every connection. We read the number the kernel measured — no extra packets are sent.

Last-hop is normally excluded. The exception is a game whose servers won't answer any probe: there we use last-hop, and only when steady two-way match traffic confirms we timed the real path. Those numbers read slightly low, and the game's page says so. A measurement that switched methods midway is never averaged in, and traffic that rides a relay network is reported separately as relay% — it is never passed off as server latency.

From two sources, both of them ordinary and above board — no code ever goes near the game.

• The game's own log files. Many games write the servers they join straight into their own text logs on disk. We read that file after the game has written it — the same file you could open in Notepad — and pull out the server addresses and ports it recorded.
• Windows' built-in network telemetry. For games that don't log their servers, we listen to Event Tracing for Windows (ETW) — the documented Microsoft-Windows-Kernel-Network provider. As UDP game traffic flows, Windows itself emits a small event for each datagram carrying only the header facts: which process, the local and remote address and port, and how many bytes. That is enough to see which endpoint your game is talking to, and to confirm the conversation is two-way rather than background chatter.

Both are read-only observations of things the operating system and the game already produced. Crucially, here is what pingrank never does:

• No DLL injection — nothing is loaded into the game.
• No reading or writing of the game's memory.
• No hooking, patching, or modifying game files.
• No packet-capture driver, and it never reads the contents of your traffic — only the header metadata Windows reports (addresses, ports, packet counts).

Because the game process is never touched and every source is a documented Windows facility or a file the game wrote itself, there is nothing for an anti-cheat system to flag. pingrank looks exactly like what it is — a bystander watching public signposts, not a program reaching into the game.

Yes. The full source for the Windows app — the CLI, the background service, and the tray — is public at github.com/bpbp-boop/pingrank-cli under the MIT licence. You don't have to take this page's word for anything: the code shows how the app detects games, how it measures latency, and every field a shared recording contains.

GitHub Actions builds every release from that source and attests each build. Run gh attestation verify <file> --owner bpbp-boop to prove a downloaded installer came from the published code.

Normally we measure ping the direct way: send the game server a tiny “are you there?” packet and time how long the reply takes to come back. That round trip is your ping.

But some game servers are set up to silently ignore those packets — a firewall throws them away and never answers. When a server does that, we simply can't ask it directly. Rather than report nothing, we trace the route your traffic takes toward that server and measure to the last machine along the path that does answer — the final router before the game server, almost always sitting in the same datacentre on the same network. That is the last-hop measurement.

Think of it like driving to a house at the end of a private driveway. You can't get a reading from the front door, so you take one from the gate at the bottom of the drive. The gate is a few metres short of the door, but it tells you almost exactly how far you travelled — the whole journey across town is already accounted for; only the last few steps are missing.

So a last-hop number runs a little below true in-game ping (often 10–30 ms short) and we're careful to call it an estimate — a lower bound, never dressed up as a direct reading. It's the best measurement available when a server won't answer, and because the part that actually differs between ISPs — the routing and peering across the internet — is fully captured, it stays a fair like-for-like comparison. Games where this applies say so on their own page.

Some games never let your traffic reach the game server directly. Instead it enters the publisher's own private network at a doorway near you and rides their internal backbone the rest of the way. The best-known example is Valve's Steam Datagram Relay (SDR), which carries CS2 and Dota 2 matches — it hides server addresses to blunt denial-of-service attacks, and can route around congested public internet paths.

For a ranking, relayed traffic is a trap: timing the relay only measures the short hop to that nearby doorway, and beyond it the relay network chooses the route — your ISP has nothing to do with it. Counting it as ping would flatter every ISP that happens to sit near a relay entrance. So the share of traffic seen riding a relay is reported as its own relay% column and never blended into the latency numbers.

Most games run every match on a dedicated server in a datacentre. A few instead pick one player in the lobby and make their machine the host — peer-to-peer, marked P2P here. Everyone else in the match connects to that player's home connection.

That changes what a ping means. Against a dedicated server, your ping mostly measures your ISP's route to a fixed, well-connected building — repeat the measurement tomorrow and it tells the same story. Against a player host, half the path belongs to a stranger: their city, their ISP, their Wi-Fi. A host across town gives you a great number; a host on another continent gives you a terrible one — and neither says much about your ISP.

We still measure and rank these games. Over many sessions the hosts average out, and a large gap between ISPs is still real. But the numbers vary far more than for server-hosted games, so every player-hosted game says so at the top of its page — take its rankings as a rough guide, not a verdict.

Ping is the round trip a piece of your game's data makes to the server and back, in milliseconds — lower is better. One number can't describe thousands of pings, so the board shows a few views of them:

p50

The typical ping. Line every measured ping up from fastest to slowest; this is the middle one. Half were faster, half slower — it's what the game feels like most of the time.

p95

The rough-moment ping: 19 of every 20 pings were faster than this. A p95 far above p50 means the connection is fine most of the time but suffers lag spikes.

jitter

How much the ping wobbles from moment to moment. A steady 40 ms feels smoother than a 20 ms that keeps jumping around — jitter is what makes a game feel stuttery.

loss

The share of data packets that never arrived and had to be resent or skipped. Even 1–2% can cause rubber-banding and shots that don't register.

relay

The share of traffic that travelled through the game's own relay servers — a middleman, like Valve's SDR — instead of straight to the game server. It's reported separately and never mixed into the ping numbers.

sessions

How many recorded play sessions the row is built from. More sessions means more players backing the numbers — and more trustworthy rankings.

access

How the ISP hands out Internet connections on this network — see access detection below.

region

The country the network's addresses are registered in, so you can compare how a game performs from different parts of the world. It is worked out on the server from the submitting connection at the moment a session arrives — the address itself is discarded, never stored.

Access is how your ISP hands you the Internet. Some connections get a public IPv4 address of their own; many sit behind an ISP translation layer instead — carrier-grade NAT (CGNAT), NAT64 or 464XLAT on IPv6-only access, DS-Lite, or address-and-port sharing. That layer is invisible in a speed test but matters for gaming: it changes NAT behaviour, can break hosting and peer-to-peer play, and adds a translation hop you never see. Rankings combine an ISP's access types into one result; open the ISP detail page to see which access types its players have observed.

pingrank access classifies a connection from evidence it gathers locally:

• It asks reflectors in different regions — small servers that simply report back what address and port your traffic appears to come from — over UDP, TCP, and HTTPS.
• It compares that outside view with the external address your own router reports. When the two differ, something upstream is translating.
• On IPv6-only access it discovers NAT64 prefixes and verifies them with a real connection to an IPv4 reflector.
• Source-port allocation patterns expose address-and-port sharing.

One machine cannot always tell ISP-level sharing from an ordinary home LAN, so the server adds fleet correlation: submissions carry one-way keyed correlation values (never raw addresses), and a network is only confirmed as sharing addresses when at least three unrelated installations appear behind the same public IPv4 at the same time while clearly being different households (three distinct IPv6 networks). A family playing on one connection never counts as CGNAT.

ISP detail pages show the access classifications observed for that network, along with confidence, contributing players, sessions, and IPv6 availability. Inconclusive results remain labelled as such — missing router information is not evidence for or against CGNAT.

native public IPv4

The device has a directly usable public IPv4 path — no upstream translation detected.

no visible upstream translation

Only your own router's NAT is visible. This does not prove upstream address sharing is absent.

ISP-level address sharing

Independent observations show a translation layer beyond the local network — CGNAT, confirmed by fleet correlation.

NAT64

IPv6-only access reaching the IPv4 Internet through the ISP's translator; a discovered NAT64 prefix passed a verified connection to an IPv4 reflector.

likely 464XLAT

Verified NAT64 plus working IPv4 sockets — IPv4 apps running over IPv6-only access via a local translation layer.

likely DS-Lite

The router or the machine itself showed signs of DS-Lite — IPv4 tunnelled to the ISP over IPv6.

likely address-and-port sharing

Your traffic keeps getting ports from one narrow band — the pattern of several customers sharing one address, each holding a slice of its ports.

undetermined

The available measurements are inconclusive. Missing evidence is not evidence.

A submitted session is the per-server stats worked out on your machine (latency percentiles, jitter, loss), the game ID, client version, and access-path evidence, plus a random 128-bit installation ID generated locally — no MAC address, hardware ID, or account. The public source code shows each field the app sends.

The server uses your IP once, in memory, to work out your ISP's ASN, then discards it — it is never logged or stored. Exact addresses and source ports are replaced with one-way keyed correlation values before anything is stored, and neither those values nor any individual observation is ever published. Public access tables only show rows backed by at least five distinct installations. The complete inventory is on the privacy page.

Download: install PingRank.gg for Windows and leave its background service running while you play. It detects supported games and shares verified recordings automatically. Latency rows appear immediately; access rows appear once five different players on your network get the same result.