|
|
Posted by Eric Sosman on 06/25/07 01:37
Jerry Stuckle wrote:
> David T. Ashley wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:YdWdncWaU_Y1E-PbnZ2dnUVZ_rfinZ2d@comcast.com...
>>> David T. Ashley wrote:
>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>> news:BP2dnRB4hISwQODbnZ2dnUVZ_u2mnZ2d@comcast.com...
>>>>> So they have to be adjusted. And even though NTP tries to speed up
>>>>> and slow the clock - it's not perfect. And at times the clock WILL
>>>>> jump forwards or backwards at least one second.
>>>> My documentation for NTP proper says it won't do this.
>>>>
>>>> What kind of events are you speaking of that might cause
>>>> discontinuities?
>>>>
>>> It depends on a lot of things. Many systems do not have the
>>> necessary hardware adjust clock speed. So just like any clock, if
>>> it's running fast, it must be set back sooner or later.
>>
>> Interesting. I had assumed that adjtimex() was available on just
>> about every system that would run PHP.
>>
>> Also, I'm not sure that adjusting time has much to do with hardware.
>> My understanding of it was that every system has the capability for
>> RTI (some sort of real-time interrupt at a periodic rate--perhaps
>> adjustable, perhaps not), but maybe something around 100Hz is typical.
>>
>> In any case, my understanding of Linux timekeeping was that on every
>> timetick, an integer was added to the internal time. The integer
>> would be fairly large, so that the timekeeping precision is several
>> orders of magnitude finer than the RTI rate. It would be this integer
>> adjusted to change the effective rate of the clock, not hardware.
>>
>> For example, let's assume that the RTI rate is 100Hz, and we maintain
>> time as a 64-bit integer, with the radix point after the first 32
>> bits. Then, on each tick, we add 42,949,673 to the integer. Every
>> 100 ticks, the upper 32 bits will be incremented. Time adjustment is
>> possible to about 1 part in 43 million. And the system is very cheap
>> (integer arithmetic is cheap).
>>
>> For example, if we want the clock to run a bit slower, we add
>> 42,949,672 each time rather than 42,949,673.
>>
>> What did I miss?
>>
>> Is hardware really involved?
>>
>> Can you point me to documentation about any system where the rate
>> can't be adjusted under Linux?
>>
>> Thanks, Dave.
>
> Dave (and others who responded)
>
> That is true, it depends on the clock frequency. However, the system
> clock runs even when the system is turned off - it's battery operated
> and that's why you don't have to reset the clock every time you start up.
Not on any hardware I've ever encountered (a non-universal
sample, I freely admit). There's usually a periodic interrupt
that fires at some nominal rate while power is on and the system
is running, but this interruptor doesn't run while the system
is off (and certainly not when power is removed) -- after all,
who would service the interrupt? But there's a secondary ToD
"wristwatch" chip that runs all the time on a small battery.
This ToD chip furnishes the t=0 value during boot, and may be
rewritten during clean shutdown and perhaps at other times.
But once it's supplied t=0="2007-06-24 21:34:36" at boot time,
the ToD chip is not responsible for cyclic interrupts thereafter.
Perhaps there's a system where both functions are rolled
into one device, but I haven't run into it.
--
Eric Sosman
esosman@acm-dot-org.invalid
Navigation:
[Reply to this message]
|