Hello, On Fri, May 24, 2013 at 09:46:32AM -0400, Alan Stern wrote: > On Fri, 24 May 2013, Philippe De Muyter wrote: > > > 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, Sorry for the typo, it is actually a BU-353 > > > > 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. > > Have you tried usbmon? The detailed information about the timing of > the URBs might give you some clues. > > > > 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. > > It's possible that the delays are at the user level and not in the > kernel. I analyzed the problem as deeply as I could, and the problem was threefold : (remember it is on a cpu-intensive environment) - the user had inadvertently dropped the setuid/setgid of the application program, thus it did not run in the highest priority, but at a normal priority - usb serial lines do not have the low_latency mode set, and setserial cannot set it either : linux-1syr:~ # setserial /dev/ttyUSB0 low_latency Cannot set serial info: Inappropriate ioctl for device linux-1syr:~ # - the gps receiver hardware/firmware (Gloabalsat BU-353, with a SiRF III chip) sometimes takes 100-200ms more to begin sending its messages (I can see that because the bulk_read allways give only one byte of data). Additionaly, because I only got one character at a time, the debugging I had put in pl2303.c tried to detect the beginning of a new message by measuring the delay between the last byte received and the current one and comparing that to a threshold. My threshold was too high, and sometimes (rarely now), there is no gap between the end of the message of second s and the beginning of message of second s+1. That gave wrongly the impression of a '1 additional second' delay. Setting low_latency in the pl2303 driver helped a lot !!! Now I only see the intrinsic delay of the gps receiver itself, and some millisecs from usb. Thanks for your input.. 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
