Dear Alan, After tracing the flow, and we do the measurement about cpu cycles for function in ehci irq path. We find the function scan_periodic(), in for loop, case Q_TYPE_ITD will occupy much cpu cycles. It will increase irq latency for ehci. below is the issue that increase irq latency: 1. when in case Q_TYPE_ITD , it will run itd_complete() for URB complete. 2. if modified is true, then it will goto restart, then case Q_TYPE_ITD will run again, it is repeatly. 3. Sometime, we can see uvc driver uvc_video_decode_isoc() will take much cpu cycle,too. Since uvc driver decode data in complete call back function. Our question: is it possible to modify flow of uvc driver? Since in complete call back function, it will do decode and re-submit new urb. it will take more time, right? is it possible to reduce the time for case Q_TYPE_ITD? Note: the test condition: ip camera configuration: 1280x720, 30fps Could you kindly help to give us the hints for the enhancement iso schedule? Thanks a lot! Best Regards, Soho ============================================================== 2011/5/31 Soho Soho123 <soho123.2012@xxxxxxxxx>: > Dears, > > We have apply the patch you mentioned below. the result is the same. > And we see the phenomenon about how long the urb will be complete. the > time duration may not 20 ms periodically, sometime is about 30 ms. > Could you explain the reason about why 20ms is "must" in ehci iso > schedule mechanism? > And it is possible longer urb complete time in sometimes, right? > > Thanks a lot! > > Best Regards, > Soho > > 2011/5/27 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: >> On Thu, 26 May 2011, Soho Soho123 wrote: >> >>> Dears, >>> >>> >>> Let me ask the question more detail below. >>> >>> 1. So linux 2.6.30 has bug, "it can work over night" is wrong. >> >> Yes. >> >>> 2. the meaning of yours is uvc video driver submit new urb too late, right? >>> but as my understand, the new urb is submited when the urb has complete. so, >>> the time for urb complete is too long, right? >>> the time duration for ehci irq service function to finish is too long, right? >>> Or, >>> ehci irq service function can not be run due to CPU resource has been >>> occupied by other device, right? >> >> Yes. If you use usbmon (see Documentation/usb/usbmon.txt) you'll see >> exactly when each URB is submitted and when it completes. >> >>> 3. do you have any suggestion for work around ? >> >> Start with usbmon to make sure my analysis is correct. Then try to >> figure out what part of your system is responsible for the high >> interrupt latency and fix it. >> >> Another thing to try is applying commit >> 1e12c910eed82da6971f1c0421a069c680faba2e (EHCI: don't rescan interrupt >> QHs needlessly) from the USB development tree: >> >> https://git.kernel.org/?p=linux/kernel/git/gregkh/usb-2.6.git;a=commitdiff;h=1e12c910eed82da6971f1c0421a069c680faba2e >> >> That was specifically intended to help reduce latency. >> >> You can also try increasing the number of URBs to 32. But that's not >> going to do anything about the source of the problem. >> >> Alan Stern >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
