Daniel sent us this one — and honestly, it's the kind of question that makes you realize how much we all just... trust our ISPs without evidence. He's running OPNsense on a router connected to a fiber gateway in bridge mode, and he noticed something odd. For all the plugins OPNsense offers, there's no dedicated tool for tracking connection quality over time. Not uptime monitoring — that's there — but actual metrics like average upload speed, download speed, and jitter, tracked historically. If you've got multiple ISPs to choose from in your area, none of them are going to volunteer their real quality-of-service numbers. So the question is: what tools exist, open source or commercial, that can run on your own hardware and give you meaningful, long-term ISP performance data?
This is one of those gaps that, once you see it, you can't unsee it. What are you actually getting at two in the morning on a Tuesday? More importantly, is your jitter creeping up every evening when your neighborhood starts streaming? Without your own data, you're just guessing.
And the ISP's own speed test — the one they tell you to use when you call support — is about as trustworthy as a fox guarding the henhouse. They can prioritize that traffic, route it internally, make it look pristine while your actual connection to the rest of the internet is struggling.
So today we're building a DIY ISP quality dashboard. No black boxes, no ISP-provided apps, no trusting the marketing copy. Just tools you run on your own hardware, pointed at your own connection, collecting real data over weeks and months.
The key word there is "your own hardware." Daniel specifically mentioned he's on a wired fiber connection — the gateway's in bridge mode, so we're measuring the actual line, not WiFi variability. That's the right way to do this. You want to know what's coming out of the wall, not what your router's antennas are doing three rooms away.
Let's start by understanding exactly what OPNsense is missing and why that gap exists. OPNsense actually has excellent uptime monitoring built in. You've got gateway groups, you've got dpinger — it'll tell you the moment your connection drops. But there's zero built-in historical bandwidth quality metrics. No speed test scheduler, no jitter trending, no latency-over-time graphs. It's a glaring omission for a platform that otherwise gives you tremendous visibility into your network.
That's not a criticism of OPNsense, really — it's a firewall and routing platform first. But it means if you want to know whether your ISP is actually delivering what you're paying for, you need to bring your own tools.
Here's why this matters beyond just satisfying curiosity. ISPs shape traffic. They oversubscribe nodes — selling more bandwidth than the infrastructure can actually handle at peak, betting that not everyone will use it simultaneously. They degrade during peak hours. And without your own long-term data, you have no ammunition. You call support, they run their own test, they say "looks fine on our end," and that's the end of the conversation.
The "looks fine on our end" shutdown. I've been there. It's infuriating.
It's designed to be. But if you can say "I have ninety days of data showing my jitter triples every Saturday at seven PM and my download speed drops forty percent between eight and ten PM on weeknights" — now you're not asking them if there's a problem. You're telling them there's a problem, and you have the receipts.
If you're in an area with multiple ISP options — which Daniel mentioned is part of his consideration — this data becomes your actual decision-making tool. Not "which ISP has the shiniest ads" or "which one gave my neighbor a good deal," but "which one actually delivers consistent performance to my house, on my street, during the hours I actually use the internet.
That's the frame. This is a practical tools episode — we're not going deep on networking theory, we're not explaining what TCP is. We're assuming you know what OPNsense is, you know what jitter means, and you want to know what to install and how to use it.
Sounds like exactly what I'd want if I were staring at an OPNsense plugin list wondering why this doesn't exist. Alright, let's get into the tools. I'm going to walk through four options, starting with the most powerful and flexible setup — and fair warning, it's also the most work to configure.
The first one, and honestly the gold standard for self-hosted monitoring, is what people call the TIG stack — Telegraf, InfluxDB, and Grafana. Telegraf is the data collector, InfluxDB is the time-series database where all your measurements live, and Grafana is the dashboard layer that turns raw numbers into graphs you can actually read.
Telegraf is the key piece here because it has two plugins that are perfectly suited for this exact use case. The first is the ping plugin. You configure it with multiple targets — say, Cloudflare's one-dot-one-dot-one-dot-one, Google's eight-dot-eight-dot-eight-dot-eight, and your ISP's own DNS server — and it continuously measures latency, jitter, and packet loss to all of them. It writes those measurements into InfluxDB, and Grafana graphs them over time.
The second plugin is where it gets really interesting — the speedtest plugin. This actually runs the Ookla Speedtest CLI on whatever schedule you set, ingests the download speed, upload speed, and latency results, and stores them alongside your ping data. So now you've got a single dashboard showing you latency trends and throughput trends, all correlated by time.
This is the most powerful option because it gives you the complete picture. You can look at a Grafana dashboard and see, for example, that your latency to Cloudflare is stable at three milliseconds all day, but the moment your speed test runs at eight PM, the latency during the test spikes to forty-five milliseconds. That's bufferbloat. That's your router or your ISP's equipment buffering too aggressively, and it's something you'd never catch with a single-point speed test.
Let me flag a few practical details on the Telegraf setup because this is the least documented part. The Ookla Speedtest CLI requires you to accept their license — it's not a big deal, but you need to know it going in. Also, running a speed test consumes real bandwidth. A full gigabit test uses about two hundred megabytes of data. If you run it every thirty minutes, that's roughly two to three gigabytes per month just in testing. On a capped connection, that matters. On uncapped fiber, it's negligible.
The resource cost on the OPNsense box itself — Telegraf is surprisingly lightweight. About fifty megabytes of RAM, typically under two percent CPU on anything modern. You're not going to notice it running.
The heavier part is InfluxDB and Grafana. Those you probably don't want running directly on your router. The recommended architecture is: Telegraf on the OPNsense box, and InfluxDB plus Grafana on a separate machine — a Raspberry Pi four, an old NUC, a small VM somewhere on your network. Keeps the monitoring stack off your router's CPU and storage, and gives you more flexibility with Grafana dashboards.
That's the TIG stack — most powerful, most flexible, but highest setup effort. If you want something simpler and more focused, that brings us to tool number two: SmokePing.
SmokePing is purpose-built for exactly one thing, and it does it beautifully — latency and jitter monitoring over time. It uses fping to probe multiple targets simultaneously, and it renders these RRD graphs that make jitter spikes visually obvious in a way that raw numbers never could. The graph shows you not just the average latency, but the range — the spread between minimum and maximum ping times. When your connection is healthy, that spread is tight. When jitter creeps in, the graph gets... You can see it instantly.
Here's the part Daniel will love — SmokePing is available as an OPNsense plugin. It's called os-smokeping, it's in the community repository, and installation is basically point and click. You add your targets — ISP gateway, Cloudflare, Google DNS — and within a day you've got latency graphs that would make a network engineer weep with joy.
The classic pattern you'll see on a SmokePing graph: a fiber connection sitting at a rock-solid three milliseconds all day, and then at eight PM, the line jumps to forty-five milliseconds and stays there until midnight. That's oversubscription. Your ISP sold more bandwidth than the neighborhood node can handle, and when everyone gets home and starts streaming, your latency suffers. SmokePing makes that pattern impossible to miss.
The downside of SmokePing is it's laser-focused. It doesn't do throughput testing — no download or upload speed measurements. It's strictly latency and packet loss. So it answers "is my connection responsive" but not "is my connection fast." For a lot of people, that's actually the more important question — jitter matters more for real-time applications than raw throughput does.
Tool three is vnStat. This one's different — it's not a speed test at all. vnStat is a lightweight bandwidth monitor that reads directly from your network interface counters. It tracks daily and monthly traffic totals, average speeds, and peak usage hours. The beauty of it is the resource footprint — it uses less than ten megabytes of RAM and has no database overhead. It's truly set-and-forget.
VnStat gives you utilization patterns, not performance measurements. But that's valuable in its own right. If you see your interface counters showing heavy traffic every weekday at nine AM, but your speed tests are fine, you know the issue isn't your ISP — something on your network is saturating the connection. Conversely, if vnStat shows low utilization but your latency is spiking, that points squarely at the ISP side.
Tool four is LibreNMS. This is the nuclear option — a full network monitoring suite with auto-discovery, alerting, and historical graphs for latency, packet loss, and interface utilization. You install it on a separate machine or VM, point it at your OPNsense via SNMP, and it discovers everything. It'll graph your WAN interface throughput, your CPU temperature, your DHCP lease status — it's comprehensive.
For a single router, LibreNMS is probably overkill. But if you've got a home lab — a switch, an access point, maybe a server or two — it becomes genuinely useful. And the alerting is excellent. You can set thresholds and get notifications through pretty much any channel you want.
Let me give you a quick comparison matrix. The TIG stack is the most flexible — you can build exactly the dashboard you want, correlate any metrics, set any alerts. But it's the highest setup effort. SmokePing is laser-focused on jitter and latency, dead simple to install via the OPNsense plugin, but doesn't do throughput. vnStat is set-and-forget bandwidth tracking with essentially zero overhead, but it's not a performance test. And LibreNMS is the everything-in-one-box solution that's probably overkill unless you have a home lab.
The one that gives you the most actionable data for ISP complaints is definitely the TIG stack — because you get correlated latency and throughput data over time, with alerts. You can walk into a support call with graphs showing exactly when and how your connection degrades. That's hard for an ISP to dismiss.
Those are the tools. But having the data is only half the battle — now let's talk about what you actually do with it.
Because here's the thing — long-term data fundamentally changes how you interact with your ISP. You stop being a customer who "feels like the internet is slow" and become someone with ninety days of empirical evidence. That's a very different conversation.
I want to share a concrete case study because it illustrates exactly why this matters. There was a user with one gigabit fiber who set up the TIG stack and noticed something strange in their Grafana dashboard. Every weekday at nine AM, their download speed dropped from around nine hundred fifty megabits per second to about three hundred. Consistent, clockwork, every single weekday. The latency stayed fine — this wasn't congestion, it was something else.
That's the kind of pattern you'd never catch with an occasional manual speed test. You'd just think "huh, internet feels slow this morning" and move on with your day.
But the Grafana dashboard made the pattern obvious. They exported the graphs, contacted the ISP, and presented the data. The ISP investigated and found that a business customer on the same node was running massive daily backups at exactly nine AM, saturating the shared infrastructure. Within two weeks, the ISP split the node. Without the data, that user would have just lived with a degraded connection indefinitely.
That's the leverage we're talking about. ISPs respond to data because data is hard to argue with and — this is the important part — data can end up in front of regulators. Which brings us to another practical point: what do you actually do with this information once you have it?
If you see consistent jitter above ten milliseconds or speed drops below seventy percent of your advertised rate, collect at least fourteen days of data. Then file a formal FCC complaint if you're in the US, or the equivalent regulatory body in your country. In the US, ISPs are required to respond to formal FCC complaints within thirty days. That's a legal obligation, not a courtesy.
Here's something most people don't realize — some ISPs have acceptable use clauses that technically prohibit automated speed tests. It's rarely enforced, especially on residential connections, but it exists in the fine print. Worth knowing about, even if the practical risk is near zero.
The bufferbloat detection angle is worth digging into because it's one of the most common issues and one of the hardest to diagnose without the right tools. Bufferbloat happens when network equipment — your router or your ISP's hardware — holds packets in excessively large buffers instead of dropping them when the link is congested. The result is that your latency spikes dramatically under load.
The TIG stack can catch this. You configure Telegraf's ping plugin to run continuously, and you schedule speed tests to run periodically. When a speed test starts and saturates your connection, the ping plugin keeps measuring. If your latency jumps from three milliseconds to two hundred milliseconds during the test, that's bufferbloat. If it stays flat, your connection is well-tuned.
On the OPNsense side, if you detect bufferbloat, the fix is usually enabling FQ-CoDel — Fair Queuing with Controlled Delay. It's a queue management algorithm that's built into OPNsense, and it dramatically reduces bufferbloat by keeping queues short and dropping packets intelligently rather than letting them pile up.
Let me boil this down into a concrete action plan you can implement this weekend. Start with SmokePing. It's the easiest — install os-smokeping from the OPNsense community repo, add targets for your ISP gateway, Cloudflare's one-dot-one-dot-one-dot-one, and Google's eight-dot-eight-dot-eight-dot-eight. That's it. Check the graphs after one week and you'll already see patterns.
Once SmokePing is running and you're comfortable with the concept, then add the TIG stack when you're ready for full speed test history. The minimum viable setup: Telegraf on your OPNsense box, InfluxDB and Grafana on a Raspberry Pi or old machine on your network. Configure the ping plugin and the speedtest plugin. Give it a month.
That month is important. One week of data can be an anomaly — maybe there was a fiber cut in your area, maybe your neighbor was running a Bitcoin mining operation that tripped a breaker. A month of data is a trend. Don't make ISP switching decisions based on anything less.
One last thing to think about as you set this up. ISPs are increasingly moving toward CGNAT — Carrier-Grade NAT — and IPv6-only deployments. This changes the monitoring landscape. If you're behind CGNAT, your SmokePing targets might not be reachable from outside in the same way. And with IPv6-only, you need to make sure your monitoring tools are targeting IPv6 addresses, not just legacy IPv4.
The other shift happening is the rise of five-G fixed wireless as a competitor to fiber. If you're comparing ISPs, you might find yourself comparing a fiber connection to a five-G connection, and jitter monitoring becomes even more critical. Cellular connections have inherently variable latency that fiber users aren't used to. A SmokePing graph of a five-G connection looks very different from a fiber graph — and you need to know whether that variability matters for your use case.
That's the landscape. Tools exist, they're mature, they're free, and they'll give you data that changes your relationship with your ISP from one of trust to one of verification. We'd love to hear what you find when you set this up — share your weirdest ISP monitoring discoveries with us.
Now: Hilbert's daily fun fact.
Hilbert: In the late Victorian period, explorers in the Simpson Desert reported hearing a low-frequency hum emanating from sand dunes during katabatic wind events — the descending cold air vibrating the dune faces like a massive aeolian harp, producing tones around twenty-seven hertz, just at the threshold of human hearing.
A singing desert.
Twenty-seven hertz.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this episode, do us a favor and leave a review wherever you listen — it helps more people find the show. We'll be back next week with another prompt from Daniel.
The thing that surprised me when I first dug into this is that OPNsense actually has a really sophisticated monitoring system already — it's just aimed at a completely different problem. Gateway groups and dpinger are designed to answer one question: is the connection up or down? And they do that brilliantly. You can set up multi-WAN failover, you get instant alerts if a gateway drops, you can even script actions based on link state. But the moment you ask "how good is the connection while it's up," you hit a wall.
It's the difference between knowing your car started and knowing how the engine is performing under load. OPNsense tells you the ignition works. It doesn't tell you the transmission is slipping.
And what Daniel noticed — that there's no plugin filling this gap — is puzzling when you think about it. OPNsense has plugins for everything from intrusion detection to dynamic DNS to VPN servers. But nothing that says "run a speed test every hour and graph the results." Nothing that tracks jitter over a thirty-day window. It's a blind spot in an otherwise comprehensive ecosystem.
Part of the reason, I think, is that the OPNsense community has historically focused on security and routing — the firewall rules, the VLAN segmentation, the VPN tunnels. Performance monitoring of the WAN connection has been treated as something you do externally. Which is fine, but it means new users like Daniel look through the plugin list, don't find what they need, and assume they're missing something obvious. They're not. The tool just isn't there.
That brings us to the second question Daniel raised, which is worth addressing directly: why can't you just trust the ISP's own speed test? Because on the surface, it seems reasonable. They point you to their own Ookla server, you run the test, it says you're getting nine hundred megabits per second, case closed.
Except what's actually happening under the hood is that many ISPs optimize the path to their own speed test servers. The traffic might never leave their network. They might prioritize those test packets in their QoS configuration. Some have even been caught exempting speed test traffic from the throttling they apply to everything else. You're not measuring your internet connection — you're measuring a carefully curated demo designed to make the ISP look good.
There was a study a few years back — researchers at Northeastern University found that major ISPs were consistently showing higher speeds on their own tests compared to third-party measurements, sometimes by twenty to thirty percent. The gap was largest during peak hours, which is exactly when you most want accurate data.
The ISP's test is useful for diagnosing whether the physical line to your house is broken. If their own test shows five megabits on a gigabit plan, something is wrong with the fiber. But for understanding the real-world performance you'll get connecting to services that aren't hosted inside your ISP's network, you need independent measurement. You need targets outside their control.
That's why Daniel's instinct is correct — you want tools running on your own hardware, pointed at neutral third-party endpoints. Cloudflare, Google, Amazon Web Services. Places your ISP can't optimize the path to without also optimizing it for everyone else.
The other piece Daniel got right is the wired-only constraint. He specifically mentioned the fiber gateway is in bridge mode, which means his OPNsense box gets a public IP directly and there's no double-NAT or ISP router in the middle doing who-knows-what. That's the ideal setup for this kind of monitoring. You're measuring the actual fiber connection, not WiFi interference from your neighbor's microwave.
WiFi introduces so many variables that it makes long-term ISP monitoring nearly useless. Your speed drops because someone walked between the router and your laptop, or because a new access point appeared on the same channel, or because your device decided to switch bands. None of that is the ISP's fault, but it all shows up in your speed test results. Wired eliminates that entire class of noise.
One thing worth mentioning before we get into the tools themselves — the scope here is practical. We're not going to explain what jitter is or how TCP congestion control works. If you're running OPNsense, you already know the basics. What we're doing is filling the gap between "I know I should be monitoring this" and "I know exactly what to install and how to configure it.
The good news is that the tools exist, they're mature, and they're almost entirely open source. You don't need to buy anything. You don't need a subscription. You need some time, some willingness to read documentation, and maybe a spare Raspberry Pi. That's it.
The TIG stack is where we should spend the most time, because it's the least documented option and the most powerful. Telegraf is the collector — it runs on your OPNsense box, and the ping plugin is the first thing you configure. You give it a list of targets, and it sends ICMP packets continuously, measuring round-trip time, jitter, and packet loss. The output goes into InfluxDB as time-series data.
The targets matter. If you only ping your ISP's gateway, you're measuring one hop. Add Cloudflare's one-dot-one-dot-one-dot-one and Google's eight-dot-eight-dot-eight-dot-eight, and now you're measuring real internet paths. If latency to your ISP gateway is flat but latency to Cloudflare spikes, the problem is upstream of your ISP's edge — which is exactly the kind of thing they'll try to blame on "the internet" rather than their own peering.
The speedtest plugin is the other half. It calls the Ookla Speedtest CLI binary — which you have to install separately and accept the license for — and runs a full download and upload test. You configure it in Telegraf's config file with a cron-style interval. Every thirty minutes is common, every hour is conservative. The results — download speed, upload speed, latency, jitter, packet loss during the test — all get written to InfluxDB.
Here's the configuration detail most guides skip: you want the ping plugin running during the speed test. That's how you catch bufferbloat. Set the ping interval to one second, let the speed test saturate the link, and watch what happens to latency. If it jumps from three milliseconds to two hundred, your buffers are too deep somewhere in the chain.
Grafana is where it all comes together. You build a dashboard with a few key panels: a latency-over-time graph with min, max, and average lines, a jitter graph showing the spread, a download and upload speed graph, and — this is the one I find most useful — a combined panel that overlays latency during speed test events. When those two lines diverge, you've got a problem.
The resource question comes up a lot, and the answer is reassuring. Telegraf on OPNsense uses about fifty megabytes of RAM and under two percent CPU on anything with a processor made in the last decade. The heavier pieces — InfluxDB and Grafana — you run elsewhere. A Raspberry Pi four handles it comfortably for a single-router setup.
SmokePing is the second tool, and it's almost the opposite philosophy. Where the TIG stack is flexible and modular, SmokePing does one thing. It uses fping to probe multiple targets, and it renders those distinctive RRD graphs where you can see the latency range as a shaded area around the average line. A healthy connection shows a tight, flat band. Jitter shows up as a widening smear.
The os-smokeping plugin for OPNsense makes installation trivial. You enable it, add your targets in the web interface, and it starts collecting. The graph that'll tell you the most is your ISP's first-hop gateway versus an external target. If both spike together, it's your local connection. If only the external target spikes, it's upstream congestion.
The classic oversubscription signature on a SmokePing graph is unmistakable. Three milliseconds all day, then at eight PM the line climbs to forty-five milliseconds and stays elevated until midnight. Every single evening. That's your ISP's neighborhood node running out of capacity when everyone starts streaming. You can't argue with a pattern that consistent.
VnStat is tool three, and it's the odd one out because it doesn't test anything. It reads your interface counters — the raw byte counts the kernel is already tracking — and turns them into daily and monthly summaries. Average throughput, peak hours, total transfer. Less than ten megabytes of RAM, zero database overhead, runs forever without attention.
The value of vnStat in this stack is correlating utilization with performance. If your SmokePing graph shows latency spikes at nine PM, and vnStat shows your interface is pushing nine hundred megabits per second at nine PM, the congestion might be on your side — something on your network is saturating the link. If vnStat shows low utilization during the spike, the problem is definitely upstream.
Tool four is LibreNMS, and I'll be honest — for a single OPNsense box, it's a lot. Full auto-discovery via SNMP, alerting rules, historical graphs for everything from interface throughput to CPU temperature. It's built for managing racks of equipment. But if you've already got a home lab with a few devices, pointing LibreNMS at your OPNsense gives you a unified monitoring view that's impressive.
The comparison comes down to what problem you're solving. If you want ammunition for ISP complaints, the TIG stack wins — correlated speed test and latency data over time, with timestamps and trends, is the hardest evidence to dismiss. SmokePing gives you the prettiest latency graphs with the least effort. vnStat is the zero-maintenance option for understanding your usage patterns. LibreNMS is the choice when you want to monitor everything, not just your WAN connection.
One thing I want to flag about the TIG stack specifically — the Ookla speed test consumes real data. A full gigabit test pulls about two hundred megabytes. Every thirty minutes, that's roughly three gigabytes a month. On uncapped fiber it's noise. On a connection with a data cap, you need to factor that in.
The thing that surprised me when I first dug into this is that OPNsense actually has a really sophisticated monitoring system already — it's just aimed at a completely different problem. Gateway groups and dpinger are designed to answer one question: is the connection up or down? And they do that brilliantly. You can set up multi-WAN failover, you get instant alerts if a gateway drops, you can even script actions based on link state. But the moment you ask "how good is the connection while it's up," you hit a wall.
It's the difference between knowing your car started and knowing how the engine is performing under load. OPNsense tells you the ignition works. It doesn't tell you the transmission is slipping.
And what Daniel noticed — that there's no plugin filling this gap — is puzzling when you think about it. OPNsense has plugins for everything from intrusion detection to dynamic DNS to VPN servers. But nothing that says "run a speed test every hour and graph the results." Nothing that tracks jitter over a thirty-day window. It's a blind spot in an otherwise comprehensive ecosystem.
Part of the reason, I think, is that the OPNsense community has historically focused on security and routing — the firewall rules, the VLAN segmentation, the VPN tunnels. Performance monitoring of the WAN connection has been treated as something you do externally. Which is fine, but it means new users like Daniel look through the plugin list, don't find what they need, and assume they're missing something obvious. They're not. The tool just isn't there.
That brings us to the second question Daniel raised, which is worth addressing directly: why can't you just trust the ISP's own speed test? Because on the surface, it seems reasonable. They point you to their own Ookla server, you run the test, it says you're getting nine hundred megabits per second, case closed.
Except what's actually happening under the hood is that many ISPs optimize the path to their own speed test servers. The traffic might never leave their network. They might prioritize those test packets in their QoS configuration. Some have even been caught exempting speed test traffic from the throttling they apply to everything else. You're not measuring your internet connection — you're measuring a carefully curated demo designed to make the ISP look good.
There was a study a few years back — researchers at Northeastern University found that major ISPs were consistently showing higher speeds on their own tests compared to third-party measurements, sometimes by twenty to thirty percent. The gap was largest during peak hours, which is exactly when you most want accurate data.
The ISP's test is useful for diagnosing whether the physical line to your house is broken. If their own test shows five megabits on a gigabit plan, something is wrong with the fiber. But for understanding the real-world performance you'll get connecting to services that aren't hosted inside your ISP's network, you need independent measurement. You need targets outside their control.
That's why Daniel's instinct is correct — you want tools running on your own hardware, pointed at neutral third-party endpoints. Cloudflare, Google, Amazon Web Services. Places your ISP can't optimize the path to without also optimizing it for everyone else.
The other piece Daniel got right is the wired-only constraint. He specifically mentioned the fiber gateway is in bridge mode, which means his OPNsense box gets a public IP directly and there's no double-NAT or ISP router in the middle doing who-knows-what. That's the ideal setup for this kind of monitoring. You're measuring the actual fiber connection, not WiFi interference from your neighbor's microwave.
WiFi introduces so many variables that it makes long-term ISP monitoring nearly useless. Your speed drops because someone walked between the router and your laptop, or because a new access point appeared on the same channel, or because your device decided to switch bands. None of that is the ISP's fault, but it all shows up in your speed test results. Wired eliminates that entire class of noise.
One thing worth mentioning before we get into the tools themselves — the scope here is practical. We're not going to explain what jitter is or how TCP congestion control works. If you're running OPNsense, you already know the basics. What we're doing is filling the gap between "I know I should be monitoring this" and "I know exactly what to install and how to configure it.
The good news is that the tools exist, they're mature, and they're almost entirely open source. You don't need to buy anything. You don't need a subscription. You need some time, some willingness to read documentation, and maybe a spare Raspberry Pi. That's it.
The TIG stack is where we should spend the most time, because it's the least documented option and the most powerful. Telegraf is the collector — it runs on your OPNsense box, and the ping plugin is the first thing you configure. You give it a list of targets, and it sends ICMP packets continuously, measuring round-trip time, jitter, and packet loss. The output goes into InfluxDB as time-series data.
The targets matter. If you only ping your ISP's gateway, you're measuring one hop. Add Cloudflare's one-dot-one-dot-one-dot-one and Google's eight-dot-eight-dot-eight-dot-eight, and now you're measuring real internet paths. If latency to your ISP gateway is flat but latency to Cloudflare spikes, the problem is upstream of your ISP's edge — which is exactly the kind of thing they'll try to blame on "the internet" rather than their own peering.
The speedtest plugin is the other half. It calls the Ookla Speedtest CLI binary — which you have to install separately and accept the license for — and runs a full download and upload test. You configure it in Telegraf's config file with a cron-style interval. Every thirty minutes is common, every hour is conservative. The results — download speed, upload speed, latency, jitter, packet loss during the test — all get written to InfluxDB.
Here's the configuration detail most guides skip: you want the ping plugin running during the speed test. That's how you catch bufferbloat. Set the ping interval to one second, let the speed test saturate the link, and watch what happens to latency. If it jumps from three milliseconds to two hundred, your buffers are too deep somewhere in the chain.
Grafana is where it all comes together. You build a dashboard with a few key panels: a latency-over-time graph with min, max, and average lines, a jitter graph showing the spread, a download and upload speed graph, and — this is the one I find most useful — a combined panel that overlays latency during speed test events. When those two lines diverge, you've got a problem.
The resource question comes up a lot, and the answer is reassuring. Telegraf on OPNsense uses about fifty megabytes of RAM and under two percent CPU on anything with a processor made in the last decade. The heavier pieces — InfluxDB and Grafana — you run elsewhere. A Raspberry Pi four handles it comfortably for a single-router setup.
SmokePing is the second tool, and it's almost the opposite philosophy. Where the TIG stack is flexible and modular, SmokePing does one thing. It uses fping to probe multiple targets, and it renders those distinctive RRD graphs where you can see the latency range as a shaded area around the average line. A healthy connection shows a tight, flat band. Jitter shows up as a widening smear.
The os-smokeping plugin for OPNsense makes installation trivial. You enable it, add your targets in the web interface, and it starts collecting. The graph that'll tell you the most
The graph that'll tell you the most is your ISP's first-hop gateway versus an external target. If both spike together, it's your local connection. If only the external target spikes, it's upstream congestion. Two different problems, two different conversations with support.
Here's where we land. If you're staring at your OPNsense dashboard right now wondering where to start, here's the priority list. Step one: install os-smokeping. It's in the community repo, it's point-and-click, and within twenty-four hours you'll have latency graphs that show you things you didn't know about your connection. Add three targets — your ISP gateway, one-dot-one-dot-one-dot-one, and eight-dot-eight-dot-eight-dot-eight. Check back in a week.
Step two: once SmokePing is running and you've confirmed that yes, your ISP is doing something weird every evening at eight PM, add the TIG stack. Telegraf on the OPNsense box, InfluxDB and Grafana on a separate machine. Now you've got throughput data correlated with latency, and you can see the full picture.
Step three is what you do with it. If you're seeing jitter consistently above ten milliseconds, or your download speed is dropping below seventy percent of what you're paying for, collect fourteen days of data — minimum. Export the graphs. File a formal complaint with the FCC if you're in the US, or your country's equivalent. ISPs have thirty days to respond to formal complaints, and they take them seriously in a way they don't take phone calls.
The final piece of advice: run your monitoring for a full month before you make any switching decisions. One bad week could be a fiber cut, a node failure, maintenance work. A month of data separates the anomalies from the trends. Don't cancel your service because Tuesday was slow.
If Tuesday's slow every week for a month, though — that's not Tuesday. That's your ISP.
One thing that's going to reshape all of this in the next few years — ISPs are pushing hard toward CGNAT and IPv6-only deployments. And that changes what these monitoring tools can actually see. If you're behind carrier-grade NAT, your OPNsense box doesn't have a public IPv4 address anymore. SmokePing targets that used to be reachable might suddenly go dark from the outside, because you're sharing an address with a few hundred other households.
The monitoring tools themselves aren't necessarily built for that world yet. SmokePing assumes you can send ICMP from a known source to a known target and get a response. Behind CGNAT, that path gets... The return traffic might not make it back to you the same way. You might be measuring the CGNAT gateway's latency, not your actual connection's latency.
Which is a whole new kind of blind spot. You think your latency is fine because the CGNAT box is three hops away and responding quickly, but your actual path to the internet is degrading and you can't see it.
The fix, I think, is that these tools are going to need to become endpoint-aware in a way they aren't right now. Instead of pinging arbitrary IPs, you might need to ping a service you control — a small VPS somewhere, or a cloud instance — where you can instrument both ends and measure the actual path, not just the ICMP echo from the nearest NAT boundary.
The other shift that makes all of this more urgent, not less, is the rise of five-G fixed wireless as a genuine competitor to fiber. If you're in an area with multiple ISP options, one of them might be a five-G service. And jitter monitoring becomes absolutely critical there, because cellular connections have inherently variable latency in a way fiber users have never experienced.
A SmokePing graph of a five-G connection is a fundamentally different shape than a fiber graph. Fiber sits at three milliseconds with a razor-thin band. Five-G might bounce between ten and forty milliseconds all day, with occasional spikes to a hundred when a truck drives past the tower. That variability might be perfectly fine for streaming video, but it'll destroy a Zoom call or a gaming session.
Here's the thing — the ISP selling you five-G fixed wireless isn't going to volunteer that information. They'll advertise "up to three hundred megabits" and mention "low latency" somewhere in the fine print, but they won't show you the jitter graph. That's on you to measure.
The tools we've talked about today become even more important as the ISP landscape fragments. You're not just comparing fiber provider A to fiber provider B anymore. You might be comparing fundamentally different technologies — fiber versus five-G versus whatever comes next — and the only way to make an informed choice is with your own data, collected on your own hardware, over a meaningful period of time.
Which brings us back to where Daniel started. He's got OPNsense, he's got a clean fiber connection, and he's asking the right question before he potentially adds a second ISP or switches providers. Get the monitoring in place now, while you have a stable baseline. Then when you add a five-G backup link or consider switching, you're not guessing. You're comparing actual performance data.
We'd love to hear what you find when you set this up. The patterns people discover are sometimes bizarre — we've heard stories of connections that degrade every time it rains because water was getting into a street-level junction box, or latency that spikes exactly when the streetlights turn on because of some weird electrical interference. Share your discoveries with us.
Now: Hilbert's daily fun fact.
Hilbert: In the late Victorian period, explorers in the Simpson Desert reported hearing a low-frequency hum emanating from sand dunes during katabatic wind events — the descending cold air vibrating the dune faces like a massive aeolian harp, producing tones around twenty-seven hertz, just at the threshold of human hearing.
A singing desert.
Twenty-seven hertz.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this episode, do us a favor and leave a review wherever you listen — it helps more people find the show. We'll be back next week with another prompt from Daniel.
