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.
This commit is contained in:
umbra audio
93
docs/node-238-capability-profile.md
Normal file
93
docs/node-238-capability-profile.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user