gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] gpsdate program, similar to 'ntpdate'


From: C.J. Adams-Collier
Subject: Re: [gpsd-dev] gpsdate program, similar to 'ntpdate'
Date: Fri, 21 Jun 2013 09:39:04 -0700

Hi there Harald,

I have no further objections.  It sounds like a bug in ntpd is keeping this common use case from working as I would expect.  I would think that it should be possible to resolve this issue, but that having a tool such as gpsdate available, which has no further external dependencies would scratch an itch that many users either currently have or will in the future realize that they need scratched.

Now to find someone with sufficient spare time to review and accept into the tree :-)

C.J.

On Jun 21, 2013 6:16 AM, "Harald Welte" <address@hidden> wrote:
Hi C.J.,

On Thu, Jun 20, 2013 at 03:56:00PM -0700, C.J. Adams-Collier wrote:
> I hear ntpdate has been deprecated long time and obsoleted in new releases.
>
> Try ntpd -q

I have tried this long ago, and would be happy if things would have been
that simple.

ntp_refclock:refclock_process_f() calls libntp:clocktime() and the
latter aboslutely cannot deal with the fact if e.g. your embedded
system without RTC boots up assuming it is January 1st 1970 and a GPS
reference time in the year 2013 has been received.

I looked into fixing the ntpd/libntp code some months ago, but gave up
as it seems to be written on the assumption that there simply are not 43
years of difference between two timestamps.

Having said that, I'm clearly not a ntpd expert and happy to try
whatever method people suggest here.  But after lots of debugging and
ntp source code reading I arrived at the conclusion that it is not
possible using the existing code, which prompted the implementation of
gpsdate.

Regards,
        Harald

--
- Harald Welte <address@hidden>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]