[ntp:questions] NTPd in embedded application slow to serve/sync time.

Martin Burnicki martin.burnicki at meinberg.de
Fri Aug 17 07:27:30 UTC 2018

Ben wrote:
> Hey all,
>  Quick question:
> I have NTP running on 2 embedded systems.
> One of them has a garmin GPS18 via ttyUSBn port (linked to /dev/gps0)
> and works great...  have "minpoll" set to 3 for fast poll time.

How long does it take after power-up until the GPS receiver claims to be
synchronized? As long as it isn't, ntpd will not accept the time from it.

Does the GPS receiver save some satellite information across power cycling?

If it doesn't, the UTC correction information may be lost after a power
cycle and it may take up to 12 minutes until the information is sent
next time by the satellites.

We have had reports here where a receiver claimed to be synchronized
even if no UTC correction parameters were available. This lets ntpd set
the system time first to raw GPS time, which is off UTC by a couple of
seconds. Then, when the UTC parameters are next time sent by the
satellites, the time from the GPS receiver steps by that number of
seconds, but ntpd accepts such steps only after ~15 minutes by default.

This may confuse clients of that server.

> The other system is set to use this first unit as its time source -- but
> seems to not get the right time. the system startup script includes a
> 3min start delay so when both units are powered up (simultaneously), the
> NTP client asks for time 3 minutes AFTER the NTP server is up and
> running. (via ntpdate)
> By the time the client asks the server, the server's local clock is set,
> but
>         ntpq -c clockvar
>         ntptime
> in a script both show that "ERROR 5" basically telling me (without
> digging further) the server clock isn't fully happy yet... (eventually,
> they sync up and go "OK")
> Anything else I can do to speed up the server to being happy about
> giving out time?

Which version of ntpd are you running on the server? In some cases ntpd
first starts *measuring* the clock frequency after power-up before it
claims to be synchronized. In this case a drift file on the server *may*
help, if it can be saved persistently across power cycles.

Please post the output of "ntpq -p -c rv" from the server, so we can see
in which state the server is shortly after power-up.

Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

More information about the questions mailing list