Flatness was the proof — two lines, two wrong suspects

Two of my three homes hang off a radio link: Kapfenberg over mobile with Magenta, Merano over fixed wireless to a mountain with Eolo. Both cause trouble occasionally, and for both the obvious suspect was the provider.

I was wrong about both — in completely different ways. In Kapfenberg it was my own automation. In Merano it was the measuring tool.

Here is how to measure the difference instead of guessing it.

Kapfenberg: four days at one fifth

The description was the usual one: “sometimes it is slow, it seems to need a reset now and again.” You cannot build a support ticket on that, or a decision.

You can build one on the measurement series:

Day	Median	lowest	highest
05.10.	409	231	660
06.10.	333	88	595
07.10.	92	85	93
08.10.	92	78	92
09.10.	92	85	93
10.10.	92	85	93
11.10.	354	89	632

Flatness is what matters, not the low value

That is the sentence this turns on. With nearly fifty measurements a day, all of them sit between 78 and 93. On any normal day the same connection swings between 90 and 660.

And both directions fall by almost exactly a factor of five: 450 → 90 down, 110 → 22 up. With the radio path unchanged — same cell, same band, same signal.

A congested cell does not throttle both directions to exactly one fifth and hold it for four days within ±5 per cent. That is an imposed limit, not congestion.

That turns “sometimes slow” into evidence you can put in front of a provider: four days, both directions at one fifth, radio path unchanged, with cell and timestamps to the minute.

And then it was my own automation

I had attributed the end of the throttling to a reset Magenta had triggered. “Plausible, but not evidenced in the measurement data.”

It is evidenced now — and it was something else.

Both timestamps in my notes were UTC, written down as if they were local time. The hourly means show the drop at 17:00 local, not at 15:07. So the end is not at 01:05 but at 03:05 local.

And that is not an arbitrary hour. That is when my own nightly restart runs, set for 02:55.

The control that carries it: during the throttled days the nights were throttled too. It is not that it simply gets fast again at night.

Night, 03:00 local	Download
Wed 07.10.	92
Thu 08.10.	92
Fri 09.10.	92
Sat 10.10.	91
Sun 11.10.	506

Four nights at 91–92, the fifth at 506. The difference is the restart.

Two hypotheses, honestly tested

The observation was: “it always happens at the weekend, after four days.”

“After four days” — not confirmed. Between restart and drop lay 2 days 14 hours once and 5 days 15 hours the other time. Four days sits exactly in between: a fair impression, but not a rule. In between lie eighteen days without a single throttling episode, across three restarts.

“At the weekend” — not confirmed. Throttled days were Wednesday to Saturday. What fell on the weekend was not the start but the end — because that is when the restart ran.

“It needs a reset” — confirmed, and more firmly than it was meant. Two of two episodes end in the restart hour. None ends by itself.

That is the value of a measurement series: it disproves two parts of an everyday observation and confirms the third harder than it was intended.

A trail that did not hold

One sensor read 0 after the restart and 2 during the throttling. That looked like the explanation — a fallback from 5G to aggregated LTE.

It did not survive the control check. In another period the same value also sat at 2, with daily medians of 350 to 414. So the value says nothing about the throttling.

The result

Instead of Sundays, the restart now runs daily. Thirteen days later: not a single continuous throttling episode, daily medians 361 to 525.

It did strike once, on a Tuesday at 21:00. Six hours later it was over.

Under the old Sunday schedule the same episode would have started on Tuesday evening and lasted until Sunday morning. Five days instead of six hours.

In passing: all three drops began in the evening — 17:00, 18:00, 21:00. Three out of three. I have no explanation, but it is on the record.

Merano: the measuring tool was the problem

Different place, different technology, different mistake.

The line there runs over fixed wireless and has two modes: around 100/20 in normal operation, around 4/10 throttled. A factor of 25 — easy to spot, you would think.

The first attempt would have proven a throttling that did not exist:

Source	Download	Upload	Ping
built-in integration	23.15	12.19	1,800,000 ms
independent service	74.15	18.3	19.9 ms
provider-near server	100.95	20.2	21.77 ms

The built-in integration was out by a factor of four, presumably through a poor server choice. Its ping sensor reported half an hour. The connection actually delivers the contractual 100/20.

It was removed. Had I believed it, I would have complained to the provider about throttling that never happened.

Which tool was which, and why Kapfenberg runs a different one from the outset, is in Bandwidth was never the interesting number.

The classification allows a third answer

The measurement is classified like this:

Download	Mode
50 Mbit/s and above	fast
10 Mbit/s and below	throttled
in between	in between

The middle range is deliberately its own answer rather than a forced classification. The split is made on download, because on upload 20 and 10 are too close together.

That is the same principle as the cool-down model in the same flat: a tool is allowed to say it cannot decide the case.

Every measurement carries its weather

Because the link runs over radio, the weather is the first question whenever something looks odd — and that is a question better not asked retrospectively. Since August every speed measurement has carried its weather with it.

What came out of that is more pleasant than expected. In twenty-one hours there were exactly two interruptions, both explained. One of them was a thunderstorm:

Local time	Rain per 5 min	Gust
18:30	0.4 mm	27 km/h
18:35	1.4 mm	—
18:40	2.6 mm ≙ 31 mm/h	59 km/h
18:45	1.6 mm	30 km/h

Six millimetres in twenty minutes, humidity at 99.9 %. The outage came two minutes after the first drops and lasted 34 seconds.

For a radio link under a cell like that, this is a good result. The peak of 31 mm/h eight minutes later the link survived without interruption.

And the honest limit: these data do not say which mechanism was at work. Rain attenuation on the path, the gust front at the roof, or lightning induction are all possible.

Model weather is no use here

I had first cross-checked against a weather model and concluded there had been no thunderstorm at all.

Wrong. Every model queried reported 0.0 mm for the whole afternoon — including the finest one at 2.2 km resolution. A thunderstorm cell in an alpine valley falls straight through that grid.

For weather questions at this location only the official station network counts. And specifically its time series archive with five-minute values, not the live query, which returns only the latest state on a ten-minute grid.

When it really has to be proven

For ongoing observation an ordinary speed test is enough — a factor of 25 between two modes needs no precision instrument.

If something has to be proven to an Italian provider, the right tool is a different one: the regulator’s official measurement procedure. Its certificate carries evidentiary weight, and values below the contractual guarantee justify a complaint or termination without penalty.

The price is effort: a computer cabled to the connection for three days, ideally with no other traffic. Evaluate the observation first, then run the official procedure — with a clear expectation of what the certificate should show.

Austria has the equivalent, and I brought its measuring client into the house: The regulator’s client, self-built .

What both cases teach

One source is not proof. In Merano one source would have evidenced throttling that did not exist. Only comparing three sources showed the truth.

Asking a device about itself is the weakest form of measurement. The router reported “WAN down” twenty-four times out of twenty-four, while in the same second an independent measurement showed the line up. Where possible: measure independently, do not ask.

Check the timezone before attributing a cause. In Kapfenberg the entire attribution hung on a two-hour offset. A wrong attribution is worse than none — it ends the search.

The shape of the curve says more than its value. Flat and down by the same factor in both directions means an imposed limit. Fluctuating means radio, weather or load. You see that in a day’s trace, not in a single measurement.

So what?

Both lines work better today than before, and in neither case did a provider repair anything.

In Kapfenberg a daily restart shortened a five-day throttling episode to six hours. In Merano removing a bad measuring tool prevented a complaint that would have been embarrassing.

To me that is the real use of home automation at this point: not making the line faster, but finally being able to say what is actually going on.