Reading ping and hops on your game server panel

The RE:NODE panel shows three network figures, and each answers a different question. Ping on the dashboard is the round trip from your own browser to the machine your server runs on, sampled every few seconds. Average Ping on the Console tab is the mean round trip to that machine from probes in 12 countries, measured only when you press "Test now". Hops is the number of routers between our network and your connection, and "≥N" means the trace went quiet before it reached you. None of the three is the ping a player sees in the scoreboard, and none of them measures the game itself. Used together, they answer the first question in every lag complaint: is this the network, and if so, whose part of it. This post is what each figure is built from, what it misses, and the order to read them in when somebody says the server is lagging.

Three figures, three different measurements#

It helps to put all three side by side before going into any of them, because most confusion comes from reading one as if it were another.

The dashboard figure is live and personal. It tells you how your connection reaches the machine right now, and it says nothing about anybody else's. Average Ping is a snapshot of the world, taken the moment you ask for it and not again until you ask. Hops is about the path rather than the time, and like the dashboard figure it describes you, not your players.

That last point matters more than any number on the page. A server owner in one city looking at their own hop count learns about their own route. A player on another continent, on another provider, has a different route with a different count. When the complaint comes from a player, the strip gives you the context; the player has to give you their own measurement. We come back to how to ask for it below.

The dashboard Ping: your browser to the node#

On the server list, every row carries a Ping metric next to memory, CPU and disk. It is the round trip from the browser you are using to the node that hosts the server. A few details about how it is taken explain why it behaves the way it does.

• It is an HTTP request, timed. A browser cannot send an ICMP echo the way the ping command does, so the panel sends a tiny web request to the node and times how long the answer takes. The content of the answer is never read; any reply proves the round trip.
• Two requests, the faster kept. The first request of a pair may have to open a fresh connection, which costs extra round trips that are not what anyone means by ping. The second rides the connection the first opened. The panel keeps the quicker of the two.
• The figure is a median. It is the middle value of the last five samples, so one slow packet does not make the number jump.
• One sampler per node. Rows for servers on the same node share a single measurement, so a long server list does not multiply the traffic.
• Hidden tabs are not sampled. A dashboard left open in a background tab stops measuring until you look at it again.
• Over 250 ms it is flagged. The metric is marked in the alarm style when the figure passes 250 ms.

Because it is an HTTP timing in a browser rather than a raw ICMP packet, expect it to sit a few milliseconds above what ping prints from the same machine. Browser scheduling, the TLS layer and the web server answering all add a little. The difference is small and constant, so the figure is honest for comparisons: your number this evening against your number last week, or one node against another.

What the dashboard Ping is good for is answering "is it me?" quickly. If your own figure doubled since yesterday while nothing changed on the server, the first suspect is your own connection: wifi, a download running on the same line, a VPN you forgot was on. If it sits at its usual value while your players complain, your path is fine and the problem, if it is on the network at all, is on theirs.

Average Ping: the world, on demand#

Under the console sits a bar titled "Latency around the world". Press Test now and the panel asks the Globalping network (globalping.io), a free network of volunteer probes, to ping the server's node from one probe in each of 12 countries spread across Europe, the Middle East, the Americas, Africa, Asia and Oceania. Each probe sends three packets. Results arrive over a few seconds; the panel stops waiting after about 25 seconds and shows whatever has come back.

The grid shows one cell per country with its average in milliseconds, sorted fastest first, plus a "You" cell with your own browser figure for comparison. Cells are toned by speed: under 100 ms reads as good, 100 to 199 ms as middling, 200 ms and over as slow. If a probe lost packets, hovering the cell shows the percentage lost. A probe that never answered shows "no reply" instead of a number.

The Average Ping in the stats strip above the console is the mean of the probes that answered, rounded to a whole millisecond. Probes that failed are left out of the average rather than counted as zero or as infinity.

A few things to keep in mind when reading it:

• It only runs when you press the button. The test sends the node's address to a third party, so the panel never runs it on page load. Until you test, the strip shows a dash and its tooltip tells you to press "Test now". After a test there is a 20-second pause before the next one will start.
• The free network has a limit. If too many tests are run in a short time, Globalping refuses and the bar says "The free test limit was reached. Try again in a few minutes." That is their limit, not a fault on the server.
• Probes are real devices on real connections. Some sit in data centres, some on home lines. A single country showing a figure far above its neighbours may be that one probe's connection on that minute. Run the test again before reading anything into one odd cell.
• Three packets is a snapshot. It tells you the round trip at that moment. It does not show jitter over time or loss that comes and goes every few minutes. For that you need a longer test from the player's side, which is the subject of a later section.

Why the average looks high and is still fine

A world average is an average over the whole planet. Any single server, wherever it is, is close to some of those 12 countries and far from others, and the far ones pull the mean up. A server can be excellent for its own region and still show a three-digit Average Ping, because Australia and Brazil are a long way from almost everywhere. That is arithmetic, not a fault.

