On Thu, May 23, 2013 at 08:31:18AM -0700, Greg Kroah-Hartman wrote: > 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? I hoped it was the configuration on the host-side. I have read internet pages that implied that for USB mice it was possible to increase the polling rate. I hoped that it would be the same for serial lines. Is it possible to make bulk_read_requests at the "interrupt" priority ? > > > 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. The baud rate is the default nmea baud rate (4800bps), and I noticed that I only get one byte at a time in the kernel when the messages are not delayed, so it seems that the pl2303 dos not wait for a number of bytes before answering bulk requests, hence I thought that the delay was caused by a delayed polling. I will add debugging to see if I get more than one byte at a time when messages are delayed. > > 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. Yes, I think that there must be something wrong but more on a software side, because I do not get such big delays on an unloaded computer. Philippe -- 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
