This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: linuxthreads, POSIX 1003.1j and CLOCK_MONOTONIC


My apologies if this is old news, but it is a summary
of a very clean and simple design for timers:

The best implementation of clocks/timers I have yet seen
in the land of computers is the IBM S/370 
"TOD clock" design. For the correct defn, you
should check the IBM "Principles of Operation" for
their current set of processors. In spite
of the fact that the clocks are a hardware design,
I think the design principles offer a lot to anyone
attempting to design an API for clocks and timers.
I'll try to summarize their characteristics here,
briefly:

Fundamental ideas:
  - a clock or timer is represented as a 64-bit
    value, relative to some epoch (I think they chose
    around 1960, but the epoch is not too relevant).
    The clock value ticks at, if I recall, 
    1 MHZ at the 2*10 bit. This permits higher resolution
    by increasing the tick frequency, up to 2* 10 MHZ.

  - 3 timer services are hardware-provided:
	a. Time-of-day (TOD clock)
 	b. Clock comparator
	c. Processor timer

The TOD clock provides the current 64-bit time value
to a process, with the following characteristics:
	- the clock is generally maintained in UTC
		(this is an OS thing, not a hardware thing)
	- the OS maintains an offset from UTC, and
		the equivalent of glibc integrates the
		offset, if desired, into the result.

	- The TOD clock NEVER returns the same value twice,
		and is guaranteed monotonically increasing.
	
	The latter facilitates using the TOD clock 
	as a way to hand out "laundry tickets", 
	or other unique identifiers. 
	
	- keeping the hardware timer in UTC allows multiple
	OSs running under a VM environment to run any
	timezone they want. 

	- returning the entire timestamp as an atomic
	value ensures that there are no race conditions
	between date sampling and time-of-day sampling.
	This is a problem with certain APIs that require
	you to sample time-of-day and date as separate
	calls to the OS, with the possibility of rollover
	of dates between the calls.

The clock comparator is a 64-bit "register" that
	contains a TOD value which will cause an interrupt
	whenever its value is less than the TOD value
	(which increments monotonically at the above
 	1MHZ or better rate). This has two virtues:
	First, an interval time queue can maintain
	real-time values in its queue entries, and
	not have to worry about race conditions or
	clock slippage between the real time and the
	expiry time. The queue manager can simply
	jam the next queue value into the clock 
	comparator and be done  with it. Of course,
	it might make more sense to post all entries
	that are known to be in the past first, but
	that's a frill for performance only.
	The key thing is that ANY event that has
	already expired will be treated properly by
	the hardware.

The processor timer is like the TOD clock, but it 
increments only when a specific task is running.
Hence, it offers high-resolution CPU time
measurement of active processes. The idea of 
GHZ processors with 100Hz timer facilities is silly,
IMO.

Historical note of no importance otherwise:
Back in the dark ages, when the alternative was the 300hz
"interval timer", switching to the processor timer
increased our monthly billing on a 1000-user timesharing
system by 42-billion pazoozas, because we threw
away too many 1/300ths of a second the old way.

Bob

> From: george anzinger <george@mvista.com>
> Date: 2002/07/10 Wed PM 07:24:57 EDT
> To: Ulrich Drepper <drepper@redhat.com>
> CC: Tom Gall <tom_gall@vnet.ibm.com>,  Brian Kuschak <bkuschak@yahoo.com>, 
>         libc-alpha@sources.redhat.com
> Subject: Re: linuxthreads, POSIX 1003.1j and CLOCK_MONOTONIC
> 
> Ulrich Drepper wrote:
> > 
> > On Wed, 2002-07-10 at 12:19, Tom Gall wrote:
> > 
> > > We are planning on getting this implemented in the next couple of
> > > months. Basically we're working on getting the rest of the
> > > POSIX Realtime Options that are currently NOT implemented, implemented.
> > 
> > And this should in some way be positive?  That you even think about
> > implementing CLOCK_MONOTONIC shows that you didn't even try to
> > understand the issues.  This clock cannot be implemented without
> > breaking the ABI.
> > 
> What is needed is the high-res-timers patch in the kernel,
> which provides kernel support for CLOCK_MONOTONIC as well as
> other nice things.  We are trying to get this into the 2.5
> kernel.
> 
> On the other hand, we need the linux threads package to
> support "thread groups" to help sort out the signal issues
> as well as some of the thread creation on timer expire
> stuff.
> 
> I would caution against doing much more in glibc with out
> the kernel support.  The problem is that all this needs to
> be supported AND some of what ends up in glibc with out
> kernel support will be a "wort" in glibc after kernel
> support just to support a feature that few folks use or
> need.
> -- 
> George Anzinger   george@mvista.com
> High-res-timers: 
> http://sourceforge.net/projects/high-res-timers/
> Real time sched:  http://sourceforge.net/projects/rtsched/
> Preemption patch:
> http://www.kernel.org/pub/linux/kernel/people/rml
> 

Robert Bernecky                  Snake Island Research Inc.
bernecky@acm.org                 18 Fifth Street, Ward's Island
+1 416 203 0854                  Toronto, Ontario M5J 2B9 Canada
http://www.snakeisland.com  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]