New Linux System time proposal

New Linux System time proposal

[linux-os]

I think that Linux time should be re-thought and done over once and
for all. I think that time should be the sum of three variables:

 	unsigned boot_time	Read from RTC upon boot and never changed.
 	signed delta_time	Starts at 0, is adjusted as required.
 	unsigned jiffies	Starts at 0 upon boot, bumped by tick only.

Any time there is a requirement to obtain the system time, these
three values are summed. At the time that occurs, the current value
of jiffies is read and compared against a previously-saved value.
The new value is saved in the old value after. If the new jiffies
is less than the old, delta_time is adjusted accordingly.

What this means is that jiffies can remain a 32-bit variable and
one only needs to read the system time once in awhile (before
it wraps twice) to keep everything synchronized.

It also means that hardware time-outs don't get disrupted when
the system clock gets set because jiffies is never touched
except by the timer-tick interrupt.

Also, time doesn't get destroyed in the process of reading it.
A simple user-mode daemon can periodically check certain hardware
timers (like the RTC), and adjust delta_time accordingly (and
slowly, like a PLL). A hook can be provided so that the
delta_time variable can be tweaked by a user-mode code that
synchronizes to time-servers as well. As a side-effect, this
daemon does the "before jiffies wraps" read to keep everything
in sync.

The actual size of the variables boot_time and delta_time can
be determined by the implementor with due consideration for
the resolution required.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: New Linux System time proposal

[Jan Engelhardt]

> I think that Linux time should be re-thought and done over once and
> for all. I think that time should be the sum of three variables:

It has been rethought a number of times, the last one being the switch to a 
64-bit jiffy counter.

> unsigned boot_time	Read from RTC upon boot and never changed.
> signed delta_time	Starts at 0, is adjusted as required.
> unsigned jiffies	Starts at 0 upon boot, bumped by tick only.
>
> Any time there is a requirement to obtain the system time, these
> three values are summed. At the time that occurs, the current value
> of jiffies is read and compared against a previously-saved value.
> The new value is saved in the old value after. If the new jiffies
> is less than the old, delta_time is adjusted accordingly.
>
> What this means is that jiffies can remain a 32-bit variable and
> one only needs to read the system time once in awhile (before
> it wraps twice) to keep everything synchronized.

jiffies is both 32 and 64 at the same time (using some linker magic).

> It also means that hardware time-outs don't get disrupted when
> the system clock gets set because jiffies is never touched
> except by the timer-tick interrupt.
>
> Also, time doesn't get destroyed in the process of reading it.
> A simple user-mode daemon can periodically check certain hardware
> timers (like the RTC), and adjust delta_time accordingly (and

One can do rdtsc() in kernelspace.

> slowly, like a PLL). A hook can be provided so that the
> delta_time variable can be tweaked by a user-mode code that
> synchronizes to time-servers as well. As a side-effect, this
> daemon does the "before jiffies wraps" read to keep everything
> in sync.
>
> The actual size of the variables boot_time and delta_time can
> be determined by the implementor with due consideration for
> the resolution required.

I don't see a change necessary unless I'm a physics professor experimenting 
with atomic clocks.



Jan Engelhardt
-- 
ENOSPC

Re: New Linux System time proposal

[john stultz]

On Tue, 2005-01-11 at 09:31 -0500, linux-os wrote:
> I think that Linux time should be re-thought and done over once and
> for all. 

I agree, and I've been working on this for awhile. 

You can find an outdated summery of my ideas here:
http://lwn.net/Articles/100665/

And as soon as I get ppc64 booting I'll be sending out a new release of
the code. 

thanks
-john

Re: New Linux System time proposal

[linux-os]

On Tue, 11 Jan 2005, john stultz wrote:

> On Tue, 2005-01-11 at 09:31 -0500, linux-os wrote:
>> I think that Linux time should be re-thought and done over once and
>> for all.
>
> I agree, and I've been working on this for awhile.
>
> You can find an outdated summery of my ideas here:
> http://lwn.net/Articles/100665/
>
> And as soon as I get ppc64 booting I'll be sending out a new release of
> the code.
>
> thanks
> -john
>

I'm glad you are working on it. The system I proposed is the same
thing that was done in VAX/VMS. There was never any need to upset
any timing anywhere because it was just BOOTTIME + OFFSET +
uFORTNIGHT-tick = (quadword) time.

A more modern version for Linux would "simplicate and add lightness",
as well as get rid of the:

    warning:  Clock skew detected.  Your build may be incomplete.

...from `make` as a result of more-and-more-usual time jumps.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

RE: New Linux System time proposal

[Robert White]

I thought it was not at all unusual to miss a jiffy here or there due to interrupt
locking/latency; plus jiffies is expressed with respect to the value of HZ so you
would need to do some deviding in there somewhere.

Where HZ has been adjusted up, or on slower embedded boxes where interrupts could be
blocked longer, you would lose time.

Or are you not talking about real-word time?

Rob White,
Casabyte, Inc.

RE: New Linux System time proposal

[linux-os]

On Tue, 18 Jan 2005, Robert White wrote:

> I thought it was not at all unusual to miss a jiffy here or there due
> to interrupt
> locking/latency; plus jiffies is expressed with respect to the value
> of HZ so you
> would need to do some deviding in there somewhere.
>

Makes no difference. The idea is that jiffies __never__ gets changed,
ever.


> Where HZ has been adjusted up, or on slower embedded boxes where
> interrupts could be
> blocked longer, you would lose time.
>

No difference. We should never touch the count in the master timer,
jiffies. Never, never, ever.

> Or are you not talking about real-word time?
>

That's what I said. When you need to read real-world time,
you read the sum of bootime, time_adj, and jiffies. The
time is read in the most natural dimension, not necessarily
microsconds, it could be micro-croak-farts, a number dimension
that results in the least number of lossy conversions.

Boot time is read from the RTC (or other hardware clock) upon
boot and never changed. Jiffies starts at 0 upon boot. Time_adj
starts at 0 upon boot, but once the system is up it gets adjusted
when the machine is set to some outside reference. This parameter
is the only element that is ever adjusted. This is the only
element that ever needs to be protected with a lock. It can
certainly be dynamically adjusted (like adjtime) as well, but
that's some other variables.


Currently, if you do:


extern void gettimeofday(void *);	// Phony, yes
int main()
{
     int foo[0x10];
     for(;;)
         gettimeofday(foo); 
}

An ordinary user can slow the system time about 10 seconds per
hour doing this! I don't know if this qualifies as a DOS, but
it isn't "nice".

> Rob White,
> Casabyte, Inc.
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.