Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!esosun!seismo!uunet!steinmetz!davidsen From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) Newsgroups: comp.arch Subject: Re: NSIEVE C Source File (long) Message-ID: <11961@steinmetz.ge.com> Date: 24 Aug 88 18:09:07 GMT References: <1070@marlin.NOSC.MIL> <1073@marlin.NOSC.MIL> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Distribution: comp.arch Organization: General Electric CRD, Schenectady, NY Lines: 34 Although I agree with the aims of NSIEVE to overcome weaknesses of the original, there are some problems in this version as well, which relate to the accuracy of the timing. I posted some commentary on time measurement last year, perhaps it's time to repeat. The clock timing value, HZ, is not set at 60 by some default, that's just the value on a VAX. In a number of system, such as SunOS, Xenix, UNICOS, and all SysV systems, the value is found in . The suggested way to get this is to use code like: #ifndef HZ #include #endif and to force the user to define it on the cc command line if it's not in the include file. Since popular values are 20, 50, 100, 4096, and 243902439 (the last on a Cray2), the assumption of of 60 will yield incorrect results. In UNIX versions the CPU time should be used, rather than real time, since the real time may vary wildly. The realtime will excede the CPU by some factor based on the load average on uniprocessor machines, and will be smaller than the CPU by about N on a good multiprocessor machine. On MS-DOS, CP/M and other small control programs the assumption of CPU=clock is usually valid. I hope that these comments will allow the author to improve this very useful program, such that it will produce consistent results. I have the UNIX routines for realtime and CPU in a portable manner if that would be of use. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me