Using realtime clock?

Using realtime clock?

[Jari Nguyen Trung Thanh]

Hello,

I'm a junior, pls help me...
I'm using Hardhat 2.2.14, and I ported it in a custom board
successfully.
This board has its own realtime clock, pls tell me where I can modify in
the kernel
so that all of the time function in linux can use my realtime
clock...such as
date function...or filesystem....

Thanks in advance,
Jari


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Gabriel Paubert]

On Wed, 10 Jan 2001, Jari Nguyen Trung Thanh wrote:

>
> Hello,
>
> I'm a junior, pls help me...
> I'm using Hardhat 2.2.14, and I ported it in a custom board
> successfully.
> This board has its own realtime clock, pls tell me where I can modify in
> the kernel
> so that all of the time function in linux can use my realtime
> clock...such as
> date function...or filesystem....

You don't want to use the real time clock for this. Getting the time is a
very frequent opeartion and you don't want to do I/O on every
gettimeofday. even if your RTC is (hopefully) in UTC, it  probably does
not keep time in the right format for the kernel (it is much more likely
to use a split format with year, month, day, hour, minutes and seconds in
different registers). Many do not provide subseconds fields and run off a
32768kHz watch cystal which provides only 30 microseconds or so
resolution.

In one word, the RTC is good to save time across reboots and in some cases
to measure the CPU timebase rate by measuring the number timebase ticks
between two second boundaries.


	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Jerry Van Baren]

The "proper" way to handle a RTC is to read it on power up and set the
system clock based on it.  From then on, the system clock will be
correct and everyone will use the system clock efficiently and accurately.

On the x86 (PC host), the utility is "hwclock" (man hwclock).  Your
best approach is to get the source for that, modify it to read your RTC
hardware (which may be different from the PC RTC hardware, although you
might get lucky and only have to deal with endian issues).  Then add a
call to it in your startup scripts, typically in /etc/rc.d/rc.local.

gvb


At 10:30 AM 1/10/01 +0100, Gabriel Paubert wrote:

>On Wed, 10 Jan 2001, Jari Nguyen Trung Thanh wrote:
>
> >
> > Hello,
> >
> > I'm a junior, pls help me...
> > I'm using Hardhat 2.2.14, and I ported it in a custom board
> > successfully.
> > This board has its own realtime clock, pls tell me where I can
> modify in
> > the kernel
> > so that all of the time function in linux can use my realtime
> > clock...such as
> > date function...or filesystem....
>
>You don't want to use the real time clock for this. Getting the time is a
>very frequent opeartion and you don't want to do I/O on every
>gettimeofday. even if your RTC is (hopefully) in UTC, it  probably does
>not keep time in the right format for the kernel (it is much more likely
>to use a split format with year, month, day, hour, minutes and seconds in
>different registers). Many do not provide subseconds fields and run off a
>32768kHz watch cystal which provides only 30 microseconds or so
>resolution.
>
>In one word, the RTC is good to save time across reboots and in some cases
>to measure the CPU timebase rate by measuring the number timebase ticks
>between two second boundaries.
>
>
>         Regards,
>         Gabriel.
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Jari Nguyen Trung Thanh]

Thank you, I think that it is the best way which I can do....
May be I'll try to make it simpler.
Thank again,
Jari


Quoting Jerry Van Baren <vanbaren_gerald@si.com>:

>
> The "proper" way to handle a RTC is to read it on power up and set the
> system clock based on it.  From then on, the system clock will be
> correct and everyone will use the system clock efficiently and
> accurately.
>
> On the x86 (PC host), the utility is "hwclock" (man hwclock).  Your
> best approach is to get the source for that, modify it to read your RTC
> hardware (which may be different from the PC RTC hardware, although you
> might get lucky and only have to deal with endian issues).  Then add a
> call to it in your startup scripts, typically in /etc/rc.d/rc.local.
>
> gvb
>
>
> At 10:30 AM 1/10/01 +0100, Gabriel Paubert wrote:
>
> >On Wed, 10 Jan 2001, Jari Nguyen Trung Thanh wrote:
> >
> > >
> > > Hello,
> > >
> > > I'm a junior, pls help me...
> > > I'm using Hardhat 2.2.14, and I ported it in a custom board
> > > successfully.
> > > This board has its own realtime clock, pls tell me where I can
> > modify in
> > > the kernel
> > > so that all of the time function in linux can use my realtime
> > > clock...such as
> > > date function...or filesystem....
> >
> >You don't want to use the real time clock for this. Getting the time is
> a
> >very frequent opeartion and you don't want to do I/O on every
> >gettimeofday. even if your RTC is (hopefully) in UTC, it  probably does
> >not keep time in the right format for the kernel (it is much more
> likely
> >to use a split format with year, month, day, hour, minutes and seconds
> in
> >different registers). Many do not provide subseconds fields and run off
> a
> >32768kHz watch cystal which provides only 30 microseconds or so
> >resolution.
> >
> >In one word, the RTC is good to save time across reboots and in some
> cases
> >to measure the CPU timebase rate by measuring the number timebase ticks
> >between two second boundaries.
> >
> >
> >         Regards,
> >         Gabriel.
> >
> >
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Wolfgang Denk]

