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
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
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,
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.
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@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@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@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@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@asus-k52f-1:/etc$ sudo ntpd
Now check with NTPQ:
ron@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@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@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@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
--
(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)
Ron Frazier
timekeepingdude AT c3energy.com
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
