Re: [tlug] timing for geeks

[Ian Wells <ijw@example.com>]

On 12/3/05, Michal Hajek <hajek1@example.com> wrote:

Unfortunately, Josh program - using either gettimeofday() or
clock_gettime()  - still produces "saw-ish" time signal.

What are you seeing?  For testing time signal resolution, you could try a bit of pointless code, like:

while(1) {
   print the time;
 }

run through uniq for a few seconds to see what the resolution is really like.

And this did not change even though I tried it with CLOCK_REALTIME and
also CLOCK_MONOTONIC clock variables [1].

Thus basicaly, using these functions does not solve the problem. But
definitely they are much better choice than my original try with
ftime(). :))))

[1] see man clock_gettime

Does anyone know if these calls are tick-based or RTC based?  Not
all
systems have a means of resolution better then the tick counter, but
some do, and I wondered if this was how it was made available.

Reading the man pages, the CLOCK_MONOTONIC clock seems best suited to
what you're doing.  The other one can, in theory, get changed
during your process's execution.  Ditto gettimeofday.  This
would be bad if you're running NTP...


Random offtopic bit:

I notice that tickless kernels might actually become a reality, judging
by http://lwn.net/Articles/160689/ - which is nice for anyone on old
machines (where interrupts have a disproportionate effect on CPU load)
and on laptops (where idle power consumption should go down). 
Seems like they use regular interrupts most of the time, though - I
would have thought it would be possible to dynamically set the time of
the next interrupt and avoid having a HZ constant...