Wanjohi 283e882ce3 feat(nesdoctor): a host readiness checker that measures instead of asking ...

The first executable form of our host requirements. Until now a machine was
qualified by a human reading a table of hard requirements, and a requirement
nothing can check is one that is silently optional.

It also replaces a form. Every field we wanted from a prospective host --
upstream, latency under load, spare disk, hours powered, library size, play
hours -- is measurable, and most of them cannot be answered honestly by a
human anyway: almost nobody knows their real upstream and essentially nobody
has seen their own bufferbloat figure. What is left for the questions is only
what a machine cannot know: intent, and what someone already pays.

What it does
  - Checks every hard requirement: /dev/kvm, an AMD or Intel GPU with a DRM
    render node, VK_KHR_video_encode_queue plus a codec, virglrenderer, the
    two stores, the io cgroup controller, virtiofsd. Pass/fail/unknown, and
    unknown is never collapsed into fail -- a machine we could not ask is not
    a machine that failed.
  - Measures upstream and, the point of the whole thing, added latency under
    load. Grade bands come from the frame budget rather than convention: the
    network allowance is ~40 ms because render, encode, decode, display and
    jitter buffer have already spent ~58 ms.
  - Reads Steam, only with an explicit yes, for library size and shape and an
    hour-of-day histogram of launches -- one sample per title, which is a real
    distribution obtained without asking.
  - Asks at most five questions, branched, all skippable.

No server
  Nothing is uploaded and no telemetry endpoint exists. The network test talks
  to Cloudflare's public sink and to 1.1.1.1, neither of which is ours. Output
  is a line on the terminal that the person may choose to paste. The line
  carries no hostname, IP, username, game title or path -- a size band rather
  than a size, hours rather than dates. The long version stays in a local
  JSON file.

Three bugs found by running it, all of which would have produced wrong data
  - vulkaninfo --summary lists ZERO VK_KHR_video entries where full vulkaninfo
    lists five on the same machine. Preferring the summary reported "not
    advertised" on a card that advertises it -- a false negative on the check
    most likely to disqualify a host.
  - btrfs subvolumes were counted as separate disks: /, /home and /srv each
    reported 91 GiB of one 91 GiB device. Deduped by backing device, which the
    two-stores check needs anyway since it wants separate devices.
  - Proton and the Steam Linux Runtimes are installed like games and are not
    games. Five of eight entries on the test machine, so the title count was
    5x too high and the library-shape question was corrupted.

And one finding about the development connection, now encoded as a verdict:
178 ms idle RTT, served from Johannesburg. That machine passes every other
check and cannot host for a European player, because it is distance and no
upgrade shortens it. HOST-READY-LOCAL exists for exactly that case -- and it
is the coverage argument from the other end: somewhere with no nearby edge is
somewhere a local host is the only option anyone has.

Dependencies are four, three of them serde/clap/anyhow. The VDF parser, every
platform probe and the text wrapping are in-tree: a binary handed to strangers
has a dependency tree that is part of its interface.

2026-09-02 00:09:00 +03:00

831 B

Raw Blame History

View Raw