In message <4.3.2.20010110072315.00bb5230@falcon.si.com> Jerry Van Baren wrote:
>
> The "proper" way to handle a RTC is to read it on power up and set the
> system clock based on it.  From then on, the system clock will be
> correct and everyone will use the system clock efficiently and accurately.

Well, that's the way  it's  often  done,  but  it's  far  from  being
perfect. On many embedded systems I'm working with the RTC is running
from  a high precision oscillator which provides much better accuracy
than the system clock. Both clocks will drift, and usually there will
be a noticable difference after a few days. This is not really nice.

> On the x86 (PC host), the utility is "hwclock" (man hwclock).  Your
> best approach is to get the source for that, modify it to read your RTC
> hardware (which may be different from the PC RTC hardware, although you
> might get lucky and only have to deal with endian issues).  Then add a
> call to it in your startup scripts, typically in /etc/rc.d/rc.local.

Any idea how to keep the system clock permanently synchronized to the
RTC?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
In an infinite universe all things are possible, including the possi-
bility that the universe does not exist.
                        - Terry Pratchett, _The Dark Side of the Sun_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Jerry Van Baren]

Wolfgang:

A good place to start is the clock mini HOWTO:
   http://www.linuxdoc.org/HOWTO/mini/Clock.html

The astronomy people, among others, are really fanatical about accurate
time and have some very elaborate programs to synchronize clocks to the
nanosecond (microsecond?) level.  These involve NTP daemons.  Note that
the NTP daemons can synchronize to a radio clock that provides a
1/second tick: your simplest solution would probably be to set up your
accurate RTC to do a 1/second interrupt and then tie it into a NTP
daemon to keep your kernel clock accurate.

Note that utilities like adjtimex (covered in the HOWTO) adjust time
slowly so that it is monotonically increasing (i.e. they speed up or
slow down the tick announcement rather than jamming a new value in the
linux clock).  This is a VERY GOOD feature: otherwise you the risk of
having Really Bad things happen like your cron job running twice if the
clock jam happens to run at just the wrong moment (quite likely,
actually, since you probably update the clock as a cron job).

gvb

Disclaimer: some of this is from memory and may be inaccurate in details.


At 04:06 PM 1/10/01 +0100, Wolfgang Denk wrote:

>In message <4.3.2.20010110072315.00bb5230@falcon.si.com> Jerry Van
>Baren wrote:
> >
> > The "proper" way to handle a RTC is to read it on power up and set the
> > system clock based on it.  From then on, the system clock will be
> > correct and everyone will use the system clock efficiently and
> accurately.
>
>Well, that's the way  it's  often  done,  but  it's  far  from  being
>perfect. On many embedded systems I'm working with the RTC is running
>from  a high precision oscillator which provides much better accuracy
>than the system clock. Both clocks will drift, and usually there will
>be a noticable difference after a few days. This is not really nice.
>
> > On the x86 (PC host), the utility is "hwclock" (man hwclock).  Your
> > best approach is to get the source for that, modify it to read your RTC
> > hardware (which may be different from the PC RTC hardware, although you
> > might get lucky and only have to deal with endian issues).  Then add a
> > call to it in your startup scripts, typically in /etc/rc.d/rc.local.
>
>Any idea how to keep the system clock permanently synchronized to the
>RTC?
>
>Wolfgang Denk
>
>--
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
>In an infinite universe all things are possible, including the possi-
>bility that the universe does not exist.
>                         - Terry Pratchett, _The Dark Side of the Sun_
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Wolfgang Denk]

In message <4.3.2.20010110104647.00baee80@falcon.si.com> you wrote:
>
> The astronomy people, among others, are really fanatical about accurate
> time and have some very elaborate programs to synchronize clocks to the
> nanosecond (microsecond?) level.  These involve NTP daemons.  Note that
> the NTP daemons can synchronize to a radio clock that provides a
> 1/second tick: your simplest solution would probably be to set up your
> accurate RTC to do a 1/second interrupt and then tie it into a NTP
> daemon to keep your kernel clock accurate.

Seems a bit of overhead (especially for embedded systems with limited
resources) to add a NTP daemon just to make one part  of  the  kernel
timekeeping toal to the other...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It's when they say 2 + 2 = 5 that I begin to argue."    - Eric Pepke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Jerry Van Baren]

