Initializing clock with gpsd & ntpd

[David Severt]

I have an embedded data gathering application that requires valid time
information to go with the data, so I am trying to use gpsd along with
ntpd to maintain the clock.  The real-time clock in this device will not
survive an extended power outage and, since it is headless, there can be
no user interaction to restore the system clock.  I can use ntpd to
initialize the clock via an ntp server (ntpd -Agq) and the ntpd/gpsd
combination will work to maintain the clock.  However, if I don't have
access to an ntp server because the network is unavailable, I can't get
ntpd to initialize the clock using time information from gpsd.  It looks
like the gpsd time information will only be used to slew the clock,
rather than step the clock, which is what needs to happen when the date
is Jan 1, 1970.  If the system time is Jan 1, 1970, is there a way to
get ntpd to initialize the clock using only gpsd data, or will I need to
write an application to get time information from gpsd to initialize the
clock before starting ntpd?  Once the clock is initialized, ntpd works
fine with only gpsd for time information but first I have to get it
initialized somehow.

I realize that this might be a question for the ntp mailing list but I
thought I'd try here first.

Regards,
David Severt
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Don Weeks]

I will have this problem as well. My plan is to use the GPS date/time from
gpsd to set the date and time. Then, I will start ntpd.
       Don

On Thu, Sep 24, 2009 at 6:00 PM, David Severt <severtd@...>wrote:

> I have an embedded data gathering application that requires valid time
> information to go with the data, so I am trying to use gpsd along with
> ntpd to maintain the clock.  The real-time clock in this device will not
> survive an extended power outage and, since it is headless, there can be
> no user interaction to restore the system clock.  I can use ntpd to
> initialize the clock via an ntp server (ntpd -Agq) and the ntpd/gpsd
> combination will work to maintain the clock.  However, if I don't have
> access to an ntp server because the network is unavailable, I can't get
> ntpd to initialize the clock using time information from gpsd.  It looks
> like the gpsd time information will only be used to slew the clock,
> rather than step the clock, which is what needs to happen when the date
> is Jan 1, 1970.  If the system time is Jan 1, 1970, is there a way to
> get ntpd to initialize the clock using only gpsd data, or will I need to
> write an application to get time information from gpsd to initialize the
> clock before starting ntpd?  Once the clock is initialized, ntpd works
> fine with only gpsd for time information but first I have to get it
> initialized somehow.
>
> I realize that this might be a question for the ntp mailing list but I
> thought I'd try here first.
>
> Regards,
> David Severt
> _______________________________________________
> Gpsd-users mailing list
> Gpsd-users@...
> https://lists.berlios.de/mailman/listinfo/gpsd-users
>

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

David Severt wrote:

> I have an embedded data gathering application that requires valid time
> information to go with the data, so I am trying to use gpsd along with
> ntpd to maintain the clock.  The real-time clock in this device will not
> survive an extended power outage and, since it is headless, there can be
> no user interaction to restore the system clock.  I can use ntpd to
> initialize the clock via an ntp server (ntpd -Agq) and the ntpd/gpsd
> combination will work to maintain the clock.  However, if I don't have
> access to an ntp server because the network is unavailable, I can't get
> ntpd to initialize the clock using time information from gpsd.  It looks
> like the gpsd time information will only be used to slew the clock,
> rather than step the clock, which is what needs to happen when the date
> is Jan 1, 1970.  If the system time is Jan 1, 1970, is there a way to
> get ntpd to initialize the clock using only gpsd data, or will I need to
> write an application to get time information from gpsd to initialize the
> clock before starting ntpd?  Once the clock is initialized, ntpd works
> fine with only gpsd for time information but first I have to get it
> initialized somehow.
>  

