2026-06-03

USB Interrupt Endpoint bInterval and Polling Latency

Debug USB interrupt bInterval and HID polling latency by checking negotiated speed, endpoint encoding, actual cadence, report generation, buffering, hubs, and application delay.

A HID or custom interrupt device can enumerate correctly while input arrives every 8 ms instead of 1 ms, events are coalesced, or an application reacts long after the bus transfer. The endpoint's bInterval is only one layer: its encoding depends on negotiated speed, the host schedules polls, firmware supplies reports, the driver buffers them, and the application consumes them later.

Direct answer: capture enumeration and a timed input sequence. Record device speed, endpoint address, transfer type, bInterval, maximum packet size, and actual interrupt-transfer timestamps. Convert the descriptor value using the rules for that speed, then separate host poll cadence, device response, firmware event generation, and application callback delay.

Bus Scope can connect endpoint descriptors with observed transfer timing and raw reports. It cannot see an event before firmware places it on USB or an application's scheduling after the host stack delivers it, so add device timestamps and application logs when the bus cadence is already correct.

`bInterval` must be decoded in speed context

The same byte does not mean the same interval for every USB speed and endpoint type.

For low-speed and full-speed interrupt endpoints, bInterval is expressed in frame-based milliseconds within the allowed range. For high-speed interrupt endpoints, the interval is encoded as a power of two in 125-microsecond microframe units:

high-speed service interval = 2^(bInterval - 1) microframes

Examples:

Speed	`bInterval`	Nominal service opportunity
Full speed	1	1 ms
Full speed	8	8 ms
High speed	1	125 µs
High speed	4	1 ms
High speed	7	8 ms

Apply the specification rules for the actual endpoint and speed. SuperSpeed endpoint companion information adds more scheduling context and should not be reduced to a USB 2.0 table.

Prove negotiated speed

Do not infer speed from connector shape, product label, or firmware build flag. Record what the host negotiated. A device intended for high speed can fall back to full speed because of:

cable or signal integrity;
hub path;
PHY initialization;
descriptor or controller configuration;
connection through a full-speed-only path.

If speed changes, both interval interpretation and maximum transfer capabilities can change. Compare direct-port and hub captures with speed explicitly listed.

Use the USB descriptor viewer workflow to map the endpoint and its owning interface.

Bus poll cadence and report cadence differ

An interrupt IN endpoint receives scheduled host service opportunities. The device may have no new report at every opportunity. Depending on the controller and capture abstraction, the trace may show completed transfers rather than every low-level not-ready transaction.

Separate:

Measurement	Question
Nominal descriptor interval	What schedule did the device request?
Observed host transfer cadence	When did the host service the endpoint?
New-report cadence	When did payload content change?
Firmware event cadence	When did hardware/firmware create events?
Application callback cadence	When did user space process them?

A device can be polled every 1 ms but send new sensor data every 10 ms. An app can batch ten 1 ms reports into one callback. Neither means bInterval is 10.

Measure timing from enough samples

One interval is not a distribution. Capture a stable period and calculate:

number of completed interrupt transfers;
median gap;
95th and maximum gap;
payload-change cadence;
gaps around suspend, resume, or heavy bus activity;
missing sequence numbers if reports contain them.

Use a table:

Metric	Expected	Observed	Interpretation
nominal service	1 ms	n/a	descriptor contract
median transfer gap	near 1 ms	1.01 ms	normal
P95 gap	bounded	1.18 ms	modest scheduling variation
maximum gap	investigate	8.2 ms	correlate with reset or host load
new report interval	4 ms	4.0 ms	firmware generation policy

Do not claim hard real-time guarantees from the nominal interval. Host scheduling and capture timestamps have limits.

Report generation faster than polling

Firmware can generate events faster than the host services the endpoint. Without a queue, newer state can overwrite older state:

button transition A occurs;
report A is prepared;
button transition B occurs before the host read;
firmware replaces report A with report B;
host receives only B.

That is not USB packet loss because report A never crossed USB. Add firmware sequence numbers or event counters in a diagnostic build where possible. Compare generated count with captured report count.

Choose a policy:

latest-state reporting for axes or continuous state;
queued transitions for events that must not be lost;
bounded queue with explicit overflow counter;
aggregation when the class contract permits it.

The right policy depends on the device, but the support report should name it.

Polling faster than report generation

If the host offers service more often than firmware produces data, the device can have no report ready for some polls. That is normal. Avoid manufacturing duplicate application events merely to fill every interval unless the HID idle-rate or product protocol requires periodic reports.

Check:

whether repeated identical reports are intentional;
HID idle-rate handling for applicable devices;
sensor sample rate;
interrupt/DMA completion;
buffer handoff from producer to USB endpoint;
first report after configuration and resume.

A low application event rate is not proof that the endpoint is scheduled slowly.

Descriptor mistakes that affect latency

Common errors include:

copying bInterval=8 while documentation promises 1 ms;
applying full-speed interpretation to a high-speed descriptor;
placing the intended value in one alternate setting while the host selects another;
editing a source descriptor but returning an older generated array;
assigning the endpoint to the wrong interface;
advertising an unrealistic interval for firmware's data production.

Capture the exact descriptor returned by the tested firmware. Source code comments and generated headers can drift.

HID report layout can mimic missed polling

Reports may arrive on time but be ignored because their descriptor contract is wrong:

missing Report ID;
unexpected payload length;
bit-packed transition interpreted incorrectly;
signed axis declared unsigned;
report for another top-level collection;
boot protocol versus report protocol mismatch.

Verify raw report bytes and IDs before attributing every missing input to bInterval. The HID report descriptor guide covers that layer.

Hub and controller topology

Interrupt scheduling shares host-controller resources. Test:

direct root port;
same port through the reported hub or dock;
quiet bus;
bus with the other devices that reproduce the problem;
same device at the same negotiated speed.

Record topology rather than saying "hub bad." A comparison can show that interval outliers correlate with a specific path, but electrical or controller-level proof may require hardware instrumentation beyond a host capture.

Suspend and resume create a separate interval boundary

After selective suspend or system sleep, the first report can be delayed or lost because:

endpoint buffers were not re-armed;
firmware restored the wrong protocol mode;
a stale event triggered immediate wake;
the host reset and re-enumerated instead of resuming;
application retained an invalid handle.

Mark the final pre-suspend report, resume event, first post-resume poll, and first changed payload. Do not include a long intentional suspend gap in normal polling statistics.

The USB remote wakeup guide covers power-state sequencing.

Application latency is downstream

If bus transfers occur at the expected cadence, measure:

physical event
→ firmware timestamp
→ USB transfer completion
→ driver delivery
→ application callback
→ visible response

Bus Scope covers the USB portion. Device instrumentation covers the first segment; OS tracing and app logs cover the last. Do not shorten bInterval when the delay is a blocked UI thread.

A repeatable polling-latency workflow

Record firmware, OS, topology, controller, and device identity.
Capture from enumeration through a controlled input pattern.
Prove negotiated speed.
Map interface, alternate setting, and interrupt endpoint.
Decode bInterval using the correct speed rules.
Measure many transfer timestamps.
Separate transfer cadence from changed-payload cadence.
Add known event markers or firmware sequence numbers.
Compare direct port and reported hub path.
Mark suspend/resume and reset boundaries.
Compare USB completion with application callback time.
Save a bounded .bscope session and timing table.

Use Bus Scope platform capture to select the correct controller or usbmon bus before measuring.

QA questions

Does `bInterval=1` always mean 1 ms?

No. Interpretation depends on negotiated speed and endpoint rules. At full speed it represents a 1 ms interval for an interrupt endpoint; at high speed the encoded service interval uses microframes.

Does a 1 ms endpoint guarantee 1000 new reports per second?

No. It describes host service scheduling, not firmware sample generation or application callbacks. The device may have no new payload at many service opportunities.

Why are fast button presses missing when polling looks correct?

Firmware may overwrite an unsent report, the HID layout may be wrong, the driver/application may coalesce events, or the physical event may never reach the report queue. Sequence numbers and cross-layer timestamps identify the boundary.

Can a hub change observed timing?

Topology and shared controller scheduling can affect timing. Compare controlled direct and hub captures while confirming the same speed and endpoint descriptor; do not infer the electrical cause from timing alone.

Can Bus Scope measure end-to-end input latency?

It can measure the USB portion from captured transfer timestamps. Physical-event detection before USB and application rendering after driver delivery require additional instrumentation.

Final diagnosis

An interrupt-latency report should state negotiated speed, decoded bInterval, actual transfer distribution, report-change cadence, and the first layer where expected timing diverges. That separates descriptor configuration, host scheduling, firmware buffering, HID parsing, and application delay instead of treating every lag complaint as one polling-rate bug.

How should latency be accepted?

Define the expected interval from negotiated speed and descriptor semantics, then measure a distribution across a representative window rather than quoting one packet. Report median, worst observed gap, changed-report cadence, and the application timestamp for the same input action. Repeat with a known idle device and under workload. This reveals whether the endpoint is polled as declared but firmware supplies stale data, or whether the delay begins before the host receives the transfer.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: