Re: [uCsimm] For exact date

From: Larry Doolittle (ldoolitt@recycle.lbl.gov)
Date: Fri Mar 10 2000 - 12:18:40 EST


> >Real Linux kernels can phase slip their internal UTC clock to the
> >external timebase at an arbitrary rate, settable to a fraction of a ppm.
> >I hope RTLinux can do that too.
>
> You mean time correction code (11 minite interval) of linux kernel? or NTP?

No, and no.

> Real Linux kernel means Normal Linux kernel?

Yes.

> I've heard that normal destop has seperated RTC chip and they say it uses
> cheap crystal. Therefore linux kernel has correction code for this RTC using
> system clock (they say it more accurate than RTC crystal).

On Pentium and higher, the system clock uses the processor cycle clock,
both because it is higher resolution and takes less time to read
than the RTC chip. This does add complexity, because the jiffy
interrupt comes from the RTC still. This is not what I was referring to.

The code of interest is in arch/*/kernel/time.c. I will refer to
the i386 branch here, because that is what I'm familiar with
(and because the 2.0.36 tree I have unpacked in front of me doesn't
have an arch/or1k directory :-p).

The do_gettimeoffset() routines compute how many microseconds have
elapsed since the beginning of the current jiffy.
The function do_fast_gettimeoffset() is the Pentium-specific version.
Ignore that and look at do_slow_gettimeoffset(). This reads the
RTC value and scales it to microseconds.

Now look at timer_interrupt(). The "11 minute" code is there, ignore
that and go to do_timer(), in the non-arch-specific kernel/sched.c.
Eventually that thread of control passes to update_wall_time_one_tick().
_That_ is what I was referring to. Depending on the settings configured
with the adjtimex() system call, we get to control the kernel's perception
of the length of a jiffy to much better than a microsecond.

If the DragonBall's crystal is 32.000 kHz, and you divide by 320 to get
the interrupt, time_adjust_step is 10000, and time_adj is close to
zero. You are expected to make small adjustments to time_adj if you
find your system time runs fast or slow, this is what NTP is supposed
to do automatically).

If the DragonBall's crystal is 32.768 kHz, and you divide by 328 to get
the interrupt, time_adjust_step is 10010, and time_adj is close to
(1e6/(32768/328)-10010)*2^22, or -983040 (I think I got that right).
Again, small corrections to time_adj are possible and recommended.

The user-space access point to time_adjust_step and time_adj is adjtimex(2).
There is a command line shell for this by Dick and Van Zandt, its man
page is in section 8 on my Red Hat machine. xntpd is the normal tool
for using this feature to phase lock the system clock to UTC, that's
a very heavyweight beast. I have about 3/4 of the work done in my
ntpclient program, which works (as far as it goes) on uCLinux. I have
mailed it to a few people for evaluation -- if someone wants to add the
"close the feedback loop" code before I get around to it, contact me.

> In sleep/doze mode (for battery operation),
> the only clock running would be CLK32. another idea?

This is of course a desirable situation. It may take some careful
thought and creative hacking to get the above phase adjustment to
take place correctly when coming out of sleep mode.

       - Larry Doolittle <LRDoolittle@lbl.gov>
This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:34 EST