So read the grid, not just the average. The useful questions are: what do the countries your players actually live in show, and has that changed since the last time you looked? The bands in our post on game server ping by region give you a feel for what each distance should cost. If your players are mostly in two countries and both show two-digit figures with no loss, the network is doing its job, whatever the average says.

Hops: counting the routers#

The Hops figure in the stats strip is the number of routers between our side and the address you are visiting the panel from. A browser cannot see its own route, so the trace runs the other way: our side walks the path towards your address with tracepath, which sends UDP probes with increasing TTL values and notes which router answers at each step. It is the same principle as the traceroute tools you may already know.

 1?: [LOCALHOST]                      pmtu 1500 1:  10.0.0.1                          0.412ms 2:  192.0.2.17                        1.006ms 3:  198.51.100.4                      4.880ms ...14:  203.0.113.9                      31.207ms reached     Resume: pmtu 1500 hops 14 back 14

When the destination answers, tracepath prints a Resume: line with the real hop count, and the strip shows a plain number: 14. When it does not, the panel takes the last numbered line that had an address on it and shows that as a lower bound: ≥11. The tooltip says exactly that: "≥" means the last routers did not answer, so the real count is at least that many.

A ≥ figure is normal. Most home routers and many mobile networks drop the probes a trace depends on, so the trace runs into silence a hop or two before the end even though your connection is perfectly reachable. The panel stops a trace after four silent hops in a row at the end, and never traces further than 24 hops.

Some practical details:

• It is cached for ten minutes. A trace can take up to about twenty seconds, and routes do not change by the minute, so the result for an address is kept for ten minutes and the strip asks again on that interval. A route change will show up on the next refresh, not instantly.
• It shows a dash when it cannot measure. If your address is private or reserved (you are on the same network as the panel, or behind certain proxies), or a trace is still running, the strip shows a dash and tries again shortly.
• A VPN changes what is measured. If you browse through a VPN, the trace ends at the VPN's exit, not at your home. The count is then the distance to the VPN server.
• Your address is not stored. The cache is keyed on a hash of the address and holds only a count.

Why hops matter, and why they are not the whole story

Hop count does not translate into milliseconds directly. A modern router forwards a packet in well under a millisecond, so ten extra hops inside one city cost almost nothing. Distance costs far more: light in fibre covers roughly 200 km per millisecond, so a path that runs 3,000 km out of its way adds around 30 ms to the round trip whether it crosses five routers or fifteen.

Hops still matter, for three reasons:

1. They expose detours. If a player in a neighbouring country has 25 hops to the server while someone further away has 12, the first player's provider is probably sending traffic the long way round, through an exchange in another country. That is the classic cause of "my ping is bad but my friend's is fine".
2. Every hop is a queue. Each router is a place where packets can wait behind other traffic at a busy hour. More hops means more places for jitter and loss to come from, especially where traffic crosses between networks.
3. Comparison is useful even when the absolute number is not. Your count today against your count last week is a cheap way to notice that a route changed. If the hop count jumped and your ping rose with it, the route changed and you know where to look.

What hops cannot tell you is which hop is slow. For that you need a per-hop view, which is what MTR gives you. Our post on reading traceroute and MTR covers how to read one without being fooled by routers that deprioritise probe replies.

When players say the server lags#

"Lag" covers four or five unrelated problems, and the panel figures help with only one family of them. Before looking at any network number, rule out the server itself. The reasoning is simple: if the server is struggling, every player feels it at once, whatever their ping; if it is the network, the complaint follows particular players, places or times of day.

A working order:

1. Is it everyone or some people? If everyone rubber-bands at the same moment, look at the server first. If one player or one country is unhappy, it is almost certainly the network between them and the server.
2. Check the server graphs. The Console tab draws memory, CPU and disk against the plan's limits. A CPU line pinned at the limit while players complain means the server cannot keep up its tick rate; that feels like lag to every player and no network fix will touch it. Our post on what tick rate actually means has the in-game commands that show it per game.
3. Check your own dashboard Ping. If your figure is normal, the node is reachable and responsive from at least one place.
4. Run the world test. Press "Test now" and look at the countries your players come from. Normal figures and no loss mean the node's connectivity to that part of the world is fine at this moment.
5. Ask the complaining player for their own measurement. This is the step that actually locates the problem, because their path is the one in question.

If steps 2 to 4 are clean and one player still suffers, the problem is somewhere on that player's path: their wifi, their provider's routing, a congested link between networks at peak time. You cannot fix their provider, but you can give them a clear answer, and they can take a good measurement to their provider.

What to ask the player for

The panel's figures are measured from places that are not the player. Ask them to run a test from their own machine to the server's address (the IP shown on the panel, without the port, since ping does not use ports). On Windows:

$ ping -n 50 203.0.113.10$ tracert 203.0.113.10$ pathping 203.0.113.10

On Linux or macOS, with mtr installed:

$ ping -c 50 203.0.113.10$ mtr -rwc 100 203.0.113.10

Ask for the test at the time the lag happens, not the next morning. Evening congestion is real, and a clean test at 10:00 says nothing about 21:00. Fifty pings show the average, the spread between minimum and maximum (a rough read on jitter) and any loss. The mtr report or pathping output shows where along the path latency or loss starts and whether it carries through to the end.

