On Sat, 20 May 2006, Emil Mieilica wrote: > >I suspect it's not possible to provide any sort of performance guarantee > >to a user program when the system is under high load. Linux is not an > >RTOS. > > > > > I understand that in use space there are no latency guarantees, but in > kernel space there is a whole different story as I imagine.
Latency for kernel drivers is lower than for user programs but there are still no latency guarantees. > Each URB I submit, is scheduled in the kernel and then notified of its > completion from an IRQ context (from PCI root hub). > I wonder if this scheduler is able to provide some sorts of guarantees? There are some guarantees, but probably not the sort you are interested in. They have nothing to do with timing. > 1. Is there a priority involved in considering URB scheduling? Yes. The priority is defined by the USB specification. Periodic transfers (isochronous and interrupt URBs) are guaranteed the necessary bandwidth on the USB bus; if the bandwidth isn't available then the submission fails immediately. Control URBs are guaranteed to receive at least 10% of the bandwidth (it's shared among all the active control URBs) and bulk URBs get whatever is left over. > 2. URBs are scheduled in sequence or can there be more URBs submitted to > the root hub awaiting completion? URBs are not submitted to the root hub unless they are meant to communicate with the root hub. Usually only the hub driver needs to send URBs to the root hub; other drivers communicate with their respective devices. URBs for each device/endpoint combination are scheduled in a FIFO queue. Different endpoints have different queues and they advance independently. > 3. If I write a module, and in my read complete notification I resubmit > the URB, can I assume that the transfer will not be delayed? To some extent. If there are no other URBs scheduled for that endpoint then your URB will be active as soon as the resubmission is done. If you're not on an SMP system that should happen very quickly (interrupts are disabled while your completion routine runs). But even then, while your URB is active it still has to contend with all the other active URBs for bandwidth on the USB bus. > 4. How much time can there be between the submission of the URB and the > beginning of the transfer on the USB bus? The time from when the URB becomes active to when data starts going over the bus depends on what other URBs are running on the same bus at the same time. If there aren't any others then the transfer should begin within 1 ms. > >Something you may not have been aware of... To get maximum throughput you > >must use asynchronous USB requests and submit multiple URBs. Current > >versions of libusb do support this. In particular, you have to make sure > >that a request is always queued. If you wait for a request to finish > >before submitting the next one, you are liable to lose data. > > > > > Yes, you were right. I needed to submit multiple asynchronous request in > order to keep up. But I decided that a kernel driver is the best choice > considering the hight load I expect in other processes. I have decided > to modify a serial driver (the ftdi_sio) because it does 90% of what it > should do, but I noticed that the same problem can creep on me, and this > time from within the kernel itself. I don't think the TTY subsystem can > keep up with this amount of data because it has only > 2*TTY_FLIP_BUFFER_SIZE and some strange throttle/un-throttle semantics. > Can it reliably handle the high data rates? I don't know much about the serial drivers. They probably have a lot of extra baggage you don't need (line disciplines, for example). Unless you really do want your device to appear to be a serial device. Alan Stern ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
