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!spool.mu.edu!howland.reston.ans.net!gatech!newsfeed.internetmci.com!uwm.edu!lll-winken.llnl.gov!venus.sun.com!male.EBay.Sun.COM!engnews2.Eng.Sun.COM!peyto!thurlow From: thurlow@peyto.eng.sun.com (Robert Thurlow) Newsgroups: comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.solaris,comp.unix.aix Subject: Re: ISP hardware/software choices (performance comparison) Date: 19 Jan 1996 08:06:41 GMT Organization: Sun Microsystems Computer Corporation Lines: 115 Distribution: inet Message-ID: <4dnjeh$b48@engnews2.Eng.Sun.COM> References: <4cmopu$d35@vixen.cso.uiuc.edu> <4d9has$qo9@park.uvsc.edu> <4de3db$n6a@engnews2.Eng.Sun.COM> <4depms$bi5@park.uvsc.edu> NNTP-Posting-Host: peyto.eng.sun.com Cc: Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:2038 comp.unix.bsd.bsdi.misc:2199 comp.unix.solaris:57757 comp.unix.aix:69134 In article <4depms$bi5@park.uvsc.edu>, Terry Lambert <terry@lambert.org> wrote: >thurlow@peyto.eng.sun.com (Robert Thurlow) wrote: >] You implied that SunOS 5.x was faster because it played fast and >] loose with consistency guarantees. This is simply untrue, and >] I'm calling you on it; consistency has been tightened up in many >] areas, and not made weaker anywhere. If you believe otherwise, >] please be specific. >Client caching prior to NFSv3 violates the protocol specification. You're of course not being specific here once again, but I'd guess you wouldn't mean that client caching of data read from the server must not be done; that would be quite ridiculous. Caching data and checking its consistency with GETATTRs has been done in all useful implementations. Assuming that you mean that caching data written by a program before sending it over the wire, you're still wrong; the NFS protocol spec does not care that your data may be copied to a buffer and sent after your program sees write(2) finish. It cares that the client hold onto data until the server response says that the data is safe. Copying it into the kernel and having the biod's shepard it out later is fine; if your kernel buffer is compromised, you're likely in more trouble than any retry would get you out of, anyway. Commit in NFS V3 doesn't change the client role here as much as it changes the server. Did I fail to read your mind completely? If so, please feel free to *be specific* about your comment. >Server caching of writes violates the protocol specification. Yes, the server acknowledging write requests before having the data safe in stable storage is a protocol violation. No version of SunOS officially supports a way to permit a server to cheat like this, and it's drawn lots of criticism over the years. I remember most of the criticism from when I worked at Convex, which had implemented a per-mount option to enable async writes; I always thought the option was good to have. >4.x did not do server write caching by default. Nor does any other revision of SunOS. >The one possible win (and you have yet to claim it, or anything >other than a blanket statement that 5.x is faster than 4.x, >without providing numbers or rationale) is kernel threading of >the biod's. Oh, horse droppings. There were lots of room for streamlining of the code; for reducing the number of times the data buffer was copied or checksummed; for optimizing VM interactions. SunOS 4.1.x was not the be-all and end-all of NFS; once Sun got back to paying attention to it again, lots was found that could be better. I read the code for some time after I got here, looking at all the things I found to like in the Sun NFS code base. The biod / write clustering ideas are good, but there's lots more as well. >Must I both make and refute your points? Don't bother; so far, you can't lend any real solidity to your own points. >I don't believe you. Please give specific references. I don't keep a machine running SunOS 4.1.x near my desk so that I can provide instant gratification to people who weren't really paying attention the last time they did touch Solaris, but I did get you some performance numbers. I found two low-end machines (SparcStation 1's) running 4.1.3 and 5.5, and ran Connectathon against that same equidistant server to see how they compared. With 5.5, I gave you both NFS V2 and NFS V3 results, and I also tried it from my more modern desktop machine. Given your comment above, I thought writes were most interesting thing to compare. I'll let others talk about SPEC SFS / LADDIS; it's not my area. SS 1, SunOS 4.1.3_U1 wrote 1048576 byte file 10 times in 63.13 seconds (166073 bytes/sec) wrote 1048576 byte file 10 times in 44.58 seconds (235203 bytes/sec) wrote 1048576 byte file 10 times in 43.77 seconds (239528 bytes/sec) SS 1, SunOS 5.5, NFS V2 wrote 1048576 byte file 10 times in 34.41 seconds (304652 bytes/sec) wrote 1048576 byte file 10 times in 35.96 seconds (291524 bytes/sec) wrote 1048576 byte file 10 times in 29.42 seconds (356385 bytes/sec) SS 1, SunOS 5.5, NFS V3 wrote 1048576 byte file 10 times in 28.14 seconds (372500 bytes/sec) wrote 1048576 byte file 10 times in 27.55 seconds (380586 bytes/sec) wrote 1048576 byte file 10 times in 22.94 seconds (457083 bytes/sec) SS 20, SunOS 5.5, NFS V3 wrote 1048576 byte file 10 times in 12.43 seconds (843453 bytes/sec) wrote 1048576 byte file 10 times in 12.6 seconds (869132 bytes/sec) wrote 1048576 byte file 10 times in 12.10 seconds (866174 bytes/sec) Rob T -- Rob Thurlow, thurlow@eng.sun.com There was something fishy about the butler. I think he was a Pisces, probably working for scale. -- Nick Danger, Third Eye