ntp & system without a rtc

[folkert]

Hi,

I have a raspberry pi system. This is a computer without a real time
clock. So everytime I power it on, it uses starts where it left off
which might be days earlier. It is connected only very occasionally to
the internet so syncing to that won't work. It does have, however, a gps
connected. But as it is switched mostly for less than an hour, ntpd
won't have the time to adjust the time to what the gps returns to it.
So I was wondering: is there a utility/a trick out there that picks the
current time from a gps and then "jumps" the time to what it should be?
It does not need to be very accurate - a couple of seconds off is ok
(just not hours or days).

Any ideas?


Regards,

Folkert van Heusden

--
Winnen in de staatsloterij? Check htp://vanheusden.com/sl.php voor
alle staatsloterij-uitslag statistieken denkbaar en zelfs ook een paar
win-tips!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

[Rob]

folkert <fol...@vanheusden.com> wrote:
> Hi,
>
> I have a raspberry pi system. This is a computer without a real time
> clock. So everytime I power it on, it uses starts where it left off
> which might be days earlier. It is connected only very occasionally to
> the internet so syncing to that won't work. It does have, however, a gps
> connected. But as it is switched mostly for less than an hour, ntpd
> won't have the time to adjust the time to what the gps returns to it.
> So I was wondering: is there a utility/a trick out there that picks the
> current time from a gps and then "jumps" the time to what it should be?
> It does not need to be very accurate - a couple of seconds off is ok
> (just not hours or days).
>
> Any ideas?

How do you access the GPS receiver? Via gpsd?

[folkert]

Via gpsd indeed. But it that is a problem I can do other things first
before I start gpsd.


Folkert van Heusden

--
MultiTail är ett flexibel redskap för att följa en eller flera logfiler, utföra
kommandon, filtrera, färglägga, sammanfoga, o.s.v...

[Steve Kostecke]

On 2013-05-10, folkert <fol...@vanheusden.com> wrote:
> Hi,
>
> I have a raspberry pi system. This is a computer without a real time
> clock. So everytime I power it on, it uses starts where it left off
> which might be days earlier. It is connected only very occasionally to
> the internet so syncing to that won't work. It does have, however, a gps
> connected. But as it is switched mostly for less than an hour, ntpd
> won't have the time to adjust the time to what the gps returns to it.

Why not use somthing like this:

http://www.adafruit.com/products/255

ChronoDot - Ultra-precise Real Time Clock - v2.1

The ChronoDot RTC is an extremely accurate real time clock module, based
on the DS3231 temperature compensated RTC (TCXO). It includes a CR2016
battery (not shown, but included in the product) which should last at
least 8 years if the I2C interface is only used while the device has 5V
power available. No external crystal or tuning capacitors are required.


--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/

[Rob]

folkert <fol...@vanheusden.com> wrote:
>> > I have a raspberry pi system. This is a computer without a real time
>> > clock. So everytime I power it on, it uses starts where it left off
>> > which might be days earlier. It is connected only very occasionally to
>> > the internet so syncing to that won't work. It does have, however, a gps
>> > connected. But as it is switched mostly for less than an hour, ntpd
>> > won't have the time to adjust the time to what the gps returns to it.
>> > So I was wondering: is there a utility/a trick out there that picks the
>> > current time from a gps and then "jumps" the time to what it should be?
>> > It does not need to be very accurate - a couple of seconds off is ok
>> > (just not hours or days).
>> >
>> > Any ideas?
>>
>> How do you access the GPS receiver? Via gpsd?
>
> Via gpsd indeed. But it that is a problem I can do other things first
> before I start gpsd.

No, with gpsd it is easier because you can connect the gpsd
port and ask it for the current time without having to worry
about parsing the gps data, sharing the serial port with other
applications, etc.

Just send a D command to gpsd, get and parse the reply and set the clock.

Maybe a program to do that is already available on the net.

[Richard B. Gilbert]

