Skip to content

Usb throttling#1526

Merged
kareltucek merged 8 commits intomasterfrom
usb_throttling
Apr 28, 2026
Merged

Usb throttling#1526
kareltucek merged 8 commits intomasterfrom
usb_throttling

Conversation

@kareltucek
Copy link
Copy Markdown
Collaborator

@kareltucek kareltucek commented Apr 17, 2026

Changelog:

  • Lower bluetooth latency.

@kareltucek
Instrument BLE HID report dispatch→sent latency.
9b30455 
Add an EMA (alpha=1/8) of the measured delay between handing a BLE HID
report to the stack and the corresponding sent callback firing, exposed
as HidReportBleLatencyAvgMs. Useful for observing whether the send
pipeline is saturated - e.g. before/after applying report throttling,
the averaged latency should drop from queue-depth-scaled values to
roughly one BLE connection interval.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

debuh
@kareltucek
Throttle report construction on slow transports.
c13f3fe 
Add a UsbReportWindowEstimate global that tracks when the next transport
window is expected to be available. The transport layer bumps it forward
to "now + 2 * interval" when a report is dispatched and reduces it to
"now + interval" from the send-completion callback, approximating when
the next window will open. Per-transport intervals are 1 ms (USB),
11 ms (BLE HID), and 7 ms (dongle). blockedByKeystrokeDelay() now also
postpones report construction whenever the next window is more than 4 ms
in the future, so further keystroke state can accumulate before the next
slow-transport-bound report is built.
@kareltucek
Wire the report throttle to actual ble hid interval
b806e8c 
Debuh fixes.
@kareltucek
Throttling: make it work for dongle too.
f79242d
@kareltucek
Throttling: refactor testing code away.
b45c390
@kareltucek
Copy link
Copy Markdown
Collaborator Author

kareltucek commented Apr 21, 2026 •
edited
Loading

Rough estimate:

Expected latency before:

  • sensor scanning: 10ms, 5ms average
  • i2c: up to some 6ms, 3ms average, actually lower on uhk80 since only two or so drivers are in the loop.
  • general processing by the firmware 1ms. Twice for dongle.
  • on average half of a window before getting processed
  • bluetooth in general - waiting in the queue for two ble windows
  • Resulting into:
    • hogp: 2*11+0.5*11+5+3+1 = 36.5ms
    • dongle: 2*7+0.5*7+5+3+2 = 27.5ms

Expected latency after:

  • sensor scanning, i2c: still the same, general processing: still the same
  • on average half of a window before getting processed
  • 6ms for ble stack processing instead of the two ble windows
  • Resulting into:
    • hogp: 6+0.5*11+5+3+1 = 20.5ms
    • dongle: 6+0.5*7+5+3+2 = 19.5ms

Lower bound limits:

  • sensor scanning: 5ms average
  • half of a transport window: 3.5 ms average
  • bluetooth internal processing? Can this be sped up?: 6ms
  • something between 8.5 and 14.5 seems to be the lowest achievable latency

Possible further improvements:

  • synchronize i2c polling

@kareltucek kareltucek force-pushed the master branch 2 times, most recently from 13aa0b5 to 2cf15c3 Compare April 28, 2026 10:00
@kareltucek kareltucek merged commit 6d16ae9 into master Apr 28, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

cla:signed

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@kareltucek