pauld@stowe.cs.washington.edu (Paul Barton-Davis) (05/08/91)
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 >>>systems if you try to access the process screen. On at least one system, >>>anyway...) >> >>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 >environment. It is set in /etc/default/login to HZ=100 (on ISC 2.2.1), so >why it should have turned up as a null string I don't know. Anyway u386mon >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 ? -- Paul Barton-Davis <pauld@cs.washington.edu> UW Computer Science Lab "People cannot cooperate towards common goals if they are forced to compete with each other in order to guarantee their own survival."
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (05/09/91)
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
sef@kithrup.COM (Sean Eric Fagan) (05/10/91)
In article <1991May7.180013.23250@beaver.cs.washington.edu> pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes: >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 ? Backwards compatibility? A lot of binaries might assume the value of HZ. (Personally, I recommend using gethz() instead of a #define HZ 100.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.