On 5/10/2013 10:36 AM, folkert wrote:
> Hi,
>
> I have a raspberry pi system. This is a computer without a real time
> clock. So everytime I power it on, it uses starts where it left off
> which might be days earlier. It is connected only very occasionally to
> the internet so syncing to that won't work. It does have, however, a gps
> connected. But as it is switched mostly for less than an hour, ntpd
> won't have the time to adjust the time to what the gps returns to it.
> So I was wondering: is there a utility/a trick out there that picks the
> current time from a gps and then "jumps" the time to what it should be?
> It does not need to be very accurate - a couple of seconds off is ok
> (just not hours or days).
>
> Any ideas?
>
>
> Regards,
>
> Folkert van Heusden
>

I think you may be out of luck on this one. If you can run NTPD 24x7
you can have the correct time 24x7. If you can't do this, NTPD is a
poor choice. The problem is that NTPD needs something like ten hours to
select a time source and match the time!

There is another "product" called "chrony" that has MUCH faster
convergence. I't never used chrony and can't tell you much about it.

I run 24x7 and seldom have to shut down and restart.

[unruh]

On 2013-05-10, folkert <fol...@vanheusden.com> wrote:

>> > I have a raspberry pi system. This is a computer without a real time
>> > clock. So everytime I power it on, it uses starts where it left off
>> > which might be days earlier. It is connected only very occasionally to
>> > the internet so syncing to that won't work. It does have, however, a gps
>> > connected. But as it is switched mostly for less than an hour, ntpd
>> > won't have the time to adjust the time to what the gps returns to it.
>> > So I was wondering: is there a utility/a trick out there that picks the
>> > current time from a gps and then "jumps" the time to what it should be?
>> > It does not need to be very accurate - a couple of seconds off is ok
>> > (just not hours or days).
>> >
>> > Any ideas?
>>
>> How do you access the GPS receiver? Via gpsd?
>
> Via gpsd indeed. But it that is a problem I can do other things first
> before I start gpsd.

The grammer is fractured. Why not startup gspd right at bootup from the
bootup scripts.


>
>
> Folkert van Heusden
>

[Gabs Ricalde]

If ntp.conf is setup correctly, running ntpd -q -g does the trick

On Fri, May 10, 2013 at 10:36 PM, folkert <fol...@vanheusden.com> wrote:
> Hi,

>
> I have a raspberry pi system. This is a computer without a real time
> clock. So everytime I power it on, it uses starts where it left off
> which might be days earlier. It is connected only very occasionally to
> the internet so syncing to that won't work. It does have, however, a gps
> connected. But as it is switched mostly for less than an hour, ntpd
> won't have the time to adjust the time to what the gps returns to it.
> So I was wondering: is there a utility/a trick out there that picks the
> current time from a gps and then "jumps" the time to what it should be?
> It does not need to be very accurate - a couple of seconds off is ok
> (just not hours or days).
>
> Any ideas?
>
>

> Regards,
>
> Folkert van Heusden
>
> --
> Winnen in de staatsloterij? Check htp://vanheusden.com/sl.php voor
> alle staatsloterij-uitslag statistieken denkbaar en zelfs ook een paar
> win-tips!

> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

[Gabs Ricalde]

On Sat, May 11, 2013 at 2:48 AM, Richard B. Gilbert
<rgilb...@comcast.net> wrote:

> On 5/10/2013 10:36 AM, folkert wrote:
>>
>> Hi,
>>
>> I have a raspberry pi system. This is a computer without a real time
>> clock. So everytime I power it on, it uses starts where it left off
>> which might be days earlier. It is connected only very occasionally to
>> the internet so syncing to that won't work. It does have, however, a gps
>> connected. But as it is switched mostly for less than an hour, ntpd
>> won't have the time to adjust the time to what the gps returns to it.
>> So I was wondering: is there a utility/a trick out there that picks the
>> current time from a gps and then "jumps" the time to what it should be?
>> It does not need to be very accurate - a couple of seconds off is ok
>> (just not hours or days).
>>
>> Any ideas?
>>
>>
>> Regards,
>>
>> Folkert van Heusden
>>
>

