Is the ping in the RedM server browser the same as the ping in game?

Not necessarily. The browser figure is a single estimate taken from outside the session, and it is measured against the server's listing rather than against a running game. The figure a server shows you once you are connected, in its own HUD or player list, is measured on the connection you are actually playing on. Where the two disagree, believe the one taken while you are in the world, and take several readings rather than one.

My ping is low and the game still feels late. Why?

Ping measures the trip. It says nothing about how long the server takes to think once your message arrives. A server that is overloaded, or running a script that stalls the frame, feels late at any ping, and the giveaway is that it feels late for the local players too. Ask in the server's Discord whether others are seeing it at the same time. If everybody is, the number on your screen is not the problem.

Will a VPN lower my ping to an overseas RedM server?

Usually not. A VPN adds a stop on the way, and physical distance still sets the floor, so the normal result is the same route with extra milliseconds. The exception is a genuinely bad route, where your ISP hands traffic off badly and a VPN happens to take a better path. That is worth testing rather than assuming: measure without it, measure with it, at the same hour, and keep whichever reading is better.

How long should I test for before trusting the number?

Long enough to catch a spike. Four packets is not a measurement. Run at least a hundred, which is roughly a hundred seconds, and do it once in the evening peak between about 7 pm and 11 pm local time and once outside it. The difference between those two readings tells you more about your evenings than either reading does on its own.

My ping is worse in town than out in the wilderness. Is that the route?

Rarely. Your route does not change because your character walked into Valentine. What changes is how much the server is doing: more players, more entities and more scripts in one place. If a reading taken standing in a busy town is much worse than one taken alone on a ridge, that is a server load pattern rather than a network one, and it will show up for everybody in that town.

How to test a RedM server's connection from Australia

Q: The server does not answer ping at all. Is that a bad sign?

No. Plenty of hosts filter ICMP, which is what ping and tracert use, while the game port answers normally. A row of timeouts tells you the box will not talk to that particular tool, not that it is unreachable or badly run. When that happens, skip to measuring inside the game.

What you are actually trying to find out

Three separate things get called "the ping", and they fail in different ways. Keeping them apart is most of the skill here.

The average. How long a message takes to reach the server and come back. Distance sets the floor and nothing you can buy moves it, because the speed of light through glass is not negotiable.
The variation, or jitter. How much that figure moves around between one message and the next. A steady 200 is a better evening than a 90 that jumps to 400 twice a minute, because the game can hide a delay it can predict and cannot hide one it cannot.
The loss. How often a message never arrives. This is the one that reads as rubber banding, as being shot through a wall, and as a horse that snaps back to where it was two seconds ago. A route with one per cent loss ruins evenings that a route with eighty extra milliseconds would not.

A four packet ping tells you about the first of those and nothing about the other two, which is why it is the wrong test to run and the only one most people run.

What this page does not cover

Which server to pick, what a given ping feels like to play at, and how to judge a roleplay community are covered properly on the main site, in Australian RedM servers. There is no point in two hosts printing the same article, so this one stays on the measuring.

The three commands, and what each is for

All three ship with Windows. Open Start, type cmd, and run them there. You need the server's connect address first, which is usually published in its Discord. A hostname works as well as an IP address.

1. A long ping, for the average and the loss

ping -n 100 your.server.address

The -n 100 is the whole point. It sends a hundred packets, about a hundred seconds of it, and prints minimum, maximum and average at the end along with how many were lost. The default of four packets can miss a spike that happens every thirty seconds, and that spike is the thing you are looking for.

Read the gap between minimum and maximum, not the average alone. Minimum 182, maximum 191 is a stable route to a distant place. Minimum 42, maximum 380 is a local server behind something broken between you and the modem.

2. A traceroute, for where the box actually is

tracert your.server.address

This lists every router between you and the server. The useful part is the names: hop names usually carry airport or city codes, so a route that runs through syd and stops there is in Sydney, and one that passes syd then lax or sjc has left the country. Watch for the jump where the round trip figure adds a hundred milliseconds at once. That is the ocean.

This matters because a server tagged AU in the client's list may be renting a box in Los Angeles, and the route is harder to misrepresent than a tag is. Add -d if you want it to finish faster, though that turns off the names that make it worth running.

3. Pathping, for which hop is dropping packets

pathping your.server.address

Slow, several minutes on a long route, and the only one of the three that tells you where the loss is. It walks the route, sends a batch of packets to each hop in turn, and prints a per hop loss percentage. If loss appears at hop three and continues to the end, the problem is three hops away from you and is almost certainly your ISP's to fix. If it appears only at the last line, it is at the far end.

Read the middle of a traceroute loosely

Routers treat ping traffic as the lowest priority work they have, so a middle hop showing forty per cent loss or a wild time while everything after it is clean is normal and means nothing. Only the last line, the server itself, is worth taking seriously. This one misreading sends more people chasing imaginary faults than any other.

Reading the result

Six readings cover nearly everything you will see. The right hand column is the next thing to do, not a verdict.

