How to measure response time and trace the route: ping, mtr, tracert

For an administrator or manager who wants to know how well a server in Europe will work from their office. You will measure response time and packet loss, run a trace in both directions, check the port you need and collect the data that helps support find the cause.

What you will need#

• An address to test. If you already have a server, it is the IP address support sent you. If you are still choosing a country, ask support for a test address in the location you need.
• A computer on the network people will work from. Ideally an office one, connected by cable. Test Wi-Fi and mobile internet separately: they add delay and loss of their own.
• Tools. Windows already has ping, tracert, pathping and PowerShell. Linux and macOS have ping; mtr has to be installed from packages.

# Debian, Ubuntu
sudo apt install mtr-tiny
# AlmaLinux, Rocky Linux, RHEL
sudo dnf install mtr
# macOS (Homebrew)
brew install mtr

In the examples 203.0.113.10 is the server address and 198.51.100.25 is your office’s external address. These are example addresses; substitute your own.

Step 1 ping: response time and loss#

The four packets Windows sends by default are not enough. Send at least 50. On Windows (Command Prompt or PowerShell):

ping /n 50 203.0.113.10

On Linux and macOS:

ping -c 50 203.0.113.10

The summary on Windows (a localised system prints it in its own language):

Ping statistics for 203.0.113.10:
    Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 21ms, Average = 15ms

On Linux (on macOS the last line starts with round-trip min/avg/max/stddev):

50 packets transmitted, 50 received, 0% packet loss, time 49072ms
rtt min/avg/max/mdev = 14.412/15.238/21.067/1.104 ms

To watch for longer, run ping /t 203.0.113.10 on Windows, or ping without -c on Linux and macOS. Press Ctrl+C to stop.

What to compare the result with#

This is the minimum response time in our measurements from Ukrainian providers’ networks, October 2026. Your result depends on your provider and route; on mobile internet the response time is higher. Traffic from Ukraine to the other countries reaches Poland first.

What these numbers mean for work#

The thresholds in the table are a rule of thumb from practice, not a standard.

Stability matters more than a few milliseconds: a steady 40 ms beats 15 ms with spikes to 300 ms. At 1–2% loss (also a rule of thumb) the picture already stutters and input lags.

With an accounting database it matters where the client application runs. If users log in to the server over a remote desktop and both the application and the database are on it, only the screen image crosses the network, and the table above applies. If the application runs in the office and talks to a database in Europe, every action takes dozens or even hundreds of requests, and the delay multiplies. For illustration: 300 sequential requests at 15 ms each mean 4.5 s of waiting; at 40 ms each, 12 s. So keep the application next to the database, and do not open a file-based database over the internet as a network share.

Step 2 Trace to the server#

A trace shows the hops between you and the server and the response time of each.

Windows: tracert, pathping, WinMTR#

tracert /d 203.0.113.10
pathping /n 203.0.113.10

tracert quickly lists the hops with three measurements for each; /d turns off name lookups. pathping first builds the route, then sends 100 requests to every hop and counts the loss, so it runs for several minutes; /n also turns off name lookups.

The most convenient report for support comes from WinMTR — a free, open-source program that needs no installation. Download it only from the project page.

1. Unpack the archive, run WinMTR.exe, enter the server address in the Host field and press Start.
2. Wait until the Sent column reaches at least 100 packets, then press Stop.
3. Press Copy Text to clipboard or Export TEXT — the report is needed as text.

Linux and macOS: mtr#

In report mode mtr runs the given number of cycles, prints a table and exits. On macOS run it with sudo.

mtr -r -w -b -c 100 203.0.113.10

Without -r the program runs interactively; press q to quit. All options are described in the mtr documentation.

How to read a trace#

A sample report (example addresses):

HOST: office-pc             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1          0.0%   100    0.6   0.7   0.5   1.9   0.2
  2.|-- 198.51.100.1         0.0%   100    1.8   2.1   1.5   6.3   0.6
  3.|-- 192.0.2.17          62.0%   100   14.9  15.3  14.6  19.2   0.7
  4.|-- ???                 100.0   100    0.0   0.0   0.0   0.0   0.0
  5.|-- 192.0.2.94           0.0%   100   15.2  15.4  14.8  21.5   0.8
  6.|-- 203.0.113.10         0.0%   100   15.6  15.7  15.1  18.4   0.5

