The newest install looked like the culprit

The tool that gets cleared in this piece is called Tailscale. It makes machines that sit far apart behave as if they were in the same room. Install it on the PC at home and the PC at work and the two find each other without opening any router settings or punching holes through a firewall; each machine gets a private address that only the other installed machines can reach. I move files and connect remotely over those addresses. I installed it to carry the same work between home and office.

Days after installing it, the home network started dropping several times a day. Wireless got slow, wired got slow with it, and for about thirty seconds nothing moved at all before it came back. The suspect was obvious — the thing installed a few days earlier. When only one thing is new, the new thing did it.

So before removing it I did one thing. I timed the install and the symptoms separately. With both timed, the order turned out to be backwards.

A file date is not an install date

My first install date was wrong. I read it off the file timestamps in the program folder, and those say when the vendor built it, not when I installed it. The gap was three weeks, and the symptoms lived inside those three weeks. That one fooled me once.

A real install time only holds when three sources agree — the service-registration event, the registry install stamp, and the moment the network adapter first appeared. Only when all three pointed at the same day and hour did I have a baseline.

Never let the subject supply the baseline you judge it by. A file date is a number the subject brought with it.

The symptoms predated the install by 18 to 127 days

With a baseline, comparison became possible. The wired-side error events first appeared 18 days before the install, with zero in the four months before that. A separate exhaustion marker went back 127 days before the install.

The rate settled it. Before: 3.17 events a day. After: 2.15 a day. Down 32 percent. Symptoms got less frequent after the accused arrived.

The tool itself was idle too. Zero external routing configured, its name-interception rule scoped to its own address space only, and across 134 days of connectivity checks the adapter was classified as the internet path not once. The daemon’s cumulative CPU time was zero seconds.

“It’s the newest thing” builds a suspect list; it does not close a case. Until the ordering is measured, it is only a name on the list.

I did not write “nothing happened” where nothing could be measured

The wireless symptoms could not be checked on this machine at all. It has no wireless adapter. The relevant services are stopped and the log holds zero records. Zero here does not mean clean — it means there is no instrument.

The thirty-second drops were the same. This operating system polls connectivity every 15 seconds, treats a result as stale at 30, and declares a verdict at 35. A thirty-second outage ends before the verdict is reached. The low-level packet log was switched off as well. Finding nothing afterwards is the expected result, not a finding.

Using a window where the instrument was off as proof of innocence gives you no record, not an acquittal. So both windows were excluded from the verdict and written down as “not measured.”

The one conclusion that flipped, flipped because of method

Midway I concluded the name servers were broken. The average came back at 590ms, which looked like evidence enough. But that measurement asked for randomly generated addresses that do not exist. Lookups for names that do not exist take a different path than real ones, and that path varies by tens of times between servers.

I measured again with addresses actually in use, with warm-up, rotating the order. Median 5ms — the same as the comparison servers. Only the tail was real, and a tail is a hygiene issue, not a cause.

A wrong method still returns a number. That a number came out is not evidence that the number is right.

Verdict — cleared, cause still unknown

The accused tool is cleared. I did not remove it. And I still do not know the cause. Three suspects remain — the router’s wireless side, the segment beyond the router, and the line itself — and none of them are visible from this PC.

Half of this piece exists to carry that second sentence. Clearing a suspect and finding the cause are different jobs, and finishing one without the other keeps undoing the first. The next time symptoms appear, the newest install gets suspected first again, and whoever looks will redo every measurement from scratch unless the measurements are written down. So the acquittal is recorded as do not propose this again — with the evidence attached.

What I did not do

• I did not find the cause. This is the record of clearing one suspect, not of catching one.
• I opened none of the three remaining suspects. All of them sit outside the PC and need a different observation point.
• I do not know the line’s contracted ceiling. Without it there is no way to say whether the measured throughput is normal or half.
• The wireless segment was never measured. Short of changing machines, this PC will never measure it.