It depends. On a 700 mhz athlon, 1000hz would give every task 1/1000th
of a second (1 millisecond) to operate, which would probably be
acceptable. The only disadvantage I could see is that it takes a finite
amount of time to reschedule a task. The more task reschedules per second,
the more time the OS is doing work and the less time the application is
given as a percentage of overall machine availability.
The point of no return varies from machine to machine. A 386 would be
unusable at 1000hz. A 486 would be intolerable. A pentium would be
sluggish.
100hz give every task 10 milliseconds to operate, and is a good number
for a lot of machines out there (300mhz pentiums on down).
But this number only applies if a task is doing nothing but calculations
and not trying to do any operating system i/o (where they can be suspended
until the information is ready). Generally, this timer period ends up
being a guideline for the normal mix of computer program operations
rather than an absolute from a _statistical_ point of view.
bug
On Mon, 7 Feb 2000, William Ahern wrote:
> I checked the source for 6.1 (include/asm-i386/param.h) and noticed that the
> interrupt is set for 100HZ.
>
> how much of a performace increase could be expected if this were increased (and
> the appropriate utilties were patched so they wouldn't break)? this would
> primarily affect the scheduler, right? i'd imagine that 100hz might leave alot
> of dead time for some processes... or am i being too picky?
>