Loss% is loss, Snt is packets sent, then times in milliseconds: last, average, best, worst and the spread.

1. Start with the last line — that is your server. If it shows 0% loss and Avg is close to Best, the connection is fine whatever the lines above show.
2. Loss on an intermediate hop only (line 3), with 0% further on, is not a problem. Routers limit the ICMP replies they send themselves but forward transit traffic normally.
3. A ??? line is a hop that does not answer at all. That is normal too if the later hops answer.
4. A real problem is loss that appears at some hop and stays at about the same level down to the last line.
5. The same goes for delay. A jump that persists to the end (between lines 2 and 3) is the real travel time of that segment; in the example it is the path from Ukraine to Poland. A jump on a single hop, after which the time drops again, only means that hop is slow to answer ICMP.

Step 3 Trace in the reverse direction#

Packets to the server and back often take different routes. A trace from your computer shows only the hops of the forward path, although its times and loss depend on both routes. So run a trace from the server to your office’s external address as well.

The external address is shown on your router’s status page. If you connect to the server directly, without a VPN, the server can show it too. On Linux (SSH session) it is the first value in the output of this command (run it before sudo -i):

echo $SSH_CONNECTION

On Windows Server (RDP session on the standard port), in PowerShell:

Get-NetTCPConnection -LocalPort 3389 -State Established | Select-Object RemoteAddress

Then run the same commands on the server with the office address: mtr -r -w -b -c 100 198.51.100.25 on Linux (install mtr there first) or pathping /n 198.51.100.25 on Windows Server. The office router may not answer ping — the trace will then end in a line with 100% loss or asterisks; look at the hops before it.

Step 4 Check the port#

ping tests ICMP only. A separate TCP check shows whether the port you need is open. On Windows (PowerShell), an example for RDP:

Test-NetConnection 203.0.113.10 -Port 3389

The line TcpTestSucceeded : True means the port is open (see the Microsoft documentation). On Linux and macOS, an example for SSH:

nc -vz -w 5 203.0.113.10 22

Success is a message containing succeeded, Connected or open (depending on the nc version). If Linux has no nc, install the netcat-openbsd package (Debian, Ubuntu) or nmap-ncat (AlmaLinux, Rocky Linux, RHEL).

If ping works but the port is closed, look for the cause on the server: the service is not running or the firewall blocks the port.

How to check the result#

• The last hop shows 0% loss over at least 100 packets.
• The minimum time is close to the figures above for your chosen country and your city, and the average is close to the minimum.
• The port you need answers: TcpTestSucceeded : True or succeeded.
• A repeat measurement during working hours and in the evening gives a similar picture.

Common mistakes#

• Judging by four packets. Loss of 1–2% does not show in such a sample.
• Measuring over Wi-Fi or mobile internet. First ping your own router (the first hop of the trace): if loss and spread are already there, the cause is in your network.
• A VPN left on. With it traffic takes a different route. Measure the way users will actually work.
• Deciding “the server is down” because Windows Server does not answer ping. A freshly installed Windows Server usually does not answer echo requests: its firewall blocks them. Check the port (step 4). If you need ping, allow inbound ICMPv4 echo requests from your own address only; do not turn the firewall off altogether.

When to contact support and what to attach#

Write to us if loss on the last hop repeats across several measurements, the response time stays noticeably higher than expected, or a port that should be open is unreachable although the service is running. Attach:

• an mtr or WinMTR report as text, not a screenshot — at least 100 packets, preferably in both directions;
• the date and time of the measurement and when the problem began;
• your external IP address and the server address;
• your provider’s name and the connection type (fibre, mobile internet and so on);
• what exactly works poorly: remote desktop, accounting database, file transfer.

Technical support is available around the clock: phone +38 044 206 08 08, email info@united.net.ua.

What next#

• Locations.
• How to choose a country for your server.
• Secure RDP.
• Dedicated server catalogue.