From: j...@rl.ac.uk (Mr J Pelan)
Subject: GNUseless Debates (Was Re: GNU software on a Linux system)
Date: 1996/06/04
Message-ID: <4p2hi6$11f6@newton.cc.rl.ac.uk>#1/1
X-Deja-AN: 158471251
references: <1JWBCFZN@wuschel.ibb.schwaben.com> <4otge4$u87@kelewan.dandelion.com>
organization: Rutherford Appleton Laboratory, Oxon, UK
newsgroups: gnu.misc.discuss
I cannot believe that people have attempted to quantify the
contribution of the FSF to Linux in terms of percentage of bytes | packages
(in a particular distribution) | executables etc. etc.
Not even counting the CPU cycles spent in FSF programs is going
to form a useful or meaningful metric.
It's like counting the number of books you've read to determine
the impact of the printing press on your life. Pick your own analogy.
Fundamental to the whole issue is recognition of the *principles*
behind freely distributable software, nominally under the GPL
and particularly from the FSF. Ultimately it is *not* the kernel,
the OS, the utilities, the filesystem or whatever set of instructions
that is embodied in the 'free' software that prevails.
Nor is it the particular name given to it - in whatever language.
No one knows who invented the wheel. I doubt many recall the names
of the inventors of the printing press, the laser printer and
the cathode ray tube but all have contributed in some way to
this wonderfully wasteful debate. Get the point, folks ??
In a nutshell, it's not the names that are important -
it's the tools and ideas and the fact that knowledge is a
cumulative process which relies on what has gone before.
"On the shoulders of giants..." etc.
The principles behind the GPL/FSF and Linux will not be taught by puns,
prefixes or random statistics but only through education, experience
and (most of all) success.
I think a Sesame Street song about 'co-operation' is called for...
--
John P.
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: GNUseless Debates (Was Re: GNU software on a Linux system)
Date: 1996/06/05
Message-ID: <DsJ54t.7uH@info.swan.ac.uk>#1/1
X-Deja-AN: 158606325
sender: n...@info.swan.ac.uk
x-nntp-posting-host: iifeak.swan.ac.uk
references: <1JWBCFZN@wuschel.ibb.schwaben.com> <4otge4$u87@kelewan.dandelion.com>
<4p2hi6$11f6@newton.cc.rl.ac.uk>
organization: Institute For Industrial Information Technology
newsgroups: gnu.misc.discuss
In article <4p2hi6$1...@newton.cc.rl.ac.uk> j...@rl.ac.uk (Mr J Pelan) writes:
>I think a Sesame Street song about 'co-operation' is called for...
Please no not the free software song
--
----------------------------------------------////
Yow! 233 microsecond remote host TCP latency ---- beat that
--------------------------------------------////__________ o
Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
From: n...@slothrop1.mitre.org (Jay A. Carlson)
Subject: Re: GNUseless Debates (Was Re: GNU software on a Linux system)
Date: 1996/06/05
Message-ID: <4p4vfv$rev@top.mitre.org>#1/1
X-Deja-AN: 158670087
references: <1JWBCFZN@wuschel.ibb.schwaben.com> <4otge4$u87@kelewan.dandelion.com>
<4p2hi6$11f6@newton.cc.rl.ac.uk> <DsJ54t.7uH@info.swan.ac.uk>
organization: The MITRE Corporation
newsgroups: gnu.misc.discuss
In article <DsJ54t....@info.swan.ac.uk>,
Alan Cox <iia...@iifeak.swan.ac.uk> wrote:
> In article <4p2hi6$1...@newton.cc.rl.ac.uk> j...@rl.ac.uk (Mr J Pelan) writes:
>> I think a Sesame Street song about 'co-operation' is called for...
> Please no not the free software song
I'm surprised it hasn't come up yet. Probably the easiest source of
it is jwz, who ended up fighting huge battles with the FSF over Lucid
Emacs. It's on his home page
(http://home.netscape.com/people/jwz/index.html) with the great
filepath:
http://home.netscape.com/people/jwz/why-cooperation-with-rms-is-impossible.au
> Yow! 233 microsecond remote host TCP latency ---- beat that
You should really give us a pointer to how you got this number...it's
a nice number, but kinda meaningless out of context.
--
Jay Carlson n...@kagoona.mitre.org n...@nop.com
The MITRE Corporation, Bedford MA
Flat text is just *never* what you want. ---stephen p spackman
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: TCP latency (Re: GNUseless Debates
(Was Re: GNU software on a Linux system))
Date: 1996/06/06
Message-ID: <4p7cne$2ri@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 158979349
references: <1JWBCFZN@wuschel.ibb.schwaben.com> <4p2hi6$11f6@newton.cc.rl.ac.uk>
<DsJ54t.7uH@info.swan.ac.uk> <4p4vfv$rev@top.mitre.org>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: gnu.misc.discuss
In article <4p4vfv$...@top.mitre.org>,
Jay A. Carlson <n...@slothrop1.mitre.org> wrote:
>In article <DsJ54t....@info.swan.ac.uk>,
>Alan Cox <iia...@iifeak.swan.ac.uk> wrote:
>>
>> Yow! 233 microsecond remote host TCP latency ---- beat that
>
>You should really give us a pointer to how you got this number...it's
>a nice number, but kinda meaningless out of context.
It's the "lmbench" benchmark suite. It's a a good benchmark (you can
find it on "http://www.sgi.com/~lm/" or something reasonably close to
that).
The reason Alan is happy is that Linux used to be pretty bad at
high-speed networking.
The reason the 233 usec number is nice is that Larry McVoy (who does
lmbench) reports that he got that number with the pre2.0.9 kernel
between two P133's on a 100Mbps fast ethernet network.
And the _really_ nice thing is that he also says that it's the best
result he's ever seen with lmbench, with a (noticeably faster)
UltraSparc coming in second at 280usec..
Yes, this was _completely_ off-topic, but it was more interesting than
the "on-topic" discussion, and it gave me the perfect opportunity to
brag. Besides, you asked for it.
Linus
From: se...@solutions.solon.com (Peter Seebach)
Subject: Re: TCP latency (Re: GNUseless Debates
(Was Re: GNU software on a Linux system))
Date: 1996/06/07
Message-ID: <4pa83i$2km@solutions.solon.com>#1/1
X-Deja-AN: 159062652
references: <1JWBCFZN@wuschel.ibb.schwaben.com> <DsJ54t.7uH@info.swan.ac.uk>
<4p4vfv$rev@top.mitre.org> <4p7cne$2ri@linux.cs.Helsinki.FI>
organization: Usenet Fact Police (Undercover)
reply-to: se...@solon.com
newsgroups: gnu.misc.discuss
In article <4p7cne$...@linux.cs.Helsinki.FI>,
Linus Torvalds <torva...@linux.cs.Helsinki.FI> wrote:
>The reason Alan is happy is that Linux used to be pretty bad at
>high-speed networking.
>Yes, this was _completely_ off-topic, but it was more interesting than
>the "on-topic" discussion, and it gave me the perfect opportunity to
>brag. Besides, you asked for it.
Okay, so is it Linux's fault or NetBSD's that using a Linux machine as a
gateway between two NetBSD machines works fine *unless* those machines are
using RFC 1323, in which case, a 300 ms (14.4 PPP) link will average about 30
seconds round trip time?
I'm inclined to blame Linux, because the machines otherwise work fine, and
even get *incredibly* good performance on long-distance connections.
This is even less on topic, and should probably go to email.
-s
--
Peter Seebach - se...@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al. See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency (Re: GNUseless Debates
(Was Re: GNU software on a Linux system))
Date: 1996/06/09
Message-ID: <4pe4fo$7gi@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 159265309
references: <1JWBCFZN@wuschel.ibb.schwaben.com> <4p4vfv$rev@top.mitre.org>
<4p7cne$2ri@linux.cs.Helsinki.FI> <4pa83i$2km@solutions.solon.com>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: gnu.misc.discuss
In article <4pa83i$...@solutions.solon.com>,
Peter Seebach <se...@solon.com> wrote:
>
>Okay, so is it Linux's fault or NetBSD's that using a Linux machine as a
>gateway between two NetBSD machines works fine *unless* those machines are
>using RFC 1323, in which case, a 300 ms (14.4 PPP) link will average about 30
>seconds round trip time?
Umm. RFC1323 as in high-speed TCP extensions?
If Linux acts as a router in between the two machines, it won't even
_look_ at the TCP stuff - it's just tossing IP packets back and forth.
In short, it definitely sounds like a NetBSD problem.
(Although on a 14.4 PPP link it doesn't seem to make much sense to have
the high-speed TCP extensions, so maybe NetBSD is just telling you that
you should re-think the configuration ;-)
Linus
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: TCP latency
Date: 1996/06/09
Message-ID: <4pf7f9$bsf@white.twinsun.com>#1/1
X-Deja-AN: 159323885
references: <1JWBCFZN@wuschel.ibb.schwaben.com> <4p4vfv$rev@top.mitre.org>
<4p7cne$2ri@linux.cs.Helsinki.FI> <4pa83i$2km@solutions.solon.com>
<4pe4fo$7gi@linux.cs.Helsinki.FI> <4paedl$4bm@engnews2.Eng.Sun.COM>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
torva...@linux.cs.Helsinki.FI (Linus Torvalds) writes:
> In short, it definitely sounds like a NetBSD problem.
I agree. It's a popular problem area these days. For another example,
see <URL:news:4paedl$4bm@engnews2.Eng.Sun.COM>, where Sun announces
fixes to severe problems with Solaris 2.5 (and 2.5.1) TCP performance
when communicating over slow links. (In our case, the intervening node
was a Cisco terminal server, but it wasn't Cisco's fault.) BSD and
Linux networking implementers should read that news article; it
describes some entertaining gotchas.
From: k...@khms.westfalen.de (Kai Henningsen)
Subject: Re: TCP latency
Date: 1996/06/10
Message-ID: <6AbFLHBUcsB@khms.westfalen.de>#1/1
X-Deja-AN: 159529131
references: <1JWBCFZN@wuschel.ibb.schwaben.com>
comment: Unsolicited commercial mail will incur an US$100 handling
fee per received mail.
organization: Organisation? Me?! Are you kidding?
x-no-junk-mail: I do not want to get *any* junk mail.
newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
egg...@twinsun.com (Paul Eggert) wrote on 09.06.96 in <4pf7f9$...@white.twinsun.com>:
> I agree. It's a popular problem area these days. For another example,
> see <URL:news:4paedl$4bm@engnews2.Eng.Sun.COM>, where Sun announces
> fixes to severe problems with Solaris 2.5 (and 2.5.1) TCP performance
> when communicating over slow links. (In our case, the intervening node
> was a Cisco terminal server, but it wasn't Cisco's fault.) BSD and
> Linux networking implementers should read that news article; it
> describes some entertaining gotchas.
Didn't some recent versions of the Linux kernel _also_ have severe
problems with Solaris machines? I seem to remember that the conclusion was
that the Solaris machines were doing something wrong, but the Linux kernel
was changed to work around this anyway.
This _was_ about TCP performance.
Might it have been the same problem?
Kai
--
Current reorgs: news.groups, news.admin.net-abuse.* (see nana.misc)
Internet: k...@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/private/khms/
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/06/14
Message-ID: <4proiu$b7v@news.swan.ac.uk>#1/1
X-Deja-AN: 160319229
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
<6AbFLHBUcsB@khms.westfalen.de>
organization: Institute For Industrial Information Technology
newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
In article <6AbFLHBU...@khms.westfalen.de> k...@khms.westfalen.de (Kai Henningsen)
writes:
>Didn't some recent versions of the Linux kernel _also_ have severe
>problems with Solaris machines? I seem to remember that the conclusion was
>that the Solaris machines were doing something wrong, but the Linux kernel
>was changed to work around this anyway.
Sun have also released fixes to the problem in general for Solaris 2.51 and
patches are available from Sun. Contact your vendor
--
----------------------------------------------////
Yow! 233 microsecond remote host TCP latency ---- beat that
--------------------------------------------////__________ o
Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
From: r...@cup.hp.com (Rick Jones)
Subject: Re: TCP latency
Date: 1996/06/19
Message-ID: <4qa291$t0t@hpindda.cup.hp.com>#1/1
X-Deja-AN: 161089840
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
<6AbFLHBUcsB@khms.westfalen.de> <4proiu$b7v@news.swan.ac.uk>
followup-to: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
organization: Hewlett-Packard's Network Computing Division
reply-to: r...@cup.hp.com
newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
Alan Cox (iia...@iifeak.swan.ac.uk) wrote:
: ----------------------------------------------////
: Yow! 233 microsecond remote host TCP latency ---- beat that
: --------------------------------------------////__________ o
: Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
Is that round-trip, or one-way?
Some of the netperf TCP_RR results in the netperf database might be
interesting. There are some = 162 usec one-way figures there.
The database can always use additional submittals :)
rick jones
http://www.cup.hp.com/netperf/NetperfPage.html
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/06/20
Message-ID: <4qa9c0$39v@fido.asd.sgi.com>#1/1
X-Deja-AN: 161104112
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
<6AbFLHBUcsB@khms.westfalen.de> <4proiu$b7v@news.swan.ac.uk>
<4qa291$t0t@hpindda.cup.hp.com>
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
Rick Jones (r...@cup.hp.com) wrote:
: Alan Cox (iia...@iifeak.swan.ac.uk) wrote:
: : ----------------------------------------------////
: : Yow! 233 microsecond remote host TCP latency ---- beat that
: : --------------------------------------------////__________ o
: : Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
: Is that round-trip, or one-way?
As the guy that got those numbers: it's round trip. FreeBSD numbers on
the same hardware (the *same* hardware, it's dual boot linux and bsd)
are around 550.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
From: sth...@nethelp.no (Steinar Haug)
Subject: Re: TCP latency
Date: 1996/06/20
Message-ID: <4qad7d$a5l@verdi.nethelp.no>#1/1
X-Deja-AN: 161119396
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
organization: Nethelp Consulting, Trondheim, Norway
newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
[Larry McVoy]
| Rick Jones (r...@cup.hp.com) wrote:
| : Alan Cox (iia...@iifeak.swan.ac.uk) wrote:
|
| : : ----------------------------------------------////
| : : Yow! 233 microsecond remote host TCP latency ---- beat that
| : : --------------------------------------------////__________ o
| : : Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
|
| : Is that round-trip, or one-way?
|
| As the guy that got those numbers: it's round trip. FreeBSD numbers on
| the same hardware (the *same* hardware, it's dual boot linux and bsd)
| are around 550.
So what kind of hardware is it?
Steinar Haug, Nethelp consulting, sth...@nethelp.no
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/06/20
Message-ID: <4qaui4$o5k@fido.asd.sgi.com>#1/1
X-Deja-AN: 161158063
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
<4qad7d$a5l@verdi.nethelp.no>
followup-to: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc
Steinar Haug (sth...@nethelp.no) wrote:
: [Larry McVoy]
: | Rick Jones (r...@cup.hp.com) wrote:
: | : Alan Cox (iia...@iifeak.swan.ac.uk) wrote:
: |
: | : : ----------------------------------------------////
: | : : Yow! 233 microsecond remote host TCP latency ---- beat that
: | : : --------------------------------------------////__________ o
: | : : Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
: |
: | : Is that round-trip, or one-way?
: |
: | As the guy that got those numbers: it's round trip. FreeBSD numbers on
: | the same hardware (the *same* hardware, it's dual boot linux and bsd)
: | are around 550.
: So what kind of hardware is it?
P5@133, ASUS motherboard (I can't remember the model number but it is
the really common one, pipeline burst cache), SMC 100Mbit cards using
the DEC tulip chip (nice job, DEC).
It's a pretty cool number since Sun's was the next best at 280 on a pair
of Ultrasparcs - CPUs that have about 2x the integer perf of the P5s.
I would imagine that Linux on the ultras would get that number down to
about a 140 usecs or so round trip.
Note that all is not well in Linux land, however, it scales for shit.
When you have multiple sockets in time wait (or connected) the Linux
numbers quickly slow down to about the same as the FreeBSD numbers for
latency. Linux needs to rethink it's lookup code.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
From: sth...@nethelp.no (Steinar Haug)
Subject: Re: TCP latency
Date: 1996/06/20
Message-ID: <4qc60n$d8m@verdi.nethelp.no>#1/1
X-Deja-AN: 161248184
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.freebsd.misc
organization: Nethelp Consulting, Trondheim, Norway
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.freebsd.misc
[Larry McVoy]
| : So what kind of hardware is it?
|
| P5@133, ASUS motherboard (I can't remember the model number but it is
| the really common one, pipeline burst cache), SMC 100Mbit cards using
| the DEC tulip chip (nice job, DEC).
|
| It's a pretty cool number since Sun's was the next best at 280 on a pair
| of Ultrasparcs - CPUs that have about 2x the integer perf of the P5s.
| I would imagine that Linux on the ultras would get that number down to
| about a 140 usecs or so round trip.
I see similar effects here. Tried a test varying only *one* side. A P133
running FreeBSD 2.2-960501-SNAP, against an AMD 5x86-133 overclocked to
160 MHz, running either Linux 2.0.0 or FreeBSD 2.2-960612-SNAP. 21140
card at both ends, but running at 10 Mbit/s not 100 (might try the 100
Mbit/s a bit later tonight). The numbers I got with lat_tcp (I assume
that's the one you used :-) were:
Pentium local 250 usec
AMD Linux local 330 usec
AMD FreeBSD local 350 usec
AMD Linux -> Pentium 420 usec
AMD FreeBSD -> Pentium 520 usec
So the difference is quite noticeable. Wish I had another P133 here to
test with, but unfortunately I don't.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
From: "John S. Dyson" <dy...@inuxs.att.com>
Subject: Re: TCP latency
Date: 1996/06/27
Message-ID: <31D2F0C6.167EB0E7@inuxs.att.com>#1/1
X-Deja-AN: 163336858
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
content-type: text/plain; charset=us-ascii
organization: Lucent Technologies, Columbus, Ohio
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.freebsd.misc
x-mailer: Mozilla 2.0 (X11; I; FreeBSD 2.1-STABLE i386)
Steinar Haug wrote:
> Pentium local 250 usec
> AMD Linux local 330 usec
> AMD FreeBSD local 350 usec
> AMD Linux -> Pentium 420 usec
> AMD FreeBSD -> Pentium 520 usec
>
> So the difference is quite noticeable. Wish I had another P133 here to
> test with, but unfortunately I don't.
>
All this TCP latency discussion is interesting, but how does this
significantly impact performance when streaming data through the
connection? Isn't TCP a streaming protocol? Was TTCP used in these
tests? I would think that if you were doing that many connections per
second, TTCP would be better generally (like for WWW servers.)
Isn't this just a connection latency? Hmmm... Data
througput starts overshadowing connection latency quickly. Also,
there is some latency that does not really imply CPU usage...
Interesting data point, but really doesn't appear to impact system
performance much if at all.
Isn't meaningless benchmarking fun!!!
John
From: Terry Lambert <te...@lambert.org>
Subject: Re: TCP latency
Date: 1996/07/02
Message-ID: <31D9AF0D.4C3AE08C@lambert.org>#1/1
X-Deja-AN: 163367621
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
content-type: text/plain; charset=us-ascii
organization: Me
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.freebsd.misc
x-mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
John S. Dyson wrote:
] Steinar Haug wrote:
]
] > Pentium local 250 usec
] > AMD Linux local 330 usec
] > AMD FreeBSD local 350 usec
] > AMD Linux -> Pentium 420 usec
] > AMD FreeBSD -> Pentium 520 usec
] >
] > So the difference is quite noticeable. Wish I had another P133
] > here to test with, but unfortunately I don't.
]
] All this TCP latency discussion is interesting, but how does this
] significantly impact performance when streaming data through the
] connection? Isn't TCP a streaming protocol?
It's relevent for Samba and HTTP, which are request/response
protocols which tend to not take advantage of the sliding
windows. For these protocols, the latency per packet counts
per packet instead of FTP or similar protocols, where it counts
only once per packet run.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/02
Message-ID: <31D9ECC5.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 163632623
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.freebsd.misc
x-mailer: Mozilla 3.0b5Gold (X11; I; FreeBSD 2.2-CURRENT i386)
Terry Lambert wrote:
>
> John S. Dyson wrote:
> ] Steinar Haug wrote:
> ]
> ] > Pentium local 250 usec
> ] > AMD Linux local 330 usec
> ] > AMD FreeBSD local 350 usec
> ] > AMD Linux -> Pentium 420 usec
> ] > AMD FreeBSD -> Pentium 520 usec
> ] >
> ] > So the difference is quite noticeable. Wish I had another P133
> ] > here to test with, but unfortunately I don't.
> ]
> ] All this TCP latency discussion is interesting, but how does this
> ] significantly impact performance when streaming data through the
> ] connection? Isn't TCP a streaming protocol?
>
> It's relevent for Samba and HTTP, which are request/response
> protocols which tend to not take advantage of the sliding
> windows. For these protocols, the latency per packet counts
> per packet instead of FTP or similar protocols, where it counts
> only once per packet run.
>
So I guess it is time to look at it. Isn't this likely an
artifact of the sofware interrupt/ast type scheduling in the
BSD code?
John
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency
Date: 1996/07/04
Message-ID: <4rfkje$am5@linux.cs.Helsinki.FI>
X-Deja-AN: 163699142
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4qaui4$o5k@fido.asd.sgi.com>
<4qc60n$d8m@verdi.nethelp.no> <31D2F0C6.167EB0E7@inuxs.att.com>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31D2F0C6.167EB...@inuxs.att.com>,
John S. Dyson <dy...@inuxs.att.com> wrote:
>Steinar Haug wrote:
>
>> Pentium local 250 usec
>> AMD Linux local 330 usec
>> AMD FreeBSD local 350 usec
>> AMD Linux -> Pentium 420 usec
>> AMD FreeBSD -> Pentium 520 usec
>>
>> So the difference is quite noticeable. Wish I had another P133 here to
>> test with, but unfortunately I don't.
>>
>All this TCP latency discussion is interesting, but how does this
>significantly impact performance when streaming data through the
>connection? Isn't TCP a streaming protocol?
No. TCP is a _stream_ protocol, but that doesn't mean that it is
necessarily a _streamING_ protocol.
Latency and bandwidth are both crucial, and they are almost totally
distinct (ie the correlation is by no means very strong). A high
bandwidth is important for the kinds of applications that use TCP for
just large writes and no synchronization (ftp is the obvious example),
and that's where you see the "streaming" behaviour.
But many applications don't really care about bandwith past a certain
point (they might need only a few kB/s), but latency can be supremely
important. The TCP connection might be used for some kind of interactive
protocol, where you send lots of small request/reply packets back and
forth (*).
(*) Now somebody is bound to bring up UDP, but no, UDP is _not_ a good
protocol for many of these things. If you need good performance over
wildly different network connections, and require in-order and reliable
connections, UDP sucks. You'd end up doing all the work TCP does in user
space instead, and TCP would be a lot more efficient. UDP is fine for
_certain_ applications, but if you think you should always use UDP for
request/reply, you're wrong.
Of course, a lot of applications need _both_ good throughput and low
latency. Their behaviour might even change depending on what you do. For
X, for example, you normally need low latency for good performance, but
if you're sending large bitmaps you need throughput (generally, this is
one of the advantages of TCP over UDP: it doesn't set any size limits
and it's efficient under different circumstances).
The particular benchmark here (lmbench's "lat_tcp") is just sending a
single byte ping-pong over a TCP connection, just to get the latency
number for a simple kind of connected protocol. I think Larry did the
benchmark because he noticed that this latency was one of the deciding
factors for Oracle performance..
> Data
>througput starts overshadowing connection latency quickly.
Definitely not. It depends on the application, and neither is "more
important". However, getting good throughput is usually a lot easier
than getting good latency - often you can just increase buffer sizes
(increase the TCP window, increase the MTU). Getting lower latency is a
lot harder: you have to actually fix things. That's why I personally
think latency numbers are a lot more indicative of system performance.
Oh, btw, think of memory system performance - the issues are very
similar. You obviously want good throughput ("memcpy speed") for lots
of things, but for other things latencies ("linked list speed") are more
important. The two are totally different (there is a correlation, but
it's actually pretty small, and can even be negative - you may sacrifice
latency for better throughput or vice versa).
For example, for good memory throughput you want long cache-lines and a
wide memory path (and if you want to be fancy you do readahead etc).
This is an "easy" issue, the same way TCP bandwidth is "easy": you can
just throw more hardware at it. It's not fundamentally hard to get good
throughput on SMP systems, for example.
Contrast that to low latency, which is usyally a "hard" problem: instead
of just throwing more hardware at it, you have to actually _design_ the
hardware (add a cache, or just plain get _faster_ hardware - it's
essentially a quality vs quantity thing). As a result, low latency
memory is a lot harder for SMP, for example.
Again, it depends on the application whether low latency is more
important than high bandwidth. Low latency is _critical_ for pointer
jumping (and gcc is one example of a program that does a lot of pointer
jumping), while high throughput is critical for a lot of scientific
number crunching.
>Interesting data point, but really doesn't appear to impact system
>performance much if at all.
>
>Isn't meaningless benchmarking fun!!!
Wrong. TCP latency is very important indeed. If you think otherwise,
you're probably using TCP just for ftp.
NOTE! I want to make it abundantly clear that TCP throughput is _also_
important, and that's actually what you see for a lot of "traditional"
TCP applications. And Linux gets very good throughput as well, I'm not
trying to make excuses here.
Think Quality (latency) vs Quantity (throughput). Both are important,
and depending on what you need, you may want to prioritize one or the
other (and you obviously want both, but that can sometimes be
prohibitively expensive).
Linus
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/05
Message-ID: <31DC8EBA.41C67EA6@dyson.iquest.net>
X-Deja-AN: 163786206
sender: r...@dyson.iquest.net
x-nntp-posting-host: dyson.iquest.net
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4qaui4$o5k@fido.asd.sgi.com>
<4qc60n$d8m@verdi.nethelp.no> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI>
bcc: t...@dyson.iquest.net
content-type: text/plain; charset=us-ascii
fcc: /usr6/root/nsmail/Sent
x-mozilla-news-host: snews2.zippo.com
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5Gold (X11; I; FreeBSD 2.2-CURRENT i386)
Linus Torvalds wrote:
>
> In article <31D2F0C6.167EB...@inuxs.att.com>,
> John S. Dyson <dy...@inuxs.att.com> wrote:
> >Steinar Haug wrote:
> >
> >> Pentium local 250 usec
> >> AMD Linux local 330 usec
> >> AMD FreeBSD local 350 usec
> >> AMD Linux -> Pentium 420 usec
> >> AMD FreeBSD -> Pentium 520 usec
> >>
> >> So the difference is quite noticeable. Wish I had another P133 here to
> >> test with, but unfortunately I don't.
> >>
> >All this TCP latency discussion is interesting, but how does this
> >significantly impact performance when streaming data through the
> >connection? Isn't TCP a streaming protocol?
>
> No. TCP is a _stream_ protocol, but that doesn't mean that it is
> necessarily a _streamING_ protocol.
>
Okay, you CAN kind-of misuse it by using TCP for a single transaction,
like simple HTTP transactions. That is the reason for the implementation
of the so far little used protocol extension TTCP. (FreeBSD has it
for example.) Also, there are advanced features in www browsers/servers
like Netscape where the connection is kept up for more than one transaction.
(Why be silly to re-establish a connection, when you could have kept the
previous one up?)
> But many applications don't really care about bandwith past a certain
> point (they might need only a few kB/s), but latency can be supremely
> important. The TCP connection might be used for some kind of interactive
> protocol, where you send lots of small request/reply packets back and
> forth (*).
>
With many/most web pages being 1-2K, the transfer rate starts to
overcome the latency, doesn't it? For very small transactions, maybe
100 bytes the latency is very very important. How many web pages are that
small???
Now I can understand that there might be specific applications where there
are only a few hundred bytes transferred, but those appear to be in the
minority. (Especially where it is bad that a latency of 100usecs worse
is bad in a SINGLE THREADED environment.) Note -- in most single threaded
environments, 100usecs is in the noise.
> (*) Now somebody is bound to bring up UDP, but no, UDP is _not_ a good
> protocol for many of these things. If you need good performance over
> wildly different network connections, and require in-order and reliable
> connections, UDP sucks. You'd end up doing all the work TCP does in user
> space instead, and TCP would be a lot more efficient. UDP is fine for
> _certain_ applications, but if you think you should always use UDP for
> request/reply, you're wrong.
>
Never mentioned UDP -- TTCP is better though. TTCP gives some of the
advantages of UDP though.
> > Data
> >througput starts overshadowing connection latency quickly.
>
> Definitely not. It depends on the application, and neither is "more
> important". However, getting good throughput is usually a lot easier
> than getting good latency - often you can just increase buffer sizes
> (increase the TCP window, increase the MTU). Getting lower latency is a
> lot harder: you have to actually fix things. That's why I personally
> think latency numbers are a lot more indicative of system performance.
>
There are a few applications that need very low latency, but remember,
latency != CPU usage also. You might have a 100usec additional latency,
but that might be buried by another concurrent connection... As long
as the latency doesn't tie up the CPU, and you have many multiple streams,
it isn't very important, is it? (Unless you have realtime requirements
in the region of 100usecs.) I guess it is possible that the application
have a 100usec realtime requirement, isn't it? :-).
Retorical question: are all of the pipelined CPU's "low quality" because
their latency is long, but their execution rate is fast??? They do
things in parallel, don't they? (Scheduling 101 :-)).
>
> Wrong. TCP latency is very important indeed. If you think otherwise,
> you're probably using TCP just for ftp.
>
I guess FreeBSD-current makes it up by being faster with the fork/execs
done by simple www servers. (About 1.1msecs on a properly configured
P5-166.)
>
> Think Quality (latency) vs Quantity (throughput). Both are important,
> and depending on what you need, you may want to prioritize one or the
> other (and you obviously want both, but that can sometimes be
> prohibitively expensive).
>
The quality vs. quantity is interesting, since I consider for certain
applications, slower transfer rates *significantly* impact quality.
The ability to handle many many concurrent connections seriously impacts
quality. Some very low quality trivial algorithms might work well in the
single threaded trivial cases such as lmbench. (Remember the 1.2.x scheduling
algorithm that had a really bad scalability?) One connection with a 100usec
latency difference makes little difference. I guess that I am thinking in
terms of large scale servers, where the perf is needed and not single
user NT-clones... IMO, The most valid measurement is to measure the
quality (latency) with 1000's of connections...
Remember, many times, the more efficient algorithms under load (when you
need them) are sometimes a bit slower in the degenerate case (trivial
benchmarks.) We have done the same thing with our pageout algorithm
in FreeBSD-current. We have TWO algorithms that each work better under
different conditions. Unfortunately, our default algorithm that works
best under load is slower than our algorithm that works fastest under
light load. Of course, in order to support our user base the best, we
sacrifice a bit of our benchmark perf, to make our system run better
under load, when the perf is really needed. If we enable the low quality LRU
algorithm, the perf would look better on certain TRIVIAL benchmarks.
Like I implied before, it doesn't appear that the benchmark measures
what users will see as "performance." The FreeBSD team consiously sacrifices
benchmark perf for "quality." (That is real world perf.)
I guess what I am saying is that the results would look more credible
with a real load, where the networking code would be exercised more.
One last comment -- if you notice that FreeBSD isn't that much slower in
the localhost case, it appears that the difference is that the driver could
use some work. It appears that we could be seeing the performance difference
of the specific DRIVER under LIGHT load :-), NOT the networking code
specifically.
John
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency
Date: 1996/07/06
Message-ID: <4rlf6i$c5f@linux.cs.Helsinki.FI>
X-Deja-AN: 163990308
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31DC8EBA.41C67...@dyson.iquest.net>,
John S. Dyson <t...@dyson.iquest.net> wrote:
>Linus Torvalds wrote:
>>
>> No. TCP is a _stream_ protocol, but that doesn't mean that it is
>> necessarily a _streamING_ protocol.
>>
>Okay, you CAN kind-of misuse it by using TCP for a single transaction,
>like simple HTTP transactions.
That's NOT misusing TCP. You're showing a very biased view here. Just
because YOU like streaming TCP does NOT mean that TCP should necessarily
be streaming. There is a lot more to TCP than just TCP windows.
TCP has lots of huge advantages over just about _anything_ else, which
makes it the protocol of choice for most things.
- It's everywhere. Just about _everything_ supports TCP, and unless you
want to paint yourself into a small corner of the market you'd better
use TCP these days (UDP matches this point too, but you can forget
about IPX, appletalk and TTCP).
- it works reasonably well for lots of different things. UDP is useless
for lots of things (nobody sane would ever have done http with UDP,
it simply would have been a bitch)
- it's there, and it's there NOW. It's not some great new technology
that will revolutionalize the world in ten years. It WORKS.
> That is the reason for the implementation
>of the so far little used protocol extension TTCP. (FreeBSD has it
>for example.) Also, there are advanced features in www browsers/servers
>like Netscape where the connection is kept up for more than one transaction.
>(Why be silly to re-establish a connection, when you could have kept the
>previous one up?)
We're not talking about _connection_ latency, we're talking about
_packet_ latency. The tests quoted here have not been about how fast
you can connect to a host, but how fast you can pass packets back and
forth over TCP. That's exactly the kind of thing you see with http and
keeping the connection open, or with NFSv3 over TCP, or with a
distributed lock manager (..databases) that has TCP connections to the
clients or with a _lot_ of things.
>With many/most web pages being 1-2K, the transfer rate starts to
>overcome the latency, doesn't it? For very small transactions, maybe
>100 bytes the latency is very very important. How many web pages are that
>small???
1-2kB is nowhere _near_ streaming. Over normal ethernet 1460 bytes is
still just one packet, to start seeing TCP in a streaming environment
you have to actually fill up your window (which for any reasonable TCP
implementation is usually at least 8kB). And most web pages probably
are a lot smaller than 8kB.. (and despite all the hype, let's not get
stuck on www: on a smaller scale something like a lock manager can be a
lot more performance critical for some application, for example)
Again, I want to point out that I'm not arguing against throughput here:
throughput is at _least_ as important as latency for TCP, and most
traditional uses of TCP are definitely throughput-bound. So don't get
the idea that I find throughput unimportant - I just want to point out
that latency _does_ matter, and can matter a lot more than throughput
for some applications. And those applications aren't just "make
believe": they are real-world everyday stuff.
>Now I can understand that there might be specific applications where there
>are only a few hundred bytes transferred, but those appear to be in the
>minority. (Especially where it is bad that a latency of 100usecs worse
>is bad in a SINGLE THREADED environment.) Note -- in most single threaded
>environments, 100usecs is in the noise.
Again, latency is probably more important than throughput up to around
10kB or so (TCP window), and it can actually get MORE important for a
multithreading system. Because low latency can also mean that the
system spends less time sending out the packets, so it can go on serving
the _next_ client faster.
>There are a few applications that need very low latency, but remember,
>latency != CPU usage also.
Sure, latency != CPU use, and some systems definitely try to maximize
throughput at the cost of latency. For example, the whole idea with the
Nagle algorithm for TCP is to get better throughput at the cost of some
latency - but only when we notice that the latency of the network itself
is higher than that of the application (ie Nagle doesn't take effect
until for the _next_ packet if we haven't had confirmation for the
previous one).
However, in many cases latency _is_ CPU use, and we can't just gloss
over latency with taking advantage of concurrency. It works sometimes,
but it can be very bad for other things (maybe you've followed the
threads on comp.arch about the "Tera" architecture, where essentially
the same thing has been discussed wrt memory latency).
You tend to always bring up "heavy load" as an argument against low
latency, and that is not really the answer either. You _can_ hide
latency with concurrency, but that definitely does not work for
everything. Dismissing numbers because they were done under conditions
where the machine wasn't doing anything else is as stupid as dismissing
numbers that were done under load. Can't you see that?
>Retorical question: are all of the pipelined CPU's "low quality" because
>their latency is long, but their execution rate is fast??? They do
>things in parallel, don't they? (Scheduling 101 :-)).
Actually, they do things in parallell, but they don't make latency
worse. They just take advantage of the fact that they have multiple
("independent") hardware units that do separate work, and thus they can
improve throughput by trying to avoid letting those hardware units be
idle. And the end result is that the latency for a bunch of operations
can be lower, even thought the latency for just one operation has stayed
the same.
The same goes for SMP: the latency of a single CPU is not made worse by
having another CPU do other things - they can work in parallell (yes,
this is oversimplified, and in some cases latency _does_ get worse, but
that is generally considered a real problem - it's definitely not a
feature).
Oh, and just about _anybody_ would prefer one CPU that is twice as fast
than two separate CPU's. It is almost _always_ faster (and for some
things it will be twice as fast), and the only problem with that is that
it is almost always also a LOT more expensive. This was one of my
points in the previous message: throughput is "easy", while latency is
"hard".
That's why hardware designers (and software people too) often improve
throughput instead of improving latency. Simply because it's _easier_ to
do. Not because throughput is any more important than latency.
(On some level throughput _equals_ latency - throughput can be seen just
as the "batch latency". So you could say that I'm arguing against
looking at latency from two different sides: latency for one operation,
and latency for a "batch" of operations. BOTH are supremely imporant,
and anybody who thinks otherwise is not really seeing the full picture).
>> Wrong. TCP latency is very important indeed. If you think otherwise,
>> you're probably using TCP just for ftp.
>>
>I guess FreeBSD-current makes it up by being faster with the fork/execs
>done by simple www servers. (About 1.1msecs on a properly configured
>P5-166.)
For www servers, the most important part is probably low context switch
overhead and good per-packet and connection latency (and note that the
lmbench numbers that have been floating around are _not_ connection
latency, they are "packet" latency - the two are likely to have a strong
correlation, but are not necessarilt the same thing). The fork/exec
stuff isn't as large a problem because most good servers will try to
pre-fork, exactly because they want low latency.
That's not to say I don't want to beat BSD: do you have actual
comparisons against Linux? I suspect that the problem with Linux might
be user-level overhead of the shared libraries, not the actual fork/exec
itself - if you have numbers with shared/static binaries I'd be very
interested indeed..
>> Think Quality (latency) vs Quantity (throughput). Both are important,
>> and depending on what you need, you may want to prioritize one or the
>> other (and you obviously want both, but that can sometimes be
>> prohibitively expensive).
>>
>The quality vs. quantity is interesting, since I consider for certain
>applications, slower transfer rates *significantly* impact quality.
I'm not arguing _against_ throughput. Try to get that straight.
Throughput is important too (so is Quantity - would you rather have a
_really_ really good and flat roadsystem in the US that only connects
New York and San Francisco, or do you accept a few potholes and know
that you can drive anywhere? You'd like both, but are you going to pay
for it?).
Quantity vs Quality is NOT a either or: it's a balancing issue. I'm
just telling you that latency is very important too, and if you just say
"throughput" all the time, you're losing out on 50% of the equation..
Linus
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/06
Message-ID: <31DEA3A3.41C67EA6@dyson.iquest.net>
X-Deja-AN: 164034880
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rlf6i$c5f@linux.cs.Helsinki.FI>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5Gold (X11; I; FreeBSD 2.2-CURRENT i386)
Linus Torvalds wrote:
>
> In article <31DC8EBA.41C67...@dyson.iquest.net>,
> John S. Dyson <t...@dyson.iquest.net> wrote:
> >Linus Torvalds wrote:
> >>
> >> No. TCP is a _stream_ protocol, but that doesn't mean that it is
> >> necessarily a _streamING_ protocol.
> >>
> >Okay, you CAN kind-of misuse it by using TCP for a single transaction,
> >like simple HTTP transactions.
>
> That's NOT misusing TCP. You're showing a very biased view here. Just
> because YOU like streaming TCP does NOT mean that TCP should necessarily
> be streaming. There is a lot more to TCP than just TCP windows.
>
Linus, your arrogance is showing here... making personal disparaging
remarks. You DO NOT need to do this. Note that I used the term
"kind-of." :-(. That qualification was added for a reason -- so that
you
would understand that TCP doesn't do that task as well as it does other
things.
>
> TCP has lots of huge advantages over just about _anything_ else, which
> makes it the protocol of choice for most things.
>
Believe it or not, I agree that it is the best (except for TTCP) for the
application, given what is available. It just isn't as well suited to
the application as TTCP is. That is one reason WHY TTCP was invented
and added to FreeBSD.
>
> - It's everywhere. Just about _everything_ supports TCP, and unless you
> want to paint yourself into a small corner of the market you'd better
> use TCP these days (UDP matches this point too, but you can forget
> about IPX, appletalk and TTCP).
>
That is why FreeBSD did not get rid of TCP in lieu of TTCP :-). You are
making a simple criticism of the benchmark into a much bigger argument
than it needs to be.
> - it works reasonably well for lots of different things. UDP is useless
> for lots of things (nobody sane would ever have done http with UDP,
> it simply would have been a bitch)
I agree that it works reasonably well, so what is your point? It is
not the best possible protocol for the task. That was my point.
> - it's there, and it's there NOW. It's not some great new technology
> that will revolutionalize the world in ten years. It WORKS.
>
Right.
>
>
> We're not talking about _connection_ latency, we're talking about
> _packet_ latency. The tests quoted here have not been about how fast
> you can connect to a host, but how fast you can pass packets back and
> forth over TCP. That's exactly the kind of thing you see with http and
> keeping the connection open, or with NFSv3 over TCP, or with a
> distributed lock manager (..databases) that has TCP connections to the
> clients or with a _lot_ of things.
>
But in the most often used application of HTTP, the single message per
connection happens often. Now, how many transactions are needed to
set up a TCP connection? Hmmm? Please refer to Stevens, and it will
explain it to you. (TTCP helps fix that problem.)
> >With many/most web pages being 1-2K, the transfer rate starts to
> >overcome the latency, doesn't it? For very small transactions, maybe
> >100 bytes the latency is very very important. How many web pages are that
> >small???
>
> 1-2kB is nowhere _near_ streaming.
True, but did I say anything to disagree with that? However, that 1-2K
starts making latency much less important. You appear to speak in
absolutes.
>
> Again, latency is probably more important than throughput up to around
> 10kB or so (TCP window), and it can actually get MORE important for a
> multithreading system. Because low latency can also mean that the
> system spends less time sending out the packets, so it can go on serving
> the _next_ client faster.
>
My criticism of the benchmark is that it does not model what you are
claiming above. When you speak of latency, you must qualify how much
latency and how much bandwidth. If there is a minor difference in
latency,
then bandwidth becomes more important. You are speaking in absolutes
with
little qualification given relative values. You also have to describe
the
environment for the test. If the test is the only load on the
(sub)system,
then it only shows the performance with the benchmark load. We should
also standardize tests for systems that might have 100's of connections
active, and also concurrent connection requests.
The latency results are static, and under very limited conditions.
>
>
> You tend to always bring up "heavy load" as an argument against low
> latency, and that is not really the answer either. You _can_ hide
> latency with concurrency, but that definitely does not work for
> everything. Dismissing numbers because they were done under conditions
> where the machine wasn't doing anything else is as stupid as dismissing
> numbers that were done under load. Can't you see that?
>
Please look into how much CPU is needed when you have many active TCP
connections. It goes up. Yes I do use load in the
arguments, because it IS important to consider for overall system
performance measurement. Don't you consider the scalability of you
algorithms, or just make it fast for one or two processes (makes
lmbench look good???)
>
>
> That's not to say I don't want to beat BSD: do you have actual
> comparisons against Linux? I suspect that the problem with Linux might
> be user-level overhead of the shared libraries, not the actual fork/exec
> itself - if you have numbers with shared/static binaries I'd be very
> interested indeed..
>
When I do my benchmarks between FreeBSD and Linux, I *usually* do them
without shared libs, because I usually take the kernel view of things...
If you remember alot of old lmbench runs and compare FreeBSD vs. Linux,
people would compare our dynamic shared libs results with the old Linux
static shared libs, and FreeBSD would come out far behind. We did alot
to
speed FreeBSD with dynamic shared libs to be almost as fast as Linux
with
static shared libs.
Next we noticed that we could gain alot more in performance with a few
minor
changes (enhancements.) Now, our fork/exec perf is sigificantly faster
than our old fork(alone) perf. The way that process fork is done has
now
been totally changed. Processes are now represented differently in
memory,
and almost any performance disadvantages of the excellent (I can say
that
egoless, because I did not invent them) abstractions of our pseudo-Mach
VM
system are gone. You and us started from different directions, we got
stuck
with legacy code, and you have had to implement things from scratch.
Both
are difficult to make perform well.
My recent benchmark runs show that FreeBSD-current (kernel) is 5-10%
faster
than Linux in fork/exec operations. There are more improvements being
made
to -current (not ready yet) that add a bit more performance to it. The
best
that I have seen on my machine with pre-current stuff shows about
460-480
usec fork times (the best I had gotten with Linux 1.3.9x was about 540.)
-current shows about 500-520 (built only with -O, without the latest
enhancements.) We generally don't build our kernels with (-O2
-fomit-frame-pointer), so sometimes we can gain a few percent in certain
benchmarks there also. (We have chosen to make stack tracebacks
available
by default.)
As always though, when people need the highest fork perf, when memory
is not an issue, we suggest building programs static (you should
probably
suggest that for Linux also.)
At least neither FreeBSD nor Linux are as slow as the old SVR4. :-)
>
> Quantity vs Quality is NOT a either or: it's a balancing issue. I'm
> just telling you that latency is very important too, and if you just say
> "throughput" all the time, you're losing out on 50% of the equation..
>
You are the one that brought up the Quality argument and equated Latency
with it... Sorry... I was just trying to open up your eyes to show you
that there were other factors associated with quality. Hopefully, (I
do think that) you are now seeing that. (For example, ONE cgi script
fork/exec can make a bigger difference than the TCP latency.) Even
if it isn't a www application, there are alot of applications (in
fact most) where the code actually does substantial work with the
data sent :-).
I am sure that the DRIVER for the DEC chipset will be looked at, because
it appears to be more a driver issue than a network code issue. But
the vast majority of the users of FreeBSD would gain less by investing
in that (because it is in the region of diminishing returns for most
applications of either FreeBSD or Linux), than working on other areas.
It is a quality issue -- but there are many aspects of the quality
of the product.
John
From: ehco...@inet.uni-c.dk (Erik Corry)
Subject: Re: TCP latency
Date: 1996/07/07
Message-ID: <Du681x.2Gy@kroete2.freinet.de>#1/1
X-Deja-AN: 164134956
sender: n...@kroete2.freinet.de (news)
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rlf6i$c5f@linux.cs.Helsinki.FI> <31DEA3A3.41C67EA6@dyson.iquest.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
content-type: text/plain; charset=iso-8859-1
organization: Home
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
John S. Dyson (t...@dyson.iquest.net) wrote:
: Linus Torvalds wrote:
: > In article <31DC8EBA.41C67...@dyson.iquest.net>,
: > John S. Dyson <t...@dyson.iquest.net> wrote:
: > >
: > >Okay, you CAN kind-of misuse it by using TCP for a single transaction,
: > >like simple HTTP transactions.
: >
: > That's NOT misusing TCP. You're showing a very biased view here. Just
: > because YOU like streaming TCP does NOT mean that TCP should necessarily
: > be streaming. There is a lot more to TCP than just TCP windows.
:
: Linus, your arrogance is showing here... making personal disparaging
: remarks. You DO NOT need to do this.
You need to reread it more carefully, John. Linus criticised your _view_
as being biased, he didn't criticise you. You were the one that started
criticising the person, by accusing Linus of being arrogant. I hope you
can see the difference, because it's quite critical to avoiding flame
wars on the net.
I think you should accept that Linux has beaten everyone fair and square
on a benchmark that isn't new, and that wasn't invented to prove a Linux
point. Larry McVoy invented his latency benchmarks because he thinks
latency is an undervalued performance metric in several fields of
computer design, including network performance. Your comments, initally
completely discounting the importance of latency seem to prove his
point. If you think there is some other parameter that should be given
more weight, then do the same as he did: Release a portable benchmark
program that tests what you think is important and start collecting
figures for various OS/hardware combinations. Until you do that, your
comments will just look like sour grapes.
--
You couldn't deny that, even if you tried with both hands. -- The Red Queen
--
Erik Corry ehco...@inet.uni-c.dk http://inet.uni-c.dk/~ehcorry/ +45 86166287
Configuration/programmering af Internet/TCPIP/Unix/News/Mail/WWW/net-sikkerhed..
From: Michael Graff <explo...@zhaneel.flame.org>
Subject: Re: TCP latency
Date: 1996/07/07
Message-ID: <v6wx0gdmn3.fsf@zhaneel.flame.org>#1/1
X-Deja-AN: 164164037
references: <4paedl$4bm@engnews2.Eng.Sun.COM>
organization: flame.org: yes, we do know everything
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
"John S. Dyson" <t...@dyson.iquest.net> writes:
> Believe it or not, I agree that it is the best (except for TTCP) for the
> application, given what is available. It just isn't as well suited to
> the application as TTCP is. That is one reason WHY TTCP was invented
> and added to FreeBSD.
So TTCP is something FreeBSD decided would be cool, put it in, and to hell
with standards? Or is TTCP something standard, which I can find in an
RFC somewhere?
--Michael
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/07
Message-ID: <31DFEB02.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 164167632
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rlf6i$c5f@linux.cs.Helsinki.FI> <31DEA3A3.41C67EA6@dyson.iquest.net>
<Du681x.2Gy@kroete2.freinet.de>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Erik Corry wrote:
>
> John S. Dyson (t...@dyson.iquest.net) wrote:
> : Linus Torvalds wrote:
> : > In article <31DC8EBA.41C67...@dyson.iquest.net>,
> : > John S. Dyson <t...@dyson.iquest.net> wrote:
> : > >
> : > >Okay, you CAN kind-of misuse it by using TCP for a single transaction,
> : > >like simple HTTP transactions.
> : >
> : > That's NOT misusing TCP. You're showing a very biased view here. Just
> : > because YOU like streaming TCP does NOT mean that TCP should necessarily
> : > be streaming. There is a lot more to TCP than just TCP windows.
> :
> : Linus, your arrogance is showing here... making personal disparaging
> : remarks. You DO NOT need to do this.
>
> You need to reread it more carefully, John. Linus criticised your _view_
> as being biased, he didn't criticise you. You were the one that started
> criticising the person, by accusing Linus of being arrogant. I hope you
> can see the difference, because it's quite critical to avoiding flame
> wars on the net.
>
Linus is in NO position, _Erik_ to judge my reasons for my position. It is
arrogant to judge my position in this way. His words were chosen
in a way to attempt to discredit a very valid position, by a personal
inference. It is either ignorance or arrogance to have responded in the
way he did. Which one do you choose? I don't think that he is ignorant
(maybe he is, in the way of coming from a "very biased view", but I didn't
start that.) You are perpetuating something where I have proven my point...
Various responses to my posting have started acknowleging that the no-load
latency is only one (potentially small) part of the equation. I think that it
is going too far to use the phrase "a very biased view" -- that is when
it started getting personal. In fact, that position is discredited by
other follow-up postings. This sounds like an attempt to beg the question,
or "win", when my position is standing up.
Secondly, the latency differences are in the noise at the kernel
level, per my previous postings -- additionally the results mostly show
a driver difference. At least some of the difference can be attributed
to kernel compile option difference... FreeBSD defaults to the more
conservative "-O" option. People who know that they need maximum speed
can recompile their kernels with more aggressive (Linux-like) options.
E.G. one can gain signficant speed improvements by using "-fomit-frame-pointer".
We choose not to, for better kernel stack tracebacks, and customer support.
The benchmark shows is that Linux's performance is good under
no-load. That is typical of Linux in general, and why many people are
satisified using Linux on single-user desktops. I think that Linux
has a following on large systems, for many of the same reasons that
NT does -- people use it on their desktops... There is, of course,
a better choice for larger systems (and a generally equally good choice for
small systems.) :-). People have been asking about our EXT2FS compatibility
to help solve their large system problems :-).
Even though the benchmark has been around for a few years or so, it doesn't make
it informative under real world high-load conditions where the benchmark
numbers become generally more important. So, the benchmark hasn't been
challenged until now. It needs to be re-evaluated for real-world conditions...
Or at least, it's limitations need to be understood, and clarified for those
that would misread the implications.
I have called for better, more accurate benchmarks, for networking performance.
I find it interesting if a development group is threated by it.
Cult followings have an evangelism that professional followings usually
don't espouse. I expect emotional support of Linux (and Linus), and they
obviously fills a need that many of it's users have. Sorry that I am
not falling into the Linux (and GPL) party line...
John
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/07
Message-ID: <31DFFC24.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 164172464
references: <4paedl$4bm@engnews2.Eng.Sun.COM>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Michael Graff wrote:
>
> "John S. Dyson" <t...@dyson.iquest.net> writes:
>
> > Believe it or not, I agree that it is the best (except for TTCP) for the
> > application, given what is available. It just isn't as well suited to
> > the application as TTCP is. That is one reason WHY TTCP was invented
> > and added to FreeBSD.
>
> So TTCP is something FreeBSD decided would be cool, put it in, and to hell
> with standards? Or is TTCP something standard, which I can find in an
> RFC somewhere?
>
I cannot answer that quickly, please refer to the Stevens TCP/IP
book series Vol 3. The information is in there. I think that
there is an RFC, and FreeBSD was one-of, if not the first complete, free
implementation (as of a year or so ago.) TTCP has been around
in one form or another for many years. That book series is
a wonderful description of TCP/IP and contains annotated versions
of sections of the 4.4 TCP/IP source code. He has also suggested
significant enhancements to the predominant (standard) TCP/IP 4.4
suite.
Those books are a treasure-trove of information (I know, an endorsement
by me doesn't count for much in certain circles), but they are
and excellent description of the TCP/IP standard (reference) code
implementation as used in *BSD. If I wanted to re-implement the code
I would have a copy of those books, and a source code copy of FreeBSD.
Given that many TCP/IP suites (even in embedded controllers, where
BSD licensing is superior), use the 4.3/4.4 code, having a copy
of the reference code is indespensible.
It would be great if other OSes would catch up to FreeBSD in that area,
because it might improve the performance of the net in general, when
TTCP catches on.
John
From: t...@agora.rdrop.com
Subject: Re: TCP latency
Date: 1996/07/07
Message-ID: <4rpdtn$30b@symiserver2.symantec.com>#1/1
X-Deja-AN: 164196492
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rlf6i$c5f@linux.cs.Helsinki.FI> <31DEA3A3.41C67EA6@dyson.iquest.net>
<Du681x.2Gy@kroete2.freinet.de> <31DFEB02.41C67EA6@dyson.iquest.net>
organization: Symantec Corporation
reply-to: tedm%toy...@agora.rdrop.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In <31DFEB02.41C67...@dyson.iquest.net>, "John S. Dyson"
<t...@dyson.iquest.net> writes:
>Erik Corry wrote:
>>
>> John S. Dyson (t...@dyson.iquest.net) wrote:
>> : Linus Torvalds wrote:
>> : > In article <31DC8EBA.41C67...@dyson.iquest.net>,
>> : > John S. Dyson <t...@dyson.iquest.net> wrote:
[blah blah deleted]
I have to interject something here on this discussion:
I feel this has gotten so academic that it is meaningless. Who cares what the
latency/throughput figures are or who is winning the current benchmark in
vogue!
The fact is that these numbers only become important on servers that are being
used to serve users, which strikes out 90% of the personal Unix boxes out
there in my opinion.
Of the remainder, there are two general situations:
Internal network servers (Intranet) servers used on Ethernet/Token RIng/FDDI/
100Base connections.
External network servers (Internet) servers used to serve up web pages to the
Internet at large.
In the second group, it is pointless to debate the issue. In these TCP connections,
you are depending on optimum configuration of both ends of the connection,
having great latency figures in the kernel is not going to matter because the
overall network latency of the network is going to overwhelm anything else.
Also, in the second group you are dealing with a server having many
_simultaneous_ connections at once. The internal IP stack management is
going to be much more important here. So far, I haven't read anyone's posting
saying they got 50-100 simultaneous connections going and then measured
latency or throughput, instead we have a couple of measurements from between
_two_ workstations connected together, and people who should know better
attempting to extrapolate those results to _real_ servers!
The arguments here really only have meaning on servers in the first group, where
the client workstation configuration, network, and server hardware is carefully
controlled, and face it nobody cares that much in this market because their all
more concerned with things like ease of administration.
If somebody wants to do some reasearch on Linux vs BSD when 60 or more
simultaneous connections are active, then it might be worth looking at, otherwise
attempting to say that one's TCP stack is more efficient than the other based on
2 boxes connected together is stupid and foolish.
Ted Mittelstaedt
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/08
Message-ID: <4rqcsk$ff8@fido.asd.sgi.com>#1/1
X-Deja-AN: 167148796
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4qaui4$o5k@fido.asd.sgi.com>
<4qc60n$d8m@verdi.nethelp.no> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
[lotso latency vs bandwidth discussions deleted]
Since I wrote the benchmarks, I can at least try and explain why they are
the way they are and acknowledge their limitations. I'll stay away from
saying anything about which OS is "better".
In general, all of the lmbench tests are designed to show you "guarenteed
to be obtainable without tricks" performance numbers. I don't like the
SPEC approach of allowing the -go-fast-just-for-this-spec-benchmark flag
to cc, so I insist that the benchmarks are compiled with -O and that's it.
I'll cop to the complaint John made that the tests don't show how the system
scales. There are several ways that I could improve things, such as
. plot bandwidths & latencies as a function of the number of
tests running (scaling) and amount of data transfered (cache vs
memory).
. Design benchmarks that are closer to what happens in real life
(I'm thinking mostly web stuff here - I need a benchmark that
connects, transfers a variable amount of data, and disconnects).
At any rate, that's lmbench 2.0, and we are talking 1.0. I'm aware of the
needs and I'll try and get on it this month, it's overdue. If you want,
I can post my lmbench TODO list and we can beat it up for a while. I'd
like to see the next version be something we can all agree on.
Moving on: the comment John made about static Linux vs dynamic FreeBSD
libraries doesn't ring a bell with me. It's certainly not true for any
numbers I've published (like in the Usenix paper - that was all dynamic
on all systems that supported it, including Linux).
At Usenix, it was suggested that I stacked the deck in favor of Linux
because I presented 120Mhz FreeBSD numbers vs 133Mhz Linux numbers
(if I remember correctly, it might have been the other way around, but
I doubt it since it was a BSD type complaining and they rarely complain
I'm not being fair to Linux). I sort of take offense at the suggestion;
at the time, those were all the numbers I had. And I don't "stack the
deck" on numbers. Ever. You might take a look at how SGI hardware does
on lmbench and consider that I work for them, and that the numbers are
obviously unflattering.
I do stack the deck in the following way: I talk to Linus all the time
about what I happen to think is important to OS performance. Linux looks
good in the places where he agreed that I had a point; the context switch
numbers are a great example - Linus did some really nice work there.
I make no apologies for talking to Linus, I enjoy it.
Finally getting to latencies et al. I think that everyone should print
out the two long messages from Linus in this thread. In over ten years
of working in the OS world, i have never seen a better treatment of
the issues. John needs to push that chip off his shoulder and listen
to what Linus is saying - it has nothing to about Linux vs FreeBSD; it
has everything to do with what makes sense for an OS, any OS.
The lat_tcp stuff was written before the Web existed (I think, certainly
before it was widespread). Motivations for the benchmark include: it
was a critical performance path in the Oracle lock manager. I'd like to
see Unix get clustering capabilities at some point. Part of the goal
there is to be able to do remote exec's in such a short amount of time
that you can't tell if they are local or remote. TCP latency was in that
critical path as well. Finally, I think it is a reasonable way to see
how muc overhead your stack is giving you. Since the payload is essentially
zero, you're looking at almost pure os/stack/interrupt overhead, and that's
useful information.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: j...@ida.interface-business.de (J Wunsch)
Subject: Re: TCP latency
Date: 1996/07/08
Message-ID: <4rql4p$39f@innocence.interface-business.de>#1/1
X-Deja-AN: 167163563
x-pgp-fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
x-fax: +49-351-3361187
organization: interface business GmbH, Dresden
reply-to: joerg_wun...@interface-business.de (Joerg Wunsch)
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-phone: +49-351-31809-14
l...@neteng.engr.sgi.com (Larry McVoy) wrote:
> Moving on: the comment John made about static Linux vs dynamic FreeBSD
> libraries doesn't ring a bell with me. It's certainly not true for any
> numbers I've published (like in the Usenix paper - that was all dynamic
> on all systems that supported it, including Linux).
One technical correction to this:
John's wording was:
===
[...] If you remember alot of old lmbench runs and compare
FreeBSD vs. Linux, people would compare our dynamic shared libs
results with the old Linux static shared libs, and FreeBSD would come
out far behind. We did alot to speed FreeBSD with dynamic shared libs
to be almost as fast as Linux with static shared libs.
===
You notice the term ``static shared libs'', i.e. he didn't mean static
*binaries*, but those old Linux shared libs that were arguably very
fast, but took a great pain to be made.
--
J"org Wunsch Unix support engineer
joerg_wun...@interface-business.de http://www.interface-business.de/~j
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/08
Message-ID: <4rrimn$dro@fido.asd.sgi.com>#1/1
X-Deja-AN: 167225470
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
Yup, that's right. I had completely forgotten about that. I think I have
both the old and the new libs on my 486, I'll have a crack at seeing the
perf differences and post them here. My mistake.
: > Moving on: the comment John made about static Linux vs dynamic FreeBSD
: > libraries doesn't ring a bell with me. It's certainly not true for any
: > numbers I've published (like in the Usenix paper - that was all dynamic
: > on all systems that supported it, including Linux).
: One technical correction to this:
: John's wording was:
: ===
: [...] If you remember alot of old lmbench runs and compare
: FreeBSD vs. Linux, people would compare our dynamic shared libs
: results with the old Linux static shared libs, and FreeBSD would come
: out far behind. We did alot to speed FreeBSD with dynamic shared libs
: to be almost as fast as Linux with static shared libs.
: ===
: You notice the term ``static shared libs'', i.e. he didn't mean static
: *binaries*, but those old Linux shared libs that were arguably very
: fast, but took a great pain to be made.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: Terry Lambert <te...@lambert.org>
Subject: Re: TCP latency
Date: 1996/07/08
Message-ID: <31E16AF1.1568F730@lambert.org>#1/1
X-Deja-AN: 167240681
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rlf6i$c5f@linux.cs.Helsinki.FI> <31DEA3A3.41C67EA6@dyson.iquest.net>
<Du681x.2Gy@kroete2.freinet.de> <31DFEB02.41C67EA6@dyson.iquest.net>
<4rpdtn$30b@symiserver2.symantec.com>
content-type: text/plain; charset=us-ascii
organization: Me
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
t...@agora.rdrop.com wrote:
] [blah blah deleted]
]
] I have to interject something here on this discussion:
]
] I feel this has gotten so academic that it is meaningless. Who
] cares what the latency/throughput figures are or who is winning
] the current benchmark in vogue!
I would have to hazard the guess that people who design before
they implement, care, since a discussion of the issues is
important to choosing the correct approach for a design.
It's called "engineering".
[ ... analysis deleted ... ]
I happen to disagree with much of your analysis; I believe it to
be based on flawed assumptions. Logic, however rigorous, will
result in the wrong answers if formalized from incorrect initial
assumptions.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/08
Message-ID: <31E106AF.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 167248242
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4qaui4$o5k@fido.asd.sgi.com>
<4qc60n$d8m@verdi.nethelp.no> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rqcsk$ff8@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
> I'll cop to the complaint John made that the tests don't show how the system
> scales. There are several ways that I could improve things, such as
>
> . plot bandwidths & latencies as a function of the number of
> tests running (scaling) and amount of data transfered (cache vs
> memory).
>
> . Design benchmarks that are closer to what happens in real life
> (I'm thinking mostly web stuff here - I need a benchmark that
> connects, transfers a variable amount of data, and disconnects).
>
MUCH BETTER...
>
> Moving on: the comment John made about static Linux vs dynamic FreeBSD
> libraries doesn't ring a bell with me. It's certainly not true for any
> numbers I've published (like in the Usenix paper - that was all dynamic
> on all systems that supported it, including Linux).
>
I have numbers that I am willing to send to you. See, I track the
performance of FreeBSD very carefully. I find that lmbench is
useful, but not a total measure of system performance.
> You might take a look at how SGI hardware does
> on lmbench and consider that I work for them, and that the numbers are
> obviously unflattering.
>
I used to work on Tandem OEM'ed boxes using similar processors to SGI,
and I know *exactly* what you are talking about.
>
> Finally getting to latencies et al. I think that everyone should print
> out the two long messages from Linus in this thread. In over ten years
> of working in the OS world, i have never seen a better treatment of
> the issues. John needs to push that chip off his shoulder and listen
> to what Linus is saying - it has nothing to about Linux vs FreeBSD; it
> has everything to do with what makes sense for an OS, any OS.
>
Again, using terms like "chip on my shoulder" perpetuates the
myth that I am somehow personally defective. Please refrain
from personal comments... However, you are indeed supporting
my position that the benchmark needs to measure something more
"real world." Thank you.
> TCP latency was in that
> critical path as well.
Linus EQUATED latency with quality. That is where alot of the
problem was. I had brought up the notion that there are alot
of other factors associated with quality, and the cheer about
the no-load latency being so low was kind-of overblown.
John
From: John Dyson <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/08
Message-ID: <31E16DB5.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 167264126
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: Zippo
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 2.0 (X11; I; FreeBSD 2.1-STABLE i386)
Larry McVoy wrote:
>
> Yup, that's right. I had completely forgotten about that. I think I have
> both the old and the new libs on my 486, I'll have a crack at seeing the
> perf differences and post them here. My mistake.
>
These were numbers that I got on a version of FreeBSD stable as of
20 Aug 95 and Linux 1.3.20. FreeBSD was generally compiled with
"-O" and Linux with "-O2 -fomit-frame-pointer -fno-strength-reduce -m486".
Motherboard: Micronics 486/66 with 20MBytes of ram. Remember, these
are OLD kernels, but this is the context of the fork/exec perf that I
was talking about. Specifically, showing the overhead encurred by the
dynamic shared lib scheme. Both FreeBSD and Linux have made major
improvements since these measurements were made. This is an excerpt
of a posting made near the end of '95 to some FreeBSD mailing lists.
Note also, the shell used for my FreeBSD test was bash (to eliminate
the differences between the smaller/simpler default FreeBSD shell.)
FreeBSD Linux
USING STATIC PROGRAMS:
Process fork+exit: 3249 4380 usecs
Process fork+execve: 6838 9365 usecs
Process fork+/bin/sh -c: 27156 44115 usecs
USING STATIC PROGRAMS, FreeBSD compiled with -fomit-frame-pointer:
Process fork+exit: 2821 usecs
Process fork+execve: 5917 usecs
Process fork+/bin/sh -c: 25382 usecs
LINKED WITH SUNOS STYLE SHARED LIBS:
FreeBSD Linux
Process fork+exit: 6162 usecs -----
Process fork+execve: 27716 usecs -----
Process fork+/bin/sh -c: 49842 usecs -----
FreeBSD Compiled with -fomit-frame-pointer
Process fork+exit: 5716 usecs -----
Process fork+execve: 26356 usecs -----
Process fork+/bin/sh -c: 48124 usecs -----
LINKED WITH OLD-STYLE JUMP-TABLE SHARED LIBS
FreeBSD Linux
Process fork+exit: ------ 6629 usecs
Process fork+execve: ------ 19877 usecs
Process fork+/bin/sh -c: ------ 58735 usecs
John
From: t...@agora.rdrop.com
Subject: Re: TCP latency
Date: 1996/07/09
Message-ID: <4rsmpk$quj@symiserver2.symantec.com>
X-Deja-AN: 167317640
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com>
<4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rlf6i$c5f@linux.cs.Helsinki.FI> <31DEA3A3.41C67EA6@dyson.iquest.net>
<Du681x.2Gy@kroete2.freinet.de> <31DFEB02.41C67EA6@dyson.iquest.net>
<4rpdtn$30b@symiserver2.symantec.com> <31E16AF1.1568F730@lambert.org>
organization: Symantec Corporation
reply-to: tedm%toy...@agora.rdrop.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In <31E16AF1.1568F...@lambert.org>, Terry Lambert <te...@lambert.org> writes:
>t...@agora.rdrop.com wrote:
>] [blah blah deleted]
>]
>] I have to interject something here on this discussion:
>]
>] I feel this has gotten so academic that it is meaningless. Who
>] cares what the latency/throughput figures are or who is winning
>] the current benchmark in vogue!
>
>
>I would have to hazard the guess that people who design before
>they implement, care, since a discussion of the issues is
>important to choosing the correct approach for a design.
>
>It's called "engineering".
>
I have nothing against engineering. However, I think you missed my point, which is
simply that in a real world network there are many more factors that are
uncontrolled than what are controllable on the server itself.
One of the reasons that I feel this discussion is worthless is that among all the
numbers that people have tossed out no one has mentioned anything about the
network hardware _on the server_ let alone the network hardware on the
network itself. (which I still maintain has a lot more effect on perceived server
performance)
I suppose that the measured latency figures are going to be the same if a ISA
8-bit 3Com card is used, verses a PCI SMC8XXX series card? Of course not,
you and I both know that the SMC driver under FreeBSD is a lot better than
the 3C503. At least, the last time I tested it it was.
What good is it if you have wonderful kernel engineering, when the performance
gains are all eaten up by inefficient, unstable drivers and crummy hardware.
I know that anyone setting out to design hardware has a whole raft of tradeoffs
to make, espically network hardware. Some of the network cards, such as the
3C509, push a little of this off on to the user, with config programs that can
be set to be "server mode" or "dos mode" on the card, however this is not going
to compensate for a hardware design approach that is weighted against the
OS in use.
For example, compare a network card that has no DMA, no busmastering, and
no shared memory available. The only way to communicate with this card is
through the good, old IN and OUT instructions. Are you argueing that such a card
is going to have equivalent performance to a network card that has shared
memory and busmastering available? Well, I suppose so if the driver for the
first card is excellent, and the driver for the second card stank, or perhaps the
busmastering hardware in the second card is broken in some manner.
Even better, the first card may be faster simply because the OS (DOS) is not
capabable of supporting the fancy hardware. There are companies that are
going to be making and selling such hardware simply because the ignoramuses
don't know any better.
This is exactly what drove the sale of poor-excuse SCSI adapters such as the
Adaptec 1510, the Seagate ST01, the Always IN1000 (or is it 2000) the Future
Domain 950, etc.
I suppose one can always take the bad excuse that "well, drivers are the
responsibility of the hardware vendor, we have no control if they design crap
hardware and shoddy drivers." Well, people judge the performance of
the operating system based on what this shoddy hardware is making it appear
to do! Microsoft learned this long ago, that is why when they release new
OS'es they just say hang it all and go ahead and write a lot of the more common
drivers for the garbage-grade hardware out there. (or modify buggy-supplied
code)
Now, I know that OS developers walk a thin line, on one hand they don't want
to piss off all the folks that didn't know any better and bought shoddy hardware,
on the other they don't want to encourage people to go out and buy stuff like
IDE, or Sony, or Mitshumi (sp) proprietary CDROMS, floppy-controller tape drives,
non-parity memory, etc. etc. The README files in FreeBSD alone are an excercise
in politics, go through them and you get the appearance that FreeBSD supports
this vast number of hardware peripherals. Well, maybe it does, then how come
people always seem to be running NCR or Adaptec SCSI adapters, and SCSI
tapedrives, CD's and disks, and SMC or NE2000 clone network cards ?!?!?
At the least, someone in the FreeBSD camp could put together a "reference"
FreeBSD machine composed of recommended hardware peripherals. In other
words, "this is what you buy if you intend to run FreeBSD as a serious server"
Theory does indeed have a place in any OS design. Yes, latency issues are
indeed important. However, attempting to assume that OS design goes on in a
total vacuum, totally and completely unaffected by hardware, is rediculous.
What I am attempting to convey is that the real-world outside forces such
as network latency, efficient/inefficient driver design, and network hardware
performance, affect what your arguing over far more.
I guess it's easy to discuss topics like TCP latency, as long as we don't drag in
all that dirty, impossible-to-control, improbable-to-predict, and messy
things like Network Adapters, Cabling and all that nasty stuff. After all, the
whole point of this is to see how fast we can drive the loopback device!!! :-)
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/09
Message-ID: <4rtvpf$7e5@fido.asd.sgi.com>
X-Deja-AN: 167398262
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
<31E16DB5.41C67EA6@dyson.iquest.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
: > Yup, that's right. I had completely forgotten about that. I think I have
: > both the old and the new libs on my 486, I'll have a crack at seeing the
: > perf differences and post them here. My mistake.
OK, I have a 486 system that has both elf & a.out style shared libs. It
has 24MB, 100Mhz, SCSI, PCI, etc. ASUS motherboard (the common one).
The results are from lmbench 1.0, the one distributed on the net.
My analysis: everything is identical except process creation involving
an exec. I'm sort of surprised by how much the elf stuff hurts exec -
any thoughts as to why?
But given that the effect is only felt in exec and that exec is only
used for the process benchmarks, I fail to see why this was perceived
as such a big deal. I've included the results that I published in the
Usenix paper - please note that the FreeBSD machine was a 133Mhz P5 and
the Linux machine was 120Mhz P5. It's pretty lame of the FreeBSD crowd
to be saying I stacked the deck when the Linux box was slower hardware.
I'm also interested in John's comment about the smaller, simpler shell
that FreeBSD uses (I assume it is /bin/sh, right?). If FreeBSD has a
simple shell that doesn't break any common scripts (like rc.d scripts,
that would be a bummer), I'd vote for using that in Linux. I hate using
bash to start processes, it's bloated.
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
i486-elf Linux 1.3.100 99 8 2K 18K 101K 749 8 18
i486.engr Linux 1.3.100 99 7 2K 7K 92K 673 10 19
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
i486-elf Linux 1.3.100 58 323 774 489 1111
i486.engr Linux 1.3.100 59 325 772 465 1116
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
i486-elf Linux 1.3.100 17 9 16 30 17 16 33 40
i486.engr Linux 1.3.100 17 9 17 30 17 16 33 41
Usenix paper table for just FreeBSD vs Linux. The stuff that was "unfair" is
"Simple process" and "/bin/sh process". I'm not really sure it is reasonable
to call that "unfair". It's just a different library style. FreeBSD could
have done the same thing. The point of thebenchmark is to draw out these
differences.
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
i586.1 FreeBSD 2.1-S 133 9 3K 12K 20K 105 24 28
i586.120 Linux 1.3.28 120 2 1K 5K 16K 69 10 13
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
i586.1 FreeBSD 2.1-S 104 213 387 264 450
i586.120 Linux 1.3.28 33 187 366 467 713
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
i586.1 FreeBSD 2.1-S 21 0 30 54 42 39 73 83
i586.120 Linux 1.3.28 34 7 23 9 42 38 74 75
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- --- ---- ---- -------- -------
i586.1 FreeBSD 2.1-S 133 7 111 181
i586.120 Linux 1.3.28 120 8 107 150
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: "John S. Dyson" <dy...@inuxs.att.com>
Subject: Re: TCP latency
Date: 1996/07/09
Message-ID: <31E289FB.167EB0E7@inuxs.att.com>#1/1
X-Deja-AN: 167406481
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
<31E16DB5.41C67EA6@dyson.iquest.net> <4rtvpf$7e5@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: Lucent Technologies, Columbus, Ohio
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 2.0 (X11; I; FreeBSD 2.1-STABLE i386)
Larry McVoy wrote:
>
> Usenix paper table for just FreeBSD vs Linux. The stuff that was "unfair" is
> "Simple process" and "/bin/sh process". I'm not really sure it is reasonable
> to call that "unfair". It's just a different library style. FreeBSD could
> have done the same thing. The point of thebenchmark is to draw out these
> differences.
>
Fairness is a term that is concocted by children. However, the benchmarks
need to be done with all other things equal. For example, the benchmarks
that were run A LONG time ago on an OLD, released version of FreeBSD are
hard to compare with a development version of Linux. FreeBSD V2.1 is of
the same timeframe as Linux 1.2.13. FreeBSD V2.2-current is of the
same timeframe as Linux 2.0. FreeBSD V2.2-current is due for release in
a few months -- the FreeBSD V2.1-stable (old code) has taken up alot of
time, to support existing users who need the best stability... Since
The FreeBSD V2.2 kernel is very stable right now, I would suggest comparing it to
Linux V2.0 (which is also a kernel.)
Generation wise: FreeBSD V2.2-current and Linux V2.0 are best to compare,
while FreeBSD V2.1-stable and Linux V1.2.12 are good to compare.
> L M B E N C H 1 . 0 S U M M A R Y
> ------------------------------------
>
> Processor, Processes - times in microseconds
> --------------------------------------------
> Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
> Syscall Process Process Process lat ctxsw ctxsw
> --------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
> i586.1 FreeBSD 2.1-S 133 9 3K 12K 20K 105 24 28
> i586.120 Linux 1.3.28 120 2 1K 5K 16K 69 10 13
>
i586.166 FreeBSD 2.2-c 166 500uses 1.2K 7K -- -- --
Of course, when you need fast perf, we don't suggest using shared libs, per
the numbers above. Note that FreeBSD V2.2-current scales better than Linux
1.3.28 above? Of course my comparison is just as bogus as the two previous.
I am just making a point that the benchmarks are only meaningful with critical
interpretation. (BTW, my numbers are correct -- but are only accurate for the
machine that I ran them on, under the conditions that I ran them under.)
Considering the static shared libs for Linux of that generation, the DIFFERENT
hardware used for the measurement, and the fact that some of the 2.0 enhancements
had already gone into 1.3.28 and FreeBSD V2.1 is a *conservative* release, these
numbers are only interesting to compare NEWER Linux with OLD FreeBSD on different
hardware :-(.
The shell thing is interesting also, because the lmbench benchmarks don't show
a big (if any) difference between the FreeBSD shell and BASH when running
on FreeBSD-current :-). In fact, I run with bash exclusively, because it
doesn't hurt on FreeBSD at all anymore, when there is enough memory.
FreeBSD-current handles large programs very efficiently, faulting them in
approx 3X faster than Linux V2.0 (both reading and soft pagefaults.) I did not
mean to create a red-herring about the shell.
John
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency
Date: 1996/07/10
Message-ID: <4rvmtf$ven@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 167539977
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rqcsk$ff8@fido.asd.sgi.com> <31E106AF.41C67EA6@dyson.iquest.net>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E106AF.41C67...@dyson.iquest.net>,
John S. Dyson <t...@dyson.iquest.net> wrote:
>
>Linus EQUATED latency with quality. That is where alot of the
>problem was. I had brought up the notion that there are alot
>of other factors associated with quality, and the cheer about
>the no-load latency being so low was kind-of overblown.
No, Linus did not EQUATE latency with quality.
Linus equated the _relation_ between latency and throughput with the
_relation_ between quality and quantity. I may have worded it badly, but
you also seem to still think the world is black-and-white. It isn't, and
in BOTH these relations you have to see both sides.
If you think quality vs quantity should always look at quality, you're a
very sorry individual. I'm NOT slighting bandwidth by comparing it to
quantity, nor am I trying to make latency look important by comparing it
to quality. BOTH are needed. Quality without quantity is useless
(empty promises), and quantity without quality is fodder. THAT was the
whole idea of the comparison (read the post again, without colouring it
with your preconceptions - there is nothing inherently "better" with
Quality vs Quantity).
In fact, my posts tried actively to not mention any specific OS's at
all, and tried to mention the issues without getting too involved with
such details as what OS you're running, or even what _medium_ you're
running (I tried to make you think about latency and throughput on
memory subsystems too, not just TCP or networks: the issues are really
exactly the same).
In short, I'm NOT attacking BSD for having slower TCP latency: that may
well not even be true under different circumstances. I'll freely admit
that we have our own set of problems with Linux, and we won't just sit
still and be contented with what we have. What I AM attacking is the
mentality that people show (not only you, John, but you've been arguing
that most) that seems to think that bandwidth is more important than
latency.
I'd also like to argue that a "idle" system is not less important than a
"loaded" system. For clients, the idle system tends to be the normal
case, while servers have the loaded behaviour. BOTH are important, and
I find it very very scary indeed that the UNIX community _always_ seems
to think that servers and throughput are somehow "more important" than
clients and latency. Damn UNIX idiots (and here I'm attacking the UNIX
vendors, not you, John).
Discounting numbers just because they were done under low load is just
STUPID, John. You're discounting the client side with that, and the
client side is at least 50% of the equation (and depending on how you
count, the client side is likely to be 100:1 the server side, simply
because there are usually more clients ;-).
Finally, the discussion may have been a bit one-sided: we've been able
to discuss only the low-load latency, simply because we don't have
numbers for anything else. I'd be more than happy to discuss server
side issues too, including high load, throughput, and lots of
connections per second. I'm NOT ignoring that side or saying that it's
less important. I'm not a black-and-white person. But the fact is that
I don't have any numbers for it.. (hint hint, write a benchmark you
think is valid, and we'll discuss the numbers for THAT, along with the
validity of THAT benchmark. Deal?).
Linus
From: Pedro Roque Marques <ro...@di.fc.ul.pt>
Subject: Re: TCP latency
Date: 1996/07/10
Message-ID: <x7687w1dsr.fsf@oberon.di.fc.ul.pt>#1/1
X-Deja-AN: 167569566
sender: ro...@oberon.di.fc.ul.pt
references: <4paedl$4bm@engnews2.Eng.Sun.COM>
content-type: text/plain; charset=US-ASCII
organization: Faculdade de Ciencias da Universidade de Lisboa
mime-version: 1.0 (generated by tm-edit 7.69)
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
>>>>> "tedm" == tedm <t...@agora.rdrop.com> writes:
tedm> In <31E16AF1.1568F...@lambert.org>, Terry Lambert
tedm> <te...@lambert.org> writes:
>> t...@agora.rdrop.com wrote: ] [blah blah deleted] ] ] I have to
>> interject something here on this discussion: ] ] I feel this
>> has gotten so academic that it is meaningless. Who ] cares
>> what the latency/throughput figures are or who is winning ] the
>> current benchmark in vogue!
>>
>>
>> I would have to hazard the guess that people who design before
>> they implement, care, since a discussion of the issues is
>> important to choosing the correct approach for a design.
>>
>> It's called "engineering".
>>
tedm> I have nothing against engineering. However, I think you
tedm> missed my point, which is simply that in a real world
tedm> network there are many more factors that are uncontrolled
tedm> than what are controllable on the server itself.
tedm> One of the reasons that I feel this discussion is worthless
tedm> is that among all the numbers that people have tossed out no
tedm> one has mentioned anything about the network hardware _on
tedm> the server_ let alone the network hardware on the network
tedm> itself. (which I still maintain has a lot more effect on
tedm> perceived server performance)
I've the feeling you are still missing Terry's point (at least as I understand
it). Benchmarking can be used in two ways: to evalute a hardware+software set
behaviour in a pratical application/enviroment/use and to evaluate code/design
decisions. lmbench is more oriented IMHO to the second goal although it is
based on examples of read world problems. Discussing what tcp latency is
in groups oriented to OS design should be ok and useful even when people don't
start to take it as a "My OS is better than yours" argument.
I doubt you can draw direct conclusions from the tcp latency numbers about
which OS is better for WWW server, but you can use it to track the evolution
of a particular OS TCP for instance. The famous signature behind this argument
represents an achievement for Linux. No, i wouldn't expect non Linux people
to care a bit about that but for instance i do :-)
regards,
Pedro.
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/10
Message-ID: <31E3D9E2.41C67EA6@dyson.iquest.net>
X-Deja-AN: 167623634
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31DC8EBA.41C67EA6@dyson.iquest.net>
<4rqcsk$ff8@fido.asd.sgi.com> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Linus Torvalds wrote:
>
> In article <31E106AF.41C67...@dyson.iquest.net>,
> John S. Dyson <t...@dyson.iquest.net> wrote:
> >
> >Linus EQUATED latency with quality. That is where alot of the
> >problem was. I had brought up the notion that there are alot
> >of other factors associated with quality, and the cheer about
> >the no-load latency being so low was kind-of overblown.
>
> No, Linus did not EQUATE latency with quality.
>
> Linus equated the _relation_ between latency and throughput with the
> _relation_ between quality and quantity. I may have worded it badly, but
> you also seem to still think the world is black-and-white. It isn't, and
> in BOTH these relations you have to see both sides.
>
So you admit it... Linus, quit blaming others for YOUR mistakes in
communications. It even appears that you are back-peddling.
>
> If you think quality vs quantity should always look at quality, you're a
> very sorry individual.
>
Linus, you are showing more and more that you have a bad attitude, bringing
your opinion that I am a "sorry individual" into this. In fact, I am not
a sorry individual, and you don't even know me. I find your attitude to
be sometimes offensive and un-professional.
>
> In fact, my posts tried actively to not mention any specific OS's at
> all, and tried to mention the issues without getting too involved with
> such details as what OS you're running, or even what _medium_ you're
> running (I tried to make you think about latency and throughput on
> memory subsystems too, not just TCP or networks: the issues are really
> exactly the same).
>
I think that it is okay to mention OS'es as examples, so what? It is
okay to communicate in terms of examples. In fact the original latency
discussion was in the terms that Linux is faster than FreeBSD in a rather
obscure way (relative to the performance figures that matter to most
people using these OSes.)
>
> In short, I'm NOT attacking BSD for having slower TCP latency: that may
> well not even be true under different circumstances. I'll freely admit
> that we have our own set of problems with Linux, and we won't just sit
> still and be contented with what we have.
>
Geesh, you are misttating the facts AGAIN!!! You have shown that Linux
has faster NO LOAD latency. That is only a small piece of the puzzle.
I wonder what the performance figures are for a real world latency
number?
> What I AM attacking is the
> mentality that people show (not only you, John, but you've been arguing
> that most) that seems to think that bandwidth is more important than
> latency.
>
You are looking at the argument in a very narrow way -- NO LOAD latency
is an interesting figure, but that is ONLY ONE latency figure.
>
> I'd also like to argue that a "idle" system is not less important than a
> "loaded" system. For clients, the idle system tends to be the normal
> case, while servers have the loaded behaviour. BOTH are important, and
> I find it very very scary indeed that the UNIX community _always_ seems
> to think that servers and throughput are somehow "more important" than
> clients and latency.
>
Okay, then state that the Linux NO LOAD latency is faster... Don't say that
the Linux networking latency is faster than BSD -- you have shown only
one specific circumstantial number to demonstrate your position.
One other thing, the numbers show that the DRIVER used on BSD is slower -- the
networking code is NOT SHOWN to be slower... Refer to the numbers...
Do you know that my localhost results on my P5-166 are 200usecs?
That is faster than the Linux measurements that are being espoused as a
"record" isn't it??? There is too much hyperbole associated with the
issue at hand. I think that there is little integrity in the way that
the benchmark results are being touted as "finally showing that Linux
is as good as BSD." Even Larry McVoy in other postings has admitted that
Linux falls down under load...
You back-peddling is showing that you overreached a bit, maybe one day
Linux will catch up... Did you know that Dhrystone measures faster numbers
on FreeBSD at times? Does that make FreeBSD better.... NOT!!!
>
> Finally, the discussion may have been a bit one-sided: we've been able
> to discuss only the low-load latency, simply because we don't have
> numbers for anything else.
>
Cool, you are seeing my point *finally*, sigh... It is obvious that the
latency number being measured is a *specific* case. I am sure that after
all of these discussions, someone (who will remain nameless :-)) will be
thinking about benchmarking this performance number. BTW, I am making
no claims that *BSD will come out better than Linux after that benchmark
either. I am saying that the limited latency benchmark being touted
as "proof" that the Linux networking code is "faster" is inadequate
to make that claim.
John
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/07/10
Message-ID: <4s0uuk$fpf@news.swan.ac.uk>#1/1
X-Deja-AN: 167642976
references: <31DEA3A3.41C67EA6@dyson.iquest.net> <v6wx0gdmn3.fsf@zhaneel.flame.org>
<31DFFC24.41C67EA6@dyson.iquest.net>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31DFFC24.41C67...@dyson.iquest.net> "John S. Dyson"
<t...@dyson.iquest.net> writes:
>It would be great if other OSes would catch up to FreeBSD in that area,
>because it might improve the performance of the net in general, when
>TTCP catches on.
I stopped adding TTCP when I found it couldnt talk
o Over AX.25 (poor window assumptions one liner fix to the BSD code
sorts that. I'll sell the fix to you for $1000 or you can wait)
o To KA9Q stacks ... KA9Q - amateur radio no big deal. Wrong its
used in assorted products that you cant manage with freebsd if
ttcp is enabled (some netblazers, 3com office connect 4xx,5xx,6xx)
o It widens and doesnt resolve the issues in draft-heavens on RST
frames
Alan
--
----------------------------------------------////
Yow! 233 microsecond remote host TCP latency ---- beat that
--------------------------------------------////__________ o
Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
From: t...@agora.rdrop.com
Subject: Re: TCP latency
Date: 1996/07/11
Message-ID: <4s220u$nmq@symiserver2.symantec.com>#1/1
X-Deja-AN: 167729173
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
organization: Symantec Corporation
reply-to: tedm%toy...@agora.rdrop.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In <x7687w1dsr....@oberon.di.fc.ul.pt>, Pedro Roque Marques <ro...@di.fc.ul.pt>
writes:
>I've the feeling you are still missing Terry's point (at least as I understand
>it). Benchmarking can be used in two ways: to evalute a hardware+software set
>behaviour in a pratical application/enviroment/use and to evaluate code/design
>decisions. lmbench is more oriented IMHO to the second goal although it is
>based on examples of read world problems. Discussing what tcp latency is
>in groups oriented to OS design should be ok and useful even when people don't
>start to take it as a "My OS is better than yours" argument.
>
You are probably correct in that Terry was speaking theoretically, rather than
practically. In any case, this thread has grown from the "my D$$K is bigger
than yours" to something more approximating reality, and has gotten more
useful and interesting as a result.
I have to say that one of the more common problems in the business today is
attempting to take benchmarks and apply them to everything, that is what I
was arguing against anyhow. However, I do disagree somewhat with you, I
don't see the use of most benchmarks as "evaluating a software+hardware
set of behavior in a practical environment/application/use", now there's a
mealy-mouthed sentence if I ever heard one! :-)
I prefer to rely on observed behavior of the device, rather than someone's
meaningless published benchmark. That's why I don't make large computing
equipment purchases that are without money-back guarentee. (unfortunately
this seems to be a rarity in this business also)
As far as making design decisions as a result of benchmarking, well that's all
well and good. I've usually heard that referred to as "testing" though. ;-) I
guess if your attempting to design a product that is better than your competition's
it's called "Benchmarking" and if your just trying to design a product that is
the absolute best that it can be it's called testing ;-)
Ted
From: "John S. Dyson" <dy...@inuxs.att.com>
Subject: Re: TCP latency
Date: 1996/07/11
Message-ID: <31E53C2B.41C67EA6@inuxs.att.com>#1/1
X-Deja-AN: 167802594
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
<4s220u$nmq@symiserver2.symantec.com>
content-type: text/plain; charset=us-ascii
organization: Lucent Technologies, Columbus, Ohio
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 2.0 (X11; I; FreeBSD 2.1-STABLE i386)
t...@agora.rdrop.com wrote:
>
> You are probably correct in that Terry was speaking theoretically, rather than
> practically. In any case, this thread has grown from the "my D$$K is bigger
> than yours" to something more approximating reality, and has gotten more
> useful and interesting as a result.
>
Y'know, I usually don't care how big my D$$K is until someone starts
making theirs look bigger than it really is...
John
dy...@freebsd.org
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency
Date: 1996/07/12
Message-ID: <4s5bl2$qpg@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 167971037
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E3D9E2.41C67...@dyson.iquest.net>,
John S. Dyson <t...@dyson.iquest.net> wrote:
>
>One other thing, the numbers show that the DRIVER used on BSD is slower -- the
>networking code is NOT SHOWN to be slower... Refer to the numbers...
No, read the numbers again. Linux was faster on loopback too.
>Do you know that my localhost results on my P5-166 are 200usecs?
>That is faster than the Linux measurements that are being espoused as a
>"record" isn't it???
Ooohh.. "FreeBSD is faster over loopback, when compared to Linux over
the wire". Film at 11.
linux$ ./lat_tcp linux
$Id: lat_tcp.c,v 1.2 1995/03/11 02:25:31 lm Exp $
TCP latency using linux: 181 microseconds
That's on a P166 too. With a stable kernel. What were you saying
again?
(And if you think you will get 10% better numbers by just changing
compiler options, I'd suggest you _try_ it first, without spouting it on
the newsgroups as facts with no backing).
And if you don't like latency numbers, what are your throughput numbers?
(Btw, check your bcopy() speed first to see if the hardware really _is_
comparable, see below)
linux$ ./bw_tcp linux 50m
$Id: bw_tcp.c,v 1.3 1995/06/21 21:02:49 lm Exp $
Socket bandwidth using linux: 17.14 MB/sec
Yes, the machine was idle while doing this. I guess you can just do them
in parallell, though, to get _some_ idea about the degradation under
load (admittedly not a lot of sockets, but at least some activity for
context switches etc):
linux$ ./bw_tcp linux 50m &./bw_tcp linux 50m &./bw_tcp linux 50m &
[1] 27157
[2] 27158
[3] 27159
linux$ $Id: bw_tcp.c,v 1.3 1995/06/21 21:02:49 lm Exp $
$Id: bw_tcp.c,v 1.3 1995/06/21 21:02:49 lm Exp $
$Id: bw_tcp.c,v 1.3 1995/06/21 21:02:49 lm Exp $
Socket bandwidth using linux: 6.61 MB/sec
Socket bandwidth using linux: 6.34 MB/sec
Socket bandwidth using linux: 6.30 MB/sec
(This machine does memory copies at 43MB/s - don't bother comparing to
wildly different hardware: it's memcpy() bound. I get 55MB/s on my
alpha with the same kernel)
Linus
From: "John S. Dyson" <dy...@inuxs.att.com>
Subject: Re: TCP latency
Date: 1996/07/12
Message-ID: <31E664EB.167EB0E7@inuxs.att.com>#1/1
X-Deja-AN: 167999386
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI>
content-type: text/plain; charset=us-ascii
organization: Lucent Technologies, Columbus, Ohio
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 2.0 (X11; I; FreeBSD 2.1-STABLE i386)
Linus Torvalds wrote:
>
> In article <31E3D9E2.41C67...@dyson.iquest.net>,
> John S. Dyson <t...@dyson.iquest.net> wrote:
> >
> >One other thing, the numbers show that the DRIVER used on BSD is slower -- the
> >networking code is NOT SHOWN to be slower... Refer to the numbers...
>
> No, read the numbers again. Linux was faster on loopback too.
>
Given the same kernel compile options, that has not shown to be
true. The difference of 20usecs is well within the range of them.
>
> >Do you know that my localhost results on my P5-166 are 200usecs?
> >That is faster than the Linux measurements that are being espoused as a
> >"record" isn't it???
>
> Ooohh.. "FreeBSD is faster over loopback, when compared to Linux over
> the wire". Film at 11.
>
> linux$ ./lat_tcp linux
> $Id: lat_tcp.c,v 1.2 1995/03/11 02:25:31 lm Exp $
> TCP latency using linux: 181 microseconds
>
> That's on a P166 too. With a stable kernel. What were you saying
> again?
>
Not the same machine :-(. I see that percentage here is not as important
as the absolute latency is. Seems like a pretty small difference to
me given a total reimplementation. I guess alot of performance problems
are being fixed? Hmmm... Looks like the NEW IMPROVED Linux TCP suite
is about the same perf as the BSD code... Luckily, there is movement
afoot to clean-up the BSD networking code, and I wouldn't be too awful
suprised if it betters Linux. (Some pieces of it haven't been reworked
in years.)
> (And if you think you will get 10% better numbers by just changing
> compiler options, I'd suggest you _try_ it first, without spouting it on
> the newsgroups as facts with no backing).
>
I get big differences on kernel compile options (I have seen 10% or better
given -O vs. -O2 -fomit-frame-pointer, especially on code that uses lots of
registers.) You are still not controlling the experiment. Sigh... Certain
kinds of operations show big differences. One note, it is interesting that the
latency differences are the same "20usecs" on both benchmarks...
>
> And if you don't like latency numbers, what are your throughput numbers?
> (Btw, check your bcopy() speed first to see if the hardware really _is_
> comparable, see below)
>
> linux$ ./bw_tcp linux 50m
> $Id: bw_tcp.c,v 1.3 1995/06/21 21:02:49 lm Exp $
> Socket bandwidth using linux: 17.14 MB/sec
>
I get about 17-19 MB/sec on localhost also on FreeBSD. The MBUF
code is not very inefficient in reality. Again, it is hard to
come to any conclusions given different hardware.
>
> Yes, the machine was idle while doing this. I guess you can just do them
> in parallell, though, to get _some_ idea about the degradation under
> load (admittedly not a lot of sockets, but at least some activity for
> context switches etc):
>
Geesh, do you understand that your example tests only three connections
to the same machine? You are not showing scalability at all. (Mostly
you are showing that you arent' busting the cache.) The scalability
issues on the old Linux context switch didn't come into effect until
about 20processes did it? Herein, you are showing that the localhost
code under very little if NO load runs the same speed (at least to me.)
But you STILL are not addressing the issue of scalability (especially
to/from multiple TCP/IP addresses.)
>
> (This machine does memory copies at 43MB/s - don't bother comparing to
> wildly different hardware: it's memcpy() bound. I get 55MB/s on my
> alpha with the same kernel)
>
I don't bother comparing OSes unless it is the SAME hardware... (Actually,
I'll compare the results, but certainly NOT come to any conclusions.) At
least you are trying to use more information than just NO-LOAD latency
to compare the TCP suites... You ARE making progress.
John
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/12
Message-ID: <4s67sk$oa9@fido.asd.sgi.com>#1/1
X-Deja-AN: 168045650
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
John S. Dyson (dy...@inuxs.att.com) wrote:
: The scalability
: issues on the old Linux context switch didn't come into effect until
: about 20processes did it?
BS. They degraded exponentially. @ were worse than one.
: You ARE making progress.
You're failing the "oh, please don't be insulting" test again John.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: j...@ksu.ksu.edu (James M. Chacon)
Subject: Re: TCP latency
Date: 1996/07/12
Message-ID: <4s6k8o$4o0@fox.ksu.ksu.edu>#1/1
X-Deja-AN: 168078517
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
<4s220u$nmq@symiserver2.symantec.com> <31E53C2B.41C67EA6@inuxs.att.com>
organization: Kansas State University
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
"John S. Dyson" <dy...@inuxs.att.com> writes:
>t...@agora.rdrop.com wrote:
>>
>> You are probably correct in that Terry was speaking theoretically, rather than
>> practically. In any case, this thread has grown from the "my D$$K is bigger
>> than yours" to something more approximating reality, and has gotten more
>> useful and interesting as a result.
>>
>Y'know, I usually don't care how big my D$$K is until someone starts
>making theirs look bigger than it really is...
Which:
1. You haven't proved he's attempting to do. But of course arguing for no
particular reason hasn't ever stopped you before.
2. Why is this on the netbsd groups? If it's a comparison of your D$$K size
to Linus's, take it somewhere people care, like misc.test. I've seen
calm carefully constructed arguments from him, and complete senseless
ravings from you....
James
From: "John S. Dyson" <dy...@indy.celebration.net>
Subject: Re: TCP latency
Date: 1996/07/12
Message-ID: <31E6B8AB.3E6C@indy.celebration.net>#1/1
X-Deja-AN: 168081446
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: AT&T
mime-version: 1.0
reply-to: dy...@indy.celebration.net
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (WinNT; I)
Larry McVoy wrote:
>
> John S. Dyson (dy...@inuxs.att.com) wrote:
> : The scalability
> : issues on the old Linux context switch didn't come into effect until
> : about 20processes did it?
>
> BS. They degraded exponentially. @ were worse than one.
>
So have you demonstrated otherwise? You are alluding to the issue
that I am concerned about. It is that the no-load latency figures
don't consider the potential performance hit of even reasonably large
number connections. Also, the lat_tcp benchmark hasn't shown any kind
of real world performance that I see that most of the users of FreeBSD
are interested in.
> : You ARE making progress.
>
> You're failing the "oh, please don't be insulting" test again John.
>
Why is it insulting? I feel that the issue of scalability is starting
to be understood and acknowleged. He got up to three processes, but
it still isn't in the area where TCP scalability issues come in to play.
I really don't think that the issue of scalability had been considered
before, or why was the three process test even presented? :-).
Honestly,
even I didn't think that the Linux code would have gotten very slow at
three connections to localhost... I wouldn't even think that a
primitive TCP package would be affected by three connections (actually
six, if you consider both sides.)
I think that it is best to put this discussion aside until some
benchmarks are run under controlled circumstances, by unbiased
parties, and with benchmarks that actually measure something that
people generally need. This thing is degrading all the way, bordering
on teasing by running a scalability benchmark with three :-)
connections...
John
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/12
Message-ID: <31E6FD92.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 168119357
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
<4s220u$nmq@symiserver2.symantec.com> <31E53C2B.41C67EA6@inuxs.att.com>
<4s6k8o$4o0@fox.ksu.ksu.edu>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
James M. Chacon wrote:
>
> "John S. Dyson" <dy...@inuxs.att.com> writes:
>
> >t...@agora.rdrop.com wrote:
>
> >>
> >> You are probably correct in that Terry was speaking theoretically, rather than
> >> practically. In any case, this thread has grown from the "my D$$K is bigger
> >> than yours" to something more approximating reality, and has gotten more
> >> useful and interesting as a result.
> >>
> >Y'know, I usually don't care how big my D$$K is until someone starts
> >making theirs look bigger than it really is...
>
> Which:
>
> 1. You haven't proved he's attempting to do. But of course arguing for no
> particular reason hasn't ever stopped you before.
>
He made a claim that BSD networking is not as fast as Linux, specifically
using the no-load latency figure. It was simply silly. I tried to show
him how silly it was, and he unfortunately started taking offense.
> 2. Why is this on the netbsd groups? If it's a comparison of your D$$K size
> to Linus's, take it somewhere people care, like misc.test. I've seen
> calm carefully constructed arguments from him, and complete senseless
> ravings from you....
>
Sorry James, but I wasn't the one that added NetBSD to this
argument. Look to someone else :-). Also, please recognise that it
is NOT senseless to consider the issue of scalability. To most people
the no-load latency benchmark is bordering on meaningless. Note also
that NetBSD and FreeBSD perform almost exactly the same in the
networking
arena. I guess you are not interested?
Linus has NOT proven his initial statement that Linux networking is faster than
BSD.... Sigh... You can't win sometimes with the truth... Please refer to
my posting that I suggest that this is degrading so far, that Linus has tried
a run of three connections :-) to show scalability. Time to really benchmark
the thing. Again, this applies to NetBSD also, because again, it isn't much
different than FreeBSD. Further necessary responses will be redirected to
the comp.os.linux.misc group, simply because it seems to be where all of
the scalability "experts" are. :-). They can prove that Linux is faster
than *BSD all they want there (with 3 connections :-)).
John
From: "Jordan K. Hubbard" <j...@FreeBSD.org>
Subject: Re: TCP latency
Date: 1996/07/12
Message-ID: <31E73BCA.41C67EA6@FreeBSD.org>#1/1
X-Deja-AN: 168156068
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
<31E16DB5.41C67EA6@dyson.iquest.net> <4rtvpf$7e5@fido.asd.sgi.com>
to: l...@slovax.engr.sgi.com
content-type: text/plain; charset=us-ascii
organization: Walnut Creek CDROM
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
> But given that the effect is only felt in exec and that exec is only
> used for the process benchmarks, I fail to see why this was perceived
> as such a big deal. I've included the results that I published in the
> Usenix paper - please note that the FreeBSD machine was a 133Mhz P5 and
> the Linux machine was 120Mhz P5. It's pretty lame of the FreeBSD crowd
> to be saying I stacked the deck when the Linux box was slower hardware.
Now Larry, at least try to be honest here.. You had TWO machines in
your Linux results, a P5 and a P6. I was there, and it was the P6
numbers for Linux you crowed about most triumphantly, comparing them to
the numbers for the P5/133 FreeBSD box more than once. I also noticed
that the P5/120 numbers were given somewhat rather less attention in
your speech, and when you really started going on about those P6 numbers
and how they blew all the other PC benchmarks away (something you
attributed rather bald-facedly to Linux rather than the hardware), the
groans of disgust from the FreeBSD section were audible all the way in
the back. I was scarcely the only one there who got the strong
impression you were deliberately and knowingly stacking the deck.
--
Jordan Hubbard
President, FreeBSD Project
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s7j2r$blf@fido.asd.sgi.com>#1/1
X-Deja-AN: 168148882
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com> <31E6B8AB.3E6C@indy.celebration.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
: So have you demonstrated otherwise? You are alluding to the issue
: that I am concerned about. It is that the no-load latency figures
: don't consider the potential performance hit of even reasonably large
: number connections. Also, the lat_tcp benchmark hasn't shown any kind
: of real world performance that I see that most of the users of FreeBSD
: are interested in.
Whine, whine, whine. I'm getting pretty sick of it. You use my tools,
complaining all the way, and offer nothing in return. If you want something
better, you're welcome to write it. Otherwise, you're just a whiner.
: > : You ARE making progress.
: >
: > You're failing the "oh, please don't be insulting" test again John.
: >
: Why is it insulting? I feel that the issue of scalability is starting
: to be understood and acknowleged.
Think about who you are talking about. Here's a guy that has written
much of a generic kernel (*nobody* in the BSD camp can come close to
saying the same), a guy that is doing a hell of job of outperforming your
stuff, and you sit there and say "I feel that the issue of scalability is
starting to be understood and acknowleged." Well thanks for your input.
I'm sure glad we have you here to tell me that scaling is important.
I'll bet Linus is learning a lot from your postings, keep up the good
work.
: I think that it is best to put this discussion aside until some
: benchmarks are run under controlled circumstances, by unbiased
: parties, and with benchmarks that actually measure something that
: people generally need.
I may be biased in which operating system that I want to run, I'll cop
to that. But if you are accusing me of publishing fudged numbers in any
way, shape, or form, then you're questioning my professional integrity
and I take that seriously enough that you'll end up in court.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s7jsd$blf@fido.asd.sgi.com>#1/1
X-Deja-AN: 168156072
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
<31E16DB5.41C67EA6@dyson.iquest.net> <4rtvpf$7e5@fido.asd.sgi.com>
<31E73BCA.41C67EA6@FreeBSD.org>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
Jordan K. Hubbard (j...@FreeBSD.org) wrote:
: Larry McVoy wrote:
: > But given that the effect is only felt in exec and that exec is only
: > used for the process benchmarks, I fail to see why this was perceived
: > as such a big deal. I've included the results that I published in the
: > Usenix paper - please note that the FreeBSD machine was a 133Mhz P5 and
: > the Linux machine was 120Mhz P5. It's pretty lame of the FreeBSD crowd
: > to be saying I stacked the deck when the Linux box was slower hardware.
: Now Larry, at least try to be honest here.. You had TWO machines in
: your Linux results, a P5 and a P6. I was there, and it was the P6
: numbers for Linux you crowed about most triumphantly, comparing them to
: the numbers for the P5/133 FreeBSD box more than once.
The P6 numbers were there to compare to Alphas, Ultras, and R10Ks,
and Linux was seen to be pretty nice in comparison to the vendor OS's.
I included P5/Linux numbers so that there would be a fair comparison
made between P5/Linux and P5/BSD. If I had P6/BSD numbers, I would have
included them. I didn't have them. Still don't, in fact.
: I also noticed
: that the P5/120 numbers were given somewhat rather less attention in
: your speech, and when you really started going on about those P6 numbers
: and how they blew all the other PC benchmarks away (something you
: attributed rather bald-facedly to Linux rather than the hardware), the
: groans of disgust from the FreeBSD section were audible all the way in
: the back. I was scarcely the only one there who got the strong
: impression you were deliberately and knowingly stacking the deck.
Man, oh, man. So what makes you think that you are important enough that
I'd write a benchmark suite (no small task), then collect a bunch of data,
then write paper, all with the goal of making the *BSD camps look stupid?
Seems like y'all are doing just fine without my help.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s7gdd$a79@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 168172479
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
<4s220u$nmq@symiserver2.symantec.com> <31E53C2B.41C67EA6@inuxs.att.com>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E53C2B.41C67...@inuxs.att.com>,
John S. Dyson <dy...@inuxs.att.com> wrote:
>
>Y'know, I usually don't care how big my D$$K is until someone starts
>making theirs look bigger than it really is...
Nyaah nyaah, I have a 2GB D$$K in my home machine. AND I modified df to
actually print out numbers that are twice as large, so it _looks_ like I
have a 4GB D$$K. So there!
Now somebody is going to tell me they have a 20GB RAID D$$K that does
mirroring and striping in hardware. Damn, that's unfair,
Linus
From: Michael Hancock <micha...@cet.co.jp>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E79738.1D1E@cet.co.jp>#1/1
X-Deja-AN: 168179801
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com> <31E6B8AB.3E6C@indy.celebration.net>
<4s7j2r$blf@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: CET
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 2.0 (Win95; I)
Larry McVoy wrote:
>
> I may be biased in which operating system that I want to run, I'll cop
> to that. But if you are accusing me of publishing fudged numbers in any
> way, shape, or form, then you're questioning my professional integrity
> and I take that seriously enough that you'll end up in court.
Good grief!
You're in the benchmark business, you should be prepared to take a lot of
heat. Next time you'll cover your a$$ and get past your biases and run
benchmarks on the *exact* hardware for everything.
I don't think you fudged your numbers, but I question your professional
integrity by running it on different hardware and displaying your obvious
bias in a presentation. Go ahead take me to court.
-mike hancock
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E7B8A5.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 168196395
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
<31E16DB5.41C67EA6@dyson.iquest.net> <4rtvpf$7e5@fido.asd.sgi.com>
<31E73BCA.41C67EA6@FreeBSD.org> <4s7jsd$blf@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
>
>
> : I also noticed
> : that the P5/120 numbers were given somewhat rather less attention in
> : your speech, and when you really started going on about those P6 numbers
> : and how they blew all the other PC benchmarks away (something you
> : attributed rather bald-facedly to Linux rather than the hardware), the
> : groans of disgust from the FreeBSD section were audible all the way in
> : the back. I was scarcely the only one there who got the strong
> : impression you were deliberately and knowingly stacking the deck.
>
> Man, oh, man. So what makes you think that you are important enough that
> I'd write a benchmark suite (no small task), then collect a bunch of data,
> then write paper, all with the goal of making the *BSD camps look stupid?
> Seems like y'all are doing just fine without my help.
>
Larry, you are bordering on insulting. Actually, you need to see what
you look like. Firstly, we have shown that you have made biased
conclusions from results. Secondly, you are downplaying the efforts
of others. I really don't think that you are qualified to present
ANY kind of benchmark results with ANY sort of conclusions because
of your obvious disdain and bias. In fact, I would be embarrassed
to present anything in public if I was you. At least I am being
consistant and publically represent myself as a FreeBSD person.
Over and over, I have said that your benchmark suite is useful, but
your credibility on interpreting results is nearly ZERO. Your interest
in Linux is well known, and I am sorry that the GPL had kept me from
accepting the recrutment onto the Linux team a few months ago. Linux
does need help from good people, but this no-load latency fiasco (with
the total lack of integrity of parties on presenting results), and the
misinterpretation of results during USENIX makes me feel as though I
would not be working with professional peers, but with lieing children.
Notice how important I was when I was asked to help on Linux? and now
you try to put me and my efforts down?
For the people in the peanut gallery, there are alot of things that
go on in the background, but I have been standing firm on two issues:
INTEGRITY and the fact that GPL encumberance causes alot of people severe
problems.
John
PS. Larry, thanks for the call!!! I wasn't interested... Especially
in GPLed software.
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E7BD6F.167EB0E7@dyson.iquest.net>#1/1
X-Deja-AN: 168196399
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com> <31E6B8AB.3E6C@indy.celebration.net>
<4s7j2r$blf@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
>
> : So have you demonstrated otherwise? You are alluding to the issue
> : that I am concerned about. It is that the no-load latency figures
> : don't consider the potential performance hit of even reasonably large
> : number connections. Also, the lat_tcp benchmark hasn't shown any kind
> : of real world performance that I see that most of the users of FreeBSD
> : are interested in.
>
> Whine, whine, whine. I'm getting pretty sick of it. You use my tools,
> complaining all the way, and offer nothing in return. If you want something
> better, you're welcome to write it. Otherwise, you're just a whiner.
>
I have written benchmarks better than yours for my purposes. In fact
they measure more real world numbers. Yours are good for initial
no-scaled checks. I don't release them, but suffice it to say, I am
happy with the results. Remember, it is the Linux crowd that initially
released the bogus conclusions from incomplete results (given YOUR benchmarks).
If all that was claimed was: Linux's ZERO LOAD LATENCY appears to be faster
than *BSD now. THERE WOULD HAVE BEEN NO PROBLEM. That statement would appear
have great integrity considering THE FACT that the only measurement results
that were quoted were ZERO LOAD LATENCY...
>
> : > : You ARE making progress.
> : >
> : > You're failing the "oh, please don't be insulting" test again John.
> : >
> : Why is it insulting? I feel that the issue of scalability is starting
> : to be understood and acknowleged.
>
> Think about who you are talking about. Here's a guy that has written
> much of a generic kernel (*nobody* in the BSD camp can come close to
> saying the same), a guy that is doing a hell of job of outperforming your
^^^^^^^^^^^^^
This is where questionable integrity comes in,
extending incomplete results into a general conclusion. The conclusions
would have much more integrity if the benchmarks demonstrated them. The
benchmarks that have been presented so far DO NOT. You sound very
emotional in the support of Linux. Yes, Linus should be happy that
Linux APPEARS to be catching up in certain areas. That is ALL that can be
concluded at this point.
> stuff, and you sit there and say "I feel that the issue of scalability is
> starting to be understood and acknowleged." Well thanks for your input.
Yep, Linus got up to three(3) connections :-). Psst, try 1000-3000
connections with different IP/PORT addresses, then it all starts getting
very very interesting :-).
> I'm sure glad we have you here to tell me that scaling is important.
> I'll bet Linus is learning a lot from your postings, keep up the good
> work.
>
Pompus, aren't we? :-). Does that make me a BLASPHEMER? He has NOT shown
competency in benchmarking. I'll bet you that there are qualities about
me that blow YOU AND LINUS away, but that does not make me better in the
areas that I am not expert. Additionally, have you been open about
the attempted recruitment of me onto Linux? (Y'know the VM system needs
work?)
> : I think that it is best to put this discussion aside until some
> : benchmarks are run under controlled circumstances, by unbiased
> : parties, and with benchmarks that actually measure something that
> : people generally need.
>
> I may be biased in which operating system that I want to run, I'll cop
> to that. But if you are accusing me of publishing fudged numbers in any
> way, shape, or form, then you're questioning my professional integrity
> and I take that seriously enough that you'll end up in court.
>
There is little or no integrity (it could be competency, but I won't
belabor that point) in someone who would extend a single (or
even a few) benchmark figures into a general conclusion. If you call
that me calling you names, then you have come to the conclusion yourself
There is certainly adequate information that is available publically that
shows your Linux bias anyway. At least I am publically honest about having
a FreeBSD bias.
John
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E7C0DD.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 168199814
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
<4s220u$nmq@symiserver2.symantec.com> <31E53C2B.41C67EA6@inuxs.att.com>
<4s6k8o$4o0@fox.ksu.ksu.edu> <31E6FD92.41C67EA6@dyson.iquest.net>
<4s8cuq$ljd@bertrand.ccs.carleton.ca>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Mike Shaver wrote:
>
> John S. Dyson (t...@dyson.iquest.net) wrote:
> : He made a claim that BSD networking is not as fast as Linux, specifically
> : using the no-load latency figure.
>
> He posted numbers to back up his claim that a given Linux was faster
> than a given *BSD under a given load state on given hardware.
>
> Are you disputing that fact? Would you be so kind as to let us se the
> numbers which enlightened you as to the results of the One True
> Benchmark.
>
Yes I am disputing the fact, the fact is that he had said that the
TCP latency is faster. Bzzt, that is the wrong conclusion. The
TCP latency under NO LOAD is faster. Most people don't understand
the difference, but one claim is accurate, and the other is NOT.
> Please read his posting in which he says that you _could_ run a couple
> lat_tcps in parallel, which wouldn't do much, but you'd at least get
> some context switch overhead in there. (Linux's context switches seem
> to be pretty peppy as well, though. =) )
>
The point is being missed, and this is why either Linus either doesn't
know the scalability issues, or he is disinforming. The issue is that
when most people who use the OS see the latency problem, it is when the
systems are under heavy load, and the latency that was measured by lat_tcp
is pretty much meaningless. Does Linux claim that the Linux networking
is under heavy load with only THREE connections? Sorry, even I don't
believe that one.
>
> Of course, you might have trouble finding a benchmark that everyone
> agrees is `meaningful'. Although you might possess the arrogance to
> declare what `most FreeBSD users' consider meaningful, I'm almost
> certain Linus will let the Linux community speak for itself.
>
The only arrogance that I have seen is that certain people are trying
to pass off benchmark results with bogus conclusions. I am being
skeptical because of the continued INCORRECT conclusions given the
benchmark results presented. (Psst, they are misinforming you and
I am trying to protect you from that...)
Please take a look at lat_tcp, and considering that it is run alone
on a machine and there are generally only a few other TCP connections
on the machine... How can it POSSIBLY show ANYTHING but NO-LOAD latency?
If a claim is made other than NO-LOAD latency, then someone is trying to
pull the wool over your eyes...
John
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s8piu$f6p@fido.asd.sgi.com>#1/1
X-Deja-AN: 168215496
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com> <31E6B8AB.3E6C@indy.celebration.net>
<4s7j2r$blf@fido.asd.sgi.com> <31E79738.1D1E@cet.co.jp>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
Michael Hancock (micha...@cet.co.jp) wrote:
: You're in the benchmark business, you should be prepared to take a lot of
: heat. Next time you'll cover your a$$ and get past your biases and run
: benchmarks on the *exact* hardware for everything.
No, I'm not in the benchmark business. I'm in the OS business. The fact
that I happened to have a bunch of tools sitting around that people liked
was a side effect of doing my job. It certainly isn't my job to write
benchmarks, it's my job to make things go fast. The benchmarks exist
only to tell me if I've done a decent job or not.
I'm not very worried about covering my ass. Last I checked, the usenet
was not paying my salary. Let me know if you are offering, and I'll
be happy to do things to your exact specifications.
: I don't think you fudged your numbers, but I question your professional
: integrity by running it on different hardware and displaying your obvious
: bias in a presentation. Go ahead take me to court.
I don't have any issue with the fact that I'm biased towards Linux,
simply because they are a pleasant and responsive crowd to work with.
And I could care less who knows that.
Where I get upset is when people suggest I cooked the numbers. I actually
walked through all the results and carefully picked the ones that looked
like they were reproduceable and accurate. I had a FreeBSD run that for
some reason had much worse numbers (I suspect they were doing something
else on that machine at the time) and I could have easily presented that
if I wanted to cook the numbers. I didn't, and never would.
I should probably not even argue about this, you can go get the benchmark
and reproduce the numbers yourself if you have any doubts. I do take
exception to people suggesting I fudged the numbers, so I'll ask you
to produce data if you're going to go that route. Or just shut up.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s8rtp$jsh@fido.asd.sgi.com>#1/1
X-Deja-AN: 168221406
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
<31E16DB5.41C67EA6@dyson.iquest.net> <4rtvpf$7e5@fido.asd.sgi.com>
<31E73BCA.41C67EA6@FreeBSD.org> <4s7jsd$blf@fido.asd.sgi.com>
<31E7B8A5.41C67EA6@dyson.iquest.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
John S. Dyson (t...@dyson.iquest.net) wrote:
: Firstly, we have shown that you have made biased
: conclusions from results.
What conclusions? And how were they biased? I went through the numbers
again last night and I don't really see how you can call 'em biased. The
one place that I screwed up is the Linux a.out shared libs versus the
FreeBSD SunOS style libs. And that's not a screwup, that's what was
there. Cray doesn't have shared libs - does that mean I can't report
Unicos numbers? I don't think so.
: Secondly, you are downplaying the efforts
: of others. I really don't think that you are qualified to present
: ANY kind of benchmark results with ANY sort of conclusions because
: of your obvious disdain and bias. In fact, I would be embarrassed
: to present anything in public if I was you.
Apparently, I'm overcoming that embarrassment just fine. :-) Equally
apparently, the Usenix association seemed to have the opposite idea,
given that lmbench got best of conference. And after the fact, it
seems like the interest in the benchmark suite has grown, not waned,
as would be expected if it was biased.
I think you are getting confused a little. The *benchmark* is not at
all biased. The numbers are the numbers. I am certainly biased in
that I prefer to work with Linus & Co, simply because I never get into
this sort of waste of time. But my bias is not at all present in the
benchmark, and I resent the implication, if that's what you are saying.
If you're saying I'd rather work on Linux than *BSD, you're right.
If you're saying that I'd cook the numbers to make Linux look better
than BSD, you're slandering me and I'll bet that's not what you want
to do.
: Over and over, I have said that your benchmark suite is useful, but
: your credibility on interpreting results is nearly ZERO.
Well, I guess that's your opinion. It's not widely shared outside of
the sour grapes department.
: Notice how important I was when I was asked to help on Linux? and now
: you try to put me and my efforts down?
John, you're obviously a smart guy. When I approached you about working
on Linux, it was more for your own benefit than for Linux'. It was
obvious to me then (as it is now) that the Linux effort was far more
focussed on cool technology than on people's personalities. My fear
for you, which is obviously realized, was that you would get tangled
up in silly arguments about BSD vs the world instead of having a
pleasant time working with pleasant people working on widely used
technology.
"A mind is a terrible thing to waste." I felt then, and feel now, that
working on *BSD is basically a waste of time. It was a compliment to
you that I was interested enough to try and get you to see things from
a different point of view. I'm sure you don't take it that way, but
that's your problem, not mine.
My point of view on this extends to the other smart & productive people
working on the various BSD fractions. I feel that it is self defeating
to have BSDI, OpenBSD, FreeBSD, NetBSD, and 386BSD out there. Isn't
it obvious at this point that Linux is doing a much better job of keeping
the crowd of people focussed on the technology instead of the personalities?
Is it really worthwhile to have these arguments? Wouldn't it be better
if we were all working on the same thing, making one OS the best? Instead
of arguing that your variant is better than their variant? When are you
going to realize that my bias towards Linux is because of the fact that
Linux is constantly drawing more people towards itself, while *BSD is
constantly driving people away?
The cool part about Linux is that there are no arguments like this. This
sort of time waster is a BSD idiosyncrasy, one that is a major bummer.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s8sau$jsh@fido.asd.sgi.com>#1/1
X-Deja-AN: 168223070
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com> <31E6B8AB.3E6C@indy.celebration.net>
<4s7j2r$blf@fido.asd.sgi.com> <31E7BD6F.167EB0E7@dyson.iquest.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
: > Whine, whine, whine. I'm getting pretty sick of it. You use my tools,
: > complaining all the way, and offer nothing in return. If you want something
: > better, you're welcome to write it. Otherwise, you're just a whiner.
: >
: I have written benchmarks better than yours for my purposes. In fact
: they measure more real world numbers. Yours are good for initial
: no-scaled checks. I don't release them, but suffice it to say, I am
: happy with the results.
Vaporware, John. If you really have them, put together a benchmark suite.
What, it isn't easy? It takes time? You have to make it portable?
You have to test it on a bunch of different platforms? You have to
gather a bunch of data? You have to let people tell you you did it wrong?
You can't handle that?
: If all that was claimed was: Linux's ZERO LOAD LATENCY appears to be faster
: than *BSD now. THERE WOULD HAVE BEEN NO PROBLEM. That statement would appear
: have great integrity considering THE FACT that the only measurement results
: that were quoted were ZERO LOAD LATENCY...
Umm, John, you're the only person that interpreted the results in the way
that gives you heartburn. Perhaps you want to show me the lat_tcp man
page and point out where it says that this is a throughput, loading, or
anything other than a single threaded latency benchmark? Can't find it?
How about the news posting where someone said that lat_tcp is the killer
throughput benchmark? Or a scaling benchmark? Can't find that either?
It kind of looks to me like you just wanted to vent. That's cool, but
don't blame your frustration on anything but yourself.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s8tcn$jsh@fido.asd.sgi.com>#1/1
X-Deja-AN: 168225780
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
<4s220u$nmq@symiserver2.symantec.com> <31E53C2B.41C67EA6@inuxs.att.com>
<4s6k8o$4o0@fox.ksu.ksu.edu> <31E6FD92.41C67EA6@dyson.iquest.net>
<4s8cuq$ljd@bertrand.ccs.carleton.ca> <31E7C0DD.41C67EA6@dyson.iquest.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
: Yes I am disputing the fact, the fact is that he had said that the
: TCP latency is faster. Bzzt, that is the wrong conclusion. The
: TCP latency under NO LOAD is faster. Most people don't understand
: the difference, but one claim is accurate, and the other is NOT.
Nobody said that Linux' TCP latency under load is faster, in fact, I pointed
out that it degrades to about the same as FreeBSD under load. I said, and
the benchmark said, that a ping pong test using TCP was faster under Linux
than on FreeBSD. You turned it into this general statement about TCP
latency under all conditions. That's your problem.
: The point is being missed, and this is why either Linus either doesn't
: know the scalability issues, or he is disinforming. The issue is that
: when most people who use the OS see the latency problem, it is when the
: systems are under heavy load, and the latency that was measured by lat_tcp
: is pretty much meaningless.
It's useful to know what your protocol stack is costing you. If you load
up the system, you don't know if the degradation is due to cache misses,
TCP lookup problems, locking (either bottom/upper half and/or SMP), etc.
It's useful to know the unloaded latency because it is safe to say that it
is unlikely that the latency is going to get better under load (it could,
but I think we can agree - maybe - that that is an anomaly). So if you
are trying to scale to N ping pong tests, and you know that one takes
10% of your system, then you have a pretty good idea that you aren't going
to do much better than 10 (yes, you actually could do much better than
10 if you worked your OS right. Bitch about that when you've got an OS
that shows better average latency under load than under no load; I've
been through this, it isn't easy. But since you are screaming about
how you have this great OS under load, perhaps you'd like to share
those great results?).
: > Of course, you might have trouble finding a benchmark that everyone
: > agrees is `meaningful'. Although you might possess the arrogance to
: > declare what `most FreeBSD users' consider meaningful, I'm almost
: > certain Linus will let the Linux community speak for itself.
: >
: The only arrogance that I have seen is that certain people are trying
: to pass off benchmark results with bogus conclusions.
You seem to be drawing the bogus conclusions. I personally let the numbers
speak for themselves. In the year or so that lmbench has been in widespread
public use, the only time I ever get involved (and I shouldn't) has always
been because of some BSD issue.
: Please take a look at lat_tcp, and considering that it is run alone
: on a machine and there are generally only a few other TCP connections
: on the machine... How can it POSSIBLY show ANYTHING but NO-LOAD latency?
: If a claim is made other than NO-LOAD latency, then someone is trying to
: pull the wool over your eyes...
And where is that claim being made, John? Where? You can claim that it
would be better if the TCP latencies where shown as a function of the
number of copies running in parallel, and I would agree that that's a
nice benchmark, but so what?
Nobody claimed that lat_tcp was a scaling benchmark. Maybe the problem is
that you assumed it was, or you wanted it to be.
It's kind of fun to contrast this with the Linux crowd:
BSD guys: "your benchmark sucks! your numbers are wrong! you mislead the
world! you suck! whine!"
Linux guys: "Hey Larry, the null syscall benchmark is busted because we can
do a null syscall in about 1 usec. You need to change it so
it times in nanoseconds".
So, I give up on convincing the BSD crowd of anything. I have too much
work to do anyway. If you have specific requests for the next release of
lmbench, please write up a "man page spec" for what you want. Steal one
of the existing lmbench man pages and modify it. Send that to me.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E7FB69.167EB0E7@dyson.iquest.net>#1/1
X-Deja-AN: 168230668
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com> <31E6B8AB.3E6C@indy.celebration.net>
<4s7j2r$blf@fido.asd.sgi.com> <31E79738.1D1E@cet.co.jp>
<4s8piu$f6p@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
>
> I should probably not even argue about this, you can go get the benchmark
> and reproduce the numbers yourself if you have any doubts. I do take
> exception to people suggesting I fudged the numbers, so I'll ask you
> to produce data if you're going to go that route. Or just shut up.
>
The biggest problem that I have is NOT with the numbers, but with the
conclusions associated with the numbers. For example, you run a
test on a P6-200 with Linux and P5-133 with FreeBSD. Because the
Linux runs are faster than FreeBSD, does NOT MEAN that the Linux kernel
is better (faster) than the FreeBSD kernel. All you can say is that the
faster machine ran the BENCHMARKS on Linux faster than the slower
machine ran the BENCHMARKS on FreeBSD.
My position is that BENCHMARKS are good ONLY at measuring what they
measure, and to compare OSes, it is very important to understand what
is measured. Since most people don't understand what is being mesasured,
because they most likely don't read the code, the conclusions made
by people who analyse the results are as influential as the benchmark
numbers themselves. Just be careful and have integrity with
conclusions.
John
From: sth...@nethelp.no (Steinar Haug)
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <4s9173$b8l@verdi.nethelp.no>#1/1
X-Deja-AN: 168233151
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
organization: Nethelp Consulting, Trondheim, Norway
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
["John S. Dyson"]
| > No, read the numbers again. Linux was faster on loopback too.
| >
| Given the same kernel compile options, that has not shown to be
| true. The difference of 20usecs is well within the range of them.
.
| I get big differences on kernel compile options (I have seen 10% or
| better given -O vs. -O2 -fomit-frame-pointer, especially on code that
| uses lots of registers.)
OK, let's see if we can get at least some of these problems out of the
way. I promise this will be the last posting from me on the subject ;-)
I have repeated my original lat_tcp measurements for the loopback case.
It's been done on *one* processor only, specific details:
Processor: AMD 5x86-133, overclocked to 160 MHz
Motherboard: ASUS PVI-486SP3, 24 MByte memory, 256 kByte cache
OS: Either FreeBSD 2.2-960612-SNAP or Linux 2.0.0
C compiler: gcc-2.6.3 for FreeBSD, 2.7.2 for Linux
Optimization: Three different levels:
1. Default FreeBSD: -O
2. Default Linux: -O2 -fomit-frame-pointer -fno-strength-reduce
3. Mix: -O2 -fomit-frame-pointer
I did 3 also because I thought that might be the fastest. This was not
necessarily the case; more on that below. I also tried the -m486 option,
which Linux uses by default on my AMD. It made absolutely no difference.
I ran 400 iterations of lat_tcp on an unloaded machine (single user mode).
As has been pointed out, this says nothing about scaling, or performance
under load conditions. It *does* say something about what's the minimum
achievable latency. Times below are the averages over 400 iterations, in
usecs.
Optimization FreeBSD Linux
--------------------------------------------
1 389 351
2 379 366
3 367 369
I also estimated standard deviation using the normal formula. It was in
the range 10-15 for all of the numbers above.
And what does it mean?
- On this particular machine, the measured versions of FreeBSD and Linux
are so close on the lat_tcp loopback test that I'm highly doubtful it
makes any difference at all in practice.
- Linux was somewhat faster on the average for two of the optimization
levels, but given the estimated standard deviation I find it hard to
draw any conclusion from this.
- The compilation options have *some* effect, but not necessarily what
you think. You need to actually try it out to draw sensible conclusions.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E805B5.41C67EA6@dyson.iquest.net>
X-Deja-AN: 168236455
references: <4paedl$4bm@engnews2.eng.sun.com> <4pf7f9$bsf@white.twinsun.com>
<4rql4p$39f@innocence.interface-business.de> <4rrimn$dro@fido.asd.sgi.com>
<31E16DB5.41C67EA6@dyson.iquest.net> <4rtvpf$7e5@fido.asd.sgi.com>
<31E73BCA.41C67EA6@FreeBSD.org> <4s7jsd$blf@fido.asd.sgi.com>
<31E7B8A5.41C67EA6@dyson.iquest.net> <4s8rtp$jsh@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
>
> Apparently, I'm overcoming that embarrassment just fine. :-) Equally
> apparently, the Usenix association seemed to have the opposite idea,
> given that lmbench got best of conference. And after the fact, it
> seems like the interest in the benchmark suite has grown, not waned,
> as would be expected if it was biased.
>
So you hoodwinked them, additionally, I do praise your benchmark
suite. I think that your CONCLUSIONS are sometimes biased.
> I think you are getting confused a little. The *benchmark* is not at
> all biased. The numbers are the numbers.
Please read the statement above. Yeah, FreeBSD on a P5 is slower
than Linux on a P6 -- whaa, that hurts me :-). BTW, I would generally
agree with that!!!
> If you're saying I'd rather work on Linux than *BSD, you're right.
> If you're saying that I'd cook the numbers to make Linux look better
> than BSD, you're slandering me and I'll bet that's not what you want
> to do.
>
I am speaking conclusions and interpretation AGAIN.
> : Over and over, I have said that your benchmark suite is useful, but
> : your credibility on interpreting results is nearly ZERO.
>
> Well, I guess that's your opinion. It's not widely shared outside of
> the sour grapes department.
>
Again, your benchmark suite is good, I have said it over and over
again. It is really great when one can interpret the results, as
opposed to listening to other's, biased interpretations.
> : Notice how important I was when I was asked to help on Linux? and now
> : you try to put me and my efforts down?
>
> John, you're obviously a smart guy. When I approached you about working
> on Linux, it was more for your own benefit than for Linux'. It was
> obvious to me then (as it is now) that the Linux effort was far more
> focussed on cool technology than on people's personalities.
>
Actually, I see the cult-of-personality in Linux (remember Linus-god?)
Remember the comment that you made that I had no right to question him
because he wrote the basic parts of a kernel? Ahhh come on now. This
is a major pot calling the kettle black senerio. I seem to remember
both yours and Linus' condescending remarks... I think that I have
been in the professional world much longer than Linus, and perhaps
you too...
>
> "A mind is a terrible thing to waste." I felt then, and feel now, that
> working on *BSD is basically a waste of time.
>
Why was the networking suite re-developed from scratch by the Linux
team to get (eventually) essentially the same performance? That is
where the waste really is. (Also Linux could have brought the BSD
suite under GPL, and encumbered it very nicely also.)
> It was a compliment to
> you that I was interested enough to try and get you to see things from
> a different point of view. I'm sure you don't take it that way, but
> that's your problem, not mine.
>
I have gone through the GPL quagmire, and have had to remove myself
from it. I did contribute early on to some GPL software, but the
encumberences made it VERY UNDESIREABLE for me to continue.
> When are you
> going to realize that my bias towards Linux is because of the fact that
> Linux is constantly drawing more people towards itself, while *BSD is
> constantly driving people away?
>
We get converts from Linux every day. It is usually when Linux simply
does not work for them. It is the Linux team that started
this argument with UNSUBSTANTIATED CLAIMS... I did not bring it into
comp.unix.netbsd.misc, for example... Who did?
> The cool part about Linux is that there are no arguments like this. This
> sort of time waster is a BSD idiosyncrasy, one that is a major bummer.
>
I think that it was Linux people this time... It was very wrong to let
the disinformation continue. BTW, I haven't been trying to argue
the issue of performance as much as proper interpretation of the
results!!! Bogus generalized conclusions saying things like
"FreeBSD is slower than Linux, because lat_tcp and friends
run slower" is a common problem for beginners in benchmarking.
We need to help them be able to distinguish between hype and
reality. I saw unsubstantiated hype...
John
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E80ACA.167EB0E7@dyson.iquest.net>#1/1
X-Deja-AN: 168239489
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt>
<4s220u$nmq@symiserver2.symantec.com> <31E53C2B.41C67EA6@inuxs.att.com>
<4s6k8o$4o0@fox.ksu.ksu.edu> <31E6FD92.41C67EA6@dyson.iquest.net>
<4s8cuq$ljd@bertrand.ccs.carleton.ca> <31E7C0DD.41C67EA6@dyson.iquest.net>
<4s8tcn$jsh@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
> It's kind of fun to contrast this with the Linux crowd:
>
> BSD guys: "your benchmark sucks! your numbers are wrong! you mislead the
> world! you suck! whine!"
>
> Linux guys: "Hey Larry, the null syscall benchmark is busted because we can
> do a null syscall in about 1 usec. You need to change it so
> it times in nanoseconds".
>
I think that was a kind-of cute situation. We decided NOT
to special case the syscall that Larry uses for the
null-syscall case.
Oh, by the way... another excellent strawman from Larry!!
John
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/13
Message-ID: <31E80933.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 168239490
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net>
<4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net>
<4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com>
<4s67sk$oa9@fido.asd.sgi.com> <31E6B8AB.3E6C@indy.celebration.net>
<4s7j2r$blf@fido.asd.sgi.com> <31E7BD6F.167EB0E7@dyson.iquest.net>
<4s8sau$jsh@fido.asd.sgi.com>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Larry McVoy wrote:
>
> : > Whine, whine, whine. I'm getting pretty sick of it. You use my tools,
> : > complaining all the way, and offer nothing in return. If you want something
> : > better, you're welcome to write it. Otherwise, you're just a whiner.
> : >
> : I have written benchmarks better than yours for my purposes. In fact
> : they measure more real world numbers. Yours are good for initial
> : no-scaled checks. I don't release them, but suffice it to say, I am
> : happy with the results.
>
> Vaporware, John. If you really have them, put together a benchmark suite.
> What, it isn't easy? It takes time? You have to make it portable?
> You have to test it on a bunch of different platforms? You have to
> gather a bunch of data? You have to let people tell you you did it wrong?
> You can't handle that?
>
I am not interested, simply because they do what I want... Measure the
performance of the system for MY QUALITY CONTROL needs. If I can do it,
CERTAINLY someone like you with your benchmarking credentials could do
so also... Am I wrong? Are you up to it?
I do not publish my stuff simply because it is not an interest of mine, but
ONLY a tool. Very seldom, have I publically pronounced performance figures
from these benchmarks. Additionally, I have NOT said that FreeBSD is
superior only because of a single benchmark in my suite... I can tell you
individual performance figures from them, but certainly conclusions about
the merits of the OSes are hard to distinguish. This is definitely true
when there is only a difference of 10% or so...
> : If all that was claimed was: Linux's ZERO LOAD LATENCY appears to be faster
> : than *BSD now. THERE WOULD HAVE BEEN NO PROBLEM. That statement would appear
> : have great integrity considering THE FACT that the only measurement results
> : that were quoted were ZERO LOAD LATENCY...
>
> Umm, John, you're the only person that interpreted the results in the way
> that gives you heartburn.
>
Bzzt, please refer to the previous postings where even Linus said that
these were TCP latency measurements. The benchmark results are from
YOUR TCP latency measurement that DOES NOT consider load. AGAIN, it is
the interpretation and public proclaimations that are the most
insidious problem here. I AM NOT blaming your benchmarks, it is yours
and Linus, etc conclusions...
John
From: j...@uriah.heep.sax.de (J Wunsch)
Subject: Re: TCP latency
Date: 1996/07/14
Message-ID: <4sactc$fd5@uriah.heep.sax.de>#1/1
X-Deja-AN: 168331653
x-pgp-fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
references: <4paedl$4bm@engnews2.eng.sun.com> <4rqcsk$ff8@fido.asd.sgi.com>
content-type: text/plain; charset=ISO-8859-1
organization: Private BSD site, Dresden
mime-version: 1.0
reply-to: joerg_wun...@uriah.heep.sax.de (Joerg Wunsch)
newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
x-phone: +49-351-2012 669
l...@neteng.engr.sgi.com (Larry McVoy) wrote:
> I am certainly biased in
> that I prefer to work with Linus & Co, simply because I never get into
> this sort of waste of time.
Mind you, we are only getting into this waste of time due to (mostly)
silly discussions in Usenet. Well, and we are not as much discussing
with the *BSD folks there... So if you come for 5 minutes to ``this
side of the fence'', your argumentation looks very reasonable as well
-- just with the roles exchanged.
;-)
> I feel that it is self defeating
> to have BSDI, OpenBSD, FreeBSD, NetBSD, and 386BSD out there.
I feel that it is self defeating to have twenty-five different Linuxes
around. :) (I mean complete systems here, not only kernels.)
C'mon. The BSD camps are not that scattered as you would make us
believe. 386BSD is dead (and has been created for a totally different
purpose, that's why its `father' apparently went away), and BSDi is a
commercial enterprise that would hardly find a full counterpart in the
Linux camp. This leaves three of your 5 `mainstreams', where OpenBSD
and NetBSD are indeed a result of some sad personality conflicts. The
original roots of the NetBSD and FreeBSD streams are certainly also
personality-affected, but these days, there's mainly a different
enough focus between both `camps' that allows for a useful and
peaceful coexistance, including co-operation. There's perhaps more
co-operation than you think there were... (though not as much as one
would wish there were).
--
cheers, J"org
joerg_wun...@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency
Date: 1996/07/14
Message-ID: <4sadde$qsv@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 168366925
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E7C0DD.41C67EA6@dyson.iquest.net>
<4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E80ACA.167EB...@dyson.iquest.net>,
John S. Dyson <t...@dyson.iquest.net> wrote:
>Larry McVoy wrote:
>
>> It's kind of fun to contrast this with the Linux crowd:
>>
>> BSD guys: "your benchmark sucks! your numbers are wrong! you mislead the
>> world! you suck! whine!"
>>
>> Linux guys: "Hey Larry, the null syscall benchmark is busted because we can
>> do a null syscall in about 1 usec. You need to change it so
>> it times in nanoseconds".
>
>I think that was a kind-of cute situation. We decided NOT
>to special case the syscall that Larry uses for the
>null-syscall case.
John, John, John, calm down.
You are suggesting above that YOU did not special case the system call
that Larry uses in lmbench, and by implication you are claiming Linux
does. Very subtly done, but
YOU'RE LYING
Check out the facts before you post. Linux simply _is_ that fast. If we
beat you on system call latency (and I have to admit that I haven't even
looked at the FreeBSD numbers, so I'm just assuming that from your post
above), it's simply because Linux is faster. Not because we "special
case" anything at all. Why can't you accept simple facts?
As to _why_ Linux is that fast, the reason is simply that Linux has a
better interface to the kernel than any other UNIX I know about.
Instead of messing around with "u_area" etc crap, Linux does it _right_,
and saves all the state on the stack (and saves _minimal_ state).
You're almost as bad as MS in spreading FUD and misinformation. Why the
hell can't you just accept that somebody else is better at something? Or
are you claiming that your system call latency is better than Linux
under load?
John, instead of attacking people when you find out they are faster at
something, and claiming the benchmark is bogus, how about you try to
tell the world about what YOU are good at instead? Instead of being so
damn negative about this all, why don't you try to find the POSITIVE
stuff? Don't spread FUD and misinformation - try to spread the word
about the things FreeBSD is better at, ok?
Linus
From: l...@MCS.COM (Leslie Mikesell)
Subject: Re: TCP latency
Date: 1996/07/14
Message-ID: <4sbpim$f4i@Mercury.mcs.com>#1/1
X-Deja-AN: 169079538
references: <4paedl$4bm@engnews2.eng.sun.com> <31E7B8A5.41C67EA6@dyson.iquest.net>
<4s8rtp$jsh@fido.asd.sgi.com> <4sactc$fd5@uriah.heep.sax.de>
organization: /usr/lib/news/organi[sz]ation
newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
In article <4sactc$...@uriah.heep.sax.de>,
J Wunsch <joerg_wun...@uriah.heep.sax.de> wrote:
>
>> I feel that it is self defeating
>> to have BSDI, OpenBSD, FreeBSD, NetBSD, and 386BSD out there.
>
>I feel that it is self defeating to have twenty-five different Linuxes
>around. :) (I mean complete systems here, not only kernels.)
I disagree (in both cases). There are at least 25 reasons to set up
a system differently. However, I wish it were not left as an exercise
to the reader to find out which is best for which purposes, and worse
to try to keep his own system up to date in spite of the fact that
application distributions may have different defaults than that particular
setup. In other words, I'd like to see all distributions include a
discussion of the philosophy behind any changes and maintain an archive
site where updated apps can be obtained for that distribution. The number
of variations would then be pretty much irrelevant.
Les Mikesell
l...@mcs.com
From: j...@uriah.heep.sax.de (J Wunsch)
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <4sc2lk$d3l@uriah.heep.sax.de>#1/1
X-Deja-AN: 168775853
x-pgp-fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
references: <4paedl$4bm@engnews2.eng.sun.com> <4rrimn$dro@fido.asd.sgi.com>
content-type: text/plain; charset=ISO-8859-1
organization: Private BSD site, Dresden
mime-version: 1.0
reply-to: joerg_wun...@uriah.heep.sax.de (Joerg Wunsch)
newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
x-phone: +49-351-2012 669
l...@MCS.COM (Leslie Mikesell) wrote:
> >> I feel that it is self defeating
> >> to have BSDI, OpenBSD, FreeBSD, NetBSD, and 386BSD out there.
> >
> >I feel that it is self defeating to have twenty-five different Linuxes
> >around. :) (I mean complete systems here, not only kernels.)
>
> I disagree (in both cases). There are at least 25 reasons to set up
> a system differently.
But then you must admit that at least three different BSD streams are
not too many:
. one for a commercially supported system
. one for a multi-platform system
. one for a ``mainstream platform(s) only'' but all whistles and bells
system
That should cover 24 of your 25 reasons. ;-)
(Note that i personally don't have a problem with seeing more than one
Linux distribution, but i do have a problem with Larry McVoy not
allowing us to have more than one *BSD distribution.)
--
cheers, J"org
joerg_wun...@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <4seep0$f0l@fido.asd.sgi.com>#1/1
X-Deja-AN: 168428612
references: <4paedl$4bm@engnews2.eng.sun.com> <4rrimn$dro@fido.asd.sgi.com>
<4sc2lk$d3l@uriah.heep.sax.de>
followup-to: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
: (Note that i personally don't have a problem with seeing more than one
: Linux distribution, but i do have a problem with Larry McVoy not
: allowing us to have more than one *BSD distribution.)
Wow, I didn't realize that the BSD crowd felt they had to ask my
permission - that's cool, I'll have to start using all that power :-)
Actually, it's not distributuions that I care about, it's kernel level
source trees. The Unix world has fragmented to the point that there
are several standards bodies that do nothing but try (unsuccessfully)
to hold it all together.
Step back and look at Unix from Microsoft's perspective, or the customer's
perspective. We look like a bunch of squabbling kids - this thread is
a great example. If Unix, say 5 years ago, had converged to one source
base, to the point that the default installation on every hardware
platform was identical (same apps, same window manager, same look and
feel, same system calls), then Unix would have stood a chance of being
the Windows/NT of today. As it stands, the customers hate Unix, and
are doing everything they can to migrate off of it.
It's a wild ass shot, but the reason I push Linux over BSD is that Linux is
the mostly likely Unix, in my opinion, to be identical on every platform.
I used to think that NetBSD was the right answer, but the personalities of
the people there suggested to me that it was unlikely to attract a large
following.
I do not think that Linux is superior in every way to *BSD, in fact, I am
constantly beating on Linus to make things better. But I strongly believe
that the Linux development process is better than any of the BSD processes,
that Linus does a better job of keeping Linux from fragmenting than the
BSD camps (there's only one Linux kernel source tree, and there are at least
4 BSD ones, with no signs of convergence).
I do think that there will be a day where Linux is better or as good as
*BSD in every aspect. And I believe that Linux will be far more detached
from the politics and personalities that are so pervasive in the BSD world.
I think, if you care, that the big problem with the BSD world, to quote
Bill Fisher of SGI, is "everyone wants to drive the big red firetruck".
Since the BSD folks couldn't agree on a driver, they now have several,
somewhat smaller firetrucks. Linux still has one driver, Linus, and
everyone seems quite happy to let him drive. I like that.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: ch...@ccrc.wustl.edu (Chuck Cranor)
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <4sej3e$155@dworkin.wustl.edu>#1/1
X-Deja-AN: 168439096
references: <4paedl$4bm@engnews2.eng.sun.com> <4s7jsd$blf@fido.asd.sgi.com>
<31E7B8A5.41C67EA6@dyson.iquest.net> <4s8rtp$jsh@fido.asd.sgi.com>
organization: Washington University, St. Louis MO.
followup-to: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
In article <4s8rtp$...@fido.asd.sgi.com>,
Larry McVoy <l...@slovax.engr.sgi.com> wrote:
>"A mind is a terrible thing to waste." I felt then, and feel now, that
>working on *BSD is basically a waste of time.
If people are having fun and enjoying working on a project (be it BSD,
Linux, or whatever) who are you to judge? That is an extremely arrogant
position for you to take.
>My point of view on this extends to the other smart & productive people
>working on the various BSD fractions. I feel that it is self defeating
>to have BSDI, OpenBSD, FreeBSD, NetBSD, and 386BSD out there.
I disagree with you. I also believe you are discounting the cooperation
which exists between the various BSD groups, and ignoring the parallel
issue of the large number of Linux distributions.
>Isn't it obvious at this point that Linux is doing a much better job of
>keeping the crowd of people focussed on the technology instead of the
>personalities?
No, it isn't obvious to me. And even if it was obvious to me, I would
still assert that given your lack of recent involvement with the BSDs
you are not qualified to make such a statement (except out of ignorance).
>Is it really worthwhile to have these arguments? Wouldn't it be better
>if we were all working on the same thing, making one OS the best? Instead
>of arguing that your variant is better than their variant?
No, I don't think it would be better if we were all working on the same
thing. I don't even think it is possible due to logistical, political,
and philosophical differences. Also, people tend to generally like having
alternatives to choose from. Why should that be taken away?
>When are you going to realize that my bias towards Linux is because of
>the fact that Linux is constantly drawing more people towards itself,
>while *BSD is constantly driving people away?
First, I don't accept your "fact" as a fact. In other words, I don't
think you are in a position to accurately gage whether or not *BSD is
"constantly" driving people away.
Second, based on your past statements, I believe your bias towards Linux
is because of the fact that Linux is covered by the GPL, rather than the
BSD copyright. More than once you've expressed fear that someone will
attempt to take BSD code "private" and that you feel that the GPL is the
way to prevent and protect yourself from this. I fully believe, based
on your past statements, that you would favor a GPL'd OS over a non-GPL'd
OS no matter what the performance ("we can make it better") or how many
people the GPL'd OS was drawing.
Thus, I believe you have intentionally misrepresented your position as
to the source of your pro-linux bias in order to make a gratuitous attack
on everyone working on *BSD.
>The cool part about Linux is that there are no arguments like this. This
>sort of time waster is a BSD idiosyncrasy, one that is a major bummer.
The fact that you've contributed your half to this argument invalidates
your statement.
As far as I am concerned, the major bummer is when people try and simplify
the free OS world into a simple "us vs. them, we must win -- and if you
don't agree with us you are wasting your time" type scenario. As long
as you are having fun and are happy with your work, it shouldn't matter
what OS you are working on.
chuck
--
>>Chuck Cranor, Graduate Student, Computer and Communications Research Center<<
>>Washington University, St. Louis MO http://www.ccrc.wustl.edu/pub/chuck <<
... help! my wife has accepted a job with at&t research in new jersey and
now i've got to find a job in new jersey too ...
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <31E9E3A7.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 168804102
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E7C0DD.41C67EA6@dyson.iquest.net>
<4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net>
<4sadde$qsv@linux.cs.Helsinki.FI>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5aGold (X11; I; FreeBSD 2.2-CURRENT i386)
Linus Torvalds wrote:
>
> In article <31E80ACA.167EB...@dyson.iquest.net>,
> John S. Dyson <t...@dyson.iquest.net> wrote:
> >Larry McVoy wrote:
> >
> >> It's kind of fun to contrast this with the Linux crowd:
> >>
> >> BSD guys: "your benchmark sucks! your numbers are wrong! you mislead the
> >> world! you suck! whine!"
> >>
> >> Linux guys: "Hey Larry, the null syscall benchmark is busted because we can
> >> do a null syscall in about 1 usec. You need to change it so
> >> it times in nanoseconds".
> >
> >I think that was a kind-of cute situation. We decided NOT
> >to special case the syscall that Larry uses for the
> >null-syscall case.
>
> John, John, John, calm down.
>
> You are suggesting above that YOU did not special case the system call
> that Larry uses in lmbench, and by implication you are claiming Linux
> does. Very subtly done, but
>
We could have special cased it to make the benchmark look better, but
we did not. We have looked at it carefully, and it has little impact
on real-world performance. Historically, a NULL syscall is not
a write to /dev/null... That is what the benchmark is, and simply
it is NOT IMPORTANT.
>
> YOU'RE LYING
>
Look, jerk, you are continuing your
stupid, infantile attack on me and FreeBSD. I really don't care about
what you think. Secondly yours is the only response that made this
allegation like you have. YOU ARE ALONE...
Linus, you are an arrogant, self-righteous a**hole... If I acted as stupid
as you, I would also be as embarrased as you should be. I DEMAND
a public apology. You are the one that has been continuing to making
incorrect conclusions about benchmark results. I haven't made any,
but I am willing to give analysis of what is going on. Are you a
car salesman or something?
Anyone working in the real world would see what you are doing as
EXTREMELY UNETHICAL behavior.
>
> Check out the facts before you post. Linux simply _is_ that fast. If we
> beat you on system call latency (and I have to admit that I haven't even
> looked at the FreeBSD numbers, so I'm just assuming that from your post
> above), it's simply because Linux is faster. Not because we "special
> case" anything at all. Why can't you accept simple facts?
>
With the above statement, I charge you with public unethical behaviour.
Please apologize. Thank you.
>
> You're almost as bad as MS in spreading FUD and misinformation. Why the
> hell can't you just accept that somebody else is better at something? Or
> are you claiming that your system call latency is better than Linux
> under load?
>
Speaking of misinformation, apologize to me publically for your
allegation, because it is wrong.
Now, Linus, your above statement about me LYING is disgusting.
I was NOT lying, and you yourself know it. You are acting like a
real jerk. I know that you know that I AM NOT a LIAR,
therefore your comment is a serious case of abusing your public
position.
You have lost all credibility and I fully expect some followups
even from the Linux community. I sure hope that this mail was
forged, because you have taken your lofty position and destroyed
it.
I DEMAND A PUBLIC RETRACTION. ADDITIONALLY, I DEMAND A FORMAL
WRITTEN APOLOGY or PROOF OF A FORGED USENET POSTING. If you don't
it will be a further demonstration of your ill-will, condescending
behavior, or mean spiritedness.
John
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <31E9E60F.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 168804107
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E7C0DD.41C67EA6@dyson.iquest.net>
<4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net>
<4sadde$qsv@linux.cs.Helsinki.FI> <31E9E3A7.41C67EA6@dyson.iquest.net>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5aGold (X11; I; FreeBSD 2.2-CURRENT i386)
John S. Dyson wrote:
>
> Linus Torvalds wrote:
>
>
> >
> > YOU'RE LYING
> >
I think I just figured out what is going on, either
you are very mean spirited, frightened to death of
FreeBSD actually being a very good OS. Or you are
paranoid and need medication. Actually, you are
probably paranoid anyway because there is room for
two good os'es.
You totally disgust me and you really need
professional help. I did NOTHING to deserve this
comment from you.
I will be continuing to remind you of your very
low, unprofessional behavior until I get an
appropriate apology.
Thank you for your apology in advance.
John
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <31EA0618.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 168814808
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E7C0DD.41C67EA6@dyson.iquest.net>
<4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net>
<4sadde$qsv@linux.cs.Helsinki.FI>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5aGold (X11; I; FreeBSD 2.2-CURRENT i386)
I made some previous responses to this posting, and I was
told that I appeared too angry. I am going to parse this
message from Linus to prove my point that he is being a
bad net-person...
Linus Torvalds wrote:
>
> John, John, John, calm down.
>
Condescending remark, I was not angry at the time, and was simply
stating a fact. This was meant to talk down to me. This was
very very bad ettiquite on Linus' part.
> You are suggesting above that YOU did not special case the system call
> that Larry uses in lmbench, and by implication you are claiming Linux
> does.
>
I made no such claim. In fact, the implication made by you Linus
is disgusting, and a very low blow...
> Very subtly done, but
>
> YOU'RE LYING
>
At this point it is very obvious that I am not the Liar.
> Check out the facts before you post. Linux simply _is_ that fast.
>
I made no such claim, and the implication that I did is in fact
a lie in itself.
>
> John, instead of attacking people when you find out they are faster at
> something, and claiming the benchmark is bogus, how about you try to
> tell the world about what YOU are good at instead?
>
I did not attack you before this posting, but I'll put it to you,
WHY DID YOU ATTACK ME BY IMPLYING THAT I WAS LYING? It is obvious
that you apparently feel threatened by FreeBSD.
>Instead of being so
> damn negative about this all, why don't you try to find the POSITIVE
> stuff? Don't spread FUD and misinformation - try to spread the word
> about the things FreeBSD is better at, ok?
>
Who is calling whom negative? You started the LYING GAME. The
statements about me LYING are obviously incorrect. However my
statements
that you are a jerk are invariant even after you apologize. Since
you were so quick to accuse, you are at fault even if it is true.
Linus, I have been subsequently informed that your normal mode of
operation is to bait an argument. Now I know this and know
how to handle childish pranks like yours.
I am still looking forward to your apology to me.
Thanks in advance,
John
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <4se3gq$7fl@news.swan.ac.uk>#1/1
X-Deja-AN: 168850807
references: <31E7B8A5.41C67EA6@dyson.iquest.net> <4s8rtp$jsh@fido.asd.sgi.com>
<31E805B5.41C67EA6@dyson.iquest.net>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
In article <31E805B5.41C67...@dyson.iquest.net> "John S. Dyson"
<t...@dyson.iquest.net> writes:
>Why was the networking suite re-developed from scratch by the Linux
>team to get (eventually) essentially the same performance? That is
>where the waste really is. (Also Linux could have brought the BSD
>suite under GPL, and encumbered it very nicely also.)
You know that perfectly well. In fact you've repeated that paticular pile
of bullshit repeatedly
1. At the time Linux needed networking the BSD folks were all rather
busy with a little lawsuit with AT&T and BSD code was best assumed
contaminated
2. The GPL and BSD licenses (the traditional one with documentation
and advertising credit) clash
Given the choice I'd have taken the BSD code GPL'd it and un mbuf'd it. It
would have saved me 18 months work and gone about as fast when we'd finished
reconstructing it.
Alan
--
----------------------------------------------////
Yow! 233 microsecond remote host TCP latency ---- beat that
--------------------------------------------////__________ o
Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <4se37p$7en@news.swan.ac.uk>#1/1
X-Deja-AN: 168884237
references: <31E3D9E2.41C67EA6@dyson.iquest.net> <4s5bl2$qpg@linux.cs.Helsinki.FI>
<31E664EB.167EB0E7@inuxs.att.com>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E664EB.167EB...@inuxs.att.com> "John S. Dyson"
<dy...@inuxs.att.com> writes:
>are being fixed? Hmmm... Looks like the NEW IMPROVED Linux TCP suite
>is about the same perf as the BSD code... Luckily, there is movement
>afoot to clean-up the BSD networking code, and I wouldn't be too awful
>suprised if it betters Linux. (Some pieces of it haven't been reworked
>in years.)
About time the BSD folks woke up. Last year several BSD people really took
the piss at the idea of the Linux folks catching up. Well we've passed you
(at least on these benchmarks [save the validity debate ;)]).
>I get about 17-19 MB/sec on localhost also on FreeBSD. The MBUF
>code is not very inefficient in reality. Again, it is hard to
>come to any conclusions given different hardware.
Dump mbufs, go for linear buffers, add copy and checksum passes and your
code will start to look like what everyone else has been doing to the BSD
stack while netbsd and freebsd stayed almost unchanging. It'll also start
to look remarkably like the Linux stack providing you fix the poor
granularity timers as well.
Van Jacobson has been telling people this for years
Alan
--
----------------------------------------------////
Yow! 233 microsecond remote host TCP latency ---- beat that
--------------------------------------------////__________ o
Alan Cox, Alan....@linux.org /_____________/ / /\/ /_/ ><
From: "Amancio Hasty Jr." <ha...@star-gate.com>
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <31EA9FBC.41C67EA6@star-gate.com>#1/1
X-Deja-AN: 168887137
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E7C0DD.41C67EA6@dyson.iquest.net>
<4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net>
<4sadde$qsv@linux.cs.Helsinki.FI>
content-type: text/plain; charset=us-ascii
organization: TLGnet Inc., (formerly The Little Garden)
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Linus Torvalds wrote:
>
> In article <31E80ACA.167EB...@dyson.iquest.net>,
> John S. Dyson <t...@dyson.iquest.net> wrote:
> >Larry McVoy wrote:
> >
> >> It's kind of fun to contrast this with the Linux crowd:
> >>
> >> BSD guys: "your benchmark sucks! your numbers are wrong! you mislead the
> >> world! you suck! whine!"
> >>
> >> Linux guys: "Hey Larry, the null syscall benchmark is busted because we can
> >> do a null syscall in about 1 usec. You need to change it so
> >> it times in nanoseconds".
> >
> >I think that was a kind-of cute situation. We decided NOT
> >to special case the syscall that Larry uses for the
> >null-syscall case.
>
> John, John, John, calm down.
>
> You are suggesting above that YOU did not special case the system call
> that Larry uses in lmbench, and by implication you are claiming Linux
> does. Very subtly done, but
>
> YOU'RE LYING
May I ask in which point do you think that Dyson is lying? 8)
>beat you on system call latency (and I have to admit that I haven't even
>looked at the FreeBSD numbers, so I'm just assuming that from your post
If anyone needs to calm down around here is you, *linus*. Please
don't assume either ask for the numbers or get them yourselves.
P.S.: I can understand that your group has done a lot of work
over the years and recently your OS may be suitable for server
class category -- all I can say is congrats your OS is now
almost as good as FreeBSD -- I am saying almost as good because
until is not proven out in the field with your new networking
code is just a little experiment in your box which we still
don't know its configuration nor its OS version -- very very
subtle, linus 8)
--
Amancio Hasty
Hasty Software Consulting Services
Tel: 415-495-3046
Fax: 415-495-3046
Cellular: 415-309-8434
e-mail: ha...@star-gate.com Powered by FreeBSD
From: "John S. Dyson" <dy...@inuxs.att.com>
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <31EA9F0F.41C67EA6@inuxs.att.com>#1/1
X-Deja-AN: 168860448
references: <31E3D9E2.41C67EA6@dyson.iquest.net> <4s5bl2$qpg@linux.cs.Helsinki.FI>
<31E664EB.167EB0E7@inuxs.att.com> <4se37p$7en@news.swan.ac.uk>
content-type: text/plain; charset=us-ascii
organization: Lucent Technologies, Columbus, Ohio
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 2.0 (X11; I; FreeBSD 2.1-STABLE i386)
Alan Cox wrote:
>
> In article <31E664EB.167EB...@inuxs.att.com> "John S. Dyson"
<dy...@inuxs.att.com> writes:
> >are being fixed? Hmmm... Looks like the NEW IMPROVED Linux TCP suite
> >is about the same perf as the BSD code... Luckily, there is movement
> >afoot to clean-up the BSD networking code, and I wouldn't be too awful
> >suprised if it betters Linux. (Some pieces of it haven't been reworked
> >in years.)
>
> About time the BSD folks woke up. Last year several BSD people really took
> the piss at the idea of the Linux folks catching up. Well we've passed you
> (at least on these benchmarks [save the validity debate ;)]).
>
The validity of the benchmarks (or actually the importance of what
they measure) is critical. There are numbers that we can make better,
but the effort is best spent in areas where the performance difference
matters more often.
>
> >I get about 17-19 MB/sec on localhost also on FreeBSD. The MBUF
> >code is not very inefficient in reality. Again, it is hard to
> >come to any conclusions given different hardware.
>
> Dump mbufs, go for linear buffers, add copy and checksum passes and your
> code will start to look like what everyone else has been doing to the BSD
> stack while netbsd and freebsd stayed almost unchanging. It'll also start
> to look remarkably like the Linux stack providing you fix the poor
> granularity timers as well.
>
The low granularity timers are a flaw (ok, so I have admitted to a
problem in the BSD code), but the performance numbers are not demonstrating
the superiority of the Linux stack in real world applications. I think
that it is time for the people making the superior performance claims
to show the measurments that back up the claims. However, they should also
be willing to have the claims challenged.
You know, I have made very few, if any, performance claims in this thread,
and I have mostly asked for data to back up the claims made by others.
Very little has been forthcoming. The ONLY substantiated claim is that
the no-load latency on the Linux networking is better with a specific
network adapter driver.
John
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/16
Message-ID: <4seo88$fqd@fido.asd.sgi.com>#1/1
X-Deja-AN: 169049513
references: <4paedl$4bm@engnews2.eng.sun.com> <4s7jsd$blf@fido.asd.sgi.com>
<31E7B8A5.41C67EA6@dyson.iquest.net> <4s8rtp$jsh@fido.asd.sgi.com>
<4sej3e$155@dworkin.wustl.edu>
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
Chuck Cranor (ch...@ccrc.wustl.edu) wrote:
: >Is it really worthwhile to have these arguments? Wouldn't it be better
: >if we were all working on the same thing, making one OS the best? Instead
: >of arguing that your variant is better than their variant?
: No, I don't think it would be better if we were all working on the same
: thing. I don't even think it is possible due to logistical, political,
: and philosophical differences. Also, people tend to generally like having
: alternatives to choose from. Why should that be taken away?
If you look at the directions of the computer industry, the Unix market
is shrinking (not in real numbers, in percentage), while the Windows
& Windows/NT market is growing. If you follow that out to its logical
conclusion, at some point in the future, the only "choice" we will have
will be a Microsoft product. In many ways, we're already there.
The Unix world is fond of letting personalities be more important
than survival. That's fine if all you want to do is play around, but
what if you would actually like to be able to use Unix technology to
solve problems? And you need a widely used, supported, understood OS
to do your job? Suppose Unix goes the way of MVS - do you want to be
one of those MVS dinosaurs that are largely irrelevant?
My premise throughout all of this has been that the smart minds need to
work together to make a good OS. For whatever reason, the BSD crowds
can't seem to handle more than a handful of smart people working on
their version of their Unix. That means that BSD Unix will always be a
political thing, a playground for nerds, but never a widely used platform.
I'd like to think that in 10 years, Unix will still be an interesting
platform for technical computing. How is BSD going to help that be true?
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: ch...@ccrc.wustl.edu (Chuck Cranor)
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <4sesh4$2ls@dworkin.wustl.edu>#1/1
X-Deja-AN: 169055176
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
<4sej3e$155@dworkin.wustl.edu> <4seo88$fqd@fido.asd.sgi.com>
organization: Washington University, St. Louis MO.
followup-to: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
In article <4seo88$...@fido.asd.sgi.com>,
Larry McVoy <l...@slovax.engr.sgi.com> wrote:
>If you look at the directions of the computer industry, the Unix market
>is shrinking (not in real numbers, in percentage), while the Windows
>& Windows/NT market is growing. If you follow that out to its logical
>conclusion, at some point in the future, the only "choice" we will have
>will be a Microsoft product. In many ways, we're already there.
Ok, seems like a valid concern. But why do you think the Windows/NT
market is growing and over-shadowing the Unix market?
I believe this is happening because Windows & Windows/NT have a better
user interface and superior applications for the "average" user (when
compared to Unix). In this context, I believe the problem with Unix
is not the kernel (or its performance), so I don't see how working in
that area is going to address the problem?
I think that Unix without powerful applications and a uniform user
interface will not be able to make any headway vs. Windows/Windows-NT,
regardless of how fancy the Unix/BSD/Linux kernel is. In the meantime
Microsoft, given its resources, can simply absorb the good ideas from
Unix/BSD/Linux into NT's kernel at its leisure [and the GPL offers no
protection from that].
Of course, I also think that Windows has way too much inertia for
a fixed up unix-like OS to dislodge anyway. Most people don't
care what OS they run, as long as the applications run ("go with what
you know"). [sorry to be gloomy...]
chuck
--
>>Chuck Cranor, Graduate Student, Computer and Communications Research Center<<
>>Washington University, St. Louis MO http://www.ccrc.wustl.edu/pub/chuck <<
... help! my wife has accepted a job with at&t research in new jersey and
now i've got to find a job in new jersey too ...
From: "Amancio Hasty Jr." <ha...@star-gate.com>
Subject: Re: TCP latency
Date: 1996/07/18
Message-ID: <31EE28D3.41C67EA6@star-gate.com>#1/1
X-Deja-AN: 169454271
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
<4sej3e$155@dworkin.wustl.edu> <4seo88$fqd@fido.asd.sgi.com>
<4sesh4$2ls@dworkin.wustl.edu>
content-type: text/plain; charset=us-ascii
organization: TLGnet Inc., (formerly The Little Garden)
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; U; FreeBSD 2.2-CURRENT i386)
Chuck Cranor wrote:
>
> Unix/BSD/Linux into NT's kernel at its leisure [and the GPL offers no
> protection from that].
>
> Of course, I also think that Windows has way too much inertia for
> a fixed up unix-like OS to dislodge anyway. Most people don't
> care what OS they run, as long as the applications run ("go with what
> you know"). [sorry to be gloomy...]
>
Hi,
Well the weather now days is changing and it looks like Netscape may
be able to level the playing field. Another area that Unix at least
on the PC area could possibly have a significant impact is if there
was a good emulation layer to run Windows 95. You see people have
invested time and money into the existing Windows based apps and
they are not liable to switch to an OS just on the merits of its
performance. You shall the faces of people who know Unix and Windows
when I ask them if they can run your Win95 apps on FreeBSD would
you consider FreeBSD? The answer : Heck Yeah!
Amancio
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/15
Message-ID: <4sefde$f0l@fido.asd.sgi.com>#1/1
X-Deja-AN: 169074679
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E7C0DD.41C67EA6@dyson.iquest.net>
<4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net>
<4sadde$qsv@linux.cs.Helsinki.FI> <31E9E3A7.41C67EA6@dyson.iquest.net>
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
John S. Dyson (t...@dyson.iquest.net) wrote:
: We could have special cased it to make the benchmark look better, but
: we did not. We have looked at it carefully, and it has little impact
: on real-world performance. Historically, a NULL syscall is not
: a write to /dev/null... That is what the benchmark is, and simply
: it is NOT IMPORTANT.
Umm, I'd be happy to entertain suggestions for a better measurement of
a null entry into the system. I don't want something that anyone special
cases - that's just worthless. I want something that is actually measuring
all the work you need to do to get to the point that you can do something in
the kernel.
People typically use getpid() for this, but that is a bummer because of
. it is a read only call, you could actualy cache the pid is user
space and not go into the kernel at all.
. it is very high level, you haven't broken into either the FS
layer or the networking layer.
Maybe gettimeofday() would have been a better null syscall, what do you think?
: > YOU'RE LYING
: >
: Look, jerk, you are continuing your
: stupid, infantile attack on me and FreeBSD. I really don't care about
: what you think. Secondly yours is the only response that made this
: allegation like you have. YOU ARE ALONE...
Well, I doubt you'll buy it, but I agree with Linus that your message
certainly implied that Linux special cased the null syscal metric used
in lmbench. IF that was your intended implication, you may not have been
lying, but you certainly were implying something that simply isn't true.
ALL of Linux' syscalls are typically less cost than the typical Unix
counterparts. Linus did a nice job with that, you might want to go
look at it.
: Linus, you are an arrogant, self-righteous a**hole...
Umm, when it gets to this level, maybe it is better to give yourself a
day or two before you hit that send button. Do you really want to
make public statements like this? Seems a little extreme to me.
: I DEMAND A PUBLIC RETRACTION. ADDITIONALLY, I DEMAND A FORMAL
: WRITTEN APOLOGY or PROOF OF A FORGED USENET POSTING. If you don't
: it will be a further demonstration of your ill-will, condescending
: behavior, or mean spiritedness.
Sheesh.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/07/16
Message-ID: <4sfjm8$a04@news.swan.ac.uk>#1/1
X-Deja-AN: 168481692
references: <31E6B8AB.3E6C@indy.celebration.net> <4s7j2r$blf@fido.asd.sgi.com>
<31E7BD6F.167EB0E7@dyson.iquest.net>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E7BD6F.167EB...@dyson.iquest.net> "John S. Dyson"
<t...@dyson.iquest.net> writes:
>emotional in the support of Linux. Yes, Linus should be happy that
>Linux APPEARS to be catching up in certain areas. That is ALL that can be
>concluded at this point.
Appears to be catching up. Is that the closest Mr Dyson can get to
admitting he might be losing on something.
> Yep, Linus got up to three(3) connections :-). Psst, try 1000-3000
>connections with different IP/PORT addresses, then it all starts getting
>very very interesting :-).
That is one I'd like to try, and I'd be interested in the figures for both
on the same hardware for each node you are testing against. (DONT do a dumb
two host many connection test its got no value as the packet patterns will not
resemble real traffic and you won't be accurately assessing issues like
L2 cache footprint of arp table lookups. You need to model a real network
with say 300-500 hosts off mixed subnets and on mixed traffic timers to
generate useful stats for say WWW network performance.
>competency in benchmarking. I'll bet you that there are qualities about
>me that blow YOU AND LINUS away, but that does not make me better in the
Apparent ego size ;)
>areas that I am not expert. Additionally, have you been open about
>the attempted recruitment of me onto Linux? (Y'know the VM system needs
>work?)
Well the last time I looked the VM works rather nicely now, it certainly
seems to work rather well (unlike 1.2). It also passes the portability test
in running on machines with 32 and 64bit architectures, as well as both
physical and various virtual caches, while I'm dubious the FreeBSD vm subsystem
will actually run well on a 64bit architecture - perhaps the NetBSD folk can
answer why they use the Mach VM layer not yours ?
Alan
--
Send unsolicited junk mail to this address and maybe win the chance to have
yourself added free to several hundred random mailing lists. ,---------------
------------------------------------------------------------/ Alan Cox
This signature comes with a free redistribution license / a...@cymru.net
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/07/16
Message-ID: <4sfkd3$a11@news.swan.ac.uk>#1/1
X-Deja-AN: 168487947
references: <31E7C0DD.41C67EA6@dyson.iquest.net> <4s8tcn$jsh@fido.asd.sgi.com>
<31E80ACA.167EB0E7@dyson.iquest.net>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E80ACA.167EB...@dyson.iquest.net> "John S. Dyson"
<t...@dyson.iquest.net> writes:
>I think that was a kind-of cute situation. We decided NOT
>to special case the syscall that Larry uses for the
>null-syscall case.
Nor does Linux. Its just fast at syscalls. Reminds me Linus, it looks like
there are about 3 clocks you can save on syscall entry by changing the
handling of a syscall slot containing zero.
In terms of the benchmark however Larry ought to use getppid() which cannot
be cached (you may get inherited by init). You could conceivably mmap the
page containing ppid info into the program but thats just grotesque ;)
Also a couple of people have been muttering things about code layout and
TLB misses. On a pentium the Linux kernel except when accessing user space
and on kernel entry doesnt take TLB misses. Cache footprints however are a
big issue (for example the Linux lat_tcp throughput figures double on some
machines if you do ifconfig lo mtu 1500 - as far as I can tell because it
then all fits nicely in L1 cache). PC's are horrible varied pieces of
equipment and I've seen motherboards with the same chipset and a factor
of two memory performance difference, so as various people have said - all
benchmarks have to be done on the same kit.
Alan
--
Send unsolicited junk mail to this address and maybe win the chance to have
yourself added free to several hundred random mailing lists. ,---------------
------------------------------------------------------------/ Alan Cox
This signature comes with a free redistribution license / a...@cymru.net
From: d...@engr.sgi.com (David S. Miller)
Subject: Re: TCP latency
Date: 1996/07/16
Message-ID: <4sg33d$pu8@fido.asd.sgi.com>#1/1
X-Deja-AN: 169167350
references: <31EA0618.41C67EA6@dyson.iquest.net> <4paedl$4bm@engnews2.Eng.Sun.COM>
<31E7C0DD.41C67EA6@dyson.iquest.net> <4s8tcn$jsh@fido.asd.sgi.com>
<31E80ACA.167EB0E7@dyson.iquest.net> <4sadde$qsv@linux.cs.Helsinki.FI>
<480785912wnr@tactical.co.uk>
organization: Silicon Graphics Inc., Mountain View, CA
newsgroups: comp.os.linux.networking
I think the most outstanding thing about all of this, is that not only
does Linux kick butt against the *BSD variants on the PC, we also kick
butt on other _real_ architectures. I personally have Linux taking SunOS,
Solaris, and now IRIX under the table for a few drinks on the same exact
hardware. So how are those Sparc, MIPS, PowerPC, Alpha ports of FreeBSD
coming along? I very much doubt FreeBSD could retain it's quality and
speed with 4 or 5 ports to consider all the time. It must be a thrill to
be able to optimize and not worry about the PC-centricness of ones code.
Point number two, compare how old the two code bases are, and how much
real defense department funding went into the BSD code whereas Linus did
it all on his own time and initiative along with the various contributors
on the net.
At least I know where BSD is going to be two years from now.
--
----------------------------------------------////
Yow! 233 microsecond remote host TCP latency ---- beat that
--------------------------------------------////__________ o
David S. Miller, d...@engr.sgi.com /_____________/ / /\/ /_/ ><
From: torva...@linux.cs.Helsinki.FI (Linus Torvalds)
Subject: Re: TCP latency
Date: 1996/07/16
Message-ID: <4sgo4l$ucf@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 169236842
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E80ACA.167EB0E7@dyson.iquest.net>
<4sadde$qsv@linux.cs.Helsinki.FI> <31EA9FBC.41C67EA6@star-gate.com>
content-type: text/plain; charset=ISO-8859-1
organization: A Red Hat Commercial Linux Site
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
[ This has no technical issues left. Don't bother following up: reply to
this by email if you must, as I will try to leave this thread - it's not
worth continuing ]
In article <31EA9FBC.41C67...@star-gate.com>,
Amancio Hasty Jr. <ha...@star-gate.com> wrote:
>
>May I ask in which point do you think that Dyson is lying? 8)
I assume the above question was rhetorical and meant to be a joke. In
case you really _are_ serious about the question, Johns posting
certainly seemed to imply that Linux is special-casing something for
better numbers on lmbench, and that (rather strongly, IMHO) implied
claim was what I reacted to. I seem not to be the only one who saw that
implication, so I'm not overly worried about being paranoid here.
John has later stated that he did not mean to imply anything such at
all, and as such I can only say that there seems to have just been a
misunderstanding. Sadly John stated a lot of other things in that
"corrective" posting too. I'm sure you can find that posting yourself
and make your own judgement on the matter. I'm not really intersted in
hearing about it, though.
>>beat you on system call latency (and I have to admit that I haven't even
>>looked at the FreeBSD numbers, so I'm just assuming that from your post
>
>If anyone needs to calm down around here is you, *linus*. Please
>don't assume either ask for the numbers or get them yourselves.
Oh, my assumptions are generally pretty safe assumptions. In the
specific case of the system call latency numbers, I'm pretty confident
that Linux is faster than just about anybody else. If you find numbers
to the opposite, I'd be interested in seeing them.
As you can see from other numbers posted to the thread, Linux is about
3-4 times faster than FreeBSD on that particular test, so my assumption
certainly wasn't uncalled for. And FreeBSD isn't doing especially badly
on that benchmark, Linux just happens to excel at it..
Now, the factor of 3-4 doesn't necessarily tell the whole story, and it
has been claimed that some of the overhead of FreeBSD is the VFS
overhead. Linux just seems to handle that same overhead a lot better,
and WITHOUT needing to special case anything at all.
>until is not proven out in the field with your new networking
>code is just a little experiment in your box which we still
>don't know its configuration nor its OS version -- very very
>subtle, linus 8)
Umm. You haven't followed this discussion at all, have you, Amancio?
Go back and read a few more posts. You'll find that most of the numbers
shown haven't been posted by me at all, and you'll also find that we're
talking about a stable release, not some "little experiment in my box".
We're not even talking Linux-Current in FreeBSD terms, we're talking
Linux-Stable, for chrissake! Do you talk about XFree86-3.1.2 as your
"little experiment"?
Why is it you have to resort to insinuations like the above?
Linus
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/16
Message-ID: <31EBAADC.41C67EA6@dyson.iquest.net>
X-Deja-AN: 169438566
references: <31E6B8AB.3E6C@indy.celebration.net> <4s7j2r$blf@fido.asd.sgi.com>
<31E7BD6F.167EB0E7@dyson.iquest.net> <4sfjm8$a04@news.swan.ac.uk>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5aGold (X11; I; FreeBSD 2.2-CURRENT i386)
Alan Cox wrote:
>
> In article <31E7BD6F.167EB...@dyson.iquest.net> "John S. Dyson"
<t...@dyson.iquest.net> writes:
> >emotional in the support of Linux. Yes, Linus should be happy that
> >Linux APPEARS to be catching up in certain areas. That is ALL that can be
> >concluded at this point.
>
> Appears to be catching up. Is that the closest Mr Dyson can get to
> admitting he might be losing on something.
>
This is the attitude that I find extremely distateful. Sorry, but
I am not seeing that anyone is loosing here. I have been asking
for integrity assocated with claims. If you think that my demanding
benchmark results to back up claims is an indication of bad
sportmanship, it is my position that unfounded claims are such
an indicator.
Bottom line, people like you are the ones taking my skepticism
personally :-(.
> > Yep, Linus got up to three(3) connections :-). Psst, try 1000-3000
> >connections with different IP/PORT addresses, then it all starts getting
> >very very interesting :-).
>
> That is one I'd like to try, and I'd be interested in the figures for both
> on the same hardware for each node you are testing against. (DONT do a dumb
> two host many connection test its got no value as the packet patterns will not
> resemble real traffic and you won't be accurately assessing issues like
> L2 cache footprint of arp table lookups. You need to model a real network
> with say 300-500 hosts off mixed subnets and on mixed traffic timers to
> generate useful stats for say WWW network performance.
>
We found in our real world tests, that "interesting suprises" have
appeared.
Too bad we don't have the ability to test Linux, I was kind of hoping
that the Linux developers would, and I am still looking for results...
>
> >competency in benchmarking. I'll bet you that there are qualities about
> >me that blow YOU AND LINUS away, but that does not make me better in the
>
> Apparent ego size ;)
>
Yep, I don't claim to be expert in everything, like some do. You also
do not know me, and I dare say that you would be impressed with how
unassuming I am. I claim that my ego is probably even less important
to me that yours is to you. It is your ego that is feeling threatened
by the technical superiority of FreeBSD :-). Are you in catch-up mode
still?
> >areas that I am not expert. Additionally, have you been open about
> >the attempted recruitment of me onto Linux? (Y'know the VM system needs
> >work?)
>
> Well the last time I looked the VM works rather nicely now, it certainly
> seems to work rather well (unlike 1.2). It also passes the portability test
> in running on machines with 32 and 64bit architectures, as well as both
> physical and various virtual caches, while I'm dubious the FreeBSD vm subsystem
> will actually run well on a 64bit architecture - perhaps the NetBSD folk can
> answer why they use the Mach VM layer not yours ?
>
We haven't ported it yet. Our VM system works with >32bit objects on
a 32bit arch (we had to do that to support large files.) The question
is how well do the VM systems do on architectures that they have been
ported to. I dare say that there are slow 64Bit VM systems :-). Most
all VM systems work well under light loading conditions, my goal was
not to make the VM code "a fair weather friend." The algorithms are
scalable to both 64Bits (which again, much of the code is already
64Bit in FreeBSD), and to machines without Modify/Reference bits.
I feel that it is a better investment to work on the X86 right now,
simply put. Also, we already incur significant 64Bit overhead
in our code. The only thing that is needed is the pmap layer
for a given machine, and two or three strategically placed ifdefs.
If you are interested, I can produce patches to turn off the M/R
bits on X86 and minor changes to the upper level system to
check it out. I would do so ONLY if you are really interested,
which I doubt.
By what expertise can you say that you are dubious about it, have
you studied it, or even benchmarked it (carefully) with loading
benchmarks? Do you have any valid complaints about the FreeBSD
VM system or any claims about the VM system made herein? Additionally,
I did not even bring up the FreeBSD system -- Larry brought up
Linux's VM system -- your questions are bait, not germaine and
frankly sound like sour grapes.
John
From: "Jordan K. Hubbard" <j...@FreeBSD.org>
Subject: Getting off the stick [was Re: TCP latency]
Date: 1996/07/17
Message-ID: <31EDBDA2.41C67EA6@FreeBSD.org>
X-Deja-AN: 169419480
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
<4sej3e$155@dworkin.wustl.edu> <4seo88$fqd@fido.asd.sgi.com>
<4sesh4$2ls@dworkin.wustl.edu>
to: Chuck Cranor <ch...@ccrc.wustl.edu>
content-type: text/plain; charset=us-ascii
organization: Walnut Creek CDROM
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Chuck Cranor wrote:
> I believe this is happening because Windows & Windows/NT have a better
> user interface and superior applications for the "average" user (when
> compared to Unix). In this context, I believe the problem with Unix
> is not the kernel (or its performance), so I don't see how working in
> that area is going to address the problem?
[I'll leave the cross-posting stand since we're talking applications
turf now and I suppose that's of equal interest to both groups]
Chuck has hit the nail precisely on the head, and I'd like to go one
step further with this:
If UN*X were to do its job properly over the next couple of years
(unlikely, but if) I think it would be increasingly irrelevant just
which variant you chose because the operating system would be little
more than a fairly invisible bit of enabling technology that 99% of its
user base didn't even care about anyway. To grab an analogy out of the
air (and maybe it's a little weak, but cut me some slack for a
spur-of-the-moment metaphor :-) It'd be like the hull of a ship. Most
passengers on a luxury liner don't take trips down to the bilges in
order to rap on the hull and marvel at the rivets, they're far more
interested in the swimming pool, the shuffleboard court and the various
other attractions topside. As long as the hull manages to keep itself
in one piece, they don't even think about it nor does the cruise line go
out of its way to emphasise it in any way (quite the opposite, in fact,
ship construction being rather boring to all but those few who are
genuinely interested in maritime engineering).
So it is with UNIX, except instead of brass bands and groaning buffet
tables laden with food, we've got everybody sitting on some boards
thrown hastily across the bottom of the boat and sea biscuit rations
served from a box. Before each passenger boards, they're given a 500
page instruction guide on ship repair and rescue procedures and told to
learn it or risk going down with the ship (which has a tendency to
occasionally turn turtle and sink if not handled very carefully).
And then we wonder why people aren't exactly rushing to clamber aboard
the S.S. UNIX anymore, prefering instead, for some strange reason, the
Queen Elizabeth II.
Yes, I know that Linux is growing a larger suite of apps, and I've been
watching with interest each and every player who's scrambled aboard the
Linux commercial software bandwagon with their 3rd-string spreadsheet
application or aging desktop manager in hopes of making a modest buck,
but frankly it's not even a drop in the bucket. I know one has to start
somewhere, and if I didn't hold out some hope of getting enough apps
together to hold a reasonable niche for the moment I wouldn't even be
watching (*BSD runs Linux apps too, so their "victories" are ours too),
but competetive? We're not even close, 1 million Linux users or not.
OS/2 had easily 3-4 times that many people and the financial backing of
one of the biggest computer companies on this planet, now look at it.
Pride goeth before the fall. Face it - porting software to new
platforms is hard, and most companies won't even bother unless they're
guaranteed a potential customer base far greater than Linux or *BSD
could muster combined.
Don't kid yourselves. Linux and *BSD may give us propeller-heads wet
dreams, but in the bigger scheme of things we're not even a blip, nor do
I see any long-term strategies forming which have any truly reasonable
hope of changing this (and endless "gee, wouldn't this be great!" plans
hatched by students over coffee is a very poor substitute).
While it's also certainly true that we're still growing at the moment
since all this free UN*X stuff is fun and nifty right now and the gloss
is still on, what about in 5 years? If this is all going to be down the
drain by then, why are we even wasting our time now? Yes, I do this
primarily for fun right now too, but I expect that to get old in a
couple of more years if I don't see some greater goals coming out of all
this.
Chuck is 100% correct when he says that this war won't be won in the
kernel, and after a certain point I think that both systems will be
stable and robust enough that we'll be down to diminishing returns in
hacking on any of the standard areas. Then where do we go? Try and get
that TCP interrupt latency down from 200uSec to 190? Jesus, what's the
point? The users certainly don't give a damn by that stage since
tapping on the hull is only fun for so long before you start wondering
when the music and dancing is going to start.
For us to hold our own against Microsoft, much less gain any ground, we
need to stop focusing on the classic desktop applications that Microsoft
has already won for itself and start thinkng more about server
applications which somehow capitalize off of UNIX's unique strengths
(probably in cooperation with the system builders to give that
additional edge). Features like transparent clustering, where to
increase your aggregate horsepower you simply drop another PC or
SPARCstation or whatever into your computational cluster and it rolls
into the pool like one blob of mercury joining another. Projects which
allow us to finally throw NFS out on its ear and replace it with a file
sharing protocol which is safe (e.g. actually has industrial strength
locking) and fast. More advanced frameworks which allow us to get away
from the concepts of hosts and client/server relationships and more into
the area of "services" where you don't even need to think about where
something comes from, you just ask for it and the first available
"resource server" with the information you need picks it up or tells you
who to ask in turn. The kind of management tools we need to make
administration of the system something that anyone who could drive NT
(or hell, even simpler) could do.
I could go on, but I'd probably just depress myself at thinking how
little paradigm shifting we've done over the last 10 years and some of
the utterly moronic solutions (like Motif) we've come up with instead.
If there's a cheerful side to any of this, it's that none of the things
I've discussed really require that the user have to choose any one OS
over the other. All of the things I mentioned could and should be
implemented up in user space, and with proper abstraction you could
easily run your advanced clustering protocols on fully heterogeneous
networks. This, in turn, has the interesting side-effect of turning
adversity into a strength. There are multiple operating systems?
Good! So you're not locked into one vendor. HP, Sun, SGI all rolling
their own versions of UNIX? Who cares? Just so long as all this whizzy
software ports easily to them (and you'd make sure that it did), it's of
absolutely no concern to you whether it's called Foozix or Lignox, just
so the upper interface layers your own application depends on are
implemented. You pick whatever hardware gives you the best bang for
buck that week and the rest takes care of itself.
I do realize that this is a highly idealized vision, I'm simply trying
to underscore the point that the real fight isn't in the OS arena at
all, it's what sits on top. So far, sadly, not many people have chosen
to look up there since it's far easier to worry about minescule
differences in your fork() timing than it is to design and implement
clustering protocols or write free CORBA implementations.
If the various OS camps don't wake up to this soon, THAT is what is
going to kill them, not the Linus vs *BSD fights or the fighting between
the *BSD camps themselves - that's merely arguing about a stubbed toe
while an 18 wheeler is bearing down on you from behind. Focus on the
*serious* deficiencies, please!
--
- Jordan Hubbard
President, FreeBSD Project
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/07/18
Message-ID: <4sl20h$jf1@news.swan.ac.uk>#1/1
X-Deja-AN: 168684612
references: <31E80ACA.167EB0E7@dyson.iquest.net> <4sadde$qsv@linux.cs.Helsinki.FI>
<31E9E3A7.41C67EA6@dyson.iquest.net>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31E9E3A7.41C67...@dyson.iquest.net> "John S. Dyson"
<t...@dyson.iquest.net> writes:
>I DEMAND A PUBLIC RETRACTION. ADDITIONALLY, I DEMAND A FORMAL
>WRITTEN APOLOGY or PROOF OF A FORGED USENET POSTING. If you don't
>it will be a further demonstration of your ill-will, condescending
>behavior, or mean spiritedness.
Bickering to email please, facts and figures to usenet [thats aimed at
everyone who wants to write nasty things in capital letters at each other]
--
Send unsolicited junk mail to this address and maybe win the chance to have
yourself added free to several hundred random mailing lists. ,---------------
------------------------------------------------------------/ Alan Cox
This signature comes with a free redistribution license / a...@cymru.net
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: TCP latency
Date: 1996/07/18
Message-ID: <4sl24c$jf3@news.swan.ac.uk>#1/1
X-Deja-AN: 169454157
references: <31E80ACA.167EB0E7@dyson.iquest.net> <4sadde$qsv@linux.cs.Helsinki.FI>
<31EA9FBC.41C67EA6@star-gate.com>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <31EA9FBC.41C67...@star-gate.com> "Amancio Hasty Jr."
<ha...@star-gate.com> writes:
>almost as good as FreeBSD -- I am saying almost as good because
>until is not proven out in the field with your new networking
>code is just a little experiment in your box which we still
>don't know its configuration nor its OS version -- very very
>subtle, linus 8)
Excuse me a moment, but can you and John agree on an opinion. You are saying
this benchmark matters yet John is saying it's irrelevant ;)
Alan
--
Send unsolicited junk mail to this address and maybe win the chance to have
yourself added free to several hundred random mailing lists. ,---------------
------------------------------------------------------------/ Alan Cox
This signature comes with a free redistribution license / a...@cymru.net
From: "John S. Dyson" <t...@dyson.iquest.net>
Subject: Re: TCP latency
Date: 1996/07/18
Message-ID: <31EE5BAC.41C67EA6@dyson.iquest.net>#1/1
X-Deja-AN: 169609654
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E80ACA.167EB0E7@dyson.iquest.net>
<4sadde$qsv@linux.cs.Helsinki.FI> <31EA9FBC.41C67EA6@star-gate.com>
<4sgo4l$ucf@linux.cs.Helsinki.FI>
content-type: text/plain; charset=us-ascii
organization: John S. Dyson's home machine
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5aGold (X11; I; FreeBSD 2.2-CURRENT i386)
Linus Torvalds wrote:
>
> [ This has no technical issues left. Don't bother following up: reply to
> this by email if you must, as I will try to leave this thread - it's not
> worth continuing ]
>
> In article <31EA9FBC.41C67...@star-gate.com>,
> Amancio Hasty Jr. <ha...@star-gate.com> wrote:
> >
> >May I ask in which point do you think that Dyson is lying? 8)
>
> I assume the above question was rhetorical and meant to be a joke. In
> case you really _are_ serious about the question, Johns posting
> certainly seemed to imply that Linux is special-casing something for
> better numbers on lmbench, and that (rather strongly, IMHO) implied
> claim was what I reacted to. I seem not to be the only one who saw that
> implication, so I'm not overly worried about being paranoid here.
>
Well, it is an absurd interpretation that I would make an implication
that could be refuted by 100's if not 1000's of people who are
looking at the source code. Sorry, but I did not imply it, and
it is incorrect to use the term Lie, Linus.
>
> As you can see from other numbers posted to the thread, Linux is about
> 3-4 times faster than FreeBSD on that particular test, so my assumption
> certainly wasn't uncalled for. And FreeBSD isn't doing especially badly
> on that benchmark, Linux just happens to excel at it..
>
Actually, Linus, as I have said, I am not concerned about it
right now, until it impacts significantly, real use of the system.
When it does, we'll make the changes in that part of the system to make
it
faster. There are so many things to do that impact performance,
I tend to believe that working on this right now would not
be the best thing to do.
>
> Linux just seems to handle that same overhead a lot better,
> and WITHOUT needing to special case anything at all.
>
Never argued that Linux didn't handle that benchmark well. The
benchmarks of course, are not in themselves a very accurate
measure of quality. That is why I am not really worried about
it.
I feel bad that you chose to condemn me for what you thought
was undue criticism. I have been continually looking for some
information that backs up claims that you have made (on
other threads.) I am willing to post or mail them to you
for clarification. (If anyone else would like a copy of the
claim ,just ask.) I have had no other agendas :-(.
John
From: ch...@ccrc.wustl.edu (Chuck Cranor)
Subject: Re: TCP latency
Date: 1996/07/19
Message-ID: <4socfr$3ot@dworkin.wustl.edu>#1/1
X-Deja-AN: 168876611
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4sadde$qsv@linux.cs.Helsinki.FI>
<31E9E3A7.41C67EA6@dyson.iquest.net> <4sefde$f0l@fido.asd.sgi.com>
organization: Washington University, St. Louis MO
followup-to: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
In article <4sefde$...@fido.asd.sgi.com>,
Larry McVoy <l...@slovax.engr.sgi.com> wrote:
>Umm, I'd be happy to entertain suggestions for a better measurement of
>a null entry into the system. I don't want something that anyone special
>cases - that's just worthless. I want something that is actually measuring
>all the work you need to do to get to the point that you can do something in
>the kernel.
I took Larry's lat_syscall.c and a few of J Wunsch's suggestion for
different system calls to try and ran a few tests. Here are the results:
[note: sparc 2 is running SunOS 4.1.3_U1 (48MB RAM), P5-133MHz is running
NetBSD/i386 (32MB RAM) ... both systems unloaded. all numbers are
microseconds]
program description Sparc2 P5-133MHz
lat_syscall write 1 to /dev/null 61 6
lat_gettime gettimeofday(&tv,0) 27 5
lat_kill kill(1,0) 23 2
lat_umask umask(0) 19 2
lat_getppid getppid() 17 1
Given that data, it seems like lat_syscall's writing 1 byte to /dev/null
is indeed a poor measurement of "Null syscall." This leaves me with
two questions:
1. Larry, when you were designing lat_syscall, did you see numbers like
the above? If not, then I would consider that a mistake. If so,
then why did you stick with "write 1 to /dev/null" as a measurement
of "Null syscall" (which I also consider a mistake)?
2. How much of the difference between FreeBSD lat_syscall and Linux
lat_syscall can be attributed to VFS overhead in FreeBSD? Or
more generally, how does the overhead and functionality of Linux's
VFS layer compare with FreeBSD's VFS layer?
chuck
--
>>Chuck Cranor, Graduate Student, Computer and Communications Research Center<<
>>Washington University, St. Louis MO http://www.ccrc.wustl.edu/pub/chuck <<
... help! my wife has accepted a job with at&t research in new jersey and
now i've got to find a job in new jersey too ...
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Getting off the stick [was Re: TCP latency]
Date: 1996/07/19
Message-ID: <4so8dq$p0l@news.swan.ac.uk>#1/1
X-Deja-AN: 168876741
references: <4seo88$fqd@fido.asd.sgi.com> <4sesh4$2ls@dworkin.wustl.edu>
<31EDBDA2.41C67EA6@FreeBSD.org>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
In article <31EDBDA2.41C67...@FreeBSD.org> "Jordan K. Hubbard"
<j...@FreeBSD.org> writes:
>watching with interest each and every player who's scrambled aboard the
>Linux commercial software bandwagon with their 3rd-string spreadsheet
>application or aging desktop manager in hopes of making a modest buck,
You'll offend a lot of people with those claims. People like Empress and
Applix are not third string, and their bankbalance says that. Nor are
WordPerfect corp...
>watching (*BSD runs Linux apps too, so their "victories" are ours too),
Not always. Most commercial applications are licensed for Linux specifically
so you are probably violating the license (do encourage people doing this to
be more reasonable about it if they can - Caldera can't for WordPerfect alas)
>but competetive? We're not even close, 1 million Linux users or not.
Surveys suggest we are well past that although its hard to get good figures
because of the nature of Linux. People like X/Open have been reckoning Linux
is over a million seats.
>Pride goeth before the fall. Face it - porting software to new
>platforms is hard, and most companies won't even bother unless they're
>guaranteed a potential customer base far greater than Linux or *BSD
>could muster combined.
Very very debatable argument. Companies will port a product when
cost < direct profit + indirect advantages
people who dont work to those kind of equations don't tend to be big. A
guy from S.A.S. summed it nicely - "Show us $1,000,000" of orders and we'll
port it to anything.
The Linux commercial software list is growing quite fast. I don't know how
well the BSD one is doing. Also Linux is picking up big commercial interests
from people with a lot of money (Apple, OSF, SGI, Digital)
That means you must make porting easier - POSIX compliance, strictly compliant
C compilers and libraries etc.
>hacking on any of the standard areas. Then where do we go? Try and get
>that TCP interrupt latency down from 200uSec to 190? Jesus, what's the
>point? The users certainly don't give a damn by that stage since
People doing things for fun they enjoy. Not every Linux and BSD hacker is
on a personal crusade against Big Bad Billy. Nor should anyone make it a
requirement. Working well with the old world is a key Linux focus (eg
the ability to work with netware, share files as a client of NT or Windows)
>For us to hold our own against Microsoft, much less gain any ground, we
>need to stop focusing on the classic desktop applications that Microsoft
>has already won for itself and start thinkng more about server
No. You don't win wars by running away. You don't sell many servers without
desktops[1]. You go straight back at them. You run their applications (eg WINE,
Executor, DOSemu) and you provide a faster cheaper and more stable platform.
[1] Just ask SCO..
Servers are a legitimate target platform too. You provide the full solution
or you lose market share badly.
Alan
--
Send unsolicited junk mail to this address and maybe win the chance to have
yourself added free to several hundred random mailing lists. ,---------------
------------------------------------------------------------/ Alan Cox
This signature comes with a free redistribution license / a...@cymru.net
From: lar...@saturn.sdsu.edu (Larry Riedel)
Subject: Re: Getting off the stick [was Re: TCP latency]
Date: 1996/07/19
Message-ID: <4sp5j4$3lg@hole.sdsu.edu>
X-Deja-AN: 168924374
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
<4sej3e$155@dworkin.wustl.edu> <4seo88$fqd@fido.asd.sgi.com>
<4sesh4$2ls@dworkin.wustl.edu> <31EDBDA2.41C67EA6@FreeBSD.org>
organization: San Diego State University
followup-to: comp.unix.bsd.freebsd.misc
newsgroups: comp.unix.bsd.freebsd.misc
The paradigm shift I would like to see is that it should be the goal
of developers of free software to create software which has real
value to them, and there is no reason to think this value can be
directly or immediately measured or recognized by anyone other
than the <1% of computer users who are technically astute.
I have been in the software industry for about fifteen years, and
most of what I thought had real value eventually became largely
successful - things I take so much for granted now like SMTP and
NFS and TCP/IP, C and C++, FTP, the GNU tools like GCC, emacs,
and bash, DNS, BSD Unix extensions; (mostly) open architectures
like SCSI, ISA, PCI, etc. Maybe these things were not the best
solutions, but they worked, and once we had them, we could use
them to move forward until we have something better.
There are so many things that I worried were going to go away because
companies like Micro$oft and Novell and IBM and DEC supposedly had so
much money and influence. But it seems to me that the stuff I thought
had the most value wound up succeeding more so than the inferior stuff
those companies were pushing. If I look back ten years and think about
what the big companies who had the almighty "market share" would have
be the way things are now, and I look at the way things really are now,
it is pretty obvious to me it was not they who technologically brought
us here - it was the people who provided real value by coming up with
solutions to the obvious challenges they wanted to overcome, not by
trying to make money off the mass market.
The people with whom I am familiar who have been responsible for creating
the real value I am talking about never intended to have their success
measured in dollars, or the number of novice users of their software,
or the opinions of the hoi polloi, but instead by whether or not they
and their peers believed they had created real value.
If no spreadsheet, word processor, personal information Manager, CAD
system, MIDI sequencer, animation or desktop publishing package ever
is written for FreeBSD, I think that should be fine . Is that really
what people on the leading edge of software development want to spend
their time writing? I don't think so. If 99% of the computer users
in the world think FreeBSD is far too complex to install and use then
I think that should be fine. Those people are not the ones creating
the value in the software industry. Why can't FreeBSD just be the OS
for the people creating the value, instead of everything for everyone?
I used to feel good about the BSD community because the people in it
seemed to be less interested in whether or not the number of people
who used their software was more than some other OS, and relatively
oblivious to whether or not the uninitiated could easily install,
configure, and use the software - if was easy enough for the developers,
that was what mattered, because what the developers created had value
and if the uninitated wanted access to that value, they would make the
effort to figure out how to get at it - it was never very difficult
To me the measure of success for FreeBSD should not be whether or
not it has more novice users, more foaming-at-the-mouth zealot appeal,
more third-party application software support, more name recognition,
more hardware support, or better benchmark numbers. To me the measure
of success for FreeBSD should be whether or not the best developers
think it is the best platform on which and for which to develop
software which has real value to them.
I don't think the fight is in the OS arena or what sits on top - I
think the fight is against technical challenges which, when solved,
will advance the leading edge of software. Those solutions will
be easily portable to all extant Unix-like OSes. The recognition
of their value by technically astute developers will bring about an
effort to use the solutions for whatever purpose they are effective,
such as making money.
I think there is a set of software for the demands of the Market,
and a set of software for the needs of the developers. I wish a lot
less energy in the Unix area were spent worrying about the former,
because I think the best technical minds are in the Unix arena, and
I think it is a waste of their time to worry about the immediate
demands of the Market which are much less technically challenging
and whose solutions' value is so much more evanescent.
Larry
From: iver...@cisco.com (Tim Iverson)
Subject: Re: Getting off the stick [was Re: TCP latency]
Date: 1996/07/20
Message-ID: <4spb28$kpl@cronkite.cisco.com>#1/1
X-Deja-AN: 168930347
references: <4paedl$4bm@engnews2.eng.sun.com> <4seo88$fqd@fido.asd.sgi.com>
<4sesh4$2ls@dworkin.wustl.edu> <31EDBDA2.41C67EA6@FreeBSD.org>
organization: cisco
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
In article <31EDBDA2.41C67...@FreeBSD.org>,
Jordan K. Hubbard <j...@FreeBSD.org> wrote:
|And then we wonder why people aren't exactly rushing to clamber aboard
|the S.S. UNIX anymore, prefering instead, for some strange reason, the
|Queen Elizabeth II.
Hmmm. One nice thing -- you can pilot the SSU yourself, while the captain
of the QE2 will only let you look at the wheel. If you just want to cruise
to Bimini and back, take the '2. Otherwise, you *need* the SSU.
Free Unix isn't *competing* with Microsoft. It is competing for a niche
that MS not only can't fill, but does not want to fill.
|Pride goeth before the fall. Face it - porting software to new
|platforms is hard, and most companies won't even bother unless they're
|guaranteed a potential customer base far greater than Linux or *BSD
Hmmm. Trite, but "if you can't beat 'em, join 'em." If you really want
developers to support *BSD, provide the Win95 or NT interface, even to the
driver level. Lotsa work, but far less than trying to convince all the
developers to port to *BSD.
|is still on, what about in 5 years? If this is all going to be down the
|drain by then, why are we even wasting our time now? Yes, I do this
|primarily for fun right now too, but I expect that to get old in a
IMHO, it takes an OS 10 years to become stable enough to really use. If
you're worried about 5 years from now, then you should be looking at 5 year
old OSes. Frankly, I don't see anything on the horizon that can even
remotely compete with Unix.
Unix is the champion of versatility. In five years, it will just be that
much more versatile. I think this trend will continue until we see a
fundamental revolution in the way people use computers. And, predicting
that moment is like trying to get a close look at your own blind spot.
...
Hard to pin down, eh? ;-)
|If the various OS camps don't wake up to this soon, THAT is what is
|going to kill them, not the Linus vs *BSD fights or the fighting between
|the *BSD camps themselves - that's merely arguing about a stubbed toe
|while an 18 wheeler is bearing down on you from behind. Focus on the
|*serious* deficiencies, please!
So, you want a standard API, eh? Start a consortium. No one likes dancing
to Bill's tune, if you're clever about it you may find enough backing to
make Billy-Boy dance to yours!
- Tim Iverson
iver...@lionheart.com
From: t...@agora.rdrop.com
Subject: Re: TCP latency
Date: 1996/07/20
Message-ID: <4sq7j9$86a@symiserver2.symantec.com>#1/1
X-Deja-AN: 168981632
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
<4sej3e$155@dworkin.wustl.edu> <4seo88$fqd@fido.asd.sgi.com>
<4sesh4$2ls@dworkin.wustl.edu> <31EE28D3.41C67EA6@star-gate.com>
organization: Symantec Corporation
reply-to: tedm%toy...@agora.rdrop.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
In <31EE28D3.41C67...@star-gate.com>, "Amancio Hasty Jr."
<ha...@star-gate.com> writes:
[some deleted]
>be able to level the playing field. Another area that Unix at least
>on the PC area could possibly have a significant impact is if there
>was a good emulation layer to run Windows 95. You see people have
[more deleted]
I don't agree with this strategy at all, and here is why:
I have run OS/2 since v2.0 and as we all know for a while there IBM was
pushing OS/2 as a better windoze than windoze.
The problem is that your not going to attract users to FreeBSD by saying that
it can run Windoze programs. It didn't work for the OS/2 crowd and it
ain't going to work for us. It also doesen't seem to work for the Mac
crowd either, at least according to the sales of those "windows emulator
cards for Macs"
What is going to happen instead is that lazy ISV's will simply have no
incentive to port their apps to FreeBSD, they will just beg-off users by
saying that if the users want to run their apps to run them under emulation.
Worse than that is that it will pull valuable developer time into a project
that is going to contribute nothing.
If IBM had not put Windows support into OS/2 the market would have been
smaller in the beginning, but it would have not given all those ISV's that
had half-assed OS/2 plans reasons to muddy the market. For example,
for years WordPerfect was making noise about supporting OS/2 and even did
a few ports to it. They never fully committed to it, as a result a lot of
people _didn't_ buy DeScribe wordprocessor, but just kept waiting for
Wordperfect to get into gear. If wordperfect had not had the option of telling
customers to run their Windows port under OS/2, then they might have decided
to stop playing around, and left the OS/2 market alone. That would have
given people like DeScribe more room in the market.
Here is another way of looking at it. Lets say your a software publisher and
you see the Windows market is very competitive for your product. You are
small, so you have a choice, you can develop for FreeBSD where there is
maybe only one other direct competitor, or you can develop for Windoze
where there are 20.
Now lets say someone goes and puts Windoze emulation into FreeBSD.
Now, your competing against 21 other vendors, the 20 windoze ones and the
one other FreeBSD one. At this point it may make sense to hang it all and
go develop for the Mac! ;-)
Put Windows emulation into FreeBSD and all your going to attract is a
bunch of stinking flies, attempting to push off crappy BSD ports of their
products, expecting the users to buy them just because of their names.
Then, the users buy and start demanding the bugs be removed, making
the flies do some work, and later when the flies do nothing to correct problems
the users stop buying so the flies fly away bitching to everyone who will
listen on how terrible the FreeBSD platform is.
From: t...@agora.rdrop.com
Subject: Re: Getting off the stick [was Re: TCP latency]
Date: 1996/07/20
Message-ID: <4sq67p$86a@symiserver2.symantec.com>
X-Deja-AN: 168985003
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
<4sej3e$155@dworkin.wustl.edu> <4seo88$fqd@fido.asd.sgi.com>
<4sesh4$2ls@dworkin.wustl.edu> <31EDBDA2.41C67EA6@FreeBSD.org>
organization: Symantec Corporation
reply-to: tedm%toy...@agora.rdrop.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
In <31EDBDA2.41C67...@FreeBSD.org>, "Jordan K. Hubbard"
<j...@FreeBSD.org> writes:
[some deleted]
>Chuck has hit the nail precisely on the head, and I'd like to go one
>step further with this:
>
>If UN*X were to do its job properly over the next couple of years
>(unlikely, but if) I think it would be increasingly irrelevant just
>which variant you chose because the operating system would be little
>more than a fairly invisible bit of enabling technology that 99% of its
>user base didn't even care about anyway. To grab an analogy out of the
[more deleted]
>Don't kid yourselves. Linux and *BSD may give us propeller-heads wet
>dreams, but in the bigger scheme of things we're not even a blip, nor do
[more deleted]
>additional edge). Features like transparent clustering, where to
>increase your aggregate horsepower you simply drop another PC or
>SPARCstation or whatever into your computational cluster and it rolls
>into the pool like one blob of mercury joining another. Projects which
>allow us to finally throw NFS out on its ear and replace it with a file
>sharing protocol which is safe (e.g. actually has industrial strength
>locking) and fast. More advanced frameworks which allow us to get away
>from the concepts of hosts and client/server relationships and more into
>the area of "services" where you don't even need to think about where
>something comes from, you just ask for it and the first available
>"resource server" with the information you need picks it up or tells you
>who to ask in turn. The kind of management tools we need to make
>administration of the system something that anyone who could drive NT
>(or hell, even simpler) could do.
>
Believe me, I hear what your saying. Remember that it is always easier to
build the foundation than the gingerbread.
However, Jordan, I think you are falling into the "Microsoft empire" trap that
lots of people have fallen into.
The problem is that most people don't realize it but the entire computer
industry is operating in a tremendously abnormal manner that started many
years ago.
What happened is that in the beginning computers were very large, and very
expensive, and had value to only a few very speciallized users. This is rather
normal for an infant industry, the aerospace business went through this
for example. As a result, the IBM corporation managed to get themselves
wedged into this massivly dominating position that lasted for many long years.
In the beginning, this was normal, but as the years went on and
competitors like DEC fumbled around it began to get seriously wrong.
Later on, the industry did a flip-flop and now Microsoft is in the top
position. This is largely the result on the strength of personality of Bill
Gates. You absolutely must understand that in the eyes of most people
who know even the least about the business, Bill Gates is literally a living
legend, a superman or hero of some kind. This is the normal result of
people deifying a person. And, it is very difficult to fight a living hero.
Becuase of IBM and Microsoft's domination lasting for as long as it has, it
is really easy for folks in the computer business to have tunnel vision and
think that just because the business has operated like this, that it will always
continue to do so forever.
In reality, most other industries do not operate like this, and in fact there
is nothing inherent in the computer business that should dictate that it
would continue in this manner. In fact, Microsoft is spending many hundreds
of millions of dollars in propagating this myth, and holding together the
fantasy.
Most of us here are on the young side. When we are in our sixties, and
hopefully still keying away, we will look back on this time like it was the
"Camelot" of the computer business and wonder how it ever held together
as long as it did.
Bill Gates is probably older than the majority of people here, and so we
will be lucky enough to see what happens to the industry after he dies. Once
that happens, it won't kill Microsoft, but the company will simply then become
"just another software company" much like Apple Computer and numerous
other companies. After Rockefeller died, Standard Oil became just another
oil company, for example. Sure it didn't happen right away, but it did
happen and has happened to every business that ever existed that was founded
by a charismatic individual.
When that day comes, the software industry will have it's bonds lifted and
over a number of years will split apart. By that time if Unix still exists
it will be very well positioned to gain market share back.
Now, all of the things you talk about are real, live, tangible things. However
it will be difficult to do them simply because so much software talent
is being sucked into Windows programming today. The best thing to do
is simply forget about it. Unix has survived very well on it's own, and it
will continue to do so.
If that doesen't make you feel better, perhaps this will:
The entire issue of clustering, filesharing, and resource providing is an
extremely difficult one, probably the greatest challenge to face the computer
business. A lot of the choices that need to be made are not technical ones,
they are political ones. The commercial software vendors like Microsoft
have been pouring millions of dollars of cash and talent into this problem
and still haven't come up with anything. If you stop to consider how many
man-years of software talent has been dumped into this problem without any
decent result, you might just ask the question of is this a solveable
problem at all, or just a computational blind alley?
From: j...@time.cdrom.com (Jordan K. Hubbard)
Subject: Re: Getting off the stick [was Re: TCP latency]
Date: 1996/07/20
Message-ID: <yfgn30us5xb.fsf@time.cdrom.com>#1/1
X-Deja-AN: 169170955
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
organization: Walnut Creek CDROM
newsgroups: comp.unix.bsd.freebsd.misc
In article <4sp5j4$...@hole.sdsu.edu> lar...@saturn.sdsu.edu (Larry Riedel) writes:
I used to feel good about the BSD community because the people in it
seemed to be less interested in whether or not the number of people
who used their software was more than some other OS, and relatively
[elided - I think this paragraph captures the essence of the posting
fairly well]
I think that this posting manages to miss the point in just about
every significant way. This isn't about counting heads for its own
sake, or trying to make UN*X something it's "not" - this is about
filling in pieces that I and many other BSD afficionados have long
missed, or even do simply because it's part of our personal work-ethic
that any software we release match certain standards for
installability, documentation and so on. This is what drives much of
the progress in FreeBSD, anyway.
Jordan
--
- Jordan Hubbard
President, FreeBSD Project
From: lar...@saturn.sdsu.edu (Larry Riedel)
Subject: Re: Getting off the stick [was Re: TCP latency]
Date: 1996/07/21
Message-ID: <4st0u5$a0k@hole.sdsu.edu>#1/1
X-Deja-AN: 169188181
references: <4paedl$4bm@engnews2.eng.sun.com> <4s8rtp$jsh@fido.asd.sgi.com>
<yfgn30us5xb.fsf@time.cdrom.com>
organization: San Diego State University
newsgroups: comp.unix.bsd.freebsd.misc
Jordan K. Hubbard (j...@time.cdrom.com) wrote:
> I used to feel good about the BSD community because the people in it
> seemed to be less interested in whether or not the number of people
> who used their software was more than some other OS, and relatively
> [elided - I think this paragraph captures the essence of the posting
> fairly well]
>
> I think that this posting manages to miss the point in just about
> every significant way. This isn't about counting heads for its own
> sake, or trying to make UN*X something it's "not" - this is about [...]
It made "the" points I wanted to make, which are (1) I don't believe
there is any need to think there is a "war" against any other OS to be
"won in the kernel" or anywhere else, or any need to "hold our own
against Microsoft", or any "18 wheeler" "bearing down," because what the
organizations with money and/or large user bases do is not a critical
concern since they have not historically been purveyors of the technology
which eventually gained widespread acceptance, so (2) I think the focus
should be on developing software for the needs of the technically astute,
rather than typical end users, who are not in a position to evaluate the
technical merits of new developments (unless they have something like a
magic benchmark which they run to decide system L is better than system F
even though they have no idea what are the underlying reasons the
developers of system F chose to write the software in such a way that it
failed to perform as well on that particular benchmark), and (3) I don't
think there is any need to worry about making FreeBSD easy to install or
use for the novice, because it is not, in my opinion, the forte of BSD,
and it doesn't need to be.
Sorry if those points were not "the point," but this is the kind of
"getting off the stick" and "paradigm shifting" I would like to see.
Larry
From: "Jordan K. Hubbard" <j...@FreeBSD.org>
Subject: Re: Getting off the stick [was Re: TCP latency]
Date: 1996/07/21
Message-ID: <31F2946F.41C67EA6@FreeBSD.org>#1/1
X-Deja-AN: 169340656
references: <4paedl$4bm@engnews2.eng.sun.com> <4seo88$fqd@fido.asd.sgi.com>
<4sesh4$2ls@dworkin.wustl.edu> <31EDBDA2.41C67EA6@FreeBSD.org>
<4spb28$kpl@cronkite.cisco.com>
to: Tim Iverson <iver...@cisco.com>
content-type: text/plain; charset=us-ascii
organization: Walnut Creek CDROM
mime-version: 1.0
newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
x-mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386)
Tim Iverson wrote:
> Hmmm. One nice thing -- you can pilot the SSU yourself, while the captain
> of the QE2 will only let you look at the wheel. If you just want to cruise
> to Bimini and back, take the '2. Otherwise, you *need* the SSU.
It seems that every time I have this argument, there's always at least
one or two people who seem to think that I'm advocating for the removal
of UNIX's traditional flexibilities in exchange for a locked-in "if
there's no button to configure this, you're screwed" kind of NT world.
I'm not.
I'm simply saying that UNIX represents a mighty fine "hull" (to continue
my already worn-out analogy) and that there's nothing now stopping us
from building a ship on top that provides a few creature comforts as
well as fine engineering belowdecks. I'd also expect to get a *better*
ship in the end out of this since you'd have the best of both worlds -
something you could configure easily and Just Use if that were your
goal, or something that you could tinker endlessly with if you
needed/wanted to get into the system at that level. Already, free
UN*Xen have something that NT will probably never offer to the masses:
The source code. I realize where our primary strengths lie, and I'd
never even suggest hamstringing them in pursuit of the ease-of-use
goals.
> Free Unix isn't *competing* with Microsoft. It is competing for a niche
> that MS not only can't fill, but does not want to fill.
Competing in the traditional sense no. Attempting to hold its own in
areas where Microsoft would very much like to capture the market, very
much so I think. I don't think it'd be a good idea to get too
complacent about Brother Bill.
> Hmmm. Trite, but "if you can't beat 'em, join 'em." If you really want
> developers to support *BSD, provide the Win95 or NT interface, even to the
> driver level. Lotsa work, but far less than trying to convince all the
> developers to port to *BSD.
I certainly wouldn't mind, if only to be able to say that we have
effective "bridge technology", but convincing someone like Bristol
Technologies to port their suite to FreeBSD hasn't been one of my own
victories, despite frequent attempts. :-(
> IMHO, it takes an OS 10 years to become stable enough to really use. If
> you're worried about 5 years from now, then you should be looking at 5 year
> old OSes. Frankly, I don't see anything on the horizon that can even
> remotely compete with Unix.
Hmmmmmm. While that may have been true before, bear in mind that 10
years ago we didn't know as much as we do now about OS design, nor did
we really have the horsepower available to realize all the design goals
that people had. That's changed, and I'm not about to sell Cutler and
his group too short here - they have a lot more money and full-time
bodies than we do. :-)
> Unix is the champion of versatility. In five years, it will just be that
> much more versatile. I think this trend will continue until we see a
I hope so. My only concern is how *useful* it's going to be for what
people are wanting to do in 5 years. That's rather more the bottom
line, isn't it?
> So, you want a standard API, eh? Start a consortium. No one likes dancing
> to Bill's tune, if you're clever about it you may find enough backing to
> make Billy-Boy dance to yours!
It's certainly a thought. We need a number of APIs, not just one, and
someone who really enjoys writing and nursing RFCs to champion them.
--
- Jordan Hubbard
President, FreeBSD Project
From: l...@neteng.engr.sgi.com (Larry McVoy)
Subject: Re: TCP latency
Date: 1996/07/24
Message-ID: <4t63as$f2q@fido.asd.sgi.com>
X-Deja-AN: 169945182
references: <4paedl$4bm@engnews2.Eng.Sun.COM> <4sadde$qsv@linux.cs.Helsinki.FI>
<31E9E3A7.41C67EA6@dyson.iquest.net> <4sefde$f0l@fido.asd.sgi.com>
<4socfr$3ot@dworkin.wustl.edu>
organization: Silicon Graphics Inc., Mountain View, CA
reply-to: l...@slovax.engr.sgi.com
newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,
comp.unix.bsd.freebsd.misc
Chuck Cranor (ch...@ccrc.wustl.edu) wrote:
: In article <4sefde$...@fido.asd.sgi.com>,
: Larry McVoy <l...@slovax.engr.sgi.com> wrote:
: >Umm, I'd be happy to entertain suggestions for a better measurement of
: >a null entry into the system. I don't want something that anyone special
: >cases - that's just worthless. I want something that is actually measuring
: >all the work you need to do to get to the point that you can do something in
: >the kernel.
: I took Larry's lat_syscall.c and a few of J Wunsch's suggestion for
: different system calls to try and ran a few tests. Here are the results:
: [note: sparc 2 is running SunOS 4.1.3_U1 (48MB RAM), P5-133MHz is running
: NetBSD/i386 (32MB RAM) ... both systems unloaded. all numbers are
: microseconds]
: program description Sparc2 P5-133MHz
: lat_syscall write 1 to /dev/null 61 6
: lat_gettime gettimeofday(&tv,0) 27 5
: lat_kill kill(1,0) 23 2
: lat_umask umask(0) 19 2
: lat_getppid getppid() 17 1
: Given that data, it seems like lat_syscall's writing 1 byte to /dev/null
: is indeed a poor measurement of "Null syscall." This leaves me with
: two questions:
: 1. Larry, when you were designing lat_syscall, did you see numbers like
: the above? If not, then I would consider that a mistake. If so,
: then why did you stick with "write 1 to /dev/null" as a measurement
: of "Null syscall" (which I also consider a mistake)?
Sure did. If there is a mistake here, it is my choice of name for the
benchmark. What I wanted was an entry into the kernel that represented
the approximate real, average cost of getting to the point of being able
to do something useful & common. I'll try and provide some insight into
the thinking that went into this:
getpid() It can be trivially optimized down to a memory
read. The variance from one system to the next
does not reflect anything that can be used as a
performance comparison.
getppid() This one turns into a trap plus a read. It is a
"read only" type benchmark, I wanted one that
had to do some work.
gettimeofday() Some systems have a global variable that gets
updated out of hardclock() every HZ (typically
10 millisecs). So this also can degenerate into
a trap plus a memory load. But other systems
actually read a high resolution clock for this
system call, and reading it takes variable amounts
of time, again making the results not very useful.
kill(), umask() These are the best "null system call" benchmark
choices I've seen. I'd vary the mask in the umask
one so that it was actually changing state. The
only rationale for not using these is this: the
main reason I wanted a "null system call" test was
that for all of the other benchmarks, I wanted to
be able to "decompose" them into the various costs.
For example, the pipe latency benchmark is really
process 1 process 2
write()
ctx switch ->
read()
write()
<- ctx sw
read()
So it is 4 system calls and 2 context switches.
I wanted to be able to look at the pipe benchmark
and have the numbers roughly add up. And they
typically do.
So, I'm willing to cop to the critism that the labeling was crappy and
perhaps I should call it the "null I/O syscall".
I'm also willing (and interested) to find a different syscall that just
measures trap overhead, but I haven't seen one yet that I really like.
The getppid() may be the best out there, though, it's hard to cache
that. Thoughts?
: 2. How much of the difference between FreeBSD lat_syscall and Linux
: lat_syscall can be attributed to VFS overhead in FreeBSD? Or
: more generally, how does the overhead and functionality of Linux's
: VFS layer compare with FreeBSD's VFS layer?
Both FreeBSD and Linux offer roughly the same VFS interface. It took me
a while to wrap my brain around Linus' thinking in his stuff, having
come from a SunOS/BSD background and having spent a lot of time working
in that area, but at this point, I think I can do everything in Linux that
I could do in *BSD or SunOS, in the VFS areas.
--
---
Larry McVoy l...@sgi.com http://reality.sgi.com/lm (415) 933-1804