> I think you may be out of luck on this one. If you can run NTPD 24x7
> you can have the correct time 24x7. If you can't do this, NTPD is a poor
> choice. The problem is that NTPD needs something like ten hours to select a
> time source and match the time!
>
> There is another "product" called "chrony" that has MUCH faster convergence.
> I't never used chrony and can't tell you much about it.
>
> I run 24x7 and seldom have to shut down and restart.
>

chrony's convergence is really fast: about a few minutes for a PPS
refclock. If you want to run ntpd after, copy the kernel's frequency
from ntptime into ntpd's drift file, kill chrony then start ntpd. No
need to wait for minutes/hours for ntpd to converge.

[Rick Jones]

Richard B. Gilbert <rgilb...@comcast.net> wrote:

> I think you may be out of luck on this one. If you can run NTPD 24x7
> you can have the correct time 24x7. If you can't do this, NTPD is a
> poor choice. The problem is that NTPD needs something like ten hours to
> select a time source and match the time!

NTPD is no speed daemon, and perhaps it is a subjective thing, or a
mis-interpreation on my part, but I notice NTPD declaring sync rather
sooner than 10 hours. Rather sooner than one hour even (looking at
ntpq -p output). Now, it may indeed take it a long time to get the
offset (term?) down to some acceptable level, but that depends on
one's definition of acceptable and the initial distance no?

rick jones
--
I don't interest myself in "why." I think more often in terms of
"when," sometimes "where;" always "how much." - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[E-Mail Sent to this address will be added to the BlackLists]

folkert wrote:
> I have a raspberry pi system.
> This is a computer without a real time clock.

The uC likely has a RTC, its just not battery backed up?

> So everytime I power it on, it uses starts where it left
> off which might be days earlier.
> It is connected only very occasionally to the internet
> so syncing to that won't work.
> It does have, however, a gps connected.
> But as it is switched mostly for less than an hour,
> ntpd won't have the time to adjust the time to what
> the gps returns to it.
> So I was wondering: is there a utility/a trick out there
> that picks the current time from a gps and then "jumps"
> the time to what it should be?
> It does not need to be very accurate - a couple of seconds
> off is ok (just not hours or days).
>
> Any ideas?

nptd -g -q ?


--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.

[John Hasler]

E-Mail writes:
> The uC likely has a RTC, its just not battery backed up?

The Raspberry Pi has no rtc. There is no point in having one without a
battery.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[unruh]

On 2013-05-10, Rick Jones <rick....@hp.com> wrote:
> Richard B. Gilbert <rgilb...@comcast.net> wrote:
>> I think you may be out of luck on this one. If you can run NTPD 24x7
>> you can have the correct time 24x7. If you can't do this, NTPD is a
>> poor choice. The problem is that NTPD needs something like ten hours to
>> select a time source and match the time!
>
> NTPD is no speed daemon, and perhaps it is a subjective thing, or a
> mis-interpreation on my part, but I notice NTPD declaring sync rather
> sooner than 10 hours. Rather sooner than one hour even (looking at
> ntpq -p output). Now, it may indeed take it a long time to get the
> offset (term?) down to some acceptable level, but that depends on
> one's definition of acceptable and the initial distance no?

Yes. The 10 hours is for achieving the ultimate accuracy of a few
microseconds offset. It has a halving time of a bit under an hour (lets
say 45 min) . Ie,
after 45 min, the size of the offsets is about 1/2 of what it
was before. Because of stepping it has an error of about 100ms to start
out.
If you are happy with few millisecond precision, it will only take an hour
or two.

So if you start it out with the -g it will figure out is is way out
after a few seconds, and step. But the rate in general will still be
out, so it will rapidly drift away and ntpd will slowly bring the drift
into order.

Thus to get from hours out to hundreds of milliseconds out should occur
very quickly.
>
> rick jones

