Hi,
Is there a direct way to measure the latency between the Cyton board and its dongle?
Does it appear in any of the specs of the Cyton board?
Thanks a lot,
Gilad
This would be difficult to determine without some kind of customized hardware setup. I do know that the LabStreamingLayer people have given some thought on how to do this, you may want to checkout their docs.
On the 8 channel Cyton, at 250Hz sample rate, sample packets are sent every 4ms between the mainboard RFduino and the dongle RFduino. Once the dongle receives the radio packet, it is then enqueued via the operating system USB layer. This usb transaction and the OS buffering is likely the largest component of the latency.
Out of curiosity, I asked Google search / AI, what is the latency involved using a usb wired keyboard, between the user pressing the key and the key data being available in the end application.
See some the related links on that search. But the Gemini AI response is below. Note that with the Cyton/dongle, no 'debouncing' is involved. So the OS buffering is the major factor.
AI Overview
On a typical modern desktop with a USB wired keyboard, the total latency from key strike to input recognition by the application is generally between 3ms and 15ms. While USB polling (often at 1000Hz) adds ~ 1ms, total input lag is primarily dictated by key switch debouncing and keyboard firmware processing, which together typically take 1–4ms on high-quality devices.
Key Factors Contributing to Latency:
Polling Rate: Most gaming and high-performance keyboards use a 1000Hz (1ms) USB polling rate.
Key Scan Rate: The keyboard processor scans the matrix for keypresses, adding up to 1ms in typical scenarios.
Switch Debounce: A significant portion of the latency comes from debouncing, as keyboards must wait to ensure the key is actually pressed and not just vibrating.
Total System Lag: While the input is received quickly, the total time for the character to appear on screen includes display rendering latency, which can add significant time beyond the initial input processing.
Higher-end gaming keyboards can achieve input latency at or under 2ms, while standard office keyboards often hover around the 15–20ms range.
I then followed up with this exchange:
please ignore the keyboard scanning / debouncing delays, and concentrate on the usb and OS buffering aspects.
When you strip away mechanical debouncing and scanning, the remaining latency is dominated by the USB polling interval and the Operating System's input stack processing. On a modern desktop, this combined "digital" latency typically ranges from 1 ms to 10 ms.
USB Polling Latency (Hardware-to-OS)
USB is a host-controlled protocol, meaning the keyboard cannot "push" data to the CPU; it must wait for the USB host controller to "pull" (poll) it.
Standard Keyboards (125 Hz): These are polled every 8 ms. On average, a keypress will wait 4 ms (half the interval) before being picked up by the bus.
Gaming Keyboards (1000 Hz): These are polled every 1 ms, reducing the average bus wait time to 0.5 ms.
High-End Gaming (8000 Hz): These use High-Speed USB microframes (125 μs), reducing the polling delay to a negligible 0.06 ms.
OS Input Stack & Buffering (Kernel-to-App)
Once the USB controller receives the data packet, the OS must process it. This stage is highly variable based on system load and power settings.
Interrupt Handling & DPC (0.1 ms – 2 ms): The USB controller triggers a hardware interrupt. The CPU then executes a Deferred Procedure Call (DPC) to hand the data to the HID (Human Interface Device) class driver. In a "clean" system, this takes under 0.5 ms, but high DPC latency from poorly written drivers (like GPU or Wi-Fi) can spike this to 2 ms+.
OS Message Queue (1 ms – 5 ms): The OS (e.g., Windows win32k.sys) places the keystroke into the "System Input Queue" and then dispatches it to the specific application's message thread. This process is generally fast (~1 ms) but can be delayed if the OS is under heavy load or if "Selective Suspend" power-saving features cause a momentary wake-up lag.
Application Retrieval (<1 ms): The consuming program must "pump" its message loop (e.g., GetMessage in Windows) to retrieve the event. In a well-optimized, high-frame-rate application, this is nearly instantaneous.
Summary of Latency Budget (Non-Mechanical)
Stage | Typical (Office) | Optimized (Gaming)
USB Polling (Average) 4.0 ms 0.5 ms
Kernel / HID Driver 1.0 ms 0.2 ms
OS Message Dispatch 2.0 ms 0.5 ms
Application Queue 1.0 ms 0.1 ms
Total "Digital" Latency ~8.0 ms ~1.3 ms
Comments
Hi Gilad,
This would be difficult to determine without some kind of customized hardware setup. I do know that the LabStreamingLayer people have given some thought on how to do this, you may want to checkout their docs.
https://www.google.com/search?q=labstreaminglayer+latency
On the 8 channel Cyton, at 250Hz sample rate, sample packets are sent every 4ms between the mainboard RFduino and the dongle RFduino. Once the dongle receives the radio packet, it is then enqueued via the operating system USB layer. This usb transaction and the OS buffering is likely the largest component of the latency.
Out of curiosity, I asked Google search / AI, what is the latency involved using a usb wired keyboard, between the user pressing the key and the key data being available in the end application.
https://www.google.com/search?q=on+a+typical+modern+desktop,+what+is+the+latency+in+milliseconds+between+a+user+striking+a+keyboard+key+on+a+usb+wired+keyboard,+and+the+key+being+available+in+the+consuming+program?
See some the related links on that search. But the Gemini AI response is below. Note that with the Cyton/dongle, no 'debouncing' is involved. So the OS buffering is the major factor.
I then followed up with this exchange:
https://www.google.com/search?q=labstreaminglayer+how+to+measure+latency
https://sccn.ucsd.edu/labinfo/equipment/latencies/
https://sccn.ucsd.edu/labinfo/equipment/latencies/biosemi.html