DEV Community: pretjeuh

ping-multiple.sh — a live terminal dashboard for monitoring multiple hosts

pretjeuh — Tue, 16 Jun 2026 13:51:40 +0000

After a migration or a firewall swap, you need to verify that a dozen endpoints are reachable — on the right protocols. Is SSH still up? Did HTTP come back? Is that database port open? Firing ping or nc one host at a time is slow and you lose the overview the moment you move to the next check.

ping-multiple.sh is a single bash script that watches all of them at once, live, in your terminal.

What it looks like

Each row shows:

Column	Meaning
Status	`UP` / `SLOW` / `DOWN` / `...`
RTT	Latest round-trip time (`TO` = timeout)
Host	IP or hostname
Probe	`[ICMP]`, `[SSH]`, `[HTTP]`, etc.
Bar	60 most-recent results, newest on the right
Sparkline	RTT trend `▁▂▃▄▅▆▇█` (ICMP only)

Green = up/fast. Yellow = slow (above your threshold). Red = down. Gray = waiting for first sample.

Features

ICMP and TCP probes per target — mix and match on the same dashboard
Dual probe cadence for ICMP: a fast 1-second probe drives the bar, a slower 5-second probe drives the RTT column
TCP connect latency for SSH, HTTP, HTTPS, RDP, or any port
State-change alerts — terminal bell + optional --log FILE for every UP↔DOWN transition
RTT sparkline per host using 8-level block characters
CSV export on exit — per-host samples, loss %, min/avg/max RTT
Interactive wizard (--guide) or CSV import (--csv targets.csv)

Quick start

# ICMP ping to two hosts
./ping-multiple.sh 8.8.8.8,1.1.1.1

# Interactive setup — choose probe type per host
./ping-multiple.sh --guide

# Load from a CSV file, log state changes
./ping-multiple.sh --csv targets.csv --log events.log

CSV format:

ip,label,probe
8.8.8.8,Google DNS,icmp
10.0.0.1,Web server,tcp:80
10.0.0.2,Database,tcp:5432
mail.example.com,Mail server,tcp:25

How it works

Every host gets its own set of background subshells. For ICMP targets there are two workers: a fast one (1s interval, 1s deadline) writing G/Y/R chars to a ring-buffer file, and a slow one (5s interval, 5s deadline) updating the RTT column. TCP targets get a single worker that connects with nc every 10 seconds and records connect latency.

The display loop reads all the ring buffers once per second, calculates BAR_WIDTH from the current terminal width, and redraws every row in place. TCP samples are each expanded to fill 10 display blocks so the bar fills at the same visual rate as ICMP — without that, a TCP bar would be 90% gray for the first minute and a half.

State changes (UP→DOWN, DOWN→UP, UP→SLOW) fire a terminal bell and optionally append a timestamped line to a log file.

Requirements

bash 4+ (macOS ships bash 3 — brew install bash)
ping, nc, awk, date, mktemp on PATH
GNU timeout / gtimeout on macOS (brew install coreutils) — prevents nc from hanging on unreachable targets

No external dependencies, no compiled components, no containers.

Get it

github.com/pretjeuh/ping-multiple

MIT licensed. Ctrl-C to quit; temp files and cursor state are cleaned up automatically.

Measure bufferbloat on your internet connection with a single Python file

pretjeuh — Fri, 05 Jun 2026 14:50:43 +0000

Your video call sounds fine — until someone starts a big download. Suddenly you sound like you're calling from underwater. Lag spikes hit in games. SSH sessions stutter. Your bandwidth test shows 500 Mbps but nothing feels fast.

That's bufferbloat. And most people have never heard of it.

What is bufferbloat?
Why your ISP's speed test won't show it
What the tool does
My own results: a D on upload
Running it — CLI mode
Running it — Web GUI mode
How it works under the hood
The report and what to do about your grade
What actually fixes bufferbloat
The deeper problem: AQM isn't a complete solution
Try it yourself

What is bufferbloat?

Every router and modem has packet queues — buffers that hold packets while they wait to be transmitted onto the line. When your link is fully saturated, those queues fill up. New packets arriving have to wait behind everything already queued. That wait is latency.

On a modern 1 Gbps fibre connection, this rarely matters — the line clears fast enough that queues stay short. But on the bottleneck link — typically your home router's uplink to the ISP — the math changes. A 50 Mbps upload link with a 1 MB buffer can hold 160ms of packets. When it fills up, every subsequent packet waits that long before even starting its journey.

The insidious part: your bandwidth looks fine. You're transmitting at full speed. It's just that every packet is sitting in a queue for hundreds of milliseconds first.

The term "bufferbloat" was coined by Jim Gettys around 2011 after he noticed his home DSL connection had catastrophically bad latency under load despite good throughput. He traced it to enormous buffers in consumer networking equipment — added by manufacturers because "bigger buffers = better performance" seemed intuitive, even though the opposite is often true.

Why large buffers hurt

TCP congestion control works by detecting packet loss: if a packet doesn't arrive, the sender backs off. This mechanism assumes that packets get dropped when a queue fills up. But if the queue is enormous, packets don't get dropped — they just wait. The sender never sees loss, so it never backs off. The queue stays permanently full.

Result: full throughput, catastrophic latency. Every interactive packet — ACKs, DNS queries, game state updates, video call audio — sits behind a mountain of bulk transfer data.

The fix: Active Queue Management

Active Queue Management (AQM) algorithms deliberately drop or mark packets before queues fill up, using that signal to tell senders to back off earlier. The two most effective modern algorithms:

fq_codel (Flow Queuing Controlled Delay) — separates traffic into per-flow queues, applies CoDel's controlled delay target to each. Ships in Linux since 3.5, available on OpenWrt and most Linux-based routers.
CAKE (Common Applications Kept Enhanced) — more sophisticated successor to fq_codel. Handles overhead compensation for PPPoE/VLAN encapsulation, has built-in traffic shaping, and performs better at low bandwidths. The current state of the art for home routers.

The problem: most ISP-supplied modems and consumer routers don't enable either. Some don't support them at all. Before you can fix it, you need to know how bad it is.

Why your ISP's speed test won't show it

Speedtest.net and Fast.com measure throughput. They don't measure latency under load. A connection with 500 Mbps download and 400ms of bufferbloat looks identical to a connection with 500 Mbps download and 5ms of bufferbloat on a standard speed test.

The Waveform Bufferbloat Test and similar tools do test this — but they're web-based, opaque, and you can't run them locally or automate them. That's the gap this tool fills.

What the tool does

bufferbloat.py runs a multi-phase load test while measuring round-trip time (RTT) at 1 Hz throughout. It compares idle latency against loaded latency and grades your connection A–F.

The five phases are:

Baseline — measure idle RTT with no load, establishing the true unloaded latency
Download — saturate the download path with 4 parallel HTTP threads
Upload — saturate the upload path with 4 parallel HTTP POST threads
Bidirectional — both directions simultaneously, the worst case
Recovery — measure how fast latency returns to baseline after load stops

"Bloat" is calculated as the difference between loaded median RTT and baseline median RTT. Grades are based on the worst bloat seen across any loaded phase:

Grade	Added latency under load	Experience
A	< 5 ms	Excellent — barely noticeable
B	< 30 ms	Good — minor impact on sensitive apps
C	< 60 ms	Moderate — video calls degrade under load
D	< 200 ms	Poor — noticeable lag spikes, games unplayable
F	> 200 ms	Severe — SSH stutters, calls drop

My own results: a D on upload

I ran this on my own connection — ISP-supplied modem-router combo, fibre to the cabinet, QoS settings untouched since installation.

Baseline: 8ms RTT to Amsterdam

Download phase: 11ms median — 3ms bloat, essentially nothing

Upload phase: 112ms median — 104ms bloat, grade D

Bidirectional: 89ms median — 81ms bloat, grade D

Download was fine. Upload was the problem. The uplink buffer was filling up completely under load and staying full, adding over 100ms to every packet. Meanwhile my speed test showed a healthy 40 Mbps upload. Nothing in the ISP dashboard flagged anything unusual.

The asymmetry makes sense in hindsight: my download is ~200 Mbps, my upload is 40 Mbps. The upload bottleneck is tighter and the modem's uplink queue is apparently enormous.

This is the common pattern. Download buffers are less likely to cause problems because TCP ACKs travel upstream — when the downstream is saturated, ACK traffic competes for the (smaller, often less congested) upstream, partially self-limiting. Upload saturation has no such natural relief valve.

Running it — CLI mode

It's a single Python file. On first run it creates its own virtual environment and installs the two dependencies (matplotlib and flask) automatically.

git clone https://github.com/pretjeuh/bufferbloat
cd bufferbloat
python3 bufferbloat.py --target amsterdam

There are 30+ geographic targets — CDN77 Points of Presence (PoPs) and major DNS providers across Europe, North America, and Asia-Pacific. The tool probes the target before starting and warns you if it's unreachable.

# See all available targets
python3 bufferbloat.py --list-targets

# Use your router as the ping target (measures internal queue separately)
python3 bufferbloat.py --ping-host 192.168.1.1

# Longer phases, skip upload (for restricted networks)
python3 bufferbloat.py --target frankfurt --duration 20 --no-upload

# Verbose: print each RTT measurement as it arrives
python3 bufferbloat.py --target amsterdam --verbose

Tip on ping target choice: pinging your router (--ping-host 192.168.1.1) measures only the queue inside your router, not the ISP's equipment. Pinging an external host measures the total path including ISP buffers — usually what you want. If your router ping is clean but external ping shows bloat, the problem is upstream at the ISP's DSLAM or CMTS.

Running it — Web GUI mode

python3 bufferbloat.py --gui

Opens a local Flask web app. Pick a target, watch the RTT chart update live as each phase runs.

When the test finishes, you can download the full self-contained HTML report — useful for comparing runs before and after making changes.

How it works under the hood

Load generation

