4 ms·

Capturing USB2 video at 35MB/sec on Linux

8 points by happyman 15y ago

nodata 15y ago
If the kernel is going to sleep when it shouldn't, that's a bug. I'd report it.
- pmjordan 15y ago
  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 15y ago
    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).

4 ms·

Capturing USB2 video at 35MB/sec on Linux

8 points by happyman 15y ago

nodata 15y ago
If the kernel is going to sleep when it shouldn't, that's a bug. I'd report it.
- pmjordan 15y ago
  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 15y ago
    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).