Note: There was a bad value `' for the field `Confidential'.
It was set to the default value of `yes'.
>Synopsis: refclock_palisade.c collects data from the GPS in
>microseconds, rather than nanoseconds.
>Arrival-Date: Sun Mar 13 04:57:00 +0000 2005
>Originator: Brian Buhrow
>Release: NetBSD 2.0 and later
System: NetBSD 2.0 NetBSD 2.0 (NFBNETBSD) #0: Tue Jan 4 10:03:02 PST 2005
[email protected]:/usr/src/sys/arch/i386/compile/NFBNETBSD i386
While trying to setup our stratum 1 time server under NetBSD-2.0 using
a Trimble GPS time receiver, I found that I could not get accurate time
readings from the GPS receiver even though it is reputed to be an extremely
accurate device. Searching to see if there were any known issues with the
Trimble Palisade receiver and NTP, I found the following data:
NTP: Bug 250 - Incorrect offset when using an Acutime 2000 / ntpd 4.2.0
Skip Navigation Links
Bugs Home | Documentation | New | Query | Reports | New Account |
Bugzilla Bug 250
Incorrect offset when using an Acutime 2000 / ntpd 4.2.0
Query page Enter new bug
Bug#: 250 Platform: [PC.......] Reporter:
[email protected] (Neil Burn)
Product: [ntp.............] OS: [Windows XP..] Add CC:
Component: [refclock - palisade..] Version: [4.2.0......] CC:
[_] [email protected]
[_] Remove selected CCs
Status: VERIFIED Priority: [P3]
Resolution: FIXED Severity: [normal.....]
Assigned To: [email protected] (Harlan Stenn) Target Milestone: [4.2.1]
Attachment Type Modified Status Actions
Create a New Attachment (proposed patch, testcase, etc.) View All
Bug 250 depends on: ____________________ Show dependency tree
Show dependency graph
Bug 250 blocks: ____________________
Using an Acutime 2000 connected to a Windows XP PC running ntp 4.2.0. "ntpq -
c pe" reports that the offset tends to zero (as expected) but monitoring the
offset between the PC and the acutime using an oscilloscope shows that the
offset is anything up to a few hundred milliseconds out. Running "ntpd -q -d"
repeatedly causes the clock to be stepped by a few hundred milliseconds every
time (rather than a step the first time followed by slews).
The problem seems to be caused by changes that have been made to
the "refclock_palisade.c" file between versions 4.1.1 and
4.2.0. Specifically there has been a change to use nsecs instead of
usecs and line 497 of the new version does not take this into account.
To fix this I made the following change to "refclock_palisade.c":
497 <! pp->nsec = (long) (getdbl((u_char *) &mb(3)) * 1000000);
497 !> pp->nsec = (long) (getdbl((u_char *) &mb(3)) * 1000000000);
With this patch the offset as reported by ntpq -c pe and the oscilloscope both
tend to zero.
------- Additional Comment #1 From Harlan Stenn 2003-11-25 09:32
I've applied your patch to the bk repos.
Please mark this bug as VERIFIED or REOPENED, as appropriate.
(_) Leave as VERIFIED FIXED
(_) Reopen bug
(_) Mark bug as CLOSED
View Bug Activity | Format For Printing
Description: Opened: 2003-11-24 10:17
Query page Enter new bug
Enter a report # or some search terms:
____________________ Show [Help]
This is Bugzilla: the Mozilla bug system. For more information about
Bugzilla see bugzilla.org.
New Account | Log In
To repeat this problem, install a stock NetBSD 2.0 system, or
NetBSD-current as of March 12 2005 or until this problem is resolved and
configure a Palisade GPS receiver on your system as follows:
ln -s /dev/tty00 /dev/palisade0
statsdir /var/ntpstats/ # directory for statistics files
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
server 127.127.29.0 prefer
#fudge 127.127.29.0 time1 0.020
Enable ntpd in /etc/rc.conf and start ntpd.
Watch the time jump all over the place, and watch the ntpd daemon jump from
server to server, trying to synchronize the clock.
To fix, import the new version of ntp when it is released. in the mean
time, the following patch works excellently on our stratum 1 server.
RCS file: /cvsroot/src/dist/ntp/ntpd/refclock_palisade.c,v
retrieving revision 1.2
diff -u -r1.2 refclock_palisade.c
--- refclock_palisade.c 4 Dec 2003 16:23:37 -0000 1.2
+++ refclock_palisade.c 13 Mar 2005 04:36:25 -0000
@@ -496,7 +496,7 @@
- pp->nsec = (long) (getdbl((u_char *) &mb(3)) * 1000000);
+ pp->nsec = (long) (getdbl((u_char *) &mb(3)) * 1000000000);
if ((pp->day = day_of_year(&mb(14))) < 0)