HZ values (was: Re: u386mon dumping core)

[Warren Tucker]

In article <1991May7.180013.23250 at beaver.cs.washington.edu> pauld at stowe.cs.washington.edu (Paul Barton-Davis) writes:
>In article <9884 at suns6.crosfield.co.uk> ir at crosfield.co.uk (ian reid) writes:
>>In article <1991May4.214132.27702 at cti-software.nl> pim at cti-software.nl (Pim Zandbergen) writes:
>>>In article <17 at metran.UUCP> jay at metran.UUCP (Jay Ts) writes:
>>>>(Also, note that the current version of u386mon dumps core on ISC 2.2
>>>
>>>I've noticed that u386mon compiled on a 2.0.2 system will dump core
>>>as described running on a 2.2 system.
>>
>>I had the problem of u386mon core dumping when going into the process screen.
>>I tracked the problem down to a variable HZ being set to a null string in the
>>uses HZ to do arithmetic, including using it as a divisor, hence the core
>>dump.  If HZ is not set in the environment u386mon uses the value in 
>>/usr/include/sys/param.h.  
>Can anyone from SCO or elsewhere enlighten me as to why SCO Unix/386
>usesa HZ value (both in the kernel and as the environment variable) of
>60, and not 100 ? Or has this been changed ... or can it be ?

I will fix the bug of a bad HZ environment variable value causing
it to dump core (surely because of divide by zero in get_cpu_time_str()).

8086 XENIX uses HZ of 20.  80286/386 XENIX uses 50.  When I saw
HZ=100 in 3.2.0, I went "HIHO! 10 msec resolution at last!"
Sigh and alas, as of 3.2.1, HZ went to 60.

I am told by SCO that even though you may manage to change the HZ value
in the kernel to 100, the system will misbehave because most of the
(AT&T supplied and otherwise) utilities use the sys/param.h value
directly and do not search the environment.

I also heard from the same guy that a HZ of 60 runs the microscheduler
(I forget the real name) only 60% as often (makes sense!) thus getting
a bit more oomph out of the box.  

I miss 10 msec resolution timing because I run a big enough box to
ignore (usually) that "UNIX ain't real time" and use it for precise
measurements.  Now,
     6099.9996 milliseconds may LOOK more precise than
     6100      milliseconds,
but I know my measurements are off +/- one tick + scheduling anyway.

I'd much rather have .010 sec as the basic interval over 0.0166666666666,
but not everyone uses 486/33s and it does make a difference on a busy
system. 

I search the environment because I wish to avoid such.  I do handle
a missing HZ=nn , but not a bad value (i.e., HZ='', yielding 0).
 
------------------------------------------------------------------------
Warren Tucker, TuckerWare     emory!n4hgf!wht or wht at n4hgf.Mt-Park.GA.US
"An ANSI C elephant: just like the real one, but the position, shape and
length of the trunk and tail are left to the vendor's discretion." -- me