Measuring…
The verdict for this game appears once the first full second of packets is in.
Comparing with other tests to this server…
Measuring…
The verdict for this game appears once the first full second of packets is in.
Comparing with other tests to this server…
Are you sure you want to delete all results?
| Date & Time | Duration | Avg Ping | Avg Jitter | Packet Loss | Actions |
|---|
Dying to someone you never saw? Rifle rounds that clearly connected and did nothing?
Hell Let Loose puts a hundred players into one continuous battlefield with no instancing and no small rooms to hide the problem in. Every infantryman, every tank and every artillery piece on that map is part of the same simulation, and your client is receiving updates about all of it. When a connection cannot keep up with that, the game does not warn you - it simply stops agreeing with what you saw, and the first evidence is usually a death you cannot account for.
What this test sends: 30 packets per second of 350 bytes, matching Hell Let Loose rather than a generic ping. estimated
Team17 publishes no rate; 100-player Unreal servers.
Run the test above for at least 60 seconds. Here is what each number means for this game specifically.
The player who shot you was drawn on your screen from interpolated updates. If those updates arrive unevenly, they were further along their actual path than you were shown - sometimes far enough that they had a clean line on you while your screen still had them behind a wall. That is the mechanism behind most deaths that feel impossible here.
Hell Let Loose gives very little confirmation of a hit, so a shot lost in transit produces the same experience as a miss. In a game where a single rifle round is usually decisive, that is not a cosmetic problem: the round you fired first simply was not counted, and the exchange went the other way.
Under 60 ms is comfortable. What matters more than the absolute figure is that a hundred players' worth of state is flowing to you continuously, so a connection that copes fine in a small-scale shooter can still struggle here. Judge it on this game's own conditions rather than by how another one felt.
What you see in game, and which number on this page explains it.
| What you see in Hell Let Loose | Look at | What it means |
|---|---|---|
| Killed by someone still behind cover on your screen | jitter | Their interpolated position lagged where the server actually had them. |
| Clear hit, no result, no feedback | loss | The shot packet may never have arrived, and the game does not confirm hits. |
| Whole server rubbery simultaneously | server | Server load under a hundred players and armour. |
| Fine in small shooters, bad here | jitter | More entities to synchronise exposes a line that just about coped elsewhere. |
Scale changes the networking problem qualitatively, not just quantitatively. A ten-player match has a small number of entities whose state must reach you promptly, and a client that misses a few updates can usually interpolate its way through without anyone noticing. A hundred players, their vehicles and their ordnance on one continuous map produce a far denser stream, and the same missing updates now leave visible holes.
Hell Let Loose compounds this with a design that is intentionally sparse in feedback. There is no killcam explaining what the server believed, no hitmarker confirming a connection, and no damage number quantifying it. Those absences are good for atmosphere and bad for diagnosis: the information a player would normally use to recognise a network problem has been removed on purpose.
The result is a game where connection quality is felt as luck. Players describe unfair deaths, inconsistent rifles and a sense that the game is against them, and some of that is genuinely server load, some of it is their own line, and some of it is the ordinary consequence of a shooter with real bullet travel and one-shot lethality. Without a measurement, there is no way to apportion it.
That is the argument for testing outside the game rather than reasoning inside it. This page cannot tell you how a given server is performing, and it does not try. What it can do is establish whether the path between you and a server is clean, which turns an unanswerable question into a much smaller one: if the line is good and the game is still unfair, the answer is on the server or in the design, and either way it is not something you were going to fix at home.
If the chart above shows packet loss or high jitter, work through these in order.
The Symptom: Deaths you cannot explain, several per match.
A continuous hundred-player state stream over a link that retries silently is the worst combination in this catalogue. Wireless does not fail loudly here; it degrades your picture of where fifty enemies are, which you experience as bad luck. A cable is the single highest-value change available.
The Symptom: The whole server feels rubbery at once.
A hundred players plus armour on one map is real load, and a server having a bad time affects everyone on it equally. If teammates report the same thing at the same moment and this chart is clean, changing settings at home is wasted effort - a different server is the fix.
The Symptom: Bad matches coincide with someone else streaming.
Continuous small packets are exactly what a saturated upload queue delays, and the effect on a hundred-player state stream is much larger than in a game with fewer moving parts. Router QoS that prioritises interactive traffic is worth more here than most places.
The Symptom: You suspect hit registration but cannot prove it.
With minimal hit feedback, single engagements prove nothing either way. Run this test for a few minutes before playing and note the numbers. Repeated bad sessions with a clean chart are a skill or a server question; the same sessions with visible loss are a connection question.
Because your screen showed you an interpolated reconstruction of the other player's position, and on the server they had already moved further than your client had been told. Uneven update delivery widens that gap, which is what the jitter figure here measures.
The game gives so little hit feedback that players cannot easily tell a lost packet from a miss, which makes the question hard to answer from the inside. Measuring your line separately is how you remove one of the two explanations rather than arguing about both.
It needs consistency far more than throughput. The state stream is larger than a small shooter's but still modest in absolute terms. What breaks the experience is loss and delay spikes, not a shortage of megabits.
Because there are far more entities to keep synchronised and no small maps to reduce the problem. A line that is adequate for a ten-player match can visibly struggle with a hundred players on one continuous battlefield.