I hear ntpdate has been deprecated long time and obsoleted in new releases.
On Jun 20, 2013 2:16 PM, "Harald Welte" <
address@hidden> wrote:
Hi all,
recently I discovered what I considered a severe shortcoming in the
combination of using gpsd + ntp[d] on embedded systems without RTC:
While ntpd is very happy to use a local gpsd as source, 'ntpdate'
exclusively works with NTP-based time servers.
This means, during system boot, with no half-way valid clock at all,
ntpd will receive the time from gpsd, but will refuse to adjust the
clock by years in difference. On the other hand, ntpdate will not even
work with the shared memory gps driver, i.e. the time will never be set
correctly, and ntpd will never get into a state where it can do
fine-grained syncing against GPS.
To resolve the problem, I wrote a small tool called 'gpsdate', which can
be used as 'ntpdate' replacement in boot scripts: It connects to GPSD,
waits until a valid time has been received, and then uses settimeofday()
to set the local clock. After that, it terminates and leaves future
fine-grained synchronization to ntpd.
The tool can be found in its git repository at "git clone
git://git.sysmocom.de/gpsdate.git". I've attached the only source code
file for your convenience to this message
I would appreciate if it could become part of either the gpsd or ntpd
source trees. Releasing it under the license of the respective original
software project (instead of GPLv2+) is no problem at all.
First I'd like to get review from the ntpd and gpsd maintainers if any
of the two (and if so: who!) would want to merge it. My personal bias
is towards gpsd, as it depends on libgps and has no NTP dependencies.
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)