CLOCK_REALTIME_RES and nanosecond resolution

CLOCK_REALTIME_RES and nanosecond resolution

[Benjamin Herrenschmidt]

Hi !

I noticed that we set

#define CLOCK_REALTIME_RES TICK_NSEC  /* In nano seconds. */

Unconditionally in kernel/posix-timer.c

Doesn't that mean that we'll advertise to userland (via clock_getres) a
resolution that is basically HZ ? We do get at lenght to get more
precise (up to ns) resolution in practice on many architectures but we
don't expose that to userland at all. Is this normal ?

Ben.

Re: CLOCK_REALTIME_RES and nanosecond resolution

[Steven Rostedt]

On Tue, 2005-11-08 at 13:55 +1100, Benjamin Herrenschmidt wrote:
> Hi !
> 
> I noticed that we set
> 
> #define CLOCK_REALTIME_RES TICK_NSEC  /* In nano seconds. */
> 
> Unconditionally in kernel/posix-timer.c
> 
> Doesn't that mean that we'll advertise to userland (via clock_getres) a
> resolution that is basically HZ ? We do get at lenght to get more
> precise (up to ns) resolution in practice on many architectures but we
> don't expose that to userland at all. Is this normal ?

Yes.

Until ktimers/high-res or another variant gets incorporated into the
kernel, the only resolution you will get for user applications is HZ.
So even though we may have timers that are much faster than HZ (which
there are a lot of them), the kernel only will work with timers on a
jiffy basis.

On a 2.6.13  I get a response of 0.004000250 seconds from clock_getres
with a HZ of 250.

On 2.6.14-rc5-kthrt7 (Thomas Gleixner's ktimers+high-res) I get from
clock_getres: 0.000001000 seconds. And this seems to be accurate.

-- Steve

Re: CLOCK_REALTIME_RES and nanosecond resolution

[Thomas Gleixner]

On Tue, 2005-11-08 at 13:55 +1100, Benjamin Herrenschmidt wrote:
> Hi !
> 
> I noticed that we set
> 
> #define CLOCK_REALTIME_RES TICK_NSEC  /* In nano seconds. */
> 
> Unconditionally in kernel/posix-timer.c
> 
> Doesn't that mean that we'll advertise to userland (via clock_getres) a
> resolution that is basically HZ ? We do get at lenght to get more
> precise (up to ns) resolution in practice on many architectures but we
> don't expose that to userland at all. Is this normal ?

This is the resolution which you can expect for timers (nanosleep and
interval timers) as the timers depend on the jiffy tick.

The resolution of the readout functions is not affected by this.

http://www.tglx.de/ktimers.html#writeup

should give you more information about that.

	tglx

Re: CLOCK_REALTIME_RES and nanosecond resolution

[Benjamin Herrenschmidt]

> This is the resolution which you can expect for timers (nanosleep and
> interval timers) as the timers depend on the jiffy tick.
> 
> The resolution of the readout functions is not affected by this.

Ok, thanks, POSIX spec wasn't very clear about that 

Ben.

Re: CLOCK_REALTIME_RES and nanosecond resolution

[Roman Zippel]

Hi,

On Tue, 8 Nov 2005, Benjamin Herrenschmidt wrote:

> > This is the resolution which you can expect for timers (nanosleep and
> > interval timers) as the timers depend on the jiffy tick.
> > 
> > The resolution of the readout functions is not affected by this.
> 
> Ok, thanks, POSIX spec wasn't very clear about that 

Actually the spec is a bit more clear than that:

"This volume of IEEE Std 1003.1-2001 defines functions that allow an 
application to determine the implementation-supported resolution for the 
clocks and requires an implementation to document the resolution supported 
for timers and nanosleep() if they differ from the supported clock 
resolution."

Historically the clock and timer resolution was equal and e.g. 
clock_gettime() returned a msec value. To get usec resolution one had to 
enable the MICRO_TIME, but this didn't change the clock_getres() value, as 
at that time higher clock_gettime() resolution was interpolated from a 
second time source and the actual clock tick remained unchanged. 
Subsequent UNIX generations have preserved this behaviour.

Thomas' expectation is not generally true, non-UNIX implementations return 
different values here and his expectation is not required by POSIX, it's 
more a traditional UNIX behaviour.

bye, Roman