Re: gettimeofday() and clock

[Steve Baker <sjbaker1@airmail.net>]

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?

>>I could have sworn it was 50Hz on Intel - because when my program
>>does a short usleep (say 1 millisecond), it generally sleeps for ~20ms - which
>>is 1/50th second.  Hence, I deduce that the kernel only wakes up and reschedules
>>my program 50 times a second - and not 100Hz as you suggest.
>>
>>I also believe the 50Hz figure because the *original* UNIX on PDP-11's used
>>50Hz - and I presumed that Linus picked the same number for compatibility.
>>
>>Try running this:
> 
> 
> [...]
> 
> Please look at e.g. 
> http://www.tldp.org/HOWTO/mini/IO-Port-Programming-4.html

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.  So either the kernel is indeed running at 50Hz - or it has some
kind of a bug that prevents it from rescheduling the task when it should.

> I am no expert, but I believe this is usually the reference one gets on 
> these matters.
> 
> Perhaps, if you have time, you could try the realtime option and nanosleep 
> instead. nanosleep does block the CPU though.

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!

>>I'd *really* like to see a shorter timeslice on Intel.  With
>>2GHz CPU's, even 100Hz is like an eternity.
> 
> 
> I believe it _is_ possible to redefine HZ to something higher, even on 
> Intel, but that it might lead to trouble.

I believe someone at work tried that - and it did indeed lead to trouble.

>>A 1000Hz kernel timeslice - and (in consequence) a usleep that was
>>accurate to ~1ms instead of ~20ms - would solve a *TON* of problems
>>for graphics programs that want to run at 60Hz and yet still use
>>'usleep' to avoid blocking the CPU.
> 
> 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.

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

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net