I have an inexpensive GPS receiver that I am using as a local clock driver for NTPD, the Network Time Protocol (NTP) daemon, running under Windows 7 64-bit. NTPD is also connected, thru another computer, to 9 stratum 2 NTP servers located on the East Coast, USA. What NTPD on this computer sees is the smoothed, best reading from the 9 NTP servers, other computers on my local network, and the GPS clock. If NTPD's output is plotted, it looks like a straight line horizontally across the page +- ~6 milliseconds (ms) around 0 offset, which is the readings from the 9 NTP servers. Superimposed on this is a sawtooth wave +- ~60 ms, which is the GPS driver output. The GPS output starts about 60 ms ahead of real time, slowly descends over a little over 24 hours to ~ -60 ms below real time, varies wildly between -60 ms and +60 ms around 0 offset real time for about 2 hours, and finally settles at +60 ms offset to begin the cycle again. You can see a plot of this data here (https://skydrive.live.com/redir?resid=92A71A1C4B64FD41!271&authkey=!ABrUBy4aS7e7sME
This sawtooth pattern continues forever, unless the computer is rebooted, in which case the GPS output restarts at +60 ms offset ahead of real time and continues its descent to -60 ms below 0 offset. The GPS output is once every 16 seconds; i.e., 1/16 Hz. The GPS unit sends its signal as a standard NMEA RMC ASCII string via USB to a Prolific USB-to-Serial (RS232) bridge. The NTPD clock driver -> WAITS <- for the signal (actually the CR/LF pair at the end) at the Windows serial API and records the exact system time received. In other words, the GPS output appears to be actually being received at the offsets shown in the plot, i.e., in a sawtooth pattern. The question is, what is the source of the varying GPS signal received times, the USB driver or the GPS clock device? A trace of the USB output looks like the GPS string is actually being received a few ms later every 16 seconds, but according to the USB specs, that is not possible. USB in interrupt mode is supposed to be polling the device at exactly the same time every cycle. The fact that a computer reboot restarts the sawtooth pattern at its apogee, and that a reboot (probably) does not affect the GPS device, seems to point to USB as the culprit. However, a good GPS NTP clock can cost $1,000 or more; the one I have cost $35. Does anyone know if USB does schedule its polling in interrupt mode a few ms later every scheduling interval, and then later tries to rectify its error? Does anyone know how to fix this error, or even approach debugging it?