USB CDC-ACM - does 'flush' block until data has been sent?

[marcpabst]

Hi, I'm trying to understand how .flush() behaves for USB CDC devices. Does it block until the data has been sent to the USB device? Or is there an intermediary buffer somewhere? I.e., can I use this blocking behaviour to infer latency? Or is this platform-dependant?

[sirhcel]

According to what we've seen in #117 you results may likely vary: macOS interprets flush() pretty differently than Linux and it does not guarantee that all output buffer data is sent on the wire before it returns.

If you're talking about a single platform and a certain device driver, you might get away with it. But I would not rely on the behavior observed on one setting to be the same in another. I'm sorry for this kind of bad news.

However depending on your application you might be able to sort this out by waiting for some time after flushing the data in question: You know baudrate and can make a rough estimate on your system latency.

[marcpabst]

Thanks four your reply! Yeah, that's what I thought! I was under the impression that on both Windows and Linux the native commands are supposed to also take care of flushing the downsream buffers, but can't find a source for that cucrrently.

Under certain conditions, I'm actually seeing very low execution times of .flush() on MacOS, sometimes <7μs - that feels a bit fishy. Lookig at the linked issue, are you saying that the function returns before sending any data or all data?

I'm basically trying to measure (or at least get an upper bound) the time it takes until the (first) USB package is send to the USB device, but I suppose I need to go at least one layer deeper to have any real chance of archiving any accuracy at all.