Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!news.vbc.net!alpha.sky.net!news.aimnet.com!ossi.com!agate!howland.reston.ans.net!newsxfer.itd.umich.edu!news.mathworks.com!enews.sgi.com!fido.asd.sgi.com!neteng!lm From: lm@neteng.engr.sgi.com (Larry McVoy) Newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc Subject: Re: TCP latency Followup-To: comp.os.linux.networking,comp.unix.bsd.freebsd.misc Date: 15 Jul 1996 21:36:44 GMT Organization: Silicon Graphics Inc., Mountain View, CA Lines: 54 Message-ID: <4sedlc$f0l@fido.asd.sgi.com> References: <4paedl$4bm@engnews2.Eng.Sun.COM> <4s8cuq$ljd@bertrand.ccs.carleton.ca> <31E7C0DD.41C67EA6@dyson.iquest.net> <4s8tcn$jsh@fido.asd.sgi.com> <DuI083.FH3@kithrup.com> Reply-To: lm@slovax.engr.sgi.com NNTP-Posting-Host: neteng.engr.sgi.com X-Newsreader: TIN [version 1.2 PL2] Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45340 comp.unix.bsd.freebsd.misc:23677 Sean Eric Fagan (sef@kithrup.com) wrote: : In article <4s8tcn$jsh@fido.asd.sgi.com>, : Larry McVoy <lm@slovax.engr.sgi.com> wrote: : >Nobody said that Linux' TCP latency under load is faster, : Part of the reason John is so upset, I think, is because Linux users : (including Larry) used to point out how wonderful Linux' context switching : numbers were -- wonderfully low, making things so fast, right? But it : bombed under load, meaning that anyone who had a heavily-used machine (such Umm, this is old, old news. The context switch alg was rewritten back around 1.3.28, well before the Usenix paper & conference, it it does not bomb at all. In fact, I'll venture a guess that it is the best performing scheduler for multi user, I/O style (your typical Unix workload) in existance. : That doesn't, however, tell the whole story. Sure, you might get a context : switch number from lmbench of three nanoseconds, but how well does that : scale with having twelve million processes, half of which are ftp processes : over your 4GB/s networking interface, and the other half are doing a build : of the entire OS from scratch? (Okay, so I'm exaggerating a bit, and : assuming that hardware will continue to improve ;).) It's a good point, and I hope to start addressing that in 2.0. : >BSD guys: "your benchmark sucks! your numbers are wrong! you mislead the : > world! you suck! whine!" : I could point out that you, Larry, have made it obvious to some people : (including myself) that if we didn't want to discuss Linux with you, we : weren't welcome to discuss *anything* with you. That's unfair. The full context of that was that I wasn't interested in hiring you and allowing you to work on free software if the free software was BSD based. If there's money involved, and I have some say over that money, then, yeah, I want you to work on Linux, I happen to think it is a better use of your time. If you want to get paid, then you have to be willing to play by your employer's rules. : However, I don't know if : you have taken that approach with lmbench; a couple of comments I've heard : have indicated that that might be the case, but I haven't heard or seen : anything from you about it. lmbench is OS neutral. The only "stacking" I do is that people that are fun to talk to generally have more influence on my work than those who scream at me (hey, I'm human just like anyone else - I like talking to people that are fun to talk to. Surprise, surprise.) But I'm very fair about what gets stuck in the benchmark and I routinely work with folks from Intel, Sun, and SGI, as well as people like Linus. If the FreeBSD crowd wanted to be part of the process, that's fine with me. -- --- Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804