Almost every network graph you have looked at was derived from a counter. Not a measurement of speed — a running total, sampled twice, subtracted, and divided by the time between the samples.
That derivation is where traffic graphs go wrong, and they go wrong in a small number of predictable ways. This is worth understanding whether or not you use our tooling, because it determines which of your graphs you should believe.
A total is not a rate
A gateway exposes cumulative octet counts: bytes since the interface came up. Turning that into "megabits per second" needs two readings and the interval between them.
The first consequence is immediate: the first reading is worthless on its own. A counter read once tells you how much has moved since the router booted. A graph that treats that number as a rate opens with an enormous spike representing days of traffic compressed into one sample — and because it is the first point, it sets the axis maximum, flattening everything real that follows into a line along the bottom.
The correct behaviour is to discard it. The first sample establishes a baseline and reports nothing.
Counters run backwards
Subtracting two readings assumes the second is larger. Two entirely ordinary events break that assumption.
Reboots. Consumer gateways reset counters when they restart, and routers restart often — firmware updates, power cuts, the nightly reboot some ISPs schedule, the user who power-cycles it because a video stalled.
Wraparound. Many gateways use a 32-bit counter. That holds about 4.3 billion octets, roughly 4 GB. Work out what that means on a modern connection: a gigabit link saturated in one direction moves 4 GB in about thirty-five seconds. Even a busy household on a mid-tier connection will wrap such a counter several times an hour. This is not an edge case; on fast links it is the normal operating condition.
In both cases the naive subtraction yields a large negative number, and what a graph does next is the whole question.
Treating it as zero invents a period of silence that did not happen. Taking the absolute value invents a flood that did not happen — and a fabricated traffic spike is considerably worse than a gap, because someone will investigate it. Or worse, they will not investigate the real one next week, having learned that the graph cries wolf.
The honest response is to report nothing for that interval, re-establish the baseline, and let the gap be visible. A gap is a true statement: "this measurement is not available." A spike is a false one.
Note also that a wrapped counter cannot be recovered by arithmetic, because a counter that wrapped twice between samples is indistinguishable from one that wrapped once. Shorter sampling intervals reduce how often this happens. Nothing eliminates it.
Not every counter exists
The UPnP Internet Gateway Device specification defines byte counters and packet counters. In practice byte counters are near-universal and packet counters are optional in the field — plenty of consumer firmware either omits them or returns an error when asked.
This produces a specific failure that is easy to miss. If a tool asks for packet counts, receives an error, and records zero, the resulting graph shows a flat line along the bottom. That is indistinguishable from a genuinely idle network, and it is the reading a person is most likely to accept without question, because zero packets on a quiet connection looks entirely reasonable.
"Not reported" and "zero" must be different states, and the difference has to reach the person looking at the graph. A metric that is not being collected should be shown as absent, and the tool should say so when it starts rather than leaving you to discover it mid-incident.
There is a subtler version of this. If a gateway answers packet queries for a while and then stops, the sudden drop from a large value to zero looks exactly like a counter reset. A monitor that treats it as one will discard that whole interval — throwing away perfectly good throughput data because a different, optional metric went away. Whatever logic handles resets has to know which counters it is actually reading.
What this means for reading graphs
Three questions worth asking of any traffic graph, including ours:
- What happens at a reboot? If the answer is a spike, the graph will lie to you a few times a month.
- Is a flat line at zero distinguishable from a missing metric? If not, you cannot tell a quiet network from a broken sensor.
- How wide is the underlying counter, and how fast is the link? If the counter can wrap between samples, the graph's accuracy depends entirely on how the tool handles going backwards.
None of this is exotic. It is arithmetic on a published specification. But it is the difference between a graph that is decorative and one you can act on.