Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:1156 comp.os.linux:55831 Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mycroft From: mycroft@duality.gnu.ai.mit.edu (Charles Hannum) Newsgroups: comp.os.386bsd.misc,comp.os.linux Subject: Re: FYI.. benchmarks on linux and 386bsd Date: 06 Oct 1993 09:49:59 GMT Organization: MIT Artificial Intelligence Lab Lines: 22 Message-ID: <MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu> References: <2CB12A8D.17397@news.service.uci.edu> NNTP-Posting-Host: duality.gnu.ai.mit.edu In-reply-to: jstern@aris.ss.uci.edu's message of 5 Oct 93 08:04:29 GMT In article <2CB12A8D.17397@news.service.uci.edu> jstern@aris.ss.uci.edu (Jeff Stern) writes: if someone has done a more careful port and measurement than i, and also if disk speed or tcp/ip access can be measured, either. Two things to say about this before I see any benchmark figures: 1) When diddling lots of small files or other operations on file system metastructure, one must consider that Linux uses write-behind for this and therefore risks serious file system corruption should the machine crash. (Back when Linux crashed a couple of times per day for me, I had no end of file system corruption which caused me to have to reinstall. I assume it does not crash that often now, but this is still a serious bug.) This also makes Linux's file systems faster. 2) I have no idea how TCP/IP performance will measure, but last I knew Linux could not fragment packets, forcing small NFS packet sizes (and thus *extremely* poor NFS write performance) and making it unusable as a gateway.