Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:1167 comp.os.linux:55872
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!sol.ctr.columbia.edu!caen!usenet.coe.montana.edu!grapevine.lcs.mit.edu!CATFISH.LCS.MIT.EDU!metcalf
From: metcalf@CATFISH.LCS.MIT.EDU (Chris Metcalf)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 7 Oct 1993 13:34:48 GMT
Organization: MIT Laboratory for Computer Science
Lines: 15
Message-ID: <2915to$crd@GRAPEVINE.LCS.MIT.EDU>
References: <2CB12A8D.17397@news.service.uci.edu> <28umsn$n4d@GRAPEVINE.LCS.MIT.EDU> <CGD.93Oct6131315@eden.cs.berkeley.edu>
NNTP-Posting-Host: catfish.lcs.mit.edu
In article <CGD.93Oct6131315@eden.cs.berkeley.edu>, Chris Demetriou wrote:
>but for {386,Free,Net}BSD, you're definitely wrong, hz is 100,
Unfortunately, dhry typically doesn't find the system-specific value of
HZ, and it will default to 60 in this case. This would have happened under
Linux (which defines only CLK_TCK, not HZ, in its include files); perhaps
*BSD defines HZ, or perhaps dhry had been built with -DHZ=100 under *BSD.
This is still the only way to explain the original discrepancy in timings.
A quick check of MIPS Ultrix 4.3, SunOS 4.1.3, NextStep 2.1 and Vax BSD 4.3
reveals that all of them use HZ=60 when returning a value via times(),
by the way; my guess at HZ in BSD was based on Vax BSD.
--
Chris Metcalf, MIT Laboratory for Computer Science
metcalf@cag.lcs.mit.edu // +1 (617) 253-7766