Hmmm...

I've run into RTCs that cannot _update_ with such good accuracy.  E.g.
on Alchemy, it can take a substantial portion of a second to update the
RTC.  (We spin for that.)  Yes, this seems bizarre to me, and no, I
don't know why it is so, only that is.

I wonder if other ports have similar issues, where even though the
internal clock is higher resolution, its harder to access it with better
than one second accuracy.

Some RTCs also have interrupt support, so at least you could get an
interrupt on the trigger of the clock.  This would avoid some of the
polling, I think.

Some ports boot very quickly, and a 1 second delay could be 20% or more
of the boot time.   I don't think creating a forced boot delay across
the board is a good idea.  As you indicated OOB, we could ifdef the code
out for those ports.

If the problem is NTP, then I suggest that we extend NTP so that it can
know when a power state change occurs and DTRT (i.e. do a step, or
whatever, go adjust the clock quickly.)

    -- Garrett

Perry E. Metzger wrote:
> On most of our platforms, the time of day is preserved on the machine
> in a battery backed up real time clock chip. Said chip is typically
> read and reset in a given port's inittodr/resettodr code.
>
> Typical battery backed RTC chips store the time to a precision of
> one second, though they are often more accurate than that in that
> their drift is relatively small over short periods.
>
> Now, when we read or reset the clock in inittodr/resettodr, we are
> typically ignoring the fact that the RTC chips tick but once a second,
> and we treat the time as equally accurate across the entire second. We
> might read the RTC chip as saying 12:00:00 .1 seconds before it would
> read 12:00:01, but we'll set the time to 12:00:00 anyway.
>
> In days of yore, this was fine, but in a modern NTPized world, this
> can cause trouble. Machines now keep far better time than one second
> accuracy, and when you sleep and wake up a machine or reboot it, the
> system can gain or lose nearly a second.
>
> I'd like to propose that on most ports, we spin in inittodr(9) waiting
> for the next second to tick over and setting the clock exactly then,
> and that in resettodr(9) we do a brief calculation of when the next
> second will tick, and wait until then to set the RTC.
>
> This has the disadvantage of adding up to a 1 second delay in machine
> pauses, boots, shutdowns, etc, but it will make timekeeping much
> better.
>
> Opinions?
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191