

Capturing USB2 video at 35MB/sec on Linux - happyman
http://www.rrfx.net/2011/11/capturing-usb2-video-at-35mbsec-on.html

======
nodata
If the kernel is going to sleep when it shouldn't, that's a bug. I'd report
it.

~~~
pmjordan
I'm not convinced it's quite so straightforward. The problem isn't exactly
that the kernel is sleeping when it shouldn't. After all, there's nothing to
do, so sleeping is sensible. The issue, as I understand it, is that the C6
state in modern CPUs causes them to sleep so deeply that it takes a long time
to wake up when an interrupt does occur. From the time of the interrupt to
when the handler can run, the high-throughput device (such as a camera, but
this also happens for external USB 3.0 hard disks and SSDs, it's just less
noticeable as the data isn't realtime and unbuffered) fills up the available
DMA buffer(s) and has to stall. So I guess the trick would be to detect when
high throughput is expected and not to sleep quite as deeply in those
situations. For cameras, that ought to be possible, as they use USB's
"isochronous" mode, for which you need to decide the bitrate in advance.
Storage devices typically use "bulk" mode, so the driver would need to detect
devices which respond to requests quickly and avoid deep sleep when issuing a
bulk command to them.

~~~
simcop2387
I'd still call that a bug myself. The solution would _appear_ to be that
drivers should be able to tell the kernel "I can't let you go into deep sleep
right now" when they're active. Say when the USB camera is actually capturing
video, when it isn't it should be perfectly fine to let it go into the deep
states. A hard drive or something else bulk like that is certainly a different
beast altogether. So at least maybe preventing the deep sleep when something
in isochronous mode is transmitting data should be fine, (I understand this
makes the assumption that USB cameras are sane and drop the isochronous mode
when not doing video, I don't know if this is a good assumption).

