From: Alan S. <st...@ro...> - 2009-12-23 16:08:48
|
On Wed, 23 Dec 2009, Daniel Drake wrote: > This is the basis for the timing calculation. > > > 09:32:39.906351 ioctl(6, USBDEVFS_SUBMITURB, 0x89f1238) = 0 > > 09:32:39.931278 timerfd_settime(5, TFD_TIMER_ABSTIME, {it_interval={0, > > 0}, it_value={668, 444906000}}, NULL) = 0 > > The timer is set for exactly 500ms after the basis discovered above. > It looks like submitting the ioctl took about 30ms, or something else > delayed us before we could program the timer. It's debatable whether > libusb's timing basis should be generated before or after submitting the > URB. Is this really debatable? Timeouts on computer systems are almost invariably lower bounds -- i.e., "Wait at least X ms for the transfer and if it hasn't completed by then, cancel it". You practically never encounter an upper bound -- i.e., "Don't allow this transfer to continue for more than X ms at most". Partly this is because people tend to need lower bounds more than upper bounds, and partly it is because upper bounds aren't enforceable. (If your process didn't happen to be running at the right time, it wouldn't be able to issue the cancellation before the X ms were over.) Philosophy aside, the meaning of timeouts for libusb should always be "Give the transfer at least X ms and if it hasn't completed by then, cancel it." So the basis for the timer should be _after_ the URB is submitted, not before. Otherwise (as in this case) the URB is liable to be cancelled too early. Alan Stern |