diff --git a/performance/reports/report-amt-power-telemetry/page.md b/performance/reports/report-amt-power-telemetry/page.md new file mode 100644 index 0000000..ca84be1 --- /dev/null +++ b/performance/reports/report-amt-power-telemetry/page.md @@ -0,0 +1,90 @@ +--- +title: report-amt-power-telemetry +visibility: private +--- + +# πŸ”Œ Report: Intel AMT / vPro per-system power-telemetry feasibility (tsys1,3,4,5,9 + 6,7) + +Status: PROPOSAL (v1, 2026-09-06). Ticket: #826. Hardware verified live via +dmidecode 2026-09-06 (tsys9 not yet reachable β€” identification step included). + +## Executive answers + +**Does AMT provide power usage data? Can it be pulled from the BIOS?** +**No β€” no Intel AMT version (9.x through current) exposes real-time watt +telemetry, via BIOS or any API.** Intel's own forum answer is categorical: +AMT provides power *control* (on/off/cycle/boot-once), not power +*measurement*. The Redfish `Power`/`PowerConsumedWatts` resource is a +server-BMC feature (iDRAC/iLO wired to PSU metering hardware), not an AMT +feature. So AMT is worth enabling only for remote KVM/power-control, never +for watts. + +## Per-system table (hardware verified by dmidecode 2026-09-06) + +| System | Platform (verified) | AMT/vPro? | Watts via mgmt? | Best watt source | +|---|---|---|---|---| +| pfv-tsys1 | OptiPlex 9020, i7-4770 (Haswell), Q87 | YES β€” AMT 9.1 (Dell spec confirms vPro/iAMT 9.x) | NO | Linux RAPL: PKG + DRAM | +| pfv-tsys3 | Precision 7510 (mobile WS), Xeon E3-1535M v5 (Skylake-H), CM236 | YES β€” AMT 11.x (patch post-CVE-2017-5689!) | NO | Linux RAPL: PKG (DRAM domain often absent on mobile SKL β€” verify) | +| pfv-tsys4 | Precision T1700, Xeon E3-1246 v3 (Haswell), C226 | **NO AMT** β€” CPU is vPro-capable but C226 has no AMT ME stack (Haswell vPro needs Q87); no BMC either | NO | Linux RAPL: PKG + DRAM | +| pfv-tsys5 | Precision T7500, Xeon E5620 (Westmere), 5520 chipset | NO β€” server-class chipset, pre-vPro era; no BMC | NO | **Nothing software-readable: Westmere has NO RAPL** (Sandy Bridge introduced it). Metered PDU / smart plug only | +| pfv-tsys6 | PowerEdge R610, 2x E5530, iDRAC6 | NO AMT (servers = BMC) | **YES via iDRAC6** | `racadm getconfig -g cfgServerPower -o cfgServerActualPowerConsumption`; ipmitool sensor "System Level" (watts often x10). DCMI partial/absent on old firmware | +| pfv-tsys7 | PowerEdge R620, 2x E5-2630 v2 (Ivy Bridge-EP), iDRAC7 | NO AMT (BMC) | **YES via iDRAC7** (full DCMI) | `ipmitool dcmi power reading`; `racadm getsysinfo -c`; plus host-side RAPL PKG+DRAM | +| tsys9 | unknown (2013-17 OptiPlex/Precision) | Identify first: `dmidecode -t system` + `lspci \| grep -i MEI` + MEBx (Ctrl+P) | if AMT: still NO watts | RAPL if Haswell or newer | + +## Practical pull methods + +- **AMT 9.x/10.x/11.x (tsys1, tsys3):** WSMAN/SOAP via `wsman` CLI or + MeshCommander (port 16993 TLS) β€” power state, on/off, KVM, inventory. AMT + 11.6+ also speaks Redfish at `https://:16992/redfish/v1/` but with no + Power telemetry resource. +- **Local MEI/HECI discovery:** `/dev/mei0`, `intelmetool` β€” tells you whether + AMT firmware is present/provisioned (use this for tsys9 triage). +- **RAPL readers:** `turbostat` (most complete; PKG/cores/DRAM), powercap + sysfs `/sys/class/powercap/intel-rapl:*` (poll `energy_uj`, delta/t = W), + `perf stat -e power/energy-pkg/`. node_exporter has NO built-in RAPL + collector β€” deploy a small rapl exporter or scrape turbostat. Caveat: RAPL + measures CPU package (+DRAM), not whole-wall draw (~60-75% of wall on + desktops). + +## RAPL coverage by CPU generation + +- RAPL introduced Sandy Bridge (2011); **Westmere (E5620) and Nehalem (E5530) + have none β€” tsys5 and tsys6 hosts cannot RAPL.** +- Haswell adds DRAM domain: tsys1 (i7-4770) and tsys4 (E3-1246 v3) get + PKG+PP0+DRAM. +- Skylake-H (tsys3): PKG yes, DRAM typically absent on mobile. +- Ivy Bridge-EP (tsys7): PKG+DRAM. + +## Recommendations + +1. Don't chase watts via AMT anywhere β€” the capability does not exist. Use + AMT (tsys1, tsys3) only for remote KVM/power control; patch tsys3's AMT 11 + firmware for CVE-2017-5689 before enabling. +2. Uniform host-side telemetry = RAPL exporter on tsys1, tsys3, tsys4, tsys7. +3. Servers (tsys6, tsys7): pull BMC watts out-of-band (racadm/ipmitool DCMI); + update iDRAC6 firmware on tsys6 if DCMI commands fail. +4. tsys5 (T7500): budget a metered PDU or smart plug β€” no software path + exists (fits the planned UPS re-cabling: put tsys5 on the metered leg). +5. tsys9 RESOLVED (2026-09-06): OptiPlex 7080, i5-10500, live PVE 9.2.5 node + (100.101.158.76 β€” runs pfv-netinfra-02 + k8s wnode-tsys9); RAPL present β€” + include it in the RAPL exporter wave. +6. UPS plan alignment: since only tsys6/7 (BMC) + RAPL hosts give per-node + watts, keep the metered UPS leg feeding the gear you most need wall-watts + for; per-node software telemetry covers the rest. + +## Sources + +- Intel Community β€” AMT and power usage monitoring: https://community.intel.com/t5/Intel-Business-Client-Software/AMT-and-power-usage-monitoring/td-p/853085 +- Intel Community β€” AMT Support Identification: https://community.intel.com/t5/Intel-vPro-Platform/Intel-AMT-Support-Identification/td-p/1275668 +- DMTF Redfish Telemetry DSP2051: https://www.dmtf.org/sites/default/files/standards/documents/DSP2051_1.1.0.pdf +- OptiPlex 9020 spec (AMT 9.x): https://www.dell.com/support/manuals/en-us/optiplex-9020-desktop/opt9020sffom-v2/specifications +- Precision 7510 spec sheet: https://i.dell.com/sites/csdocuments/Shared-Content_data-Sheets_Documents/en/us/Dell-Precision-15-7000-Series-7510-Spec-Sheet.pdf +- ARK E3-1246 v3: https://www.intel.com/content/www/us/en/products/sku/80916/intel-xeon-processor-e31246-v3-8m-cache-3-50-ghz/specifications.html +- ServerFault Dell power CLI: https://serverfault.com/questions/736068/how-do-i-get-the-power-consumption-of-a-dell-poweredge-server-on-the-cli +- jonamiki racadm power capping: https://jonamiki.com/2014/10/18/power-control-and-capping-on-dell-servers-using-racadm/ +- Dell InfoHub power reporting: https://infohub.delltechnologies.com/en-us/p/server-power-consumption-reporting-and-management/ +- Launchpad RAPL domains: https://bugs.launchpad.net/bugs/1467014 +- Hackenberg et al. Haswell RAPL survey: https://tu-dresden.de/zih/forschung/ressourcen/dateien/projekte/firestarter/2015_hackenberg_hppac.pdf +- kernel mei/iamt docs: https://docs.kernel.org/driver-api/mei/iamt.html + +> **Docs live on Discourse β€” this repo is the executable source of truth.** Perf topic: https://community.turnsys.com/t/328 diff --git a/performance/reports/report-moonlight-desktop/page.md b/performance/reports/report-moonlight-desktop/page.md new file mode 100644 index 0000000..976e7a6 --- /dev/null +++ b/performance/reports/report-moonlight-desktop/page.md @@ -0,0 +1,73 @@ +--- +title: report-moonlight-desktop +visibility: private +--- + +# πŸ–ΌοΈ Report: replacing the KDE/xrdp VM with a containerized desktop served from k8s + +Status: PROPOSAL (v1, 2026-09-06) β€” awaits founder ruling. Ticket: #826. +Source research: web-surveyed 2026-09-06 (sources linked at the end). + +## Context constraints (verified) + +- Xeon E5-2630 v2 (pfv-tsys7 class) has **no iGPU / no Quick Sync** β€” hardware + video encode is impossible on the current CPU-only nodes. Software x264 (or a + future NVIDIA node's NVENC) is the only path. +- Current access path is xrdp/KDE over Tailscale at ~36 ms RTT. Protocol choice + matters less than encoder cost and whether the Tailscale path is direct vs + DERP-relayed (DERP caps ~5 Mbps and adds latency β€” check `tailscale netcheck` + before blaming the desktop stack). +- The cluster is CPU-only today, mixed with production workloads, flux gitops β€” + heavy sustained CPU encoding on shared nodes is an operational risk. + +## Comparison + +| | Sunshine+Moonlight | Selkies-GStreamer | Kasm Workspaces | Webtop / Guacamole | Tuned xrdp (baseline) | +|---|---|---|---|---|---| +| Transport | Moonlight protocol, H.264/265/AV1 | WebRTC (browser) | KasmVNC over WebSocket | VNC/RDP β†’ WebSocket | RDP | +| GPU needed | No (x264 soft mode) but costly | No (x264 soft) | No | No | No | +| CPU cost on old Xeon | HIGH: 2–4 cores sustained @1080p60 | HIGH + WebRTC stack ~1 core | MODERATE (framebuffer diff, no video encode) | LOW–MODERATE (Guacamole ~15–27%/core per 1–2 users) | LOW | +| Latency @36 ms RTT | Best-in-class on direct path; 100–200 ms if misconfigured | Low | Moderate; fine for desktop, visible on video | Moderate–high (protocol translation + browser) | Moderate (tuned RDP is decent) | +| Client | Native Moonlight apps (excellent) β€” NOT browser | Any browser | Any browser | Any browser | Any RDP client | +| k8s fit | Awkward: privileged pod + `/dev/uinput` hostDevice, dummy X | Good (purpose-built for k8s) | Heavy control plane for one desktop | Trivial pod + PVC (webtop); Guacamole = small extra stack | Stays a VM | +| Persistence | StatefulSet + PVC | PVC | Disposable by design | webtop PVC-backed | Full VM (best) | +| GitOps friendliness | Medium | High | Medium | High | N/A | + +## Recommendation + +1. **Now:** keep the tuned xrdp/KDE VM as baseline; do NOT put Sunshine/Moonlight + on CPU-only nodes β€” real-time x264 eats 2–4 cores next to production tenants. +2. **Migration path:** deploy **linuxserver/webtop (KasmVNC variant)** as a + PVC-backed StatefulSet on a CPU-only node behind the existing ingress + (browser access; WAN via Tailscale). This is the containerized successor for + desktop-class use at 36 ms RTT: cheapest CPU, unprivileged pod, clean + flux fit. +3. **WAN/browser fallback for the existing RDP VM:** small Apache Guacamole + stack (guacd + guacamole), accepting it is slower than native RDP clients. +4. **When the NVIDIA node lands:** revisit **Selkies-GStreamer** (most + k8s-native low-latency option; NVENC removes the encoder cost) as the + premium tier. **Sunshine+Moonlight** earns its complexity (privileged pod, + /dev/uinput) only if gaming-grade latency on native clients becomes a hard + requirement β€” then pin it to the GPU node only, never shared CPU nodes. + +Rollout: tuned xrdp VM stays during migration β†’ webtop StatefulSet UAT β†’ +retire VM after human UAT β†’ Selkies on the future GPU node. + +## Sources + +- Intel Xeon Quick Sync support: https://www.intel.com/content/www/us/en/support/articles/000034104/processors/intel-xeon-processors.html +- Sunshine advanced usage (encoder cost): https://docs.lizardbyte.dev/projects/sunshine/v0.23.0/about/advanced_usage.html +- Moonlight setup guide: https://github.com/moonlight-stream/moonlight-docs/wiki/Setup-Guide +- Tailscale DERP 5 Mbps gotcha: https://cfreeman.cloud/breaking-the-5-mbps-barrier-streaming-moonlight-over-tailscale-with-full-bandwidth/ +- LizardByte latency discussion: https://github.com/orgs/LizardByte/discussions/17 +- LXC headless Sunshine/uinput: https://discuss.linuxcontainers.org/t/headless-wayland-container-streaming-via-sunshine-sway-libinput-not-finding-uinput-devices/18852 +- steam-headless uinput issue: https://github.com/Steam-Headless/docker-steam-headless/issues/191 +- Selkies-GStreamer: https://github.com/selkies-project/selkies +- Kasm desktop images: https://hub.docker.com/r/kasmweb/desktop +- linuxserver/docker-webtop: https://github.com/linuxserver/docker-webtop +- LSIO docker-kasm: https://docs.linuxserver.io/images/docker-kasm/ +- Guacamole web-client slowness: https://stackoverflow.com/questions/77224933/apache-guacamole-much-slower-on-the-web-client-than-microsoft-desktop +- guacd CPU benchmarks: https://lists.apache.org/thread/zdlsnn2br4gvtx09q6zqtxym6dwlrjwc +- Cendio on browser remote desktop limits: https://www.cendio.com/blog/apache-guacamole-alternatives/ + +> **Docs live on Discourse β€” this repo is the executable source of truth.** Perf topic: https://community.turnsys.com/t/328