Ping is how long data takes to reach a server and come back, jitter is how much that time jumps around, and packet loss is the share of data that never arrives. For live TV, steady beats fast: a connection with low jitter and no loss streams better than a faster one that is unsteady. Measure all three on the device you watch on, then fix the cause.
Key takeaways
- Ping is the delay, jitter is how much the delay changes, and packet loss is data that never arrives.
- For live TV, steady beats fast: a little packet loss or big jitter spikes can stall a stream on a connection that tests at hundreds of Mbps.
- Measure on the device you watch on, then compare your router with a server outside your home to find where the problem starts.
- Wi-Fi and bufferbloat cause most home problems; a cable and a router with SQM fix most of them.
The three numbers in plain terms
A speed test gives you one big number in Mbps, but live TV depends on three smaller ones too. Each one describes a different way data can arrive late, unevenly or not at all.
Ping, or latency, is the round-trip time in milliseconds (ms) for a small message to reach a server and return. It depends on distance, on the number of network hops and on how long data waits in queues along the way.
Jitter is the variation in that delay from one packet to the next. Ten pings of 20 ms each have almost no jitter; pings that swing between 15 and 120 ms have a lot. Packet loss is the percentage of packets that are sent but never arrive, so they have to be sent again.
| Measure | Comfortable | Worth watching | Likely to cause trouble |
|---|---|---|---|
| Ping (latency) | Under 40 ms | 40 to 100 ms | Over 100 ms, or rising sharply when the line is busy |
| Jitter | Under 10 ms | 10 to 30 ms | Over 30 ms, or spikes into the hundreds |
| Packet loss | 0% | A single lost packet now and then | 1% or more, or losses that come in bursts |
The ping ranges follow the guidance on our IPTV speed test page: under 40 ms feels instant when you change channels, and above 100 ms you may notice a pause. The jitter and loss columns are practical rules of thumb for streaming, not an official standard.
How a live channel actually reaches your TV
Most internet TV today is delivered the way the HTTP Live Streaming specification (RFC 8216) describes. The channel is cut into short media segments, each a few seconds long, and a playlist file lists the newest ones. Your player reads the playlist, downloads the segments one after another over ordinary web connections, and plays them in order.
The player never starts right at the live edge. The specification tells players not to pick a segment that starts less than three target durations from the end of the playlist, so a live channel normally plays a little behind real time. Those few seconds of downloaded video are the buffer, the reserve that hides small hiccups.
The segments travel over a reliable transport, usually TCP, or QUIC on newer HTTP/3 connections. Reliable means every lost piece is detected and sent again, so the picture never shows a gap. The cost is time: a retransmitted packet arrives late, and everything behind it waits.
That is where ping, jitter and loss enter the story. For the bigger picture from studio to screen, see how IPTV works.
When ping matters, and when it doesn’t
Once a channel is playing, a steady ping of 60 or 80 ms is not a problem. The player is downloading segments several seconds ahead of what you see, so a fraction of a second of delay on each request disappears inside that reserve.
Ping matters most at the start. Opening a channel takes several round trips before the first frame appears: looking up the server name, opening a connection, securing it, then requesting the playlist and the first segments. With a 20 ms ping that chain is over quickly; at 150 ms each step adds up and you notice a pause when you change channels.
High ping also slows a single download. Each connection waits for acknowledgements before sending more, so a longer round trip means fewer chances per second to ramp up.
Speed tests hide this by opening several connections at once, while a stream usually uses one or two. A distant server or a VPN that sends traffic far away can therefore lower what the stream really gets. Our post on whether a VPN slows down IPTV looks at that trade-off.
Why jitter drains the buffer
Jitter is the enemy of a small buffer. If segments arrive at a steady pace, the reserve stays full. If some arrive quickly and others are held up for half a second or more, the reserve shrinks every time a slow one comes in, and a run of slow ones empties it.
A few milliseconds of jitter is normal and harmless. What hurts are spikes, moments when the delay jumps from 20 ms to several hundred. Those spikes usually mean data is stuck in a queue somewhere: in a router that is holding too many packets, in a Wi-Fi network where devices are waiting for airtime, or on a congested link outside your home.
That is also why jitter is a better warning sign than ping. A high but steady ping tells you the server is far away. A jumpy ping tells you something is overloaded, and an overloaded link is the one that will stall your stream next. The standards world calls this packet delay variation, and the bufferbloat article on Wikipedia explains how oversized queues cause both delay and jitter.
Why packet loss hurts more than its percentage
One percent packet loss sounds small. For a streaming connection it isn’t, for two reasons.
First, data must arrive in order. When one packet goes missing, everything that arrives after it waits until the missing piece is detected and sent again. A single loss can stall the download for one or more round trips, which is a long time when the buffer only holds a few seconds.
Second, TCP treats loss as a sign of congestion and slows down. The standard response is to cut the amount of data in flight roughly in half and then build back up gradually. With loss every few seconds, the connection never gets back up to speed, so a line that tests at 300 Mbps can deliver a single stream far less than that. Bursts of loss, common on weak Wi-Fi, are worse than the same number of losses spread out.
- 0% loss: what a healthy wired connection should show over a few hundred pings.
- Occasional single losses: usually harmless, common on Wi-Fi.
- 1% or more, or regular bursts: enough to cause buffering on live channels, especially in 4K.
Why a fast speed test can still stutter
A result of several hundred Mbps followed by a freezing channel is the most common puzzle we hear. The two numbers measure different things, and here is how they part ways:
- Speed tests use several connections at once. Ours pulls test files over parallel connections for up to eight seconds. A stream fetches its segments over one or two, so loss and high ping hurt it much more.
- Speed tests are short. Ten seconds can miss the jitter spike that hits every few minutes, or the burst of loss when the microwave starts.
- Speed tests report a summary. A good average can hide moments of near-zero throughput, and those moments are what empty the buffer.
- The test server is close. Speed tests pick a nearby server, while the stream may come from farther away along a different route.
This is why the extra numbers matter. If the speed is fine but jitter or loss is high, more Mbps will not help; a steadier connection will. If the speed itself is too low for the quality you want, our guide to internet speed for IPTV lists what each quality needs.
Measure 1: browser tests on the streaming device
Start with the device you actually watch on, because that is the connection that matters. Wi-Fi at the TV is often much worse than at the router.
Open our IPTV speed test in the device’s web browser. It sends several tiny requests to the nearest edge server and keeps the fastest round trip as your latency, shows how much the round trips vary as jitter, and measures download speed. Run it three times, a minute apart, and note the worst result as well as the best.
For a second opinion that also reports packet loss, use the CIRA Internet Performance Test. CIRA, the organization that runs the .ca domain, hosts its test servers at internet exchange points in Vancouver, Calgary, Winnipeg, Toronto, Montréal and Moncton. The result shows download and upload speed along with latency, jitter and packet loss.
Browser tests are a quick health check. To find where a problem starts, you need the command-line tools below, run from a computer placed where the TV is or connected the same way.
Measure 2: a long ping from a computer
A ping test of a few hundred packets shows loss and jitter that a ten-second browser test can miss. Run it twice: once to your own router, then to a server outside your home. If the router test is clean and the outside test isn’t, the problem is beyond your walls.
Find your router’s address
On Windows, open Command Prompt and type ipconfig; the router is listed as Default Gateway, often something like 192.168.0.1 or 192.168.1.1. On a Mac, open Apple menu → System Settings → Network, select your connection, click Details, then TCP/IP; the router address is shown there.
Run the test on Windows
Type ping -n 300 192.168.1.1 with your router’s address, wait about five minutes, then repeat with a public name such as ping -n 300 one.one.one.one. The -n option sets how many pings to send; the default is only four. At the end, Windows prints a summary with packets sent, received and lost, and the minimum, maximum and average round-trip times.
Run the test on a Mac or Linux computer
Open Terminal and type ping -c 300 followed by the address, for the router and then for the public name. The summary shows the loss percentage and the minimum, average and maximum round-trip times. On Linux it also includes mdev, the spread of round-trip times; the higher it is, the more variable your connection.
What to look for
To your router over a cable, you should see 0% loss and times of a few milliseconds. Over Wi-Fi, a few milliseconds more is normal, but losses or spikes over 100 ms point straight at the wireless link. Outside your home, steady times with 0% loss are healthy; a maximum many times higher than the average means jitter.
Measure 3: tracert and pathping on Windows
When the outside test shows trouble and the router test doesn’t, the next question is where along the route it starts. Windows includes two tools for that.
tracert lists every router, or hop, between you and a destination. Type tracert -d one.one.one.one; the -d option skips name lookups so it runs faster. Hops that don’t answer appear as a row of asterisks, which on its own is normal.
pathping goes further. As Microsoft’s pathping reference explains, it first finds the hops like tracert, then sends repeated pings to each one over a period of time and reports the loss at every router and on every link. Type pathping -n one.one.one.one and wait; with the default of 100 queries per hop, it takes a minute or two depending on how many hops there are.
The result has a Lost/Sent = Pct column for each hop. Hop 1 is your router. The next one or two hops usually belong to your internet provider’s local network, and everything after that is the wider internet.
Measure 4: mtr on a Mac or Linux
On a Mac or Linux computer, mtr combines traceroute and ping in one live display, updating the loss and timing for every hop as it runs. It is the best single tool for watching a problem as it happens.
- On a Mac with Homebrew installed, type brew install mtr. On Debian or Ubuntu Linux, install the mtr package from your package manager.
- On a Mac, start it with sudo mtr, because it needs administrator rights; enter your password when asked.
- For a report you can save or send, type sudo mtr -r -w -c 300 one.one.one.one. The -r option prints a report at the end, -w keeps host names in full, and -c 300 sends 300 cycles of one second each.
- Add -n to show addresses instead of names if the lookups slow it down.
The report shows each hop with its loss percentage and its last, average, best and worst times, plus a standard deviation column that works as a jitter figure for that hop.
Reading a hop-by-hop result without fooling yourself
Hop-by-hop tools are easy to misread. Many routers on the internet are busy forwarding traffic and give low priority to answering test pings, so a middle hop can show 30% or even 100% “loss” while the connection is perfect.
The rule is simple: loss only counts if it carries on to the last hop. If hop 5 shows 40% loss but hops 6 to 10 and the destination show 0%, hop 5 is just ignoring pings. If loss starts at hop 5 and every hop after it shows about the same loss, the problem really starts there.
- Loss or spikes from hop 1 onward: your own Wi-Fi, cable or router.
- Clean hop 1, loss from hop 2 or 3 onward: the line into your home or your provider’s local equipment, including the modem.
- Clean until a later hop, then loss to the end: a congested link farther away, which is rarely something you can fix at home.
- Loss only at the destination: that server is busy or limits pings; test another destination before drawing conclusions.
Microsoft’s pathping notes make the same point in their own words: loss shown at a router suggests the router itself may be overloaded, while loss on the link between two routers suggests congestion on that link.
What causes high ping, jitter and loss at home
Most problems that you can fix sit in the first hop or two. The table matches common causes to the pattern they leave in your tests.
| Cause | What your tests show | Fix |
|---|---|---|
| Weak or crowded Wi-Fi | Loss and spikes to the router itself; fine over a cable | Use 5 GHz or 6 GHz, move closer, add a mesh point or Ethernet |
| Bufferbloat | Normal ping when idle, ping rising by hundreds of ms during downloads or uploads | SQM or smart queue on the router, schedule big transfers |
| Overloaded or ageing router | Jitter that rises with the number of devices, router feels hot, problems fixed by a restart | Firmware update, restart, replacement if it is several years old |
| Damaged cable, coax splitter or connector | Loss even on a wired computer, sometimes worse in hot or cold weather | Reseat or replace cables; ask your provider to check the line |
| Evening congestion in your area | Clean in the morning, loss and jitter after hop 2 in the evening | Keep a log and contact your provider |
| Distant route or VPN | High but steady ping to the stream, normal ping to nearby servers | Turn off the VPN for TV, test again |
If your results change with the time of day rather than with what you do at home, our guide to IPTV buffering in the evening shows how to build a log your provider can act on. For Wi-Fi fixes, see Wi-Fi vs Ethernet for streaming.
Testing for bufferbloat
Bufferbloat is the hidden cause behind many “fast but stuttering” homes. Modems and routers with large, unmanaged queues hold packets for a long time when the line is busy, so ping and jitter shoot up whenever someone uploads or downloads something big. Your TV’s stream waits in that same queue.
You can test it with tools you already have. Start a long ping to a public server, note the normal times, then start something heavy on another device: a large download, a cloud photo backup or a game update. If the ping jumps from 20 ms to 200 ms or more and falls back when the transfer ends, you have bufferbloat.
On a Mac running macOS Monterey or later, Apple’s built-in networkQuality command in Terminal measures responsiveness while it loads the connection. It reports round trips per minute (RPM) and rates the result as Low, Medium or High; a Low rating on a fast line is a classic sign of bufferbloat. Type man networkQuality in Terminal for its options.
Fixing bufferbloat with SQM
The fix for bufferbloat is a router that manages its queue instead of filling it. The feature is called Smart Queue Management (SQM) on many routers, and some brands name it smart QoS, adaptive QoS or a gaming or streaming mode. Under the hood it uses queue-management methods such as fq_codel or cake that keep delay low by sharing the line fairly between connections.
SQM works by limiting your traffic slightly below the line’s real speed, so the queue builds in your router, where it is managed, rather than in the modem, where it isn’t. The OpenWrt project’s SQM guide suggests starting at 90% of the download and upload speeds you measured, then adjusting. You give up a little peak speed and gain steady ping under load.
Not every internet provider’s gateway offers SQM. If yours doesn’t, a separate router that supports it, placed behind the gateway, is the usual answer. Our router settings guide covers where to find SQM and QoS, and what the other options do.
Fixes in order, from free to paid
Work through these after you have measured, so you can see which one made the difference. Test again after each step.
- Restart the modem, router and streaming device. It clears overloaded queues and memory, and a problem that keeps coming back after a restart is useful evidence.
- Check every cable. Reseat the Ethernet and coax connectors, remove unused coax splitters, and replace any cable with bent or damaged ends.
- Move the TV off weak Wi-Fi. Switch to 5 GHz or 6 GHz, move the router into the open, or run a cable.
- Pause big transfers during live TV. Schedule backups, game downloads and updates for overnight.
- Turn off the VPN on the TV device and compare.
- Turn on SQM or smart QoS if your router has it, or add a router that does.
- Give the player a larger buffer. It adds a few seconds of delay but rides out jitter spikes; see our guide to IPTV buffer size settings.
- Call your internet provider if a wired computer shows loss from hop 2 onward.
The general buffering checklist, including the app cache and the video decoder, is in our nine buffering fixes.
What to send us, or your provider
If the stream still stutters after these steps, numbers make the conversation much shorter. Whether you contact your internet provider or our Online Support chat, send:
- your device, player app and connection type (Wi-Fi band or cable),
- a ping summary to your router and to a public server, with loss and minimum, maximum and average times,
- a pathping or mtr report taken while the problem was happening,
- the times and channels that buffered, and whether other channels played normally.
Your provider can act on loss that starts at hop 2 or later on a wired computer. We can act on a pattern where your tests are clean but our streams still struggle, by checking the channels and the route on our side. That kind of help is included with every IPTV subscription we sell.
Questions people ask
What is a good ping for streaming live TV?
Under 40 ms is comfortable and makes channel changes feel instant. Between 40 and 100 ms works fine once a channel is playing, though you may notice a short pause when switching. A steady ping matters more than a low one: 80 ms that never changes beats 20 ms that spikes to 300.
How much packet loss is acceptable for streaming?
Ideally none. A wired connection should show 0% loss over a few hundred pings. Occasional single losses on Wi-Fi are usually harmless, but 1% or more, or losses that arrive in bursts, is enough to make live channels buffer, especially in 4K.
Can jitter cause buffering even with fast internet?
Yes. Jitter spikes mean some video segments arrive much later than others, and each late one drains the player’s buffer. If the delays are long or frequent enough, the buffer empties and the picture stops, even when a speed test shows hundreds of Mbps.
How do I check packet loss on Windows?
Open Command Prompt and type ping -n 300 followed by a server name, then read the loss percentage in the summary. To see where loss starts, run pathping -n followed by the same name; it reports the loss at every hop between you and the server.
Does Wi-Fi cause packet loss?
It can. Weak signal, interference from neighbouring networks and devices competing for airtime all cause lost and delayed packets on Wi-Fi. If a long ping to your own router shows loss over Wi-Fi but not over a cable, the wireless link is the cause.