I sent out a query recently about the performance of the IPC vs the
Classic, based on a message I'd seen recently claiming that the
numbers were not nearly as different as might seen.
I've included two replies below -- the first was from Adrie Koolen,
who sent out the original message that prompted me. He sent along a
clarification of his message.
The second message is from Larry Wake, who talks about my original
question that concerned the relative CPU/ethernet bandwidth issues
involved in whether I should use an IPC or a Classic as a MBONE
(Internet audio/video) router.
Thanks to all who replied.
Date: Mon, 2 Aug 93 09:44:51 +0200
Subject: Re: IPC vs Classic performance?
I wrote that our LX wasn't much faster than my IPC. A few remarks must
be made. First, I made a mistake in compiling the benchmark program
(dhrystone). On the LX (SunOS 5.1), HZ is 100. On my IPC (SunOS 4.1.3)
HZ is 60. Dhrystone had a fixed HZ set to 60, so the results of the LX
machine were too low. Then, the LX's Tsunami processor definitely is
faster than the 25MHz Sparc processor in the IPC, but not by the factor
that Sun tells you. The IPC is supposed to give you some 16 MIPS
(measured by Sun and myself), but Sun says that the LX would give you
59 MIPS. I got 36 MIPS and Casper Dik told me he got 44 MIPS, using
the latest GCC compiler (2.4.5). The operating system on the LX, SunOS
5.x, seems to slow down the computer quite a bit. I think that you'd
get the best results on an LX using SunOS 4.1.3 and the latest and
fastest GNU C compiler (2.4.5). I don't think that the LX is 59/16
times as fast as an IPC in general applications. The SPECmark numbers
provide a better indication, I think.
Adrie Koolen (firstname.lastname@example.org)
Philips Consumer Electronics, Eindhoven, the Netherlands
Date: Mon, 2 Aug 93 13:03:05 PDT
From: email@example.com (Larry Wake - Sun San Diego Systems Engineer)
Subject: Re: IPC vs Classic performance?
Feel free to weight this message by its source, but...
I can't speak to what MBONE will exercise more: the CPU or the Ethernet
interface. Generally speaking, an IPC should come pretty close to
driving an Ethernet interface as fast as the net will let it. However,
if CPU processing comes into play, which it sounds like your routing
function will do, then the Classic should outperform the IPC by a
What I prefer to tell customers, and no one has felt this to be out of
line after using the machine themselves, is that the LX/Classic is
about 20% faster than an *IPX*. Not an IPC, but its successor. I'm
surprised that anyone would say it's only slightly faster than an IPC.
Consider that performance wise, the major difference between the IPC
and the IPX was a turn-up of its clock speed. The IPC was a 13.5
SPECmark (SPEC 89) machine, the IPX was a 24.4 SPECmark machine.
The Classic is rated at 26.4 SPECint92. That's a more restrictive
benchmark than SPEC 89, precisely because people were doing way too
much compiler magic. Even so, that's about twice the speed of the IPC,
and is as "real" as a benchmark comparison like this can get. I would
fully expect any task that isn't bound by some other factor such as
disk I/O (or network I/O, in your case) to easily run twice as fast on
a Classic as on an IPC.
Another way to look at it: both the IPC's processor and the Classic's
processor are scalar implementations of SPARC. The IPC's CPU clock ran
at 25 MHz; the Classic's runs at 50 MHz. Using this *extremely*
simplistic comparison (i.e., don't consider this the whole story by any
means -- this is the kind of comparison they make in PC-land, for
pete's sake! :-), the Classic should eat instructions twice as fast as
the IPC did. The major difference between the two chip implementations
is that the IPC had a larger on-chip unified instruction/data cache,
but the microSPARC has a much tighter CPU-memory coupling, which would
make jobs that blow cache run faster on microSPARC than an original SPARC
running at the same clock rate.
To sum up: judging from SPECmarks, the Classic should easily outperform
the IPC, CPU-wise. If Ethernet is the bottleneck, this may not matter.
If CPU is, it will make a great difference.
Larry Wake, Sun Microsystems San Diego field office
Friend or foe, there's only us.
-- J. Paul Holbrook CICNet Technical Services Manager firstname.lastname@example.org (313) 998-7680
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:05 CDT