Reading a bandwidth graph: what normal looks like

Open your router's traffic graph for the WAN interface and set the window to the last seven days. Most people have looked at this once, decided it was a blue mountain range, and closed it again.

It is one of the more useful instruments you already own, and nearly everything worth knowing is in the shape rather than the numbers.

Two things that will mislead you first

The vertical axis rescales. A graph whose peaks touch the top of the frame does not mean you are maxed out; it means the tallest thing inside the window got drawn at the top. Read the peak value against what you pay for — a graph that fills the frame at 12 Mbps on a 300 Mbps circuit is a quiet week.

And check the units. Circuits are sold in megabits per second; plenty of tools graph megabytes per second, and a factor of eight will convince you that you are saturated at an eighth of the line. RX and TX are from the router's point of view, so on the WAN interface RX is your download.

A normal business day

Lumpy. A rough plateau from when people arrive to when they leave, falling overnight to a trickle that never quite reaches zero — updates, cloud sync, cameras, keepalives. Download several times upload, with spikes that jump well above the average and drop straight back.

The quality to notice is raggedness. Human traffic is bursty at every timescale, so when a graph goes smooth, something automated is driving it.

The backup window

A rectangle. It begins at a round-numbered time, usually between midnight and four, holds a nearly constant rate for a few hours, then stops. Mostly upload. The flat top is the tell: one transfer that has found a ceiling — a rate limiter, or the circuit itself — and is sitting on it.

Two things to check. Does it finish before people arrive? A rectangle still running at 8:30 is why the morning feels slow. And is the flat top at your full upload rate? If so, every other upload, voice calls included, is queueing behind it.

A saturated uplink

Flat at your circuit rate, and staying there. This one is treacherous because it doesn't look like a fault; it looks like the line working hard, which is what you bought it for.

The difference between saturation and one rate-limited transfer is the texture of the top edge. A rate limiter draws a clean line; saturation is fuzzy, many flows shoving at the ceiling and losing packets to each other. A flat upload under a normal download is almost always backup, camera footage, or file sync.

The broadcast storm

Sudden, square-edged and enormous. A LAN interface jumps to near line rate — 900-odd Mbps on a gigabit port — inside a single sample, and it shows on several ports at once with near-identical shapes, because that is what a loop looks like: the same frames going round.

The confirming detail is packet size. Divide bytes by packets. A storm is an enormous count of very small frames, which no real workload produces; /interface print stats gives you both counters. Then hunt the loop — a patch cable in two wall ports, an unmanaged switch daisy-chained back on itself, an access point bridging a VLAN to itself.

The polling sawtooth

Identical narrow spikes at a fixed interval, day and night. Something on a timer: a monitoring agent, a camera pushing snapshots, a mail client checking every five minutes. Harmless, and useful as a heartbeat — when it stops, that device stopped.

What the graph cannot tell you

This is why "check the bandwidth graph" so often goes nowhere. When people say the internet is slow, they are rarely describing throughput. They are describing delay, and delay and utilization are only loosely related.

A 200 Mbps circuit sitting at 60 Mbps can feel unusable if one upload has filled the buffer inside the modem. Nothing is dropped, so nothing looks wrong — packets are queued, and a queue deep enough to hold a second of traffic adds a second of latency to every other packet, including the DNS lookup at the front of every page load. That is bufferbloat, and a bandwidth graph cannot show it.

Proving it takes thirty seconds: ping something stable while a large transfer runs. If idle latency is 12 ms and loaded latency is 400 ms, more bandwidth will not help. You need the queue to form on your side of the modem, where you control how it drains:

/queue type
add name=cake-wan kind=cake
/queue simple
add name=wan-shape target=192.0.2.0/24 max-limit=18M/180M \
    queue=cake-wan/cake-wan

Set the limits a little under what the circuit actually delivers — around 90 percent — so your router is the bottleneck rather than the modem. On older builds, kind=fq-codel does most of the same work.

What to do

1. Turn graphing on for the WAN and the uplinks between your switches, and leave it running.
2. Learn your own normal while nothing is wrong. Shapes only mean something against a baseline you have watched before.
3. When someone reports slowness, take the loaded-latency measurement before you look at throughput.
4. Use live tools for the "who" question. A graph gives a shape; /tool torch ether1 gives the host.

If nobody is watching these graphs in between the moments something breaks, that gap is most of what NetCare is for.