Load uses plain Python — urllib.request for downloads, HTTP POST for uploads, with 4 parallel threads per direction hitting Cloudflare's speed test endpoints (anycast, so they hit your nearest PoP). No iperf3, no custom servers, nothing to install beyond the script itself.

Four threads is usually enough to saturate any home connection. If you have a multi-gigabit symmetric fibre line, you might need more — but for typical DSL, cable, and VDSL connections where bufferbloat is most common, 4 threads saturates the bottleneck.

Latency measurement

Ping runs once per second via the system ping binary — cross-platform on Windows, macOS, and Linux. A regex extracts the RTT value; timeouts (no reply within 2s) count as packet loss and are recorded separately.

One ping per second is deliberately conservative. More frequent pings would give a smoother RTT curve but also inject more ICMP traffic that might get deprioritised differently from regular traffic. 1 Hz gives enough data points per phase without interfering with the load test itself.

The GUI stream

The GUI uses Server-Sent Events (SSE) from a Flask /stream endpoint. Each rtt, phase_start, and phase_complete event updates a canvas chart drawn in plain JavaScript — no Chart.js, no external dependencies. A keepalive comment every 15 seconds prevents the SSE connection from timing out during quiet stretches.

Before starting, the /probe endpoint does a quick single ping to the selected target. If it doesn't respond, you get a warning before the test wastes your time.

The report and what to do about your grade

The HTML report is fully self-contained — inline CSS, base64-encoded PNG charts, works offline and is easy to share.

It includes:

RTT timeline with phase boundaries marked
Box plot of RTT distribution per phase (shows spread, not just median)
Phase table: min / median / P90 / max / packet loss / throughput / bloat / grade
Overall grade
Grade-specific remediation advice

The remediation section is the part I built this for. Getting a grade is useful; knowing what to actually do about it is more useful.

What actually fixes bufferbloat

If you have an OpenWrt router

This is the best case. OpenWrt ships CAKE and fq_codel. Enable SQM (Smart Queue Management):

opkg update && opkg install luci-app-sqm

Then in LuCI: Network → SQM QoS → Enable, set your interface (usually eth1 or pppoe-wan), set download and upload speeds to ~95% of your measured line rate, and pick CAKE with piece_of_cake.qos as the queue discipline.

The 95% headroom is important — CAKE needs to be the bottleneck, not your ISP's equipment. If you set it to 100% or higher, the ISP's buffer fills before CAKE can act.

If you have DD-WRT

Navigate to NAT/QoS → QoS and enable it. Set the upload speed to ~90% of measured. DD-WRT's QoS is less sophisticated than CAKE but still better than nothing.

If you have OPNsense or pfSense

OPNsense: Interfaces → [WAN interface] → Edit → check "Enable Traffic Shaping" and configure HFSC or CAKE via the traffic shaper.

pfSense: Firewall → Traffic Shaper → HFSC. Alternatively, install the pfSense-pkg-cake package if available for your version.

If you have a consumer router with no AQM support

Your options:

Enable bridge mode on your ISP modem and put a proper router (OpenWrt-capable hardware like a GL.iNet or Belkin RT3200) behind it
Flash OpenWrt on your existing router if it's supported — check openwrt.org/toh
Use a Raspberry Pi as a router — runs Linux natively, full CAKE support
Contact your ISP — some ISPs will enable AQM on their equipment if asked, especially if you can show them test data

If you're on Wi-Fi

Run the test wired first. Wi-Fi adds its own variable latency on top of bufferbloat, and it's hard to separate the two sources of latency spikes. If your wired result is A/B but Wi-Fi is C/D, the problem is Wi-Fi contention, not bufferbloat — and the fix is different (less congested channel, Wi-Fi 6, mesh placement).

The deeper problem: AQM isn't a complete solution

Worth knowing: AQM fixes the queue problem but not all latency spikes under load.

A 2022 APNIC research paper (Beyond Bufferbloat) makes the argument that end-to-end congestion control has a fundamental limitation: when link capacity drops suddenly (common on Wi-Fi and 5G), packets queue up before the sender receives any congestion signal. Even with perfect AQM, there's an unavoidable minimum latency spike equal to roughly one RTT's worth of in-flight data.

For typical home broadband over wired ethernet or stable DSL, this matters less — capacity is relatively stable. For mobile and Wi-Fi connections where capacity can halve in milliseconds due to channel conditions, it's a real constraint.

The practical implication: if you test over Wi-Fi and still see latency spikes after enabling CAKE, you might be hitting this fundamental limit rather than a queue management problem. Test wired to isolate it.

Try it yourself

git clone https://github.com/pretjeuh/bufferbloat
cd bufferbloat
python3 bufferbloat.py --target amsterdam

The project is open source — github.com/pretjeuh/bufferbloat. Issues and PRs welcome — especially if you find a target that doesn't respond reliably, or a platform where ping parsing breaks.

What did you score? Drop your grade, your router model, and whether you're on DSL/cable/fibre in the comments. Curious how widespread the D/F club is — and whether the upload-is-worse pattern holds up across more connections.