On Thu, May 23, 2013 at 03:07:09PM +0200, Philippe De Muyter wrote: > Hi all, > > I have a lot of linux computers equipped with a GlobalSat Br-353 GPS receiver, > which is connected via USB (an integrated PL2303). The GPS receiver emits > one multi-line message every second, giving position and time. I listen > to this messages in a user program running in the highest priority, > and I have noticed that under load, the messages are not delivered to my > process every second, but often delayed, which is not great for a time source. > > I looked at the sources of pl2303 and added a diagnostic message if the > beginning of a message came more than one second later than the beginning > of the previous one, and I noticed that the delay was already present > in the kernel: often even more than one second delay after the expected > beginning time. Then that implies that the device itself is holding on to the message, right? > Can you give me some advice on how to avoid that delay ? How > can I increase the polling priority of this serial line, or how may I get > some usefull debugging about the USB polling for this serial line ? There is no "polling" of USB serial devices (well, there is, but it's a USB thing, and the hardware does it for us, not the software). The pl2303 is a _very_ cheap chip, and it might buffer the message for a long time before it decides to send it to the USB host. The delay might also be in the GPS device itself, it has to send serial data to the pl2303 device, and who knows at what baud rate that is coming in at. USB is not something that you can rely on for very high-frequency, low latency, timing things. Although to be fair, second delays are quite rare, which implies that your hardware is to blame here. Sorry, greg k-h -- 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