At 05:22 PM 1/10/01 +0100, Wolfgang Denk wrote:
>In message <4.3.2.20010110104647.00baee80@falcon.si.com> you wrote:
> >
> > The astronomy people, among others, are really fanatical about accurate
> > time and have some very elaborate programs to synchronize clocks to the
> > nanosecond (microsecond?) level.  These involve NTP daemons.  Note that
> > the NTP daemons can synchronize to a radio clock that provides a
> > 1/second tick: your simplest solution would probably be to set up your
> > accurate RTC to do a 1/second interrupt and then tie it into a NTP
> > daemon to keep your kernel clock accurate.
>
>Seems a bit of overhead (especially for embedded systems with limited
>resources) to add a NTP daemon just to make one part  of  the  kernel
>timekeeping toal to the other...
>
>Wolfgang Denk
>
>--
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
>"It's when they say 2 + 2 = 5 that I begin to argue."    - Eric Pepke

Yup.  However, adjtimex() is a function call that tweaks the clock
parameters in the kernel.  If you understood those parameters (I
don't), you could keep your clock very accurate.

If you tracked down some references (NTP source code, NTP RFCs, "David
L. Mills' clock adjustment algorithm"), I suspect you would be able to
figure out how to properly use adjtimex().  Further, I suspect
adjtimex() a pretty lightweight routine since it merely adjusts the
parameters that presumably already exist in your kernel.

I'm just leaving the fun parts for the reader :-).

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Bill Roman]

Jerry Van Baren wrote:

> If you tracked down some references (NTP source code, NTP RFCs, "David
> L. Mills' clock adjustment algorithm"), I suspect you would be able to
> figure out how to properly use adjtimex().  Further, I suspect
> adjtimex() a pretty lightweight routine since it merely adjusts the
> parameters that presumably already exist in your kernel.
>
> I'm just leaving the fun parts for the reader :-).

Network Time Synchronization Project : http://www.eecis.udel.edu/~mills/ntp.htm


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Gabriel Paubert]

On Wed, 10 Jan 2001, Jerry Van Baren wrote:

>
> Wolfgang:
>
> A good place to start is the clock mini HOWTO:
>    http://www.linuxdoc.org/HOWTO/mini/Clock.html
>
> The astronomy people, among others, are really fanatical about accurate
> time and have some very elaborate programs to synchronize clocks to the
> nanosecond (microsecond?) level.  These involve NTP daemons.  Note that
> the NTP daemons can synchronize to a radio clock that provides a
> 1/second tick: your simplest solution would probably be to set up your
> accurate RTC to do a 1/second interrupt and then tie it into a NTP
> daemon to keep your kernel clock accurate.

As an astronomer, I'm not that fanatical about clock accuracy, let us say
a couple of milliseconds is sufficient. OTOH VLBI and pulsar astronomers
are absolutely obsessed by clock precision. But yes, ntp is the protocol
to use to synchronize machines on a LAN: one machine has a radio clock
or whatever and all the other lock on it through ntp.

>
> Note that utilities like adjtimex (covered in the HOWTO) adjust time
> slowly so that it is monotonically increasing (i.e. they speed up or
> slow down the tick announcement rather than jamming a new value in the
> linux clock).  This is a VERY GOOD feature: otherwise you the risk of
> having Really Bad things happen like your cron job running twice if the
> clock jam happens to run at just the wrong moment (quite likely,
> actually, since you probably update the clock as a cron job).

ntp does it too, actually they both ajust the duration of the jiffy though
the adjtimex syscall. Funny things may still happen around leap seconds
however (one second is repeated).

Why would you update the clock as a cron job ?

ntpd does it (actually the kernel does it on a regular basis when adjtimex
tells it that the pll with the time server is closed).

	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Using realtime clock?

[Gabriel Paubert]

On Wed, 10 Jan 2001, Jerry Van Baren wrote:

> Yup.  However, adjtimex() is a function call that tweaks the clock
> parameters in the kernel.  If you understood those parameters (I
> don't), you could keep your clock very accurate.

Indeed, but the hard part is to compute the parameters for adjtimex (BTW
never set the state bit to locked otherwise the kernel will rewrite the
RTC from the system clock, creating an interesting loop).

> If you tracked down some references (NTP source code, NTP RFCs, "David
> L. Mills' clock adjustment algorithm"), I suspect you would be able to
> figure out how to properly use adjtimex().  Further, I suspect
> adjtimex() a pretty lightweight routine since it merely adjusts the
> parameters that presumably already exist in your kernel.


It is.  ntp also is lightweight: about 5 minutes for the main server I
have here after >6 months of operation on a 200MHz 603e, serving about 10
machines at higher than average rate (to improve precision) and
broadcasting for less critical machines.

	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/