283e882ce3
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.
3.4 KiB
nesdoctor
Is this machine any good — as a Nestri host, or as a client?
nesdoctor
Checks every hard requirement for running a Nestri box, measures what your connection actually does when it is busy, and asks at most five questions.
Nothing is uploaded
There is no server. No telemetry endpoint exists, and there is no build of this
program that reports home — the network test talks to Cloudflare's public
speed-test sink and to 1.1.1.1, neither of which is ours.
The output is a line on your terminal. If you want us to have it, you paste it somewhere. If you do not, we never had it. That is a property of the design rather than a promise about our intentions: there is nothing to switch on later.
The shareable line carries no hostname, no IP, no username, no game titles and
no file paths — a size band rather than a size, and an hour histogram rather
than timestamps. The long version does include titles and paths, and it stays in
nesdoctor.json on your disk.
Reading your Steam library needs an explicit yes, and the question is asked last, after you have seen what this program does.
The number worth running it for
Everybody knows their download speed. Almost nobody has seen how much latency their connection adds when it is busy, and for anything interactive that is the figure that decides it:
upstream 28 Mbps
latency, idle 179 ms
latency, loaded 198 ms
added under load +19 ms grade B
A 500 Mbps uplink that queues for 300 ms under load cannot carry a game. A
25 Mbps one with fq_codel or CAKE can. If your grade is C or F it is almost
always a router setting rather than a line you need to upgrade.
Options
--no-net |
Skip the network test (it uploads ~100 MB) |
--no-steam |
Never look at Steam, and do not ask |
--yes |
Take the defaults — for a second run, not a first |
--json <PATH> |
Where to write the full report |
--quiet |
Only the summary line, for scripting |
Verdicts
HOST-READY |
Passes everything, and close enough to the network to serve others |
HOST-READY-LOCAL |
Passes everything, but far enough out that it can only serve players nearby |
HOST-NET |
Good machine; the connection is in the way |
HOST-FIXABLE |
Nothing is a hardware limit — what is missing can be installed |
CLIENT |
Not a host. A complete answer, and what most machines are |
UNKNOWN |
A blocking check could not be run. An unknown is not a no |
What it deliberately does not tell you
- A pass is not a promise. Every check is a necessary condition. Nothing here runs under load, so a machine that passes can still fail on block I/O.
vulkaninforeporting the encode extension is not proof the path works. We have had a correct extension list over a broken path before.- Whether
libvirglrenderercarries the native-context patches cannot be determined from outside, so that row reports presence only.
Building
cargo build --release -p nesdoctor
Four dependencies, three of them serde/clap/anyhow. Everything that could
be done with std is: the VDF parser, the platform probes and the text wrapping
are all in-tree, because a binary handed to strangers has a dependency tree that
is part of its interface.
A static build, for a release someone downloads rather than compiles:
cargo build --release -p nesdoctor --target x86_64-unknown-linux-musl