Re: gettimeofday() and clock

[Mads Bondo Dydensborg <madsdyd@challenge.dk>]

On Mon, 2 Sep 2002, Steve Baker wrote:

> Mads Bondo Dydensborg wrote:
> 
> > I believe so. Look in
> > usr/include/asm/param.h
> 
> Hmmm - it certainly says:
> 
> #define HZ 100
> 
> ...but does that prove that the kernel is iterating at that rate?

OK, this is getting to be nitpicking, sorry: I _know_ you have tons of
experience (and I have nearly none, so forgive me), and I respect your
observations, but, I believe that the statement you made to the effect
that:

> but in practice it can't wake
> your program up any faster than the kernel timeslice - which is 1/50th 
> second.

is wrong. Not the first part, only the latter, and this may only be
because I misread it (I answer these mails too late in the evening,
English is not my native language, I tend to misunderstand the core of a
thread sometimes). I believe the kernel _can_ wake you up in HZ of a
second, which is why the original poster saw sleeps of 10 seconds + 10 ms.

You are investigating something sligthly different though; what is the
minimal delay to be _put to sleep_ and _waken up_.  This may very well be 
20 ms on Intel - at least if you do not want to eat up the cycles.

 > 
> Well, it *says* some vague stuff about being able to use usleep for
> delays longer than ~10ms - but my experiment (at least on my computer)
> shows that ~20ms is the minimum delay.  I do a *LOT* of heavy realtime
> work - and I'm 100% certain that you can't reliably delay for less than
> 20ms.  

I am quite sure you can not _reliably_ sleep for less than
something-in-the-ballpark-of 200ms, actually, depending on your hardware.

> Well, yes - but it certainly *does* block.  I could block quite happily with
> a 'gettimeofday' in an empty 'for' loop - but throwing away 10milliseconds
> of CPU time out of every 16ms seems a little harsh!

Yes, indeed.

> Maybe it's time for us games/graphics types to hang out on the kernel
> mailing list and lobby for a higher rate.
> 
> Whatever the rate is, it's been the same since 33MHz 386's - and now
> we are close to having 3.3GHz CPU's (100 times faster), asking for a mere
> 10x speedup in the kernel's update rate seems a rather modest request.

Not only that, with increased caches and memories, the cost of switching 
contexts should have gone down (although I am unsure about the virtual 
page tables).

> 
> The impact on the ease of writing games and other graphics-related
> packages would be significant.

But Linux would still be a soft realtime system though...

Mads

-- 
Mads Bondo Dydensborg.                               madsdyd@challenge.dk
Windows XP, which according to everybody is the ``most reliable Windows
ever.'' To me, this is like saying that asparagus is ``the most articulate
vegetable ever.'' 
                               - Dave Barry