Try "chrony" - it's a rather neat ntp implementation which has given a
lot of thought to this kind of situation.  If you check the mailing list
there is a chap who has posted patches which can take the gpsd output
directly into chrony (there are some other patches which can use ntp as
an intermediary, but I don't think you want this)

Chrony can be configured to step when the time change is large.  Also it
can be used to do clever things like combine a gps + upstream ntp.  It
appears to converge VERY much faster than ntp (mins/secs instead of
hours) and it even has a bunch of features to condition your RTC clock
if this is useful

If you have control over the hardware you could also consider replacing
whatever supercap is there for a lithium cell so that your RTC works for
longer?  Chrony is still useful in that it uses the RTC much more
intelligently

Good luck

Ed W
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[David Severt]

Ed W wrote:

> David Severt wrote:
>> I have an embedded data gathering application that requires valid
>> time information to go with the data, so I am trying to use gpsd
>> along with ntpd to maintain the clock.  The real-time clock in this
>> device will not survive an extended power outage and, since it is
>> headless, there can be no user interaction to restore the system
>> clock.  I can use ntpd to initialize the clock via an ntp server
>> (ntpd -Agq) and the ntpd/gpsd combination will work to maintain the
>> clock.  However, if I don't have access to an ntp server because the
>> network is unavailable, I can't get ntpd to initialize the clock
>> using time information from gpsd.  It looks like the gpsd time
>> information will only be used to slew the clock, rather than step the
>> clock, which is what needs to happen when the date is Jan 1, 1970.  
>> If the system time is Jan 1, 1970, is there a way to get ntpd to
>> initialize the clock using only gpsd data, or will I need to write an
>> application to get time information from gpsd to initialize the clock
>> before starting ntpd?  Once the clock is initialized, ntpd works fine
>> with only gpsd for time information but first I have to get it
>> initialized somehow.
>>  
>
> Try "chrony" - it's a rather neat ntp implementation which has given a
> lot of thought to this kind of situation.  If you check the mailing
> list there is a chap who has posted patches which can take the gpsd
> output directly into chrony (there are some other patches which can
> use ntp as an intermediary, but I don't think you want this)
>
> Chrony can be configured to step when the time change is large.  Also
> it can be used to do clever things like combine a gps + upstream ntp.  
> It appears to converge VERY much faster than ntp (mins/secs instead of
> hours) and it even has a bunch of features to condition your RTC clock
> if this is useful
>
> If you have control over the hardware you could also consider
> replacing whatever supercap is there for a lithium cell so that your
> RTC works for longer?  Chrony is still useful in that it uses the RTC
> much more intelligently
>
> Good luck
>
> Ed W
>

Ed;

Thanks for the tip, I'll definitely look into it.  I saw an issue today
that bothered me as well.  Last night, I shut down the Linux box that
was acting as a gateway for my embedded test box and I had already
killed gpsd.  This morning, I started up the gateway, started up gpsd
and ntpd was still running.  But even though ntpd was able to contact
the servers, it decided to reject both my ntp server and gpsd as "false
tickers" since the clock had drifted almost 30 seconds away from the
reference clocks during the time the network and gpsd were unavailable.  
So ntpd decided to use "LOCAL(0)" as it's preferred clock even though it
was way off and the servers were actually correct.  Maybe if I let it
run long enough, it would eventually start believing the time servers
but I wasn't patient enough to just let it run, so I just killed it and
restarted with "-g" to step the clock.  Does ntpd ignore a server
forever if it's been flagged as a "false ticker" or would it eventually
start using ntp/gpsd server time instead of LOCAL(0)?

A lithium cell would be very nice.  Unfortunately, the hardware group
"wins" this argument every time and I'm stuck with a super-cap, mostly
due to lifetime and accessibility issues.  New hardware and we're
designing-in the same problems as the old hardware.  Sigh....

David
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

David Severt wrote:

>
> Thanks for the tip, I'll definitely look into it.  I saw an issue
> today that bothered me as well.  Last night, I shut down the Linux box
> that was acting as a gateway for my embedded test box and I had
> already killed gpsd.  This morning, I started up the gateway, started
> up gpsd and ntpd was still running.  But even though ntpd was able to
> contact the servers, it decided to reject both my ntp server and gpsd
> as "false tickers" since the clock had drifted almost 30 seconds away
> from the reference clocks during the time the network and gpsd were
> unavailable.  So ntpd decided to use "LOCAL(0)" as it's preferred
> clock even though it was way off and the servers were actually
> correct.  Maybe if I let it run long enough, it would eventually start
> believing the time servers but I wasn't patient enough to just let it
> run, so I just killed it and restarted with "-g" to step the clock.  
> Does ntpd ignore a server forever if it's been flagged as a "false
> ticker" or would it eventually start using ntp/gpsd server time
> instead of LOCAL(0)?

I'm not an expert on ntp, but I think I believe it's default is to
remain out of step, hence the desire to run ntp-client on boot if you
need to step the clock?

Give chrony a go, it's got a lot more features to help with this...

> A lithium cell would be very nice.  Unfortunately, the hardware group
> "wins" this argument every time and I'm stuck with a super-cap, mostly
> due to lifetime and accessibility issues.  New hardware and we're
> designing-in the same problems as the old hardware.  Sigh....

Given the lifetimes are usually good for a lithium cell this would imply
that you have long expected service times for these units?  Curious...

I guess cost is a concern, but I would assume a supercap is more
expensive than a lithium cell?  Could you increase service intervals by
doubling up on cells?  Is a combo of both within budget?


I think chrony will likely sort you out anyway.  Give it a try!

Ed W
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Jason Curl-4]

David Severt wrote:

> I have an embedded data gathering application that requires valid time
> information to go with the data, so I am trying to use gpsd along with
> ntpd to maintain the clock.  The real-time clock in this device will not
> survive an extended power outage and, since it is headless, there can be
> no user interaction to restore the system clock.  I can use ntpd to
> initialize the clock via an ntp server (ntpd -Agq) and the ntpd/gpsd
> combination will work to maintain the clock.  However, if I don't have
> access to an ntp server because the network is unavailable, I can't get
> ntpd to initialize the clock using time information from gpsd.  It looks
> like the gpsd time information will only be used to slew the clock,
> rather than step the clock, which is what needs to happen when the date
> is Jan 1, 1970.  If the system time is Jan 1, 1970, is there a way to
> get ntpd to initialize the clock using only gpsd data, or will I need to
> write an application to get time information from gpsd to initialize the
> clock before starting ntpd?  Once the clock is initialized, ntpd works
> fine with only gpsd for time information but first I have to get it
> initialized somehow.
>
> I realize that this might be a question for the ntp mailing list but I
> thought I'd try here first.
>  

The page "http://tldp.org/LDP/sag/html/basic-ntp-config.html" describes
the rationale behind NTP for doing this. Does the option "iburst" not
work? Looking here "http://www.ece.udel.edu/~mills/ntp/html/ntpd.html":
"Operating Modes

The ntpd program normally operates continuously while adjusting the time
and frequency, but in some cases it may not be practical to run it
continuously. With the -q option ntpd operates as in continous mode, but
exits just after setting the clock for the first time. Most applications
will probably want to specify the iburst option with the server command.
With this option a volley of messages is exchanged to groom the data and
set the clock in about 10 s. If nothing is heard after a few minutes,
the daemon times out and exits."

But maybe this is still not fast enough.

With that said, I had NTP and GPSD working together a long time ago but
I don't remember starting without an Internet connection. I discontinued
because I didn't have a 1PPS signal for better synchronisation.

Also, while it's rare, it's happened a few times in our embedded
products, we've had epoch jumps until a restart of the GPS. I don't know
if GPSD can handle this or just passes it on, or if one can set the
expected epoch. But I'd certainly vouch for a persistent RTC in anycase.

> Regards,
> David Severt
> _______________________________________________
> Gpsd-users mailing list
> Gpsd-users@...
> https://lists.berlios.de/mailman/listinfo/gpsd-users
>
>  

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[David Severt]

Jason Curl wrote:

> David Severt wrote:
>> I have an embedded data gathering application that requires valid
>> time information to go with the data, so I am trying to use gpsd
>> along with ntpd to maintain the clock.  The real-time clock in this
>> device will not survive an extended power outage and, since it is
>> headless, there can be no user interaction to restore the system
>> clock.  I can use ntpd to initialize the clock via an ntp server
>> (ntpd -Agq) and the ntpd/gpsd combination will work to maintain the
>> clock.  However, if I don't have access to an ntp server because the
>> network is unavailable, I can't get ntpd to initialize the clock
>> using time information from gpsd.  It looks like the gpsd time
>> information will only be used to slew the clock, rather than step the
>> clock, which is what needs to happen when the date is Jan 1, 1970.  
>> If the system time is Jan 1, 1970, is there a way to get ntpd to
>> initialize the clock using only gpsd data, or will I need to write an
>> application to get time information from gpsd to initialize the clock
>> before starting ntpd?  Once the clock is initialized, ntpd works fine
>> with only gpsd for time information but first I have to get it
>> initialized somehow.
>>
>> I realize that this might be a question for the ntp mailing list but
>> I thought I'd try here first.
>>  
> The page "http://tldp.org/LDP/sag/html/basic-ntp-config.html"
> describes the rationale behind NTP for doing this. Does the option
> "iburst" not work? Looking here
> "http://www.ece.udel.edu/~mills/ntp/html/ntpd.html":
> "Operating Modes
>
> The ntpd program normally operates continuously while adjusting the
> time and frequency, but in some cases it may not be practical to run
> it continuously. With the -q option ntpd operates as in continous
> mode, but exits just after setting the clock for the first time. Most
> applications will probably want to specify the iburst option with the
> server command. With this option a volley of messages is exchanged to
> groom the data and set the clock in about 10 s. If nothing is heard
> after a few minutes, the daemon times out and exits."
>

The iburst option does fine to sync with ntp servers when first starting
ntpd with a network connection.  But iburst doesn't have an effect on
the psuedo-servers defined for the gpsd interface.

> But maybe this is still not fast enough.
>
> With that said, I had NTP and GPSD working together a long time ago
> but I don't remember starting without an Internet connection. I
> discontinued because I didn't have a 1PPS signal for better
> synchronisation.
>
> Also, while it's rare, it's happened a few times in our embedded
> products, we've had epoch jumps until a restart of the GPS. I don't
> know if GPSD can handle this or just passes it on, or if one can set
> the expected epoch. But I'd certainly vouch for a persistent RTC in
> anycase.
>
>> Regards,
>> David Severt
>> _______________________________________________
>> Gpsd-users mailing list
>> Gpsd-users@...
>> https://lists.berlios.de/mailman/listinfo/gpsd-users
>>
>>  
>
>

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[David Severt]

The "chrony" project pages seem to have disappeared off the face of the
earth.  I can find sources but "chrony.sunsite.dk" comes up with a
"Project hosting terminated" message and most chrony links that I can
find take me there.  Does anyone know if this project is being maintained?

David

Ed W wrote:

> David Severt wrote:
>> I have an embedded data gathering application that requires valid
>> time information to go with the data, so I am trying to use gpsd
>> along with ntpd to maintain the clock.  The real-time clock in this
>> device will not survive an extended power outage and, since it is
>> headless, there can be no user interaction to restore the system
>> clock.  I can use ntpd to initialize the clock via an ntp server
>> (ntpd -Agq) and the ntpd/gpsd combination will work to maintain the
>> clock.  However, if I don't have access to an ntp server because the
>> network is unavailable, I can't get ntpd to initialize the clock
>> using time information from gpsd.  It looks like the gpsd time
>> information will only be used to slew the clock, rather than step the
>> clock, which is what needs to happen when the date is Jan 1, 1970.  
>> If the system time is Jan 1, 1970, is there a way to get ntpd to
>> initialize the clock using only gpsd data, or will I need to write an
>> application to get time information from gpsd to initialize the clock
>> before starting ntpd?  Once the clock is initialized, ntpd works fine
>> with only gpsd for time information but first I have to get it
>> initialized somehow.
>>  
>
> Try "chrony" - it's a rather neat ntp implementation which has given a
> lot of thought to this kind of situation.  If you check the mailing
> list there is a chap who has posted patches which can take the gpsd
> output directly into chrony (there are some other patches which can
> use ntp as an intermediary, but I don't think you want this)
>
> Chrony can be configured to step when the time change is large.  Also
> it can be used to do clever things like combine a gps + upstream ntp.  
> It appears to converge VERY much faster than ntp (mins/secs instead of
> hours) and it even has a bunch of features to condition your RTC clock
> if this is useful
>
> If you have control over the hardware you could also consider
> replacing whatever supercap is there for a lithium cell so that your
> RTC works for longer?  Chrony is still useful in that it uses the RTC
> much more intelligently
>
> Good luck
>
> Ed W
>

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

David Severt wrote:
> The "chrony" project pages seem to have disappeared off the face of
> the earth.  I can find sources but "chrony.sunsite.dk" comes up with a
> "Project hosting terminated" message and most chrony links that I can
> find take me there.  Does anyone know if this project is being
> maintained?

I believe it's kind of in maintenance mode, but the message on that site
suggests that it's more like it's SunSITE which has pulled the rug from
under them...

I dropped a note to the mailing list in case someone wasn't actually
looking, but I hope it will get re-instated promptly somewhere else...

Either way the code is very solid.

I would suggest you might want to just jump straight for the git repo here:
http://fedorapeople.org/~mlichvar/chrony/

This chap seems to pretty much have taken over recent development on his
own branch and in particular it has the ability to talk directly to gpsd
and take an accurate clock input.

Certainly the site was up only weeks ago when I last looked, so this
seems pretty sudden...

Ed
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[hamish_b]

Ed wrote:
> Certainly the site was up only weeks ago when I last
> looked, so this seems pretty sudden...


try the wayback-machine at archive.org



H



     
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users