Packetman saysPerformance grading is the passive complement to the Speed Test add-on. Every TCP session your device runs gets a latency reading and a retransmission count from the kernel itself — these are numbers Linux and Windows already track for their own use, and we just expose them. No synthetic probes, no test bursts, no proxy in the middle. Sessions shorter than half a second are ignored because TCP hasn't escaped slow-start in that time, so the readings would be noise. Everything else gets graded against four explicit thresholds: Excellent under 50ms with under half a percent retransmits, Good under 100ms and under 1%, Fair under 200ms and under 3%, Poor anything worse. The verdict uses the worst of the two metrics so an app with great latency but high retransmits doesn't get a flattering average. Per device, per app, on a 24-hour timeline, and ranked across your whole fleet. Included freeNo synthetic probes. No proxy. No bandwidth taxed. Every TCP session your devices run gets a kernel-native latency and retransmit reading; we roll those into one verdict per device, one per app, a 24-hour timeline, and a fleet ranking — in plain English, on every tier, at no add-on cost.
Hover Packetman for the technical bit.
Packetman saysPacketman here. Security is essential, and when it's working there is nothing to do. That's the point. What actually eats a team's week is performance: the call that stutters, the app that crawls, the sync that never finishes. So the same agent that vets every destination also reads how often each device had to send the same data twice, per device and per program. And when we test on purpose, we send about ten packets instead of hundreds of megabytes.Nobody spends Tuesday afternoon on a threat that was refused before it arrived. They spend it on “the call keeps dropping” and “this used to be fast.” The same agent that does the security job quietly is built to answer those — without becoming the problem it is measuring.
How often a device had to send the same data twice is the most telling health signal a network has. We read it from every session, grade it in plain English, and attribute it to the program that opened the session — so a struggling file sync and a healthy video call on the same laptop are told apart, not averaged together.
When we test on purpose, we send a small burst and read the spacing between packets on the far side. That reveals capacity and latency from kilobytes of traffic. The popular speed tests push hundreds of megabytes through the very link they are trying to measure. How we measure →
Your devices test the paths between each other, each direction on its own, on a schedule. When a branch is slow, the answer is which leg, which direction, and since when — measured from the machines your people actually use. Mesh diagnostics →
Packetman saysPacketman here. A lot of security events show up first as a performance complaint. Data being stolen looks like a slow upload. A compromised machine probing its neighbors looks like retransmits and resets. A cryptominer looks like a hot, sluggish laptop. Because every session we record carries both its performance reading and the program and destination behind it, a slowdown and a security finding are often the same row read two ways. That's why one agent does both.Many security events announce themselves as a performance complaint long before anything else notices. Because every session record here carries both its performance reading and the program and destination behind it, the slowdown and the security finding are often the same row, read two ways. Four shapes that come up again and again:
The upload path is saturated, calls stutter, sync crawls. The per-program view shows one program moving far more data out than anything else on the machine — to a destination with a grade attached, from an executable with a verdict attached. The slow afternoon and the security finding are one record.
A compromised host trying its neighbors generates failed connections — timeouts, resets, retransmits — which grades as Poor. We attribute every attempt to the executable that made it and see the same program fanning out across machines. The “bad network card” turns out to be a program.
Processor pegged, fans on, everything slow. The live resource gauges show the load; the session record shows which program is holding connections open, to where, and how that destination grades. The performance ticket names the intruder.
Tiny, regular sessions from one program produce no performance symptom whatsoever — which is exactly why you need the security lens on the same record: periodic timing, an unsigned binary, a low-grade destination. One lens alone misses it.
It runs the other way too. When a security action has a performance cost — a blocked destination that broke an app — the Blocked tab shows the program, the reason, and the dispute path, so “the app is broken” resolves in one look. Security and performance are cousins; the agent reads each through the other. The security side of the same idea →
Packetman saysWhy trust a passive reading? Because the numbers underneath it are the ones four decades of packet work taught us to watch. Retransmission rate — how often a host had to send a packet twice — is the closest thing the network has to an SOS signal, and the kernel already counts it for free. We measure each direction on its own, because TCP is half-duplex and an average across upload and download hides whichever one is failing. And when we do test on purpose, we sip — about ten packets of packet-pair dispersion finds the bottleneck without flooding your link. The agent should never cause the problem it's measuring.Three forensic habits sit under every verdict on this page — they’re why a passive reading can be trusted as much as a test you ran on purpose.
The fraction of packets a host had to send twice is the single most powerful proxy for network health. We read it straight from the kernel, no probes. Out of ten thousand devices it points you at the thirty or forty that are actually struggling.
Upload and download succeed or fail on their own. We measure and report every metric per direction, A→B and B→A, because an average across both hides the one direction that’s failing.
When we measure actively, packet-pair dispersion — roughly ten packets — reveals the bottleneck without flooding the link. Brute-force flood tests are the anti-pattern, opt-in only. The agent should never cause the problem it’s measuring.
Two metrics — median internet latency and retransmission percentage. Worst-of-two drives the grade so an app with great latency but high retransmits never gets a flattering average.
Sub-half-second sessions are excluded from grading — TCP hasn't escaped slow-start that early, so the latency reading would be noise rather than signal.
Packetman saysPacketMan here. A network number with no owner is half an answer — knowing the link is slow doesn't tell you if it's the line, the Wi-Fi, or one bad app. We read every qualifying TCP session from the kernel — throughput, round-trip time, retransmits — and tie it to the exact program that opened it. So the readout isn't "the network is slow," it's "Teams is hurting while OneDrive on the same machine is clean." Symptom, meet diagnosis.We don’t sample a few connections and guess at the rest. Every qualifying TCP session your machine opens gets read — throughput each direction, round-trip latency, and retransmits — and tied to the exact program that opened it. That per-session reading is the raw material; everything else on this page is that material rolled up.
| Program (this device, last hour) | Throughput · down / up | Latency (RTT) | Retransmits | Grade |
|---|---|---|---|---|
| OneDrive | 41 / 8 Mbps | 44 ms | 0.2% | Excellent |
| Chrome | 18 / 1 Mbps | 39 ms | 0.4% | Excellent |
| Zoom | 1.8 / 0.9 Mbps | 96 ms | 0.8% | Good |
| Microsoft Teams | 2.1 / 0.4 Mbps | 182 ms | 3.1% | Fair |
Illustrative readout. Throughput, latency, and retransmits are read per session and attributed to the owning process — so “Teams is the one struggling” is a fact on the screen, not a guess.
One reading rolls up four ways, so the right answer is there whether you own one laptop or run ten thousand of them.
A single TCP session: throughput each direction, round-trip latency, retransmits — the rawest signal, owned by one process.
Every session that executable ran today, rolled into one grade. Answers the eternal “is it the app or is it the network?”
Every program on that device, one verdict and a 24-hour timeline. This is the view the agent’s owner opens straight from the tray or dock.
The same verdict across the whole tenant, ranked. The operator’s view through the dashboard menus — is it one desk, or the whole floor?
Two audiences, one measurement: the person who owns a single agent watches their own machine from the tray; the operator watches the fleet from the menus. Nobody has to ask the other for a number.
Those scales show up as three surfaces in the product, each a click from your dashboard — the same data, sliced for the question you're asking.
Packetman saysLives on every agent detail page under the Performance tab. The grade pill is paired with a one-sentence headline ("This device is performing well") and the evidence ("97% sessions clean · median 38 ms · 0.2% retx"). Last-hiccup line shows the most recent fair-or-worse session — when, which app, and the numbers — so you can chase the actual cause.One pill, one headline, one evidence line. "This device is performing well — 97% of sessions ran clean, median internet latency 38 ms, 0.2% retransmits." If anything's hurting it, the last-hiccup line names the app and when.
24h timeline — five-minute buckets, color = worst grade in that window. Dim grey = device idle.
Packetman saysSame grading rules applied to each app independently. Apps with fewer than 3 qualifying sessions are excluded — too few readings to grade fairly. Worst-graded apps surface first, so the thing hurting your experience jumps to the top of the table without you having to sort.Every app you used today, graded the same way. Slack: Excellent · Edge: Good · OneDrive: Fair (180 ms · 3% retx). Worst-graded apps surface first, so the thing actually hurting you sits at the top.
Packetman saysTenant-wide view at /agents/health. Top of every dashboard shows a single-line band: "Fleet is healthy — ● 8 Excellent · ● 3 Good · ● 1 Fair" with a link through to the full ranked tables. The page itself shows Fastest 10 + Slowest 10 with grade pill, median RTT, retx %, and session count, and the grade distribution as a horizontal bar.The whole fleet, ranked. Fastest 10 on the left, Slowest 10 on the right, grade distribution across the top, median fleet latency right next to it. One click from your dashboard band tells you exactly which devices need attention.
Packetman saysPacketman here. Passive grading watches each session your device runs — but it can't tell you which agent-to-agent path inside your network is hurting. The mesh does. Paired agents run a controlled small-burst test between themselves on a schedule, in both directions independently, and the fleet dashboard collapses N-squared pairs into one heat-map. A path with 5 milliseconds in one direction and 80 in the other isn't a paradox — it's a clue. The chips up top tell you how many cells are within each link's own historical best, how many slipped a little, how many slipped a lot. One look, the whole fleet's inter-agent posture.Every agent pairs with every other agent in a controlled small-burst test — both directions independently, on a schedule. The fleet dashboard collapses N² pairs into one heat-map so the worst legs jump out instantly. Below is the live readout from our own mesh.
| G16 | acer | gus mac lap1 | linda | si | stun | |
|---|---|---|---|---|---|---|
| G16 → | · | 5 ms | 80 ms | 63 ms | 2 ms | 46 ms |
| acer → | 6 ms | · | 86 ms | 81 ms | 6 ms | 49 ms |
| gus mac lap1 → | 57 ms | 65 ms | · | 101 ms | 63 ms | 104 ms |
| linda → | 61 ms | 64 ms | 99 ms | · | 61 ms | 101 ms |
| si → | 1 ms | 5 ms | 186 ms | 119 ms | · | 45 ms |
| stun → | 46 ms | 51 ms | 147 ms | 109 ms | 46 ms | · |
| G16 | acer | gus mac lap1 | linda | si | stun | |
|---|---|---|---|---|---|---|
| G16 → | · | 19 Mb | 12 Mb | 2.0 Mb | 19 Mb | 17 Mb |
| acer → | 21 Mb | · | 18 Mb | 1.2 Mb | 27 Mb | 6.1 Mb |
| gus mac lap1 → | 1.9 Mb | 2.2 Mb | · | 4.6 Mb | 2.2 Mb | 189 Mb |
| linda → | 1.9 Mb | 2.0 Mb | 3.5 Mb | · | 2.4 Mb | 1.3 Mb |
| si → | 51 Mb | 54 Mb | 3.3 Mb | 3.0 Mb | · | 92 Mb |
| stun → | 2.8 Mb | 2.2 Mb | 34 Mb | 3.7 Mb | 3.8 Mb | · |
Live snapshot from our own mesh — six agents across LAN, home broadband, mobile, and server. Each cell is one direction of one pair; the colour compares the current reading to that link’s own historical best, so a fast link slipping is what jumps out, not a slow link staying slow. Cells with a midpoint dot are self-cells (an agent doesn’t test against itself). With N agents you get N² − N independent direction-specific readings: six agents produce 30 cells, ten agents produce 90, fifty agents produce 2,450 — one click of the menu surfaces them all.
Packetman saysPacketman again. Every cell in that heat-map is the result of a real connection between two agents, and getting that connection is harder than it sounds. Most pairs sit behind home routers or carrier NAT, so neither side can be called directly. Our coturn server gives each agent two things at startup: a STUN reading of what address-and-port the public internet sees it on, and a TURN relay slot in case nothing else works. Each agent advertises both to the others through the tenant platform, and then for every peer it tries the cheapest path first — same-LAN if they share a subnet, otherwise a coordinated hole-punch that opens a direct path through both NATs, and only if that fails does it fall back to relaying through coturn. The green path is what we want every time: coturn just told us each side's reflected port; the packets themselves go agent-to-agent. The lavender path is the always-works last resort.The mesh measurement is honest only if the path it measures is the path your data would actually take. So agents try the cheapest, most direct path first — same-LAN if available, then a coordinated NAT hole-punch, then mutual relay through coturn as the last resort. The diagram below shows the ladder.
DTM1 echo → RTT (EWMA, α = 1/6) so a single bad sample doesn’t spike the chartDTM3/4 packet-pair (×5) → bottleneck bandwidth in Mbps without flooding the linkDTM5 punch-hint → coordinated NAT crack when the path doesn’t already existEvery agent maintains a persistent TURN allocation on stun.datastun.com. That allocation gives the agent its reflected IP:port (STUN side) and a relay address (TURN side); both are advertised to every peer, so each peer can try LAN, punch, and relay in sequence and pick the one that works. The green path is the goal: coturn was contacted only to learn the reflected port, and the test packets go agent-to-agent. The lavender path is correct when nothing else works, but the measurement is then of the relayed leg.
Packetman saysPacketman again. The heat-map is the overview; this is what you see when you click a cell. It's the actual traceroute between two of your agents, IPv6 in this case because both ends had public v6 — and v6-direct is preferred when it's available because it avoids the NAT-punch entirely. Each circle is one TTL slot, one router along the way. The solid cyan circles responded with ICMP Time-Exceeded so we have their IP and RTT; the dashed circles didn't — carriers often suppress ICMP on a subset of hops, especially in the core, so silent hops are normal and not an alarm. The hop's IP and RTT are staggered above and below the path so long IPv6 addresses don't overlap each other; a thin guide line ties each label to its hop. Hover any hop in the real product for rDNS, ASN, and geo; the NAT translations on each end show whose carrier you're crossing — AT&T to TWC in this case, which is why you see two ASNs on the trip.Every cell in the heat-map above is a clickable drill-down. The per-pair view shows the actual route between two agents — both NAT translations, every IPv6 hop that answered, and the ones that didn’t. Below is the live readout for one of our own pairs: acer in Cedar Park to linda in Humble, 14 hops, half of them silent (which is normal — carriers suppress ICMP in the core).
Each circle is one TTL slot. Solid cyan = the router at that hop responded with ICMP Time-Exceeded, so we have its IP and RTT. Dashed = no response within 900 ms (carriers commonly suppress ICMP on a subset of hops, especially in the core, so silent hops are normal and not an alarm). Each responding hop’s IP and RTT are staggered above and below the path so long IPv6 addresses don’t overlap; a thin guide line ties each label to its hop. The +N next to each RTT is the delta from the previous responding hop — a small positive number is healthy ladder behaviour; a sudden jump points at the leg where the latency is being added. In the real product, hover any hop for rDNS / ASN / geo; if the pair used a TURN relay (lavender on the connection ladder above), additional cyan curves appear at each end showing the relay leg.
Packetman saysPacketman here. The popular internet speed tests — Ookla, fast.com, speedtest.net — work by hurling hundreds of megabytes of traffic at a single CDN node a thousand miles away and timing how long it takes. That's useful exactly once, when you want to know "how fast is my link, at this moment, in this one direction, to this one CDN." It's useless for everything else: it taxes the link you're trying to measure, it can't tell you what's between your laptop and your file server, and if you're on a metered cell connection it costs you real money. We do it differently. Small-burst smart sampling — roughly ten packets with inter-packet-gap analysis — gives us throughput and latency for kilobytes of cost, not megabytes. And we run those bursts between your agents, on a schedule, in both directions independently. That's how you get a heat-map of every leg inside your fleet without anyone noticing the test ran.The popular internet speed tests hurl hundreds of megabytes at a single CDN node to clock your link in one direction. Useful once. Useless if you want to know what’s happening between your laptop and your file server — and expensive on a metered, mobile, or congested link. We do it differently: small-burst smart sampling between your agents, both directions, on a schedule.
Hurl as much traffic as the link will carry at a single CDN node and clock the throughput.
Coordinated small bursts between your own agents, both directions, on a schedule.
Need the deterministic-flood number anyway — for an ISP SLA dispute, a before-and-after change validation, a network-acceptance test? The Speed Test add-on runs that on demand, still agent-to-agent (or agent to a DT-operated heavy responder), still under your control. See the Speed Test add-on →
Passive grading runs on every tier. The Speed Test add-on layers controlled measurement bursts on top when you want a deterministic number.
| Performance grading (this page) | Speed Test add-on → | |
|---|---|---|
| How it measures | Reads kernel-native TCP stats from sessions your apps were already running | Active measurement bursts between paired agents (N² mesh) |
| Bandwidth cost | Zero — observes existing traffic only | Configurable; small-burst smart sampling by default, not Ookla-style flood |
| What you get | Verdict per device + per app + 24h timeline + fleet rank | Latency, throughput, jitter, packet loss, traceroute — per direction |
| When to use it | Always — it's the daily-driver "is anything wrong?" surface | When you need a deterministic before/after, or pair-specific path data |
| Tier | Every tier — included free | Per-agent add-on, Business and above |
| Privacy | Metadata only (latency, byte counts, retransmit counts) — never packet contents | Same; the burst is to a peer agent we control, not a third-party endpoint |
The two are designed to work together. Passive grading runs continuously and tells you something is off; active testing answers how off with controlled, repeatable measurements.
Synthetic probes are easy to fool, expensive to run at scale, and tell you about a moment in time. Real-traffic readings tell you what your users are actually experiencing.
The agent reads numbers the kernel already tracks for its own TCP control loop. We don't generate traffic, we don't open extra sockets, we don't tax your bandwidth even on metered or congested links. The data was free; we just expose it.
A speed test to a CDN node twenty miles away tells you the best-case capacity of your line. It doesn't tell you why Microsoft Teams is stuttering or why OneDrive uploads are taking forever. Reading the kernel stats from the actual Teams session does.
A user runs a speed test, gets a fine number, and ten minutes later their call drops. Passive grading is always running, so the 24-hour timeline shows you exactly when things were bad — even if no one was at the keyboard to notice.
Active probes measure the network. Passive grading measures the network per application — because every TCP session is owned by a specific process, and we know which one. "Slack is fine, OneDrive is fair" is the answer; you didn't have to think to ask the question.
Worst-of-two-metrics means an app with 30 ms latency but 5% retransmits grades Poor — the problem isn't hidden by an average. Sub-half-second sessions are excluded so quick connection probes don't drown out the real conversation. The thresholds are explicit, published, and calibratable per tenant later.
One agent's verdict is useful. The same verdict applied across every device on your tenant lets you rank the fleet, surface the slowest 10, and answer "is it just my machine or is the whole office hurting today?" in one glance.
We read what the kernel already tracks. We don't inspect packets, we don't decrypt anything, we don't proxy anything.
TCP_INFO.tcpi_rtt, Windows ESTATS hooks)All four are numbers the kernel tracks for its own control loop. We expose them; we don't compute them.
There is no decryption code path on the agent. There is no proxy. The data we see is the same data netstat sees — just continuous, attributed, and graded.
Grading is the always-on signal: it tells you which device, which app, which hour went bad. When you need the cause — not just the location — the same agents escalate to active diagnostics, on demand. No new software, no truck roll.
Passive grading runs continuously and surfaces the device or app that slipped to Fair or Poor — with the hour, the throughput, the latency, and the retransmit count already attached. You start knowing where.
Run an agent-to-agent test along the suspect path, both directions, to turn “something’s off” into a deterministic number — throughput, jitter, loss, and the routers on the way out and the way back.
When a number still isn’t enough, Advanced Packet Diagnostics captures the session on both ends, decodes it centrally, and hands PacketMan the trace for a plain-English diagnosis — with no capture tools installed on the machine.
For paths that look fine on a traceroute but lose packets on every hop, Hop Starvation probes for the silent TTL-expiry drops that betray an injection appliance. The grade points; the diagnostics close.
Packetman saysPacketman here. In IT service management the discipline is called problem management: find the recurring cause behind the incidents, not just the incident. Our version is distributed. Each device grades its own sessions, names the program behind a slowdown, and runs the deeper tests itself when asked. The center collects the findings and hands them to your help desk already diagnosed. The device did the work; the person gets the answer.Service-management frameworks call it problem management: find the underlying cause behind the incidents that keep coming back. It is where help desks lose the most hours, because the person with the ticket rarely has the evidence. Here the evidence is gathered by the device itself and arrives with the ticket.
Every session is graded on the machine that ran it, per device and per program, so the recurring problem shows up as a pattern — this app, this device, this hour — not as a pile of unrelated complaints.
The diagnosis names actors: the headline, the pattern, the programs and destinations involved, and the action to take. When a number is not enough, the same agent runs the path test or the packet capture on request — no truck roll, no software to install.
In-product support answers first with the device’s own context, and gives the user commands they run themselves. Anything unresolved escalates to your admin with the whole thread attached, so the second person does not start from zero.
Findings and alerts leave by signed webhook and email into your on-call and help-desk tooling today; native incident-shaped records for service-management platforms are on the roadmap. Business tier and above. Integrations →
The architecture rests on decades of professional experience of which problems actually occur on real networks — and on the observation that the device experiencing the problem is the one best placed to diagnose it.
Packetman saysPacketman here. Everything above is included. Two things sit on top, as options. Advanced diagnostics let a central team run deep tests on a local machine or between two of them, and capture the packets when a number isn't enough. That one is priced per incident. Remote assist lets the help desk reach out through the same system and help the person directly, with the user's consent absolute. That one is a four-dollar-per-endpoint add-on, billed across the whole tenant, and it stays off until an administrator turns it on. Larger organizations may already have tools. Smaller ones usually don't, and integrating a separate remote-management system is hard. Here it's already in place.The grading, the diagnosis, and the help-desk hand-off above are included. For the small share of problems that are genuinely hard, two capabilities sit on top as add-ons — one priced per incident, one per endpoint across the tenant — each gated by policy and consent, each running on the same agent that is already there.
When a critical problem resists the ordinary evidence, a central engineer can run deep analysis on one local machine or between two of them: the mesh test along the suspect path in both directions, and Advanced Packet Diagnostics, which captures the actual packets at both ends, charts each direction, runs the expert analysis, and adds a plain-language diagnosis. The evidence grade that used to need an engineer with a tap on site, from wherever the agent is.
Security-dependent by design. Captures are opt-in per test, issued by an authorized operator, scoped to one peer and port, brief, and removed from the device after upload. Nothing is installed on the endpoint to do it. Outside of a capture, the agent never sees content.
The help desk that already sees the device’s diagnosis can, with the person’s agreement, see their screen and help them directly — through the same agent, the same console, and the same audit trail, with no second product to deploy.
The basics, honestly scoped. Today it is attended help for Windows users: screen, mouse and keyboard, several monitors, text clipboard, and admin changes the person approves; on Linux and macOS it is a terminal on the device over the same consented session. It is not yet file transfer, not the Windows login screen or elevation prompts, not a smooth video feed, and not screen sharing on macOS. Those are on the list in roughly that order; the price reflects the basics.
Consent is absolute. The person at the keyboard says yes each time, sees who is asking and why, sees a banner the whole time, and can end the session from it. Sessions start view-only; the person can allow control, or keep it to viewing only. They can also say never — and a never cannot be overridden by an administrator, a policy, or us. Nothing is recorded.
An add-on on Tribe, Business, and Enterprise: $4 per endpoint per month, billed on every endpoint in the tenant — it is turned on for the tenant, not per device, so a device that never uses it is still counted. Off for every tenant until an administrator turns it on and chooses who may operate — your own admins, your IT provider, or DataStun support. Larger organizations with their own remote-support tools can leave it off. Smaller organizations get remote help without standing up and integrating a separate remote-management product. Pricing →
N² pairs of agents producing bidirectional latency / throughput / jitter / packet-loss measurements. 500 agents = 124,750 measurement pairs. When a user says “the VPN is slow,” you do not argue.
Probes networks for silent TTL-expiry drops that indicate an injection appliance. The diagnostic for paths that look fine on a traceroute but lose packets on every hop. Per-agent add-on on Business+.
Performance grading lights up the moment your first agent is enrolled. No setup, no opt-in, no add-on charge. Individual tier covers up to 10 agents with 30 days of history.