Some networks drop ICMP to the destination, so a ping that times out completely while the game connects fine is not proof of anything. In that case the trace and the game's own ping display are the better evidence.

Matching numbers to symptoms#

Once you have the player's figures alongside yours, the common patterns read like this:

High and steady is the easiest case and the least fixable. A player 150 ms away will always be 150 ms away, and no setting on the server changes the speed of light. Games compensate in different ways; a co-op survival game hides 150 ms well, a competitive shooter does not.

Jitter and loss feel much worse than their averages suggest, because the game has to wait for or guess at missing updates. Our post on latency, jitter and packet loss goes through what each does to a game and how to tell them apart in a minute of ping. The short version for a player: plug in a cable, stop the download running on the same line, and test again. A surprising share of "the server lags" ends there.

The long-route case is the one where hop counts earn their place. If two players in the same city on different providers see 15 and 28 hops and a 40 ms difference in ping, the problem is the second provider's routing. The player can report it with their trace attached; providers sometimes change a route when a customer shows them the detour. Some players try a VPN to force a different route. Occasionally that helps, more often it adds distance; our post on whether a VPN lowers ping in games covers how to test it rather than guess.

A worked example#

Say a group of eight plays on a server most evenings. Six are in one country, two in a neighbouring one. One of the two starts reporting rubber-banding around 21:00 every evening.

You open the panel. The CPU graph shows the server comfortably below its limit while the complaints come in, and the other seven are not complaining, so it is not the server. Your dashboard Ping is at its usual value. You press "Test now": the country closest to the struggling player shows a normal two-digit figure with no packet loss.

So the node's link to that part of the world is fine, and your own path is fine. The suspect is the player's own path. You ask them to run mtr -rwc 100 (or pathping on Windows) at 21:00. Their report shows clean figures for the first eight hops, then latency rising by 60 ms and 4% loss from hop nine onwards, carried through to the final line. Hop nine is the point where their provider hands traffic to another network.

That is congestion at an interconnect at peak hour, and it is entirely outside your server. The useful thing you can do is tell the player plainly, and suggest they send that report to their provider with the time of day on it. A test at 10:00 the next morning would have shown nothing, which is why the timing of the request mattered.

Compare that with the opposite outcome: the player's trace is clean all the way, but in-game they still see delays. Then go back to the server side, because something other than the network is the cause: a plugin spiking the tick time, a save running every few minutes, a server sitting at its CPU limit only when that player's base is loaded.

What the panel figures cannot tell you#

It is worth being plain about the limits, because a number on a dashboard looks more authoritative than it is.

• None of them is the in-game ping. Games measure ping in their own way, often including a tick or two of processing on top of the network trip. A game showing 60 ms where ping shows 45 ms is normal.
• None of them measures your players' paths. The world test uses one probe per country, on that probe's provider. Your players use others.
• The world test is a moment. Three packets per probe, taken when you pressed the button. It does not catch a problem that comes and goes.
• The hop count describes our side to you. It is traced from our side to the address you browse from, which is a useful indicator of the distance and how straight the route is, but it is your path, not a player's.
• Loss on the world grid is a hint, not a verdict. A probe losing one of three packets may be that probe's own line. Loss that appears from several countries at once is worth a closer look; loss on one cell is worth a second test.

Used for what they are, the three figures save time. They rule out your own connection in a glance, show whether the node is reachable from where your players live, and turn a vague "it lags" into either "it is the server" or "it is somewhere on your path, please run this". That second answer is the one players most need and least often get.

FAQ#

Why is my Average Ping over 100 ms when the server feels fast?

Because it averages 12 countries spread across the world, and some of them are a long way from any single server. The far probes pull the mean up. Look at the cells for the countries your players live in; those are the figures that describe their experience.

What does "≥" in front of the hop count mean?

The trace stopped hearing answers before it reached your connection, usually because your home router or mobile network drops trace probes. The count shown is the last hop that answered, so the real figure is at least that. It is common and not a fault.

Can I run the world ping test automatically every hour?

No. It runs only when you press the button, because each test sends the node's address to a third-party probe network. There is also a short cooldown between tests and a rate limit on the free network, so frequent testing is not what it is for. For trends, run mtr on a schedule from a machine you control.

Does a lower hop count always mean lower ping?

No. Distance matters much more than the number of routers. A route with 18 hops inside one region can be faster than a 10-hop route that crosses a continent. Hops are most useful for spotting a detour or a route change, not for predicting milliseconds.

My dashboard Ping is higher than what the ping command shows. Which is right?

Both, measuring slightly different things. The dashboard times a small web request from the browser, which carries a few milliseconds of overhead that an ICMP ping does not. Use it to compare against itself over time; use ping for an absolute figure.

Is my IP address stored when the panel counts hops?

No. The result is cached for ten minutes under a hash of the address, and what is kept is a number. The world ping test sends the node's address to Globalping, which sees your address the way any website you call does.