Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.telstra.net!psgrain!news.ITB.ac.id!news.bapedal.go.id!news.idola.net.id!uunet!in3.uu.net!199.94.215.18!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!howland.erols.net!rill.news.pipex.net!pipex!uknet!usenet1.news.uk.psi.net!uknet!uknet!lyra.csx.cam.ac.uk!news.ox.ac.uk!sable.ox.ac.uk!mbeattie
From: mbeattie@sable.ox.ac.uk (Malcolm Beattie)
Newsgroups: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.unix.bsd.misc,comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy
Subject: Re: Linux vs whatever
Date: 5 Feb 1997 10:46:34 GMT
Organization: Oxford University, England
Lines: 59
Message-ID: <5d9oea$sms@news.ox.ac.uk>
References: <32DFFEAB.7704@usa.net> <5d7rtu$ao9@rzstud2.rz.uni-karlsruhe.de> <5d81q1$8ls@cynic.portal.ca> <5d85sq$27u@rzstud2.rz.uni-karlsruhe.de>
NNTP-Posting-Host: sable.ox.ac.uk
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:156446 comp.os.linux.networking:67421 comp.os.linux.setup:95713 comp.unix.bsd.misc:2292 comp.os.ms-windows.nt.advocacy:52009 comp.os.os2.advocacy:265963
In article <5d85sq$27u@rzstud2.rz.uni-karlsruhe.de>,
Felix Schroeter <uk1o@rzstud2.rz.uni-karlsruhe.de> wrote:
>Hello!
>
>In article <5d81q1$8ls@cynic.portal.ca>,
>Curt Sampson <cjs@cynic.portal.ca> wrote:
>>In article <5d7rtu$ao9@rzstud2.rz.uni-karlsruhe.de>,
>>Felix Schroeter <uk1o@rzstud2.rz.uni-karlsruhe.de> wrote:
>
>>[...]
>>>The 1KB write size was hardcoded in the Linux (2.0.something) NFS
>>>client implementation.
>>[...]
>
>>Try an NFS test with 8 KB blocks, and you'll see just how broken
>>the TCP/IP implementation is.
>
>How do I do that? Patch the kernel or is there an easier way?
Far easier: you use
mount -o rsize=8192,wsize=8192 ...
just as you do on any other Unix system to change the NFS blocksize.
The only difference is that Linux defaults to 1K blocks to keep
compatibility with some *very* old NFS server out there which do
horrible things with larger blocks. Curt is right that you will then
see "how broken" the TCP/IP implementation because the answer is
"not broken". It's not currently very *good* at NFS (which is a small
or negligible part of TCP/IP performance in many environments) but
it's not very bad either. As I've mentioned before, I get 500-700K/s
for writes and 660-700K/s for reads which is not good, not bad and
not broken.
>> There's a very good reason that Linux
>>uses 1 KB blocks for NFS; the stack will crawl on 8 KB blocks
>>because it has to do an extra copy of all the data every time it
>>reassembles the fragments. (I described this in detail in another
>>post.)
500-700K/s must be some meaning of the word "crawl" of which I
was previously unaware. I'd call it more of a lope or a canter.
>Hmmm. Does that adversary effect matter more than the adversary effect
>of *many* *synchronous* writes (yielding a write "performance" of
>about 35 kB/sec)?
The Linux NFS server currently keeps conseratively close to the NFS
specs and writes out what the client sends it as soon as possible.
In the absence of write-gathering by the client that gives you poor
performance iff the client writes in tiny chunks (such as gcc does
if compiled with the wrong options). The current Linux NFS client
doesn't do write-gathering (though it does now multithread RPCs for
reading).
--Malcolm
--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee