On Thu, 26 Mar 2009, Richard wrote: > Alan Stern wrote: > > > > > You should try sched_setparam() and sched_setscheduler(). Use the > > SCHED_FIFO policy. > > > > You should also have your program print out the current time just > > before and after each of the USB transfers. Comparing those values to > > the values from usbmon will provide some clues. > > > > I did the above, and set the program to run at > sced_priority_max (as root). I ran a short series of 3 usb > write-reads and compared the output of usbmon and > the printout from my program. Here are the results, > where I have added comments after "*" and I've > marked suspicious areas with "*****": ... > I found that for the 1st and 2nd interrupt read transactions, there > is about 3ms extra delay between when usbmon says that the read > transaction is completed, and when my program gets out of the > usb_interrupt_read() routine and prints its message. Of course > there are other intervening instructions, such as a gettimeofday > call, however this does not add so much delay when I call it > elsewhere in the program. Here is the relevant part of my code > around the usb_interrupt_read() call: ... > Another thing I noticed is that this extra delay does not > occur for the 3rd interrupt read transaction. For that one > only 26 bytes are read, instead of 62. > > It appears that there is a delay in getting out of the > usb_interrupt_read() function for the case of reading > 62 bytes. Do you have any idea why this might occur? > Or is there something else I am missing? Come to think of it, this is because of the way older versions of libusb (prior to 1.0) work. Instead of waiting synchronously for an URB to complete, the library polls the status and sleeps in between. I don't know why. So you could try using the newest libusb, or you could try using usbfs directly. I don't know why the third read behaves differently from the first two. > >> I also have a general question - given that this > >> device enumerates as a HID device, how is it that > >> the HID driver never enters into the picture? > > > > I can't tell you in detail because you didn't describe exactly how your > > program works. However, if the HID driver were bound to your device > > then your program would not be allowed to access the interrupt > > endpoints. > > > > Does your program call usb_detach_kernel_driver_np()? If it does, that > > removes the HID driver from the picture. > > > > I don't call usb_detach_kernel_driver_np(). However one thing > I noticed that might give a clue, when I attach the device I > get the following message on the terminal: > > HID device not claimed by input or hiddev That explains why you don't need to detach any kernel drivers; they don't know how to drive your device so they didn't claim it in the first place. And it also shows that the HID driver is not involved in managing your device. 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
