Dear Alan, My meaning is : is there any time time inaccuracy acceptable in ehci host??? Or any blind spot from iso schedule check criterion? Since we do not familiar with ehci host iso schedule algorithm. When we update ehci host and usb subsystem code to 2.6.39 version, the slower platform has this problem. Thanks a lot! Best Regards, Soho 2011/6/2 Soho Soho123 <soho123.2012@xxxxxxxxx>: > Dear Alan, > > > My comment below: > > 2011/6/2 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: >> On Thu, 2 Jun 2011, Soho Soho123 wrote: >> >>> >> Soho: in our platform the time precision is 10ms per tick . >>> > >>> > In a PC, the time precision is between 1 and 10 ms per tick. But PCs >>> > also have high-precision timers available; apparently your platform >>> > does not. Without high-precision timestamps, there's no way to tell >>> > what's causing your latencies to be so large. >>> >>> >>> soho:???? >> >> If your usbmon timestamps were accurate down to microseconds, I could >> tell whether the latency was caused by ehci-hcd, by uvcvideo, or by >> something else. >> > > > Soho:we have sent you the log from ther other e-mail. you should get > that. Could you kindly help to confirm the error condition? thank you > very much!!! > >>> > One other thing you can try: Increase UVC_MAX_PACKETS to 100. >>> >>> soho: we will try it later. Could you explation the consideration >>> about increase uvc max packet? >> >> With UCV_MAX_PACKETS set to 32, you get an interrupt and have to submit >> a new URB every 4 us. That's a pretty high rate. With UVC_MAX_PACKETS >> set to 100, an interrupt will occur every 12.5 us. The timing >> requirements will be less strict and the overhead of interrupt handling >> will be reduced. >> >> Alan Stern >> >> > > Soho: we have do the verification with large UVC_MAX_PACKETS. it seem > better for the faster platform. > In the faster platform , we do not see submit urb error in a few minutes. > But in another platfrom , that is slower, the modification of > UVC_MAX_PACKETS is no any effect. the problem is still exist. Our > target is to see the cause in slower platform and fixed it if > passible.One more question: > We take the observation: > if we suspected UVC complete function (or UVC device driver is cause). > in theory, the urb_actual_length is not fixed, sometimes is shorter > and sometimes is longer. So, the time for decode is sometimes is > shorter and sometimes is longer. usb_submit_urb is handle by usb code > and ehci host driver. Then the time frame for re-submit urb to ehci > host is sometimes earlier and sometimes later, right? > is there any time inaccuracy in ehci host? > -- 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