[E-Mail Sent to this address will be added to the BlackLists]

John Hasler wrote:
> E-Mail writes:
>> The uC likely has a RTC, its just not battery backed up?
>
> The Raspberry Pi has no rtc.

Raspberry Pi has a Broadcom BCM2835 SoC (700 MHz ARM11 ARM1176JZF-S)
Broadcom seems to want to hold their full datasheet from public view.
Perhaps it doesn't have an internal RTC peripheral.


Many ARM SoCs have an internal RTC peripheral.
If the product manufacturer doesn't supply an easy
way to connect a battery on their PCB,
the RTC is still in the chip.

> There is no point in having one without a battery.

Or a "SuperCap", depending how long it is typically off.

Just like e.g. the PPS input on a Pi,
if the chip package has a RTC, and the pin/trace is
accessible, you could hook up a Batt/CAP.

... or e.g. hook up a RTC chip on the I2C, ...

I noticed someone make a RTC with batt for the Pi
<http://www.hobbytronics.co.uk/raspberry-pi-real-time-clock>

Likely several others do too, {Seems so}.
<http://www.instructables.com/id/How-to-add-a-Real-time-clock-to-the-Raspberry-Pi-o/>
<https://www.modmypi.com/rasclock-raspberry-pi-real-time-clock-module>
<http://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/overview>

[unruh]

On 2013-05-11, E-Mail Sent to this address will be added to the BlackLists <Nu...@BlackList.Anitech-Systems.invalid> wrote:
> John Hasler wrote:
>> E-Mail writes:
>>> The uC likely has a RTC, its just not battery backed up?
>>
>> The Raspberry Pi has no rtc.
>
> Raspberry Pi has a Broadcom BCM2835 SoC (700 MHz ARM11 ARM1176JZF-S)
> Broadcom seems to want to hold their full datasheet from public view.
> Perhaps it doesn't have an internal RTC peripheral.

The Raspberry Pi is an ultra low cost computer. the parts are kept to a
bare minimum. Even the ethernet is a usb->ethernet link. Sticking an rtc
on the thing would up the cost, a battery of supercapacitor would up the
cost, and to little purpose since many of the uses of the Rpi do not
need even inaccurate times.
As you point out others have made an rtc for it.
It is astonishing that one could have a full computer for $35.

[David Lord]

My pc with GPS was last restarted April 28 and involved three
reboots for a NetBSD update from 6.1_RC2 to 6.1_RC3. The pc
is in a south facing unheated bedroom.

Offset logs from "ntpq -crv -p" polling period 6 min:
20130427: -0.000000 - +0.000065 s
20130428: -0.000000 - +0.000897 s = +897 us
20130429: -0.000000 - +0.000043 s

loop_summary has:
rng(us) rms freq
20130427: 16 +/- 50 7.7 -36.07 +/- 0.492
20130428: -40410 +/- 64152 2929.6 -36.32 +/- 0.202
20130429: 6 +/- 36 4.9 -36.29 +/- 0.265

So would suggest if the requirements are within a few ms
and with an existing established driftfile in place that
ntpd might be ok.

If the system is not powered continuously I believe chrony
might be a better choice, although when I used chrony it was
for on-demand-dialup to "demon" and pcs were powered up 24/7.

David

[folkert]

> >> How do you access the GPS receiver? Via gpsd?
> >
> > Via gpsd indeed. But it that is a problem I can do other things first
> > before I start gpsd.
>
> No, with gpsd it is easier because you can connect the gpsd
> port and ask it for the current time without having to worry
> about parsing the gps data, sharing the serial port with other
> applications, etc.
>
> Just send a D command to gpsd, get and parse the reply and set the clock.

Yeah that's what I did in the end. Only 10 lines of code using libgpsd.

> Maybe a program to do that is already available on the net.

There's no fun in that :-)


Folkert van Heusden

