ble: instrument the actual MTU settle time (follow-up to #1066) - #1153
Merged
Conversation
#1066 (@TAKEOFF69) fixed the Solana Saga MTU-vs-discovery race by making onMtuChanged telemetry-only and always waiting a FIXED 1.5s (MTU_DISCOVERY_SETTLE_MS) before discovery — there's no provenance bit to end the wait early. That's correct, but it adds ~1.4s to EVERY connect's discovery (the accepted path used to fire on onMtuChanged in ~100ms), which matters for a WHOOP that reconnects often. Log how long the MTU ACTUALLY takes to settle (delta from the requestMtu attempt to onMtuChanged) alongside the fixed wait: 'MTU negotiated: 247 (status=0) — settled 84ms after request (fixed wait 1500ms)'. A capture across devices then shows how much headroom the 1.5s has, so the constant can be tuned DOWN with data instead of a guess (and re-validated on the Saga). Logging only — no sequencing/behaviour change; the timestamp resets per connection. Android-only (no iOS MTU-provenance race).
Re-review: the settle-time log sat AFTER the OnePlus same-value dedup early-return. On the exact Saga case #1066 targets, the connection-event MTU fires first and our requestMtu completes second with the same value — so that second callback was dedup'd and its timing dropped, making the measurement UNDER-report the real settle bound the 1.5s wait must cover (it would show the fast connection-event, not our slower request). Log the dropped callback's '(Nms after request)' too, so a capture shows the full picture the tuning depends on. Still logging-only.
simoncad7
pushed a commit
to simoncad7/noop
that referenced
this pull request
Aug 17, 2026
…ryanbr#1153) * ble: instrument the actual MTU settle time (follow-up to ryanbr#1066) ryanbr#1066 (@TAKEOFF69) fixed the Solana Saga MTU-vs-discovery race by making onMtuChanged telemetry-only and always waiting a FIXED 1.5s (MTU_DISCOVERY_SETTLE_MS) before discovery — there's no provenance bit to end the wait early. That's correct, but it adds ~1.4s to EVERY connect's discovery (the accepted path used to fire on onMtuChanged in ~100ms), which matters for a WHOOP that reconnects often. Log how long the MTU ACTUALLY takes to settle (delta from the requestMtu attempt to onMtuChanged) alongside the fixed wait: 'MTU negotiated: 247 (status=0) — settled 84ms after request (fixed wait 1500ms)'. A capture across devices then shows how much headroom the 1.5s has, so the constant can be tuned DOWN with data instead of a guess (and re-validated on the Saga). Logging only — no sequencing/behaviour change; the timestamp resets per connection. Android-only (no iOS MTU-provenance race). * ble: also log the dedup'd MTU callback's timing (re-review fix) Re-review: the settle-time log sat AFTER the OnePlus same-value dedup early-return. On the exact Saga case ryanbr#1066 targets, the connection-event MTU fires first and our requestMtu completes second with the same value — so that second callback was dedup'd and its timing dropped, making the measurement UNDER-report the real settle bound the 1.5s wait must cover (it would show the fast connection-event, not our slower request). Log the dropped callback's '(Nms after request)' too, so a capture shows the full picture the tuning depends on. Still logging-only.
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
1 participant
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.
Follow-up to #1066 (@TAKEOFF69's Solana Saga MTU-vs-discovery fix, just merged).
Why
#1066 correctly made
onMtuChangedtelemetry-only and always waits a fixed 1.5s (MTU_DISCOVERY_SETTLE_MS) before service discovery — there's no provenance bit to end the wait early. The trade is that discovery is now ~1.4s slower on every connect (the accepted path used to fire ononMtuChangedin ~100ms; the rejected path fired immediately). For a WHOOP that reconnects frequently, that's real connect-latency + radio-on time.Shortening the 1.5s can't be done safely by guessing — it needs to know how long the MTU actually takes to settle across devices.
What
Log the real settle time (delta from the
requestMtuattempt toonMtuChanged) next to the fixed wait:A detailed capture across devices then reveals the headroom, so
MTU_DISCOVERY_SETTLE_MScan be tuned down with data (and re-validated on the Saga) — turning a hard-coded conservative guess into a measured one.Safety
requestMtu/onMtuChangedprovenance race, so nothing to instrument).compileFullDebugKotlin✓,MtuServiceDiscoverySequencingTeststill green, i18n--ci✓.