Fixed indentation issue on diagram in README.md#4
Closed
WebSurfer108 wants to merge 1 commit into
Closed
Conversation
codal-tshah
approved these changes
Dec 29, 2025
This was referenced May 12, 2026
ruvnet
added a commit
that referenced
this pull request
May 12, 2026
…set loader test (#537) Closes the remaining doable items from the 2026-05-11 training-pipeline audit: #6 (CSI format default = 56-sc / 1 NIC) + #7 (multi-band 168-sc mesh not in config): new `TrainingConfig::for_subcarriers(native, target)` plus named presets `mmfi()` (114→56), `ht40_192()` (≈192-sc ESP32 HT40 → 56) and `multiband_168()` (168-sc ADR-078 multi-band mesh → 56). Non-MM-Fi CSI shapes are now first-class instead of requiring manual `native_subcarriers` / `num_subcarriers` overrides; the field docs list the supported source counts and the multi-NIC mapping (a 2–3-node mesh currently rides on `n_rx` until a dedicated node dimension lands). Model input width stays `num_subcarriers`; the presets only vary the resampling input. #4 (proof.rs uses synthetic data): reframed — a deterministic proof *must* use a reproducible source, so `verify-training` correctly stays on `SyntheticCsiDataset`. The real gap was that nothing exercised the on-disk `MmFiDataset` path. New `tests/test_real_loader.rs` writes synthetic CSI to `.npy` files in the `MmFiDataset::discover` layout, loads it back, and checks the resulting `CsiSample` — covering the no-interp case, the subcarrier-interpolation branch, and the empty-root case. Adds `ndarray` / `ndarray-npy` as dev-deps for the fixture writing. cargo check + cargo test -p wifi-densepose-train --no-default-features: clean, all existing tests green, 3 new loader tests + the updated config doctest pass. Purely additive — no model-shape change, no tch-module change.
ruvnet
added a commit
that referenced
this pull request
May 12, 2026
Publishing the additive changes from PRs #536/#537 to crates.io: - `signal_features` module — wires `wifi-densepose-signal` into the pipeline (audit #1/#2) - `TrainingConfig::for_subcarriers` / `ht40_192()` / `multiband_168()` presets + the real `MmFiDataset` loader integration test (audit #4/#6/#7) No public API removals or changes — additive only, so 0.3.0 -> 0.3.1 is semver-correct. No other workspace crate depends on `wifi-densepose-train`, so this is a standalone bump. Co-Authored-By: claude-flow <ruv@ruv.net>
This was referenced May 23, 2026
Closed
ruvnet
added a commit
that referenced
this pull request
Jun 13, 2026
…57 §5 #4) ADR-157 §5 #4 recorded the native wlanapi.dll multi-BSSID fast path as "asserted but NOT implemented; live scanner is the ~2 Hz netsh shim". Audit finding: that status is stale — wlanapi_native::scan_native already implements the real WlanOpenHandle → WlanEnumInterfaces → WlanGetNetworkBssList → WlanFreeMemory/WlanCloseHandle FFI (handle cleanup on all exits, length-bounded buffer walks, #[cfg(windows)] with typed Unsupported off-Windows), and WlanApiScanner::scan_instrumented already wires it native-first with a netsh fallback. The missing piece was an honest MEASUREMENT. Add benchmark_backend(backend, window): drives one specific backend over a fixed wall-clock window so netsh is timed independently (the existing benchmark() picks native-first and so never measures netsh on a box where native works). Returns None for an unavailable native path (honest negative, not a fabricated number). MEASURED on this box (Intel Wi-Fi 7 BE201 320MHz, 2026-06-13), 10 s window: native 21.42 Hz vs netsh 3.84 Hz = 5.57× (mean 5.0 BSSIDs/scan each). native-only run: 18.0 Hz. 50/50 back-to-back native scans, no handle leak. A real positive result — NOT a fabricated 10×. Achieved 21.4 Hz is in the asserted >2 Hz regime, below the asserted 10–20 Hz upper bound. Tests (live-WLAN, #[ignore] for CI, RUN here): measure_native_vs_netsh_throughput, native_scans_dont_leak_handles, measure_native_scan_rate. Non-ignored pin native_scan_runs_real_ffi_on_windows (pre-existing) stays green. wifi-densepose-wifiscan: 94 passed / 0 failed. ADR-157 §5 #4 + §8 → MEASURED (was ACCEPTED-FUTURE / CLAIMED-unmeasured). Co-Authored-By: claude-flow <ruv@ruv.net>
ruvnet
added a commit
that referenced
this pull request
Jun 13, 2026
… 5.57x native wlanapi scan (#1054) * fix(hardware): constant-time HMAC sync-beacon tag compare (ADR-157 §B4) AuthenticatedBeacon::verify compared the 8-byte HMAC-SHA256 tag with `self.hmac_tag == expected`, which short-circuits on the first differing byte and leaks, via verification latency, how many leading bytes a forged tag matched — a byte-by-byte tag-recovery oracle (~256·N trials vs 256^N). Replace with a hand-rolled branch-free `constant_time_tag_eq`: XOR-accumulate every byte difference into a single u8 with no early exit, compare to zero once. `#[inline(never)]` + `core::hint::black_box(diff)` resist the optimizer reintroducing a short-circuit or a non-constant-time memcmp; length mismatch returns false without inspecting contents. No new dependency — ADR-157 had deferred this only to avoid the `subtle` crate; a fixed 8-byte compare needs none. Test (hard gate): tag_compare_is_constant_time_shape — equal / first-differ / last-differ / all-differ / length-mismatch + end-to-end verify() last-byte tamper. Proven to fail on a last-byte-skipping constant-time bug. A coarse timing smoke check (tag_compare_timing_invariance_smoke) is #[ignore]d to avoid CI flakiness. Grade MEASURED (constant-time construction). ADR-157 §8 §B4 → RESOLVED. wifi-densepose-hardware: 164 passed / 0 failed. Co-Authored-By: claude-flow <ruv@ruv.net> * feat(wifiscan): MEASURE native wlanapi.dll vs netsh throughput (ADR-157 §5 #4) ADR-157 §5 #4 recorded the native wlanapi.dll multi-BSSID fast path as "asserted but NOT implemented; live scanner is the ~2 Hz netsh shim". Audit finding: that status is stale — wlanapi_native::scan_native already implements the real WlanOpenHandle → WlanEnumInterfaces → WlanGetNetworkBssList → WlanFreeMemory/WlanCloseHandle FFI (handle cleanup on all exits, length-bounded buffer walks, #[cfg(windows)] with typed Unsupported off-Windows), and WlanApiScanner::scan_instrumented already wires it native-first with a netsh fallback. The missing piece was an honest MEASUREMENT. Add benchmark_backend(backend, window): drives one specific backend over a fixed wall-clock window so netsh is timed independently (the existing benchmark() picks native-first and so never measures netsh on a box where native works). Returns None for an unavailable native path (honest negative, not a fabricated number). MEASURED on this box (Intel Wi-Fi 7 BE201 320MHz, 2026-06-13), 10 s window: native 21.42 Hz vs netsh 3.84 Hz = 5.57× (mean 5.0 BSSIDs/scan each). native-only run: 18.0 Hz. 50/50 back-to-back native scans, no handle leak. A real positive result — NOT a fabricated 10×. Achieved 21.4 Hz is in the asserted >2 Hz regime, below the asserted 10–20 Hz upper bound. Tests (live-WLAN, #[ignore] for CI, RUN here): measure_native_vs_netsh_throughput, native_scans_dont_leak_handles, measure_native_scan_rate. Non-ignored pin native_scan_runs_real_ffi_on_windows (pre-existing) stays green. wifi-densepose-wifiscan: 94 passed / 0 failed. ADR-157 §5 #4 + §8 → MEASURED (was ACCEPTED-FUTURE / CLAIMED-unmeasured). Co-Authored-By: claude-flow <ruv@ruv.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I don't know whats up with the last line. I didn't touch it.