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?)