Interpreting a hundred packet ping and a traceroute against a game server.
What you see	What it usually means	What to do next
Average 45, maximum 55, no loss	A short, clean route. The floor is set by distance and there is nothing in the way.	Nothing. Go and play.
Average 190, maximum 205, no loss	Far away but steady. Predictable delay is the kind the game handles best.	Decide whether you want that distance, then test it in a gunfight rather than on paper.
Average 60, maximum 400, no loss	Jitter, and at that average it is almost certainly at your end or in your street.	Test wired instead of wireless, stop any download, and run it again at a quiet hour.
One to three per cent loss, steady, at the last hop	A real fault on the route or at the far end. Small numbers here cause large problems.	Ping something else well known to see whether it is only this server, then run pathping.
Heavy loss at a middle hop, clean at the end	A router deprioritising ping traffic. Not a fault.	Ignore it entirely.
Every packet times out, but the game connects	ICMP is filtered at the host. Common, and says nothing about the server.	Measure inside the game instead, as below.

Measuring inside the game, which is the reading that counts

Everything above measures a route. It does not measure the server's own load, and the two fail independently. A box can sit eight milliseconds from you and still answer late, because how long a server takes to think once your message lands is not a network question at all.

Ignore the first few minutes. Your first join to any server downloads its resources, so the client is busy in a way it will never be again. Any reading taken during that is worthless.
Use the figure the server shows you, not the browser's. Most servers display a ping in their own HUD or player list. That one is measured on the session you are actually in.
Take it twice, in different places. Once standing alone somewhere quiet, once in the busiest town at a busy hour. A large gap between the two is server load, and it is the thing that ruins an evening on paper-perfect latency.
Test the thing you care about. A gunfight, or any minigame with a moving window, tells you in thirty seconds what an hour of pinging cannot. The window closes on server time, so distance shows up there first.
Go back at 8 pm on a Wednesday. Both the route and the server behave differently under load, and the evening peak is when you will actually be playing.

Ruling out your own end first

Before blaming a server, spend five minutes proving the problem is not in your house. In rough order of how often each one turns out to be the answer:

Wireless. Wifi adds variation even when it looks fine, and variation is the expensive kind of problem. Test once on a cable. If the jitter disappears, you have your answer.
Something else using the connection. A console updating in another room will not change your average much and will wreck your maximum.
The evening peak. Congestion between roughly 7 pm and 11 pm is a normal property of a residential connection. Compare a reading then against one at lunchtime.
Powerline adapters and old cabling. Both produce exactly the pattern of occasional loss that is hardest to attribute, because everything else looks fine.
A VPN you forgot was running. Worth checking before you conclude anything about a route.

A useful control is to ping a well known address that is definitely close to you and one that is definitely far away, in the same sitting. If both look bad, the server was never the problem.

Disclosure, and running these checks on us

Who wrote this

This guide is published by the people who run The Pub, an Australian RedM server. That is a conflict of interest and you should read the page with it in mind. Every check on this page works against our server exactly as it works against anybody else's, which is the only reason it is worth publishing under our name.

The checkable facts, so you can hold them against the readings rather than taking them on trust. The Pub is hosted in Sydney, it is free to join, and its framework is written from scratch rather than built on VORP or RSGCore. Entry is open, with no application to fill in. It is in closed testing at the time of writing, so a temporary allowlist is on until it opens, and while that is true you can measure the route to the box but you cannot log in to take an in-game reading.

Ask in the Discord for the connect address, run the three commands above against it, and see whether a Sydney host looks like a Sydney host from where you are sitting. Then do the same to every other server you are considering. A server that will not tell you its address has answered a different question.

None of that makes it the right server for you, and this page is not the place that argument belongs. It is on the main site, at redm.thepub.beer, where you can weigh it knowing who wrote it.

Common questions

Is the ping in the server browser the same as the ping in game?

Not necessarily. The browser figure is one estimate taken from outside the session. The figure a server shows you once you are connected is measured on the connection you are playing on. Where they disagree, believe the second one, and take it more than once.

My ping is low and the game still feels late.

Ping measures the trip, not how long the server takes to think once your message arrives. An overloaded server feels late at any ping, and the giveaway is that the local players feel it too. Ask in the Discord whether anyone else is seeing it.

Will a VPN lower my ping to an overseas server?

Usually not. It adds a stop, and distance still sets the floor. The exception is a genuinely bad route where the VPN happens to take a better path, which is worth measuring both ways at the same hour rather than assuming in either direction.

The server does not answer ping at all.

Plenty of hosts filter the traffic that ping and tracert use while the game port answers normally. A row of timeouts tells you the box will not talk to that tool. It does not tell you anything about the server.

How long should I test for?

Long enough to catch a spike. A hundred packets, which is about a hundred seconds, once during the evening peak and once outside it. The difference between those two readings is the useful part.

Why is my ping worse in town than in the wilderness?

Your route did not change because your character walked into Valentine. The server's workload did. A large gap between a quiet reading and a busy town reading is load, and everybody in that town is seeing it.

Is there an Australian RedM server worth testing this on?

There are a few, and they are hard to filter for in the client's list. The main site covers finding them in Australian RedM servers, including what to ask a server that will not say where it is hosted.

RedM vs FiveM

An honest comparison for people who already know FiveM: what carries over, what does not, and what the smaller ecosystem costs.

Read the comparison

Installing RedM

Prerequisites, the first run patch, where the files live and the errors that stop most first installs. Covered on the main site rather than repeated here.

Read the install guide