Re: time source unstable on usb/serial/pl2303 (globalsat br-353)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: time source unstable on usb/serial/pl2303 (globalsat br-353)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: time source unstable on usb/serial/pl2303 (globalsat br-353)
On Fri, May 24, 2013 at 09:27:17AM +0200, 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, 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. You can increase the interrupt request rate some, but if the device doesn't have any data to send, it doesn't matter how often you ask it for data. Is it possible to make bulk_read_requests at the interrupt priority ? There is no difference in the priority of the two requests at all, they are the same. 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. That's odd, let us know if you find anything out with your tests. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: time source unstable on usb/serial/pl2303 (globalsat br-353)
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, 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. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
time source unstable on usb/serial/pl2303 (globalsat br-353)
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. 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 ? Thanks in advance Philippe -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: time source unstable on usb/serial/pl2303 (globalsat br-353)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
