Hi fellow admins!
I thought this might be of interest for all of you! Following are
just some preselected news-postings about Linux on Sparc-Workstations.
Concerning performance, stability, and so on.
If you have questions, feel free to mail me!
Regards,
Herbert
------- Forwarded Messages
>Date: Thu, 10 Oct 1996 06:43:46 +0200
>From: torvalds@cs.Helsinki.FI (Linus Torvalds)
>cc: sparclinux@vger.rutgers.edu, sparc-list@redhat.com, lm@engr.sgi.com
>Subject: Re: NAH NAH NAH NAH...
>In-Reply-To: <199610100020.UAA05510@caip.rutgers.edu>
>Message-ID: <Pine.LNX.3.91.961010073715.11120D-100000@linux.cs.Helsinki.FI>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Reply-To: sparc-list@redhat.com
>X-Mailing-List: <sparc-list@redhat.com> archive/latest/1360
>X-Loop: sparc-list@redhat.com
>Precedence: list
>Resent-Sender: sparc-list-request@redhat.com
>X-URL: http://www.redhat.com
>Organization: Muc e.V. - Verein zur Foerderung privater Datenkommunikation
>Newsgroups: linux.sparc.redhat
>Approved: postnews
>Lines: 40
On Wed, 9 Oct 1996, David S. Miller wrote:
>
> NAH NAH NAH NAH! SLOWWWW-LAAAAR-IS, GOOOD-BYE!
Very subtle, David, very subtle.
Good work!
> 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
> --------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
> trombetas Linux 2.0.21 50 15 4.1K 57.8K 156K 181 56 71
> geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
> negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
Damn, I really hate those /bin/sh numbers. I see the same thing on all other
platforms too: beting everybody on all the other numbers, and then losing out
on the shell execution numbers.
Now, at least on other platforms the problem is not the kernel, but simply
the fact that bash is large and slow and overkill for these kinds of
benchmarks. I assume you're running a native Linux bash above, and that
that's why SunOS has better numbers for /bin/sh process?
On the other hand I definitely don't want to have a smaller and stupider
/bin/sh. Bash is a good standards-conforming shell, it's just not very
fast for this particular benchmark.
But we certainly kill both SunOS and Solaris on any other benchmark.
You've done good, David. Call me pinhead,
Linus
- --
To unsubscribe: mail -s unsubscribe sparc-list-request@redhat.com < /dev/null
------- Message 2
>Date: Thu, 10 Oct 1996 02:20:13 +0200
>Message-ID: <199610100020.UAA05510@caip.rutgers.edu>
>From: davem@caip.rutgers.edu ("David S. Miller")
>CC: sparc-list@redhat.com, lm@engr.sgi.com, torvalds@cs.helsinki.fi
>Subject: NAH NAH NAH NAH...
>Reply-To: sparc-list@redhat.com
>X-Mailing-List: <sparc-list@redhat.com> archive/latest/1356
>X-Loop: sparc-list@redhat.com
>Precedence: list
>Resent-Sender: sparc-list-request@redhat.com
>X-URL: http://www.redhat.com
>Organization: Muc e.V. - Verein zur Foerderung privater Datenkommunikation
>Newsgroups: linux.sparc.redhat
>Approved: postnews
>Lines: 52
NAH NAH NAH NAH! SLOWWWW-LAAAAR-IS, GOOOD-BYE!
Yowza! The party is over folks, it's simply over.
Yee haw! Looks like Solaris has some, ummm, performance problems.
And geee, I still have 4 or 5 large optimizations still on my back
burner for the Sparc. Solaris you have no chance, no chance.
The scoreboard has been updated! ;-) hahahahaha!
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
- --------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 2.0.21 50 15 4.1K 57.8K 156K 181 56 71
geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
- --------- ------------- ------- ------- ------- ------- -------
trombetas Linux 2.0.21 201 985 1620 1198 2212
geneva.ru SunOS 5.5 530 1563 2080 1354 2398
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
- --------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 2.0.21 9 7.3 24.1 23.0 19 25 40 37
geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
- --------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 2.0.21 49 20 172 180 600 No L2 cache?
geneva.ru SunOS 5.5 49 - - - - Bad mhz?
negro.rut SunOS 4.1.3_U 49 20 175 183 659 No L2 cache?
- --
To unsubscribe: mail -s unsubscribe sparc-list-request@redhat.com < /dev/null
------- Message 3
>Message-ID: <199610102050.NAA23583@neteng.engr.sgi.com>
>From: lm@neteng.engr.sgi.com (Larry McVoy)
>cc: sparc-list@redhat.com, "David S. Miller" <davem@caip.rutgers.edu>,
>Subject: Re: NAH NAH NAH NAH...
>Date: Thu, 10 Oct 1996 22:50:40 +0200
>Sender: lm@neteng.engr.sgi.com
>Reply-To: sparc-list@redhat.com
>X-Mailing-List: <sparc-list@redhat.com> archive/latest/1393
>X-Loop: sparc-list@redhat.com
>Precedence: list
>Resent-Sender: sparc-list-request@redhat.com
>X-URL: http://www.redhat.com
>Organization: Muc e.V. - Verein zur Foerderung privater Datenkommunikation
>Newsgroups: linux.sparc.redhat
>Approved: postnews
>Lines: 57
: Yeah the only reason it's faster is because it's got so many security
: holes in it, that they take everything out.
OK, I think I can handle this. Tell your friend that I used to work at
SunSoft, in the kernel group, I did posix, ufs clustering, the sun source
mgmt system, started 100baseT, architected the cluster product line (from
which came vlans which I invented), etc. I think my credentials are
probably enough to impress a sys admin :-)
The main reasons that Linux is faster than commercial Unices:
. the system call entry is a better design. All Unix systems
other than linux use the design done by Bell Labs 20 years
ago and the Linux design is simply lighter - it approaches
a procedure call in cost. The complaint is always that
Linux can't possibly be supporting all the features, such as
restartable system calls, if it is that fast. Those claims
turn out to be false - Linux supports the same features,
including security, as any commercial Unix. It's just
designed better. And commercial Unices are starting to
pick up the ideas.
. Linux kernel hacks count instructions and cache misses and
eliminate them. This is a biggy. When each "feature" is
added into a kernel, people will do gross measurement to
show that it made no difference. And each feature doesn't
make a measurable difference - one or two more cache misses
in a code path won't show up. But do that a 100 times and
all the "features" taken together start to hurt. Linux is
far ahead of the rest of the world, including NT, in that
Linus and the other senior kernel folks do not kid themselves
that a cache miss here and there doesn't matter. I frequently
see the Linux development effort keep working at it until the
feature they are working on can not go faster because it is
running at hardware speeds - there is no more room for
optimization. Contrast that with the commercial approach
of "well, it didn't slow down for me" and you can start to
see how things get out of hand. Kudos to Linus, David and
Alan for being the smartest coders in this regard. I'd
like to be that good.
. Linux is a redesign. Many ideas have been rethought using
current thinking. All other Unix implementations (exceptions
are things like QNX - which also performs at Linux like speeds
abnd has also been shown to be posix/xpg4 etc compliant) are
basically the same under the covers. It isn't surprising that
fresh minds can do better - one would hope that we have learned
something in 20 years.
I gotta go to work so if this isn't enough, ping me and I'll try and
do a better job.
--lm
- --
To unsubscribe: mail -s unsubscribe sparc-list-request@redhat.com < /dev/null
------- Message 4
>Date: Thu, 10 Oct 1996 23:33:56 +0200
>Message-ID: <199610102133.RAA13424@caip.rutgers.edu>
>From: davem@caip.rutgers.edu ("David S. Miller")
>CC: torvalds@cs.Helsinki.FI, sparclinux@vger.rutgers.edu,
>In-reply-to: <199610101757.KAA17896@neteng.engr.sgi.com>
>Subject: Re: NAH NAH NAH NAH...
>Reply-To: sparc-list@redhat.com
>X-Mailing-List: <sparc-list@redhat.com> archive/latest/1401
>X-Loop: sparc-list@redhat.com
>Precedence: list
>Resent-Sender: sparc-list-request@redhat.com
>X-URL: http://www.redhat.com
>Organization: Muc e.V. - Verein zur Foerderung privater Datenkommunikation
>Newsgroups: linux.sparc.redhat
>Approved: postnews
>Lines: 25
From: lm@neteng.engr.sgi.com (Larry McVoy)
Date: Thu, 10 Oct 1996 10:57:09 -0700
I think the Solaris buttheads should bow down in amazement,
especially on the TCP numbers, since Solaris is cheating and Linux
is really doing the work. Those numbers would imply that Linux is
going to be better over the wire.
Have no fear, I am working on the 100mb/s HME Ethernet driver for
SparcLinux so that we can verify this. Perhaps on my HyperSparc
system, I can come close to obtaining the new over the wire latency
world record.
(It is funny to note that last evening as Linus and myself were
chatting, we realized that is have come to the point where the only
way that Linux can strive for much better performance is to have
the different ports compete against each other. I thought this was
neat.)
David S. Miller
davem@caip.rutgers.edu
- --
To unsubscribe: mail -s unsubscribe sparc-list-request@redhat.com < /dev/null
------- End of Forwarded Messages
_____________________________________________________________________
Herbert Wengatz GABO mbH Munich |Office mailto:hwe@uebemc.siemens.de
Private mailto:hwe@rtfact.muc.de | This mail is my own opinion, not
http://www.muc.de/~hwe/rtfact | that of my employer!
--- "Excellence is a moving target." ---
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:13 CDT