*BSD News Article 90664


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!goanna.cs.rmit.edu.au!news.apana.org.au!cantor.edge.net.au!news.teragen.com.au!news.access.net.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!news.maxwell.syr.edu!news.bc.net!rover.ucs.ualberta.ca!gpu3.srv.ualberta.ca!not-for-mail
From: jgg@gpu3.srv.ualberta.ca (J Gunthorpe)
Newsgroups: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc
Subject: Re: User-space file systems.  (Re: Linux vs BSD)
Followup-To: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc
Date: 8 Mar 1997 03:19:19 GMT
Organization: University of Alberta
Lines: 20
Message-ID: <5fqlrn$11ni@pulp.ucs.ualberta.ca>
References: <5e6qd5$ivq@cynic.portal.ca> <5fj9q4$s0i@pulp.ucs.ualberta.ca> <5fjek4$gtm@cynic.portal.ca> <5fl7gf$urs@pulp.ucs.ualberta.ca> <5flmlf$6a3@cynic.portal.ca> <5fmtsp$112u@pulp.ucs.ualberta.ca> <5fp73s$8l$4@halon.vggas.com>
NNTP-Posting-Host: gpu3.srv.ualberta.ca
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:163534 comp.os.linux.networking:71329 comp.os.linux.setup:101664 comp.unix.bsd.bsdi.misc:6263 comp.unix.bsd.misc:2760

James Youngman (JYoungman@vggas.com) wrote:
: In article <5fmtsp$112u@pulp.ucs.ualberta.ca>, jgg@gpu5.srv.ualberta.ca says...
: 
: >Actually, I do have 1 question, you have been saying a protection switch
: >is taking > 20 us (Is it even that much?)
: 
: It almost certainly isn't.   I wrote a program to drive a certain serial 
: protocol, and it turned out that my P100 averaged under 1us CPU time per 
: *message* as measured by time(1), on a benchmark that ran overnight.
 
1us isn't all that much, if you do 4 kernel transitions per k on a NFS
server that is 4us. At 10Mbit you get 1K / 1000K/s = 0.001s, 4us is 0.4%
of the transimission time, at 100 mbit it's 4%. Use 4K blocks and it goes
down to 1%, 0.5% with 8k. With a fast medium you'd be better off using
larger blocks anyhow, fewer delays incurred by other pieces of code (int
handling etc)

(BTW, is time(1) accurate enough to make such a claim, ie is it's
resolution limited by the RT clock?)