From 11f27f5ef9c556cf6a8d5c38e428eb50cbfa1021 Mon Sep 17 00:00:00 2001 From: umbra audio Date: Sat, 3 Oct 2026 08:55:40 -0700 Subject: [PATCH] Capability profile for node 238, measured over SSH Reached 238 via public-key enrolment - no password anywhere. The first attempt failed because the key had never landed in authorized_keys; the second worked once the fingerprint matched. Findings worth keeping beyond this node: The VM reports 'AMD Ryzen 9 3900X' and then lists 65 CPUID flags that stop at SSE4.2. No avx, no avx2, no fma. That silicon has AVX2 and FMA, so VirtualBox is masking them and /proc/cpuinfo is a declaration, not a measurement. Recorded as *unverified* rather than absent, because confirming it needs an actual AVX instruction executed and there is no gcc on the guest - a flag list cannot settle it. This is the defect the compute design already has, one layer down. The agent sets throughput_factor by string-matching a GPU model (40.0 if '4070' in name else 20.0), which is a declared factor wearing a measured one's name. Here the hypervisor makes the same kind of lie. Capability discovery therefore has to probe by executing instructions and treat an unverifiable feature as unavailable. Also: cpu.max is 'max 100000' so the guest is not CPU-capped, memory is 47.0 GiB unballooned, no GPU and no nested virt flags, and umbra has no sudo. Recorded in docs/ node-238-capability-profile.md with how each value was obtained. --- docs/node-238-capability-profile.md | 93 +++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 docs/node-238-capability-profile.md diff --git a/docs/node-238-capability-profile.md b/docs/node-238-capability-profile.md new file mode 100644 index 0000000..77687fb --- /dev/null +++ b/docs/node-238-capability-profile.md @@ -0,0 +1,93 @@ +# Node 238 — capability profile + +Measured 2026-10-03 by connecting over SSH as `umbra`. Every line is an observation, +not an inference from the model name. + +## Identity + +| | | +|---|---| +| host | `bd-VirtualBox` @ `192.168.123.238` | +| os | Linux Mint 22.3 | +| kernel | `6.8.0-142-generic` | +| arch | x86_64 | +| hypervisor | `oracle` (VirtualBox) | +| systemd | 255, cgroup v2 | +| account | `umbra`, **no sudo** | +| python | 3.12.3 at `/usr/bin/python3`, no numpy | +| docker | 29.8.2 installed, daemon active, **socket not usable by `umbra`** | + +Host key, pinned at first connect: +`SHA256:TUYmtC+joG56eJYWb79Hd79SlZqBGyHylDYh1wACY/s` (ED25519) + +Controller key used: `umbratools-node-management@oldbox`, +`SHA256:j94G4sFwCqqeWlrAtSaQONrRHuSGW1bm33THqtoPxfg` + +## The finding that matters: this box lies about its CPU + +`/proc/cpuinfo` reports **`AMD Ryzen 9 3900X 12-Core Processor`** and then lists 65 +CPUID flags that **stop at SSE4.2**. There is no `avx`, no `avx2`, no `fma`, no +`avx512f`. + +A Ryzen 9 3900X has AVX2 and FMA. They are not optional on that silicon. So the +hypervisor is masking them in CPUID, and `/proc/cpuinfo` inside this guest is a +*declaration* rather than a measurement. + +I could not confirm by execution — no `gcc` on the VM, so I could not compile an AVX +instruction and watch it fault. **So AVX is recorded as unverified, not as absent.** + +This is the same failure the compute design already has, one layer down. The agent sets: + +```python +"throughput_factor": 40.0 if "3060" in name or "4060" in name or "4070" in name else 20.0 +``` + +— a *declared* factor wearing a measured one's name, decided by string-matching a GPU +model. Here the hardware makes the same kind of lie, and a scheduler that trusted +`/proc/cpuinfo` would send AVX-tuned work to a machine that may fault on it. + +**Consequence for onboarding:** capability discovery must probe by executing +instructions, and treat an unverifiable feature as unavailable. Declared is not +measured, whichever side of the hypervisor it comes from. + +## Measured + +| property | value | how | +|---|---|---| +| logical CPUs | 12 | `nproc` | +| cores/socket | 12, 1 thread each | `lscpu` | +| cpu.max | `max 100000` → unlimited | `/sys/fs/cgroup/cpu.max` | +| memory total | 47.0 GiB (49,330,516 kB) | `/proc/meminfo` | +| memory in use | ~10.4 GiB at time of check | `free` | +| swap | 1 GiB | `free` | +| disk / | 125 GB total, 75 GB free | `df` | +| disk device | `sda` VBOX HARDDISK | `lsblk` | +| loadavg | 0.51 / 1.14 / 0.88 | `/proc/loadavg` | +| scalar list sum | 8,388,608 items in 0.841s | python loop | +| list-comp doubling | 13.5 M items/s | python list-comp | + +`docker0` and `br-9c6f539459cf` are present, so this guest has nested container +networking; `enp0s3` is the LAN interface. + +## Fit for purpose + +Good for: capability discovery work, benchmarking harness development, testing the +scheduler, testing the agent update path, cross-network tests, developing the ingest +and object-storage paths against a real second node. + +Not good for: GPU work (no `nvidia-smi`, and nested virt flags are 0 so no passthrough), +and anything needing root until sudo is arranged. + +No sudo is a live constraint, not a formality — `poc/poc_node_user.sh setup` and +`update` both require root, and the GPU udev rules require it outright. For this +sandbox, running the agent as `umbra` in user space is the better shape anyway: the +capability and benchmarking work needs no root, and keeping it unprivileged means the +benchmark results are not measured through a privileged lens. + +## Open + +- `umbra` has no sudo. Decide whether to grant it or stay unprivileged. +- Docker is running but its socket is not accessible to `umbra` — needs the + `docker` group, which needs root to add. Not required for the current work. +- AVX/AVX2/FMA status unverified by execution. Installing `gcc` would settle it; that + needs no sudo. \ No newline at end of file