Comcast Says Everything Is Fine
Your connection drops every night around 8 PM. Pages stall. Games lag. Video calls pixelate. You reboot the router. You call your ISP. They run a line test, find nothing, tell you everything looks great from their end, and close the ticket.
You hang up. It happens again at 8:06 PM.
Here’s the thing — without data, you’re just a person on the phone complaining about vibes. You need a paper trail. You need timestamps, packet loss percentages, and latency variance graphs that make a support rep pause before they type “no issue detected.”
SmokePing gives you exactly that.
What SmokePing Actually Is
SmokePing is Tobi Oetiker’s — same guy who made MRTG and RRDtool — continuous latency monitoring tool. It’s been around since 2003, it’s written in Perl, and its output looks like nothing else: a “smoke” chart where the thick band is your latency range, the darker center line is the median, and individual dots represent packet loss. One glance tells you more than ten minutes of reading ping output.
It’s not sexy. The web UI is aggressively 2004. But it produces the most information-dense latency visualization you’ll find anywhere, and it runs on a Raspberry Pi without breaking a sweat.
Why does this still matter in 2026 when you’ve got Grafana dashboards and Prometheus everywhere? Because SmokePing’s smoke charts show latency variance, not just average latency. Variance is what bufferbloat looks like. Variance is what a saturated upload queue looks like. Average latency hides all of that. Your ISP’s monitoring shows average latency. SmokePing shows the truth.
Running It in Docker
No need to install Perl dependencies from 2007. LinuxServer.io maintains a solid SmokePing image.
services: smokeping: image: lscr.io/linuxserver/smokeping:latest container_name: smokeping environment: - PUID=1000 - PGID=1000 - TZ=America/Chicago volumes: - ./config:/config - ./data:/data ports: - "8080:80" restart: unless-stoppedmkdir -p smokeping/{config,data}cd smokeping# Drop your compose file heredocker compose up -dFirst boot generates default configs in ./config/. Visit http://localhost:8080/smokeping/ and you’ll see SmokePing already pinging a few default targets. Now let’s configure it to actually tell you something useful.
Configuring Your Targets
This is where SmokePing earns its keep. The Targets file defines what you’re pinging, from where, and with what probe.
*** Targets ***
probe = FPing
menu = Toptitle = Network Latency Overviewremark = Sanity check for your internet connection.
+ Internetmenu = Internettitle = Internet Targets
++ Cloudflaremenu = Cloudflare 1.1.1.1title = Cloudflare DNShost = 1.1.1.1
++ Googlemenu = Google 8.8.8.8title = Google DNShost = 8.8.8.8
++ ISPGatewaymenu = ISP Gatewaytitle = Your ISP's First Hophost = 10.0.0.1
++ Steammenu = Steam Content Servertitle = Steam CDN (Seattle)host = 23.33.130.30
+ VPNmenu = VPNtitle = VPN Infrastructure
++ VPNEndpointmenu = WireGuard VPNtitle = My VPS VPN Endpointhost = your.vps.ip.here
+ DNSmenu = DNS Response Timestitle = DNS Probe Targets
++ CloudflareDNSmenu = Cloudflare DNS Lookuptitle = DNS Query Time (Cloudflare)probe = DNShost = 1.1.1.1
++ GoogleDNSmenu = Google DNS Lookuptitle = DNS Query Time (Google)probe = DNShost = 8.8.8.8The hierarchy matters: + is a group, ++ is a target inside that group. The indentation and plus count define the tree structure you see in the web UI.
For your ISP gateway: run ip route | grep default and ping the next hop. That’s the closest point inside your ISP’s network. If you’re seeing loss or high variance just to that address, it’s their infrastructure, not yours — and that’s a powerful thing to be able to say.
Probe Types
SmokePing ships with a lot of probes. The ones you’ll actually use:
FPing — The default. Sends ICMP echo requests in bulk, fast. Great for general reachability. Most targets should use this.
FPing6 — Same thing over IPv6. Useful if you’re dual-stack and want to know if your IPv6 path is worse than IPv4 (spoiler: sometimes it is).
DNS — Times actual DNS resolution. Separate from ICMP ping — if DNS is slow but ping is fine, you’ve found something interesting.
EchoPingHttp / EchoPingHttps — HTTP GET timing to a URL. This is your “does this site actually respond” check, measuring TCP + TLS + first byte, not just ICMP.
To configure DNS probes, add this to your Probes file:
*** Probes ***
+FPingbinary = /usr/bin/fpingblazemode = true
+FPing6binary = /usr/bin/fping6
+DNSbinary = /usr/bin/diglookup = google.compings = 5step = 180
+EchoPingHttpspings = 5step = 300The step value (in seconds) controls how often the probe runs. Default is 300 seconds (5 minutes). Smaller values give you more granularity but also more RRD storage. For troubleshooting active issues, drop it to 60 on the specific target you’re watching.
Multi-Vantage-Point: Slaves
Here’s where SmokePing gets clever. You can run a second SmokePing instance as a “slave” — it probes targets independently and ships results back to the master. This is how you prove whether a problem is local to your network or upstream.
If your VPS in Chicago shows no loss to 1.1.1.1 but your home instance in Dallas shows 8% loss, the problem is between Dallas and 1.1.1.1, not 1.1.1.1 itself.
On your VPS, run the slave image:
services: smokeping-slave: image: lscr.io/linuxserver/smokeping:latest container_name: smokeping-slave environment: - PUID=1000 - PGID=1000 - TZ=America/Chicago - SMOKEPING_SLAVE=1 - MASTER_URL=http://your.home.ip:8080/smokeping/ - SLAVE_NAME=vps-chicago - SLAVE_SECRET=changeme_use_a_real_secret restart: unless-stoppedOn your master, add to Slaves:
*** Slaves ***
secrets = /config/slavesecrets
+vps-chicagodisplay_name = VPS Chicagocolor = ff0000And /config/slavesecrets:
vps-chicago:changeme_use_a_real_secretNow in your Targets file you can add slaves = vps-chicago to any target and get overlaid graphs from both perspectives. The overlapping smoke makes it immediately obvious when one path is degrading and the other isn’t.
Reading the Smoke: What You’re Actually Looking At
Once data starts accumulating (give it 24–48 hours for patterns to emerge), here’s how to read it:
Thin, consistent band: Good. Latency is stable. Your median and your percentiles are close together.
Widening band: Bad. Latency variance is increasing. This is bufferbloat — your upstream is filling queues. Often happens during upload saturation (large backup job, video upload, gaming session on a connection without QoS).
Colored dots on the line: Packet loss. Each color represents a different percentage bracket. A few scattered dots are noise. A cluster during your 8 PM mystery event is evidence.
Sudden median spike that doesn’t come back down: Something changed. Could be a routing change, a new neighbor saturating shared fiber, or your ISP quietly throttling you.
Bufferbloat: The Smoke Doesn’t Lie
Bufferbloat is what happens when your router’s upload queue fills up faster than it drains. Latency balloons — not because the link is slow, but because every packet is waiting behind a queue of other packets. Your gaming session is getting lag-spiked by your spouse uploading a birthday video.
SmokePing shows this perfectly. Start a large upload and watch your smoke chart widen in real time. The median climbs, the upper percentiles go through the roof, and you have your culprit.
The fix is fq_codel or cake — both are Linux traffic disciplines that manage queue lengths intelligently:
# Check what you're running nowtc qdisc show dev eth0
# Apply cake (better than fq_codel, requires iproute2-extra on some distros)tc qdisc replace dev eth0 root cake bandwidth 950mbit
# For OpenWrt/routers, this is in the SQM (Smart Queue Management) package# Set it to ~95% of your actual upload speedAfter applying, run another large upload and check SmokePing. The smoke tightens back up. That’s QoS working. Your ISP won’t tell you about this. SmokePing will show you the before and after.
Alternatives (and Why You Might Still Want SmokePing)
MTR (My Traceroute) — combines traceroute and ping, great for one-off diagnostic sessions, terrible for historical trending. Run it when something is actively broken, not as continuous monitoring.
hping3 — surgical control over packet construction, useful for specific probe types (TCP SYN pings when ICMP is blocked). Not a monitoring tool.
Prometheus Blackbox Exporter + Grafana — the modern answer. You get ICMP, HTTP, DNS, TCP probes, beautiful dashboards, alerting, the works. More infrastructure to maintain, Grafana dashboards take time to build, but integrates with everything else you’re probably already running. If you’ve got a full Prometheus stack, this is the right long-term answer.
Grafana k6 — load testing tool, not really a latency monitor. Different use case.
SmokePing wins on one dimension: the smoke chart. Nothing else in the open source world renders per-probe latency distribution that clearly in that little space. When you’re screenshotting something to attach to an ISP support ticket, a SmokePing graph is unambiguous. A Grafana panel requires explanation. The smoke speaks for itself.
Making the ISP Call Easier
After a week of SmokePing data, your 8 PM problem will be visible as a recurring pattern. Export the graph by right-clicking the chart image (they’re PNGs, served directly). You’ll have:
- Timestamp of every spike
- Packet loss percentage at each event
- Whether the loss was ICMP, DNS, or HTTP (if you configured multiple probe types)
- Comparison data showing your ISP gateway is fine while 1.1.1.1 shows loss (their network, not yours)
- Or the inverse: your gateway spikes but 1.1.1.1 doesn’t (your local segment or DOCSIS upstream)
You call. You say: “I have monitoring data showing 12% packet loss to 8.8.8.8 every night between 7:45 PM and 9:15 PM for the past six days. I can see my ISP gateway responding normally during this time, so the issue is downstream from your CMTS.” They escalate. Because now you sound like someone who knows where their problem actually is.
That’s worth setting up a Docker container for.
The Bottom Line
SmokePing is a 20-year-old tool with a web UI that looks like it was designed in WordArt. It also produces the most useful single-glance latency visualization in existence and runs in a container on a Pi with essentially zero maintenance.
If you’ve ever had an ISP close a ticket while your connection was clearly broken, you need SmokePing. If you want to know whether your bufferbloat is better after applying cake to your qdisc, you need SmokePing. If you have a VPS and want to know whether your home internet sucks from the outside too, SmokePing slaves have you covered.
Set it up, let it run for a week, then go pick a fight with your ISP with actual evidence. Your 2 AM self — debugging latency spikes with something other than vibes — will be grateful.
