There is no such thing as a USB interrupt. Under USB version 2.0 and below, a device can transmit data only when polled by the host. Under USB 3.0, a device can tell a host it has data to send. USB has four modes of data transfer: Control, bulk, interrupt, and isochronous. Control is used to tell the host of the device's existence and its capabilities, and to configure the device by the host. Bulk is used by mass storage and scanner devices to transfer large amounts of data; it has error checking, but no guaranteed transfer rate. Interrupt mode has error checking and a guaranteed latency, from 1 to 255 ms. In other words, the host will poll the device for data every 1, 2, ... (in powers of 2 for OHCI controller hosts) ms. The device can send a previously agreed upon nop if it has no data to transfer, but it counts as a transfer. "Isochronous transfers are streaming, real-time transfers that are useful when data must arrive at a constant rate or within a specific time limit and occasional errors are tolerable." There is no error checking, and hence no retransfer of data received with errors. Examples of uses include USB microphones and speakers.
I wrote a C++ program that sets up an RS-232 serial port exactly like NTP does. The port is driven by a USGlobalSat BU-353W GPS USB device, converted to a COM device by a Prolific USB-to-Serial driver, and read at 57,000 baud. The program waits for an NMEA RMC string at the port, records the time received using the GetSystemTime Windows API call, and outputs the time received, the offset between system time and GPS time, and the NMEA RMC GPS string to a file; it then waits for another RMC string. Then I used a Java program to plot the system time vs. the offset. You can see a typical result at https://skydrive.live.com/redir?resid=92A71A1C4B64FD41!270. An explanation of this plot is in order. The X-axis is time in hours past midnight in UTC. The Y-axis is the offset (difference GPS Time minus system time) in milliseconds. The squiggly lines in the graph are the offsets. The straight line somewhat bisecting the offsets is the regression line Y = m X + b. The parallel lines on either side of the regression line are +- 3 times the standard error of the prediction (Y-predicted). If the offsets were normally distributed, then the probability of an offset falling outside the standard error of the prediction is less than 0.01. In statistical quality control terms, a process is considered to have fundamentally changed when it falls outside these limits; there is an error. The process shown in the graph repeats indefinitely using my BU-353W. In other words, the offsets always begin at about 300 ms, rise slowly to about 360 ms, vary erratically between 260 and 360 ms for about two hours, settle at 260 ms, and then rise slowly to 360 ms to repeat forever. It is not clear to me if the problem is the USB interface or the GPS device. On the one hand, if the Prolific USB-to-Serial driver is using USB interrupt mode and requesting data every 255 ms, and the USB controller schedules data transfers just slightly out of sync with system time, then the graph is fully explained, except possibly for the erratic behavior between 260 and 360 ms offsets. On the other hand, using the SiRFdemo.exe program, one can access the GPS output in a SiRF proprietary binary format, interpreted and labeled. In that output there is a quantity labeled "Clock Bias" (right now 104571115 ns) which also varies up and down similar in pattern to the offsets. If the GPS output were captured in binary and the clock bias applied to the "EstGPSTime" also output, would the time be more accurate? Don't know, in part because USGlobalSat won't disclose the binary format. It might be possible to write a USB driver to capture the binary output of the BU-353W and output it to a file in hex and then figure it out. Microsoft has a page here http://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).a spx entitled "How to Access a USB Device by Using WinUSB Functions" that appears to explain how this could be done, but I have not tried it yet. If the problem with the wandering offsets is the USB interface, then I do not see why the short-term solution is not to poll the USB GPS device every 1 ms. Then at least one would have 1 ms resolution of the time the GPS string was read, and any offset would be due to the delay in the GPS sending the data. (But I just cannot persuade myself that I am the first to think of this.) Then long term solution might be to switch to USB 3.0 and let the GPS notify the host when there is data to send. This whole message is based on reading 155 pages (of 504) of Axelson, J. (2009). USB Complete: The Developer's Guide (Fourth ed.). Madison, WI: Lakeview Research LLC. Let the reader beware. Charles Elliott > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Rick Jones > Sent: Wednesday, August 08, 2012 5:35 PM > To: [email protected] > Subject: [ntp:questions] is USB inherently evil, or only if something > else is on the bus? > > I've scrounged a couple old Pentium M laptops (Hewlett-Packard nc6000s > for the trivia-minded) with serial ports while entertaining the > possibility of undertaking a project to do what so many others have > done - connect-up a GPS receiver with PPS support. That has me > wondering about some of the previous discussion about USB and how it is > perhaps not "evil" but considered quite sub-par for serving-up the PPS > signal. > > Is that unsuitability inherent in USB, so it matters not whether there > is anything else on the USB, or is it more a case of being "bad" > generally only when other things are on the same USB? I'm still > looking to go serial, but was wondering. > > Also, speaking of things considered "bad" and drifting - fudging the > LOCAL(0) is definitely frowned upon right? If I happen to have say > four servers in a location which might loose its connectivity to the > outside world I probably don't want those servers to fall-back on > LOCAL(0) right? Would configuring each to have the other three as > "peer" entities be the way to go? > > Pointers to the fine manual for any of the above would be welcome. > > thanks, > > rick jones > -- > I don't interest myself in "why." I think more often in terms of > "when," sometimes "where;" always "how much." - Joubert these opinions > are mine, all mine; HP might not want them anyway... :) feel free to > post, OR email to rick.jones2 in hp.com but NOT BOTH... > > _______________________________________________ > questions mailing list > [email protected] > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