--
www.TrustedTimestamping.com is a service that enables you to show that
at a certain point in time, you had access to a hash-value reflecting
the contents of a file (this file can be a word document, a jpeg
image, everything).

[Rob]

folkert <fol...@vanheusden.com> wrote:
>> >> How do you access the GPS receiver? Via gpsd?
>> >
>> > Via gpsd indeed. But it that is a problem I can do other things first
>> > before I start gpsd.
>>
>> No, with gpsd it is easier because you can connect the gpsd
>> port and ask it for the current time without having to worry
>> about parsing the gps data, sharing the serial port with other
>> applications, etc.
>>
>> Just send a D command to gpsd, get and parse the reply and set the clock.
>
> Yeah that's what I did in the end. Only 10 lines of code using libgpsd.

I forgot to mention libgpsd but fortunately you located it and did
not have to write the code to connect gpsd (although that is pretty
simple in many script languages).

There also is some testing code included with gpsd that parses the
reply but then does nothing useful with it. That might have been an
even easier starting point (only an stime call needs to be added).

Of course some error handling won't hurt, in case the GPS has no lock
yet.

[folkert]

> >> > Via gpsd indeed. But it that is a problem I can do other things first
> >> > before I start gpsd.
> >>
> >> No, with gpsd it is easier because you can connect the gpsd
> >> port and ask it for the current time without having to worry
> >> about parsing the gps data, sharing the serial port with other
> >> applications, etc.
> >>
> >> Just send a D command to gpsd, get and parse the reply and set the clock.
> >
> > Yeah that's what I did in the end. Only 10 lines of code using libgpsd.
>
> I forgot to mention libgpsd but fortunately you located it and did
> not have to write the code to connect gpsd (although that is pretty
> simple in many script languages).

Yes. The program came part of http://www.vanheusden.com/ows/ which is a
program to collect access points in the streets which can then be
uploaded to http://www.openwlanmap.org/?lang=en (which is a public
service for finding your location when all you have is wifi
functionality).

> There also is some testing code included with gpsd that parses the
> reply but then does nothing useful with it. That might have been an
> even easier starting point (only an stime call needs to be added).
> Of course some error handling won't hurt, in case the GPS has no lock
> yet.

Yes, I check if the fix mode >= 2 and status != NO_FIX. Works like a
charm.


Folkert van Heusden

--
Nagios user? Check out CoffeeSaint - the versatile Nagios status
viewer! http://www.vanheusden.com/java/CoffeeSaint/

[David Woolley]

folkert wrote:
> Yes. The program came part of http://www.vanheusden.com/ows/ which is a
> program to collect access points in the streets which can then be
> uploaded to http://www.openwlanmap.org/?lang=en (which is a public
> service for finding your location when all you have is wifi
> functionality).

Are you aware that Google got into trouble for collecting too much
information, when they did that.

[Richard B. Gilbert]

NTPD is NOT designed for fast convergence. From start up to get the
minutes correct, NTPD will need about thirty minutes! To get the best
time you are going to get, you will need to wait for about ten hours!

If fast convergence is your goal, you can use a a program called
CHRONY to achieve it.

If your goal is to know the time +/- 50 nanoseconds You are expected to
operate your clock twenty-four hours a day.

With a GPS Timing Receiver you can keep time +/- 50 nano-seconds.
Relatively few people NEED time with that sort of accuracy. Many
who DO need that accuracy use NTP and a Global Positioning Satellite
to get the accuracy required. A few of these people read this
newsgroup.

[David Woolley]

Richard B. Gilbert wrote:

>
> NTPD is NOT designed for fast convergence. From start up to get the
> minutes correct, NTPD will need about thirty minutes! To get the best
> time you are going to get, you will need to wait for about ten hours!
>

Convergence to within 128ms should take a lot less than that. With
iburst, I believe it should be less than one minute.

>
>

[Brian Utterback]

I just tried it on my system, I get sync in 12 seconds. Now, of course
getting the frequency correction right will take a lot longer, and it
may lose sync in the mean time if the frequency is far enough off.

> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

--
blu

Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.u...@oracle.com

[Rob]

Brian Utterback <brian.u...@oracle.com> wrote:
> I just tried it on my system, I get sync in 12 seconds. Now, of course
> getting the frequency correction right will take a lot longer, and it
> may lose sync in the mean time if the frequency is far enough off.

My experience with ntpd is when you are experimenting with the config
file and you stop and start it a few times, it will do bad things.

It will steer the time AWAY from correct, lose sync, jump back to a
somewhat correct time, and probably overshoot the other direction
until it finally locks in again after it is not touched for a longish
time.

This is inconvenient when you are experimenting with server settings,
authentication settings, etc.

[unruh]

The question is whether this is a bug or not. Mills has bluntly stated
that, no matterr how people complain, he has no interest in making ntpd
fast. I think he thinks that this is somhow related to the stability of
ntpd, but the evidence is obscure (eg see chrony which does converge
much much faster, but it uses memory -- it remembers past measurements--
to do so. I tried to suggest that perhaps ntpd could lern something from
chrony, but that was shot down, despite the fact that the evidence is
that not only is chrony faster by a lot, but is also more accurate by
factors of 3-20 being reported. Mills is wedded to his "engineering"
Markovian model of control, which he feels has been thorougly tested to
work (probably true) and that chrony's model (which is equally
"engineering") has not been as thorughly tested (which is probably also
true, and needs to be fixed). But the people using chrony do not report
problems with instability and it is hard to see ( but that could of
course be a comment on my imagination rather than on chrony) how it
could go unstable.

>
> If fast convergence is your goal, you can use a a program called
> CHRONY to achieve it.
>
> If your goal is to know the time +/- 50 nanoseconds You are expected to
> operate your clock twenty-four hours a day.

tests have shown that chrony is actually more accurate than ntpd. In
part I believe this is due to its faster response. When the computer
clock slows down due to heat, chrony notices quicky, ntpd takes forever.

But it is true for eitehr that ultimate accuracy takes a while.

>
> With a GPS Timing Receiver you can keep time +/- 50 nano-seconds.
> Relatively few people NEED time with that sort of accuracy. Many
> who DO need that accuracy use NTP and a Global Positioning Satellite
> to get the accuracy required. A few of these people read this
> newsgroup.

No you cannot discipline your computer to that accuracy. While the
reports form the clock may have that precision, the interrupt latency
etc of the computer means that the best you can do is at the microsecond
level. With specialised hardware you could do better.


>
>

[unruh]

Since ntpd steps ( changes the rate by an infinite slope) if the time is
out by 128 ms, yes, convergence IS faster than that. ( however it has to
make sure that the clock really is out by that much and that takes a few
cycles of clock querrying).

For a ms accuracy your could expect a couple of hours. for 10
microsecond, about 10 hr.
>
>>
>>

[David Lord]

Hi

I posted a reply on May 11, but did not give the ntpq stats
as they'd already been archived away.

After three reboots to replace kernel and userland taking
around 10-15 minutes 'ntpq -p' with polling at 6 minutes gave
the following:

min reach offset jitter

-18 377 -0.001 0.004
-12 377 0.007 0.007
-6 377 -0.001 0.006
0 0 0.000 0.000
6 17 -0.036 275.881
12 377 0.126 0.125
18 377 0.173 0.049
24 377 0.047 0.092
30 377 0.007 0.028
36 377 -0.001 0.007
42 377 -0.001 0.004

There was a well established ntp.drift file and my rc.conf starts
ntpd with flags="-g -N -p /var/run/ntpd.pid"

NetBSD/6.1_RC3
ntpd 4.2.6p5-o
PPS from Sure demo board


David

[David Lord]

Ouch! I've checked with the actual times logged and there
was no poll logged at 19:30

19:24 -6 377 -0.001 0.006
19:30
19:36 0 0 0.000 0.000
19:42 6 17 -0.036 275.881