*BSD News Article 22403


Return to BSD News archive

Xref: sserve comp.os.386bsd.misc:1235 comp.os.linux:56257
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!not-for-mail
From: bde@kralizec.zeta.org.au (Bruce Evans)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 15 Oct 1993 09:18:50 +1000
Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis
Lines: 29
Message-ID: <29kmoq$8eo@kralizec.zeta.org.au>
References: <2CB12A8D.17397@news.service.uci.edu> <28umsn$n4d@GRAPEVINE.LCS.MIT.EDU>
NNTP-Posting-Host: kralizec.zeta.org.au
Keywords: benchmarks speed downers uppers and other dirty laundry

In <28umsn$n4d@GRAPEVINE.LCS.MIT.EDU> metcalf@CATFISH.LCS.MIT.EDU (Chris Metcalf) writes:

>In article <2CB12A8D.17397@news.service.uci.edu>,
>Jeff Stern <jstern@aris.ss.uci.edu> wrote:
>>
>>Dhrystones per Second [386BSD]:                     8695.7
>>Dhrystones per Second [Linux]:                      5217.4

>Please note that "HZ" on Linux is 100, not 60, unlike most other common
>Unix systems (SunOS, Ultrix, *BSD, etc.).  Since 5217.4 / 8695.7 is
>*exactly* 60/100, it's clear that the time taken under Linux was exactly
>the same as the time taken under 386BSD.  Note also that the "Dhampstone"
>results were identical.

TF sources (at least for old versions) of dhrystone say to be careful about
the value of HZ.  This was poor engineering at the time and is worse now
that no one reads sources ;-) and the POSIX/ANSI standards provide somewhat
portable ways of getting at the the value of HZ (CLOCKS_PER_SEC and
sysconf(_SC_CLK_TCK) or CLK_TCK).

The system tick frequency "hz" is actually 100 under 386BSD too.  But
the tick count gets scaled in the library so that CLOCKS_PER_SEC (the
ANSI value for converting ticks returned by clock() to seconds) is 60
and so that CLK_TCK (the POSIX value for converting ticks returned by
times() to seconds) is 60 too.  The conversion is for backwards
compatibility.  Both 60 and 100 are stupid values for CLOCKS_PER_SEC.
It should have been 1000000.
-- 
Bruce Evans  bde@kralizec.zeta.org.au