[ntp:questions] help - clock jumps up to 5000 ms startup ntpd with usb gps linux

unruh unruh at invalid.ca
Sat Feb 18 18:23:16 UTC 2012


On 2012-02-18, Ron Frazier (NTP) <timekeepingntplist at c3energy.com> wrote:
> Hi all,
>
> I'm having a really weird problem where I'm using NPTD WITHOUT GPSD in 
> Ubuntu 11.04 Linux with a GlobalSat BU-353 USB GPS.  Before starting 
> NTPD, I correct the clock to within a few ms with NTPDATE.  Then, 
> immediately upon the startup of NTPD, the clock jumps 300 ms to 5000 ms 
> off as reported by NTPQ.  I know it really is off, because it reports 

300 to 500ms could be just the time (at the end of the nmea sentence)
that the gps time is stamped for. 5000 could not be. 
Note that the problem could also be ntpdate. 
look at your computer time at the time when the nmea sentence come
through. (you could set the nmea driver up to not be used by ntpd, and
look in the peers log to see what offset is being reported for that
source when you have the set the time with ntpdate. )


> this serious offset not only to the GPS but also to the internet 
> servers.  Not only that, if I run NTPDATE again after terminating NTPD, 
> it corrects the clock by approximately the same amount as the offsets 

Recall that ntpdate is deprecated and will disappear soon. You ntpdate
may have a bug. Noone will fix it if it does. 

> that NTPQ reported.  I don't think this occurs in Windows much if at 
> all.  But, it pretty much always does in Linux if the GPS is attached.  
> I hope someone can help me.  I'm not using nor do I need PPS at this 
> time, but may pursue it later.  I know that this GPS can give me 6ms 
> accuracy on Windows, and it should be able to do that on Linux.  Also, 

It can. You do have to offset it by the nmea sentence read time. 

> I'm trying not to use GPSD since that's not available in Windows and I 
> want to keep both configurations essentially the same.  Here are the 
> steps to duplicate the problem in Linux.
>
> Plug in the USB GPS.  This one uses the Prolific 2303 chipset, so Linux 
> automatically recognizes it.

It is an nmea gps. The chipset is irrelevant.

>
> Set the port settings (from David Taylor's website):
>
>       sudo stty -F /dev/ttyUSB0 57600 igncr clocal -echo -ixon
>
> Create a link from /dev/ttyUSB0 to /dev/gps5
>
>       sudo ln -T /dev/ttyUSB0 /dev/gps5
>
> I have preprogrammed the GPS to output the GPZDA sentence at 57600 
> baud.  Check the output.  Ctrl-C to end.
>
>       ron at asus-k52f-1:/etc$ sudo cat /dev/gps5
>       $GPZDA,162338.000,18,02,2012,,*51
>       $GPZDA,162339.000,18,02,2012,,*50
>       $GPZDA,162340.000,18,02,2012,,*5E
>       $GPZDA,162341.000,18,02,2012,,*5F
>
> This is exactly what the GPS should be sending out.
>
> The relevant ntp.conf lines are:
>
>       server 127.127.20.5                prefer minpoll 3 maxpoll 13 mode 72
>       fudge  127.127.20.5 time2 0.2930 refid GPS1
>
> Set the computer's clock 3 times.
>
>       ron at asus-k52f-1:/etc$ sudo ntpdate -b nist1-ny.ustiming.org
>       18 Feb 11:28:48 ntpdate[17968]: step time server 64.90.182.55 
> offset 0.012966 sec
>       ron at asus-k52f-1:/etc$ sudo ntpdate -b nist1-ny.ustiming.org
>       18 Feb 11:28:57 ntpdate[17985]: step time server 64.90.182.55 
> offset -0.000027 sec
>       ron at asus-k52f-1:/etc$ sudo ntpdate -b nist1-ny.ustiming.org
>       18 Feb 11:29:08 ntpdate[18008]: step time server 64.90.182.55 
> offset 0.001291 sec
>
> I now KNOW that the clock is right within a few ms and I KNOW that the 
> GPS is outputting the proper data.
>
> Now start NTPD:
>
>       ron at asus-k52f-1:/etc$ sudo ntpd
>
> Now check with NTPQ:
>
> ron at asus-k52f-1:/etc$ ntpq -p
>       remote           refid      st t when poll reach   delay   offset  
> jitter
>==============================================================================
> *GPS_NMEA(5)     .GPS1.           0 l    4    8   37    0.000  563.733   
> 0.010
>   nist1-ny.ustimi .ACTS.           1 u   32   64    1   54.928  
> 554.504   0.000
>   216.119.63.113  .ACTS.           1 u   43   64    1   61.896  
> 578.076   0.000
>   india.colorado. .ACTS.           1 u   44   64    1   60.297  
> 552.711   0.000
>   ping-audit-207- .ACTS.           1 u   41   64    1   84.318  
> 548.833   0.000
>
> NOTE that the clock is now off by ~ 550 ms.  I have seen it as high as 
> 5000 ms.
>
> Now I end the NTPD process from the system monitor.
>
> Now I reset the clock again with NTPDATE:
>
>       ron at asus-k52f-1:/etc$ sudo ntpdate -b nist1-ny.ustiming.org
>       18 Feb 11:34:56 ntpdate[18588]: step time server 64.90.182.55 
> offset 0.557084 sec
>
> NOTE that the clock was corrected by 557 ms!
>
> Now, just for kicks, I run NTPDATE again.
>
>       ron at asus-k52f-1:/etc$ sudo ntpdate -b nist1-ny.ustiming.org
>       18 Feb 11:36:43 ntpdate[18775]: step time server 64.90.182.55 
> offset 0.001093 sec
>
> NOTE that, this time, the clock was only corrected by 1 ms.
>
> Now, let's check the output of the GPS again:
>
>       ron at asus-k52f-1:/etc$ sudo cat /dev/gps5
>       $GPZDA,163805.000,18,02,2012,,*55
>
>       $GPZDA,163806.000,18,02,2012,,*56
>
>       $GPZDA,163807.000,18,02,2012,,*57
>
>       $GPZDA,163808.000,18,02,2012,,*58
>
> NOTE that there are now blank lines between each entry, where there 
> weren't before.  This may have something to do with the problem.  NTPD 
> appears to be turning off the igncr parameter on the /dev/ttyUSB0 port, 
> which is linked to /dev/gps5.
>
> This is totally baffling to me and very frustrating.  I have the clock 
> very closely synchronized, then I start NTPD, and it jumps way off.  
> This obviously shouldn't happen.  Then, once the clock is way off, it 
> takes a very long time for NTPD to correct it, if at all.  Compare to my 
> experience on Windows, where, if the time is say 10ms off when I start 
> NTPD, then, within just a few minutes, that 10 ms error is eliminated.  
> I MAY have seen a time jump in Windows, but it certainly doesn't happen 
> all the time, if at all.  I have to do more testing.  But I know this 
> happens pretty much every time in Linux.
>
> If anyone can help with this, it will be greatly appreciated.
>
> Sincerely,
>
> Ron
>
>



More information about the questions mailing list