Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!ns.mcs.kent.edu!kira.cc.uakron.edu!odin.oar.net!malgudi.oar.net!rclnews.eng.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!in1.uu.net!news.gtn.com!knobel.gun.de!usenet
From: andreas@knobel.gun.de (Andreas Klemm)
Newsgroups: comp.os.linux.advocacy,alt.os.linux,comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc
Subject: Re: a monthly FreeBSD magazine (and other *BSD's too)
Date: 4 Jan 1996 18:25:54 GMT
Lines: 71
Message-ID: <4ch63i$6oq@knobel.gun.de>
References: <4ajc07$sb7@unix2.glink.net.hk> <4ca3gu$4nc@news1.halcyon.com> <4cdijr$hjg@toplink1.toplink.net> <4cesep$pb1@agate.berkeley.edu> <4cf40b$9ri@bell.maths.tcd.ie> <4cg8es$1ih@knobel.gun.de> <4cgklb$22ss@info4.rus.uni-stuttgart.de>
NNTP-Posting-Host: knobel.gun.de
X-Newsreader: knews 0.9.3
In-Reply-To: <4cgklb$22ss@info4.rus.uni-stuttgart.de>
To: schweikh@itosun.ito.uni-stuttgart.de (Jens Schweikhardt)
Xref: euryale.cc.adfa.oz.au comp.os.linux.advocacy:31880 alt.os.linux:6813 comp.unix.bsd.freebsd.misc:11361 comp.unix.bsd.netbsd.misc:1710
In article <4cgklb$22ss@info4.rus.uni-stuttgart.de>,
schweikh@itosun.ito.uni-stuttgart.de (Jens Schweikhardt) writes:
>In article <4cg8es$1ih@knobel.gun.de>,
>Andreas Klemm <andreas@knobel.gun.de> wrote:
>>Ok, there are really some benchmarks, where Linux has higher values
>>(I think it were fork or exec calls). But on the whole I made the
>>experience (it's about a year ago) that FreeBSD is the more balanced
>>system. that has much better response times when the system has lot's
>>of things to do.
>>
>>Benchmarks are benchmarks, real life is real life.
>
>Amen. [No, I don't assume you are a Linux enthusiast, Andreas,
>the following is just an observation I made]
I'm an Unix enthusiast and on that way I had to deal with many
many commercial and non commercial flavours of Unix.
About a year or more I was using Linux as well ... (coming from
386BSD). But since FreeBSD 1.1 I'm using this OS .....
But I'm totally unenthusiastic concerning benchmark values...
I really don't wanna see how some people make benchmarks ...
And It's a pain in the ass, how benchmark results are being compared
to go a shout "my os is better than yours"....
>I think one reason Linux _may_ be faster in some
>circumstance is that it is sloppy when it comes to resource
>usage accounting. Last time I checked (1.2.13 if my memory
>does not fail me), getrusage() would report 0 on many
>fields, notably
>
> int ru_inblock; /* block input operations */
> int ru_oublock; /* block output operations */
> int ru_msgsnd; /* messages sent */
> int ru_msgrcv; /* messages received */
> int ru_nsignals; /* signals received */
> int ru_nvcsw; /* voluntary context switches */
> int ru_nivcsw; /* involuntary context switches */
> int ru_nswap; /* swaps */
>
>The nonzero being
>
> struct timeval ru_utime;/* user time used */
> struct timeval ru_stime;/* system time used */
> int ru_maxrss; /* maximum resident set size */
> int ru_idrss; /* integral resident set size */
> int ru_minflt; /* page faults not requiring physical I/O */
> int ru_majflt; /* page faults requiring physical I/O */
>(snipped from Solaris man page -- sorry)
>
>Reading the Linux kernel source I recall having found a comment along
>
> /* Adding the other fields to the proc structure would make
> it real big */
>
>I'm disappointed with linux in this respect. Originally I found
>this getrusage() sloppyness when I compiled GNU time and it always
>gave me 0 values for most fields. I suspected a bug in GNU time,
>but upon investigation I found it was the linux kernel who would
>not record the values.
Well, disappointing isn't it ;-)
--
andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH
Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de -
\/
ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz
apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<<