[Michael Friesen (mtfriesen)]

Summary

Portable public-source TCP churn workload with separate Windows, Netperf fixture and lab-guest adapters.

Actual netperf-machine execution: verified

https://github.com/microsoft/netperf/actions/runs/40371149553

• Successful management job on RR1-Netperf-25 using the documented parent=rr1-netperf-26\localadminuser label.
• The workload ran INSIDE the existing netperf-windows-2022-client VM via PowerShell Direct, not on the management host or a GitHub-hosted runner.
• Uses configured VM credentials without logging/publishing them; refuses an active Actions worker/CTS in the guest. No host networking or runner registration is changed.
• The thin wrapper uses Windows PowerShell 5.1, matching the actual management host. The public workload executes under PowerShell 7 inside the VM.
• 512 completed connections, 33,554,432 payload bytes, 33,754,112-byte TX and RX adapter deltas.
• Owned fixture/process/firewall/device cleanup succeeded. Downloaded artifact contains ONLY numeric result.json.
• CTS interval was 85 ms. This is deployment and data-path proof, NOT sustained performance, 80-CPU coverage or an optimization win.

The proven workload revision is 26c2f5f; subsequent documentation records this evidence.

Scheduling diagnosis and alternatives

Today's successful eBPF jobs used exactly [self-hosted,lab,os-windows-2022,x64], matching the initial dispatch. Other lab workloads were also queued, so labels were not assumed to be wrong.

The existing targeted reset procedure completed successfully for the documented Windows client slot, respecting its active-job safety gate. Neither the original labels nor an explicit image-independent Windows-lab target obtained a guest-runner assignment. The documented management runner did execute, enabling the successful guest adapter without modifying registration.

Obsolete unassigned smoke jobs were cancelled after hardware success. Normal guest-runner scheduling, hosted-smoke compatibility and management-to-guest execution remain explicitly separate targets.

Public/private and artifact contract

No private OS implementation/helper/internal feature identifier or unpublished binary is included. No new executable is introduced. CTS and Microsoft-signed DuoNIC are existing public assets, pinned by public commit and SHA256.

Native tools remain local to the execution guest. Only numeric allowlisted JSON is uploaded: no binaries, raw logs, traces, host inventory, credentials or adapter state. Workflow and publication scope are reviewed accordingly.

Portability

The core module owns plans, public CTS summary parsing, lifecycle and progress invariants. Five callbacks supply peer start/readiness, counters, client run and cleanup.

Windows execution owns processes/NIC observation. Netperf fixture provisioning and the management-to-guest transport are separate adapters. Manual/internal runners can use the same core without GitHub provisioning or publication.

Validation and remaining limits

45 public-source checks pass locally and in hosted CI; actual netperf guest provisioning/traffic/cleanup has now also passed. Workflow syntax and source-only publication checks pass.

Finite iterations cap the smoke at a port-budgeted connection count plus a deadline; no hidden port-reuse tuning. The result remains collection-only, cpuCoverage/targetBranchCoverage are not measured, and mechanismVerified=false. Selective PMTU faults, routed DGD, whole-system CPU/lock-site evidence and sustained comparative campaigns remain future work.

[Michael Friesen (mtfriesen)]

Deployment verified on the real public DuoNIC fixture: https://github.com/microsoft/netperf/actions/runs/40013903384 . All 45 source checks, traffic, and owned-resource cleanup passed. The only published artifact contains allowlisted result.json: 512 completed connections, 33554432 payload bytes, matching adapter TX/RX deltas of 33754112 bytes. The finite-iteration traffic interval was 74 ms; this is a compatibility smoke, not a sustained performance claim. Hardware-lab retry https://github.com/microsoft/netperf/actions/runs/40339654787 remains queued after successful source checks. No new binaries were committed or uploaded.

[Michael Friesen (mtfriesen)]

Verified execution on the actual netperf hardware: https://github.com/microsoft/netperf/actions/runs/40371149553 . The job ran on RR1-Netperf-25 and used PowerShell Direct to execute inside its existing netperf-windows-2022-client VM. Both source checks and guest smoke succeeded. Numeric artifact: 512 connections, 33554432 payload bytes, matching 33754112-byte adapter TX/RX deltas; cleanup succeeded. This is not the hosted fallback. The working configuration uses the documented management-runner label and Windows PowerShell on the host, with pwsh inside the guest. No runner-registration or host networking change, and no binary artifacts uploaded. The 85-ms finite smoke is not a sustained performance result.