Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!ogicse!emory!kd4nc!n4hgf!wht From: wht@n4hgf.Mt-Park.GA.US (Warren Tucker) Newsgroups: comp.unix.sysv386 Subject: Re: HZ values (was: Re: u386mon dumping core) Message-ID: <407@n4hgf.Mt-Park.GA.US> Date: 9 May 91 07:23:59 GMT References: <1991Apr30.105615.9129@gallium.uucp> <1991May4.214132.27702@cti-software.nl> <9884@suns6.crosfield.co.uk> <1991May7.180013.23250@beaver.cs.washington.edu> Reply-To: wht@n4hgf.Mt-Park.GA.US (Warren Tucker) Organization: Amateur Radio Station N4HGF Lines: 52 In article <1991May7.180013.23250@beaver.cs.washington.edu> pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes: >In article <9884@suns6.crosfield.co.uk> ir@crosfield.co.uk (ian reid) writes: >>In article <1991May4.214132.27702@cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes: >>>In article <17@metran.UUCP> jay@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@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