ix Review Solaris 2.4 x86 - Linux 1.1 4x faster Multi User Benchmarks
Robert Davies
bugs and patches, and broken patches....
Is it Sys V rel 4 thats slow and unreliable, or have Sun broken it?
In the multi-user benchmarks, Linux with a load of 16 Users was faster than
Solaris 2 with 4. Presumably Sun can sell more MP machines, more memory, more ...
Ok, so Linux has less functionality, but what about all those much vaunted
performance improvements? Sun says Solaris 2 is faster than SunOS 4, which
seems to be very dubious, considering the woes of those out there with 16MB RAM.
It's not funny anymore.. Does anyone acutally like Solaris2?
-- Rob
And me with a pain in all the diodes down my left side
Casper H.S. Dik
>Having spent a depressing few hours looking at all the latest Solaris 2.4,
>bugs and patches, and broken patches....
>Is it Sys V rel 4 thats slow and unreliable, or have Sun broken it?
I'm not sure what you did or on what hardware. We find Solaris 2.3/2.4
very reliable. It also feels faster than SunOS 4.1.x.
>In the multi-user benchmarks, Linux with a load of 16 Users was faster than
>Solaris 2 with 4. Presumably Sun can sell more MP machines, more memory, more ...
*the* benchmark? Which benchmark was that? And was it on the same
hardware? Solaris 2.x handles a lot more things than linux does and
that has some disadvantage. Almost all executables need to load
atleast 4 dynamic libraries, which is slow. So the relative
overhead of starting an application in Solaris 2.x is huge.
But this overhead is required for the support of libintl and libw which
need the capability of dynamic linking.
Sun should and can bring this overhead down.
Solaris 2.x also has much more stuff in the kernel than Linux and
some of it is much faster/better than Linux (networking/NFS)
But I really wonder about these benchmarks. A lot of people have
reported that Linux degrades very badly under load, which is something
we don't notice on Solaris 2.x.
>Ok, so Linux has less functionality, but what about all those much vaunted
>performance improvements? Sun says Solaris 2 is faster than SunOS 4, which
>seems to be very dubious, considering the woes of those out there with 16MB RAM.
We don't have much problems with 16MB machines. But you are confused.
Solaris 2.x does require more memory but it *is* faster with sufficient
memory (4-8MB more than SunOS 4.1.x)
>It's not funny anymore.. Does anyone acutally like Solaris2?
Yes. It is much easier to maintain and configure than SunOS 4.1.x,
once you know SunOS 4.1.x as good as Solaris 2.x.
Casper
Kevin Martinez
[....]
>In the multi-user benchmarks, Linux with a load of 16 Users was faster than
>Solaris 2 with 4. Presumably Sun can sell more MP machines, more memory, more ...
[.....]
>It's not funny anymore.. Does anyone acutally like Solaris2?
Yes, people actually like Solaris 2. I have several machines that can
boot either Solaris x86 2.4 or Linux. I use both modes.....
On the same machine with identical hard drives, Linux fires up quicker
(if no e2fsck!) and seems a little peppier in response and in the file
system. Some of the things I do with Solaris involve wabi, answerbook and
the nice NFS server package. I can guess that some of the apparent
overhead that Solaris x86 seems to have with respect to Linux involve
the dynamic libraries and the extensive system info and statistics
gathering.
The Linux developers have done a fine job (in my opinion) and Sun has
done an excellent job of porting their pre-existing O/S to Intel
hardware. I give applause and virtual beers to both groups!
Kevin Martinez
l...@rahul.net
--
------------------------------------------------------------------------
Kevin Martinez | Fry's Electronics: Where
l...@rahul.net | Incompetence is the Standard!
------------------------------------------------------------------------
David Holland
>It's not funny anymore.. Does anyone acutally like Solaris2?
Yes, far more than Linux.
>-- Rob
> And me with a pain in all the diodes down my left side
David Holland
--
David Holland "Of course, trusting the government with your privacy is like
dav...@use.com having a Peeping Tom install your window blinds."
-- John Perry Barlow
Thomas Fritz
-> Having spent a depressing few hours looking at all the latest Solaris 2.4,
-> bugs and patches, and broken patches....
->
-> Is it Sys V rel 4 thats slow and unreliable, or have Sun broken it?
->
-> In the multi-user benchmarks, Linux with a load of 16 Users was faster than
-> Solaris 2 with 4. Presumably Sun can sell more MP machines, more memory, more ...
->
I find SunOS / Solaris a dog.
For example, using a Sparc 1000E server with 1gb of ram, and two raid
5 disk arrays(fast and wide). This system only gets 5megs per sec. xfer rate.
I pull the disk arrays, and put them on a SGI DM system (basic), and run the
same dd command (dd if=/dev/zero of=/array_mount_point/file.test bs=1024k
count=19531) which SGI gives about 14 megs per sec. xfer rate. So I called
Sun, and they thought that the 5megs per sec. was great! Great? I think
they need to have another look at the device drivers / kernel.
Now, my Linux box using the same test gets 8megs per sec. It is a P5/90
system.
-> Ok, so Linux has less functionality, but what about all those much vaunted
-> performance improvements? Sun says Solaris 2 is faster than SunOS 4, which
-> seems to be very dubious, considering the woes of those out there with 16MB RAM.
Don't let them lie to you. That is a lie, and they know it. Should you want
proof, ask almost anyone at Sun (Bay Area) who have been converted, if it (Solaris)
is faster, and they will tell you that Solaris sucks. On power servers (like my
Sparc 1000E) to workstation's.
->
-> It's not funny anymore.. Does anyone acutally like Solaris2?
->
-> -- Rob
->
-> And me with a pain in all the diodes down my left side
->
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-= Thomas Fritz -=*=- t5...@isp.net =-
-= Unix System Admin. | flames=/dev/null =-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Sven C. Dack
Robert> 2.4, bugs and patches, and broken patches....
Robert> Is it Sys V rel 4 thats slow and unreliable, or have Sun broken it?
Robert> In the multi-user benchmarks, Linux with a load of 16 Users was
Robert> faster than Solaris 2 with 4. Presumably Sun can sell more MP
Robert> machines, more memory, more ...
Robert> Ok, so Linux has less functionality, but what about all those much
Robert> vaunted performance improvements? Sun says Solaris 2 is faster than
Robert> SunOS 4, which seems to be very dubious, considering the woes of
Robert> those out there with 16MB RAM.
First of all I have to say that the guy from the ix magazine has done a
lousy job on testing Solaris 2.4 for x86. All it showed was that 2.4 "as-is"
doesn't run very well with just 16 MB. He probably not even though about
adding more memory to see if this would change anything. Solaris is known to
need a lot of memory.
Just because the little info sheets that came with it said it would be able
to run Solaris 2.4 with 16 MB doesn't mean it's enough for a user load of 4
or even 16.
The guy mentioned those info papers several times and complained they would
not give enough information and he had to struggle several hours around to
figure out he needed an /etc/hostname.smc0 file for his eithernet card. But
somebody (in de.comp.os.unix) said that the hostname.smc0 file is beeing
mentioned in those installation docs. So, either this guy is lying or the
one from the ix magazine didn't read it all through ...
Installing Solaris just the way it comes down from the CD without ablying
atleast the recommented patches is silly. Not that it has to be that way, but
I guess he just didn't do that (atleast he said nothing about it). Otherwise
I have no idea why he had so many crashes.
But I was also surprised about the fact that Linux is that much faster than
Solaris. But is there any commercial unix that would not loose against Linux
when it comes pure OS performance? (Again this is not an excuse of course.)
And with every new feature Linux becomes a bit slower. So, wait till it's
able of multi threading, supports multiple cpus, can handle 16 bit wide
characters, ...
It is sad. Normally the ix magazine gives you really good information and
their test reports reflect the Real World (TM).
Robert> It's not funny anymore.. Does anyone acutally like Solaris2?
Yes, atleast for Sparcs I do. SunOS 5.4 compared to 4.1.3 may be a little
bit faster, but all I can say is that it is faster than 5.3 and about as fast
as 4.1.3. But OpenWindows has become a lot faster than under 4.1.3. So I
would say Solaris 2.4 is a bit faster than 4.1.3.
Sven
--
LOAD "EMACS",8,1
Casper H.S. Dik
>I find SunOS / Solaris a dog.
>
>For example, using a Sparc 1000E server with 1gb of ram, and two raid
>5 disk arrays(fast and wide). This system only gets 5megs per sec. xfer rate.
>I pull the disk arrays, and put them on a SGI DM system (basic), and run the
>same dd command (dd if=/dev/zero of=/array_mount_point/file.test bs=1024k
>count=19531) which SGI gives about 14 megs per sec. xfer rate. So I called
>Sun, and they thought that the 5megs per sec. was great! Great? I think
>they need to have another look at the device drivers / kernel.
>Now, my Linux box using the same test gets 8megs per sec. It is a P5/90
>system.
I don't think you give us all the parameters in the test.
E.g., you can't even write 19GB files under Solaris 2.x.
On single disks under Solaris 2.x we get the max I/O bandwidth
available from the disk. (6MB/s on F&W baracudas on writes,
9MB/s if you don't fsync)
The thruput on the disk array is probably limited by the speed of the
disks. The disks Sun ships max out at perhaps 1-2MB/s.
So depending on how wide your stripes are, 5MB/s may well be the
limit of the disk. In my experience, the limit of the disk
is the limit of Solaris 2.x, unless the processor is slow.
The SGIs aren't as fast as they look. While they obviously do
I/O buffering faster, I don't find the thruput of normal
disks that enormous. (you seem to be getting 14MB/s until
you fsync() the file, after which time the aggregrate thruputs drops
back to values expected from the disk thruput)
SGI does use a trick with page aligned buffers that aren't copied
to the kernel, which can be an enormous performance win.
Linux's filesystem implementation doens't use synchronous writes, and
I'm actually suprised that you only get 8MB/s on a P90, provided
all I/O fits in memory. But we can't judge that as you obviously
didn't give us the test you really did run.
>Don't let them lie to you. That is a lie, and they know it. Should you want
>proof, ask almost anyone at Sun (Bay Area) who have been converted, if it (Solaris)
>is faster, and they will tell you that Solaris sucks. On power servers (like my
>Sparc 1000E) to workstation's.
I'd be surprised if SunOS 4.1.x is faster on the SS1000E.
We do find that the Solaris 2.4 desktop performance is considerably faster
than SunOS 4.1.x. If you're asking the sysadmins, they may well dislike
the change for obvious reasons (having to relearn things)
Casper
Larry McVoy
: For example, using a Sparc 1000E server with 1gb of ram, and two raid
: 5 disk arrays(fast and wide). This system only gets 5megs per sec. xfer rate.
: I pull the disk arrays, and put them on a SGI DM system (basic), and run the
: same dd command (dd if=/dev/zero of=/array_mount_point/file.test bs=1024k
: count=19531) which SGI gives about 14 megs per sec. xfer rate. So I called
: Sun, and they thought that the 5megs per sec. was great! Great? I think
: they need to have another look at the device drivers / kernel.
:
: Now, my Linux box using the same test gets 8megs per sec. It is a P5/90
: system.
Thanks for the SGI plug :-) I'll add to your fire. By way of background,
I'm a kernel hacker that used to work at Sun and now works at SGI. This
sort of I/O stuff is my area of expertise. You can discount my ravings
because I work for SGI, but you should trust that I know what I'm talking
about in this area; ask people, even Sun engineers will admit it :-)
I can happily say that SGI blows the socks off of any Sun system in
terms of disk or network I/O. I'm currently working on being able to
do at least 50MB/sec disk <-> net <-> remote machine. I've done my own
testing on SGI systems and I can get 18MB/sec per fast&wide SCSI
string using just 3 disks. Sure wish I had 100MB/sec SCSI strings...
On the lab nmachine we use for NFS performance, I've done 162MB/sec of
disk reads, sustained. Personally. I went into the lab and watched
all those pretty lights going. I couldn't do any more than that because
I had 9 fast&wide SCSI strings. Notice that the scaling was 100%
linear -- 162/9 == 18.
But that's no big deal, get a load of this. SGI has a *file system*
that goes that fast. Faster, in fact. The xFS file system has been
measured running at 350MB/sec by Cray computer engineers (they're
bummin - their RAM disks aren't that fast, no kidding) Internally,
we've had it up to 450MB/sec (I haven't seen that one myself, I don't
have that many disks). By the way - the performance numbers are one
process doing normal reads. No multi threading required.
In addition, SGI's network walks all over Sun's network. I regularly get
over 70MB/sec through TCP/IP over HiPPI cables. Try and do that with a
Sun (good luck).
SGI's MP's just blow the frigging doors off of Sun hardware &
software. Sun may have more market share but they don't have a chance
of competing with SGI in terms of I/O. SGI is at least a couple orders
of magnitude faster. Sun doesn't stand a chance - if you care about
I/O, you buy an SGI.
: -> It's not funny anymore.. Does anyone acutally like Solaris2?
No. Never did, never will. It's part of why I left Sun.
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Kevin Clarke
>SGI's MP's just blow the frigging doors off of Sun hardware &
>software. Sun may have more market share but they don't have a chance
>of competing with SGI in terms of I/O. SGI is at least a couple orders
>of magnitude faster. Sun doesn't stand a chance - if you care about
>I/O, you buy an SGI.
Wow 500mb per second off a single disk. It's a wonder I even come
to work the way you've got this all figured out.
---
=================================================================
| Kevin Clarke - Solaris Perf | "To err is human, |
| k...@Eng.Sun.COM | to moo bovine." |
=================================================================
Paul De Bra
>Robert> Having spent a depressing few hours looking at all the latest Solaris
>Robert> 2.4, bugs and patches, and broken patches....
>
>Robert> Is it Sys V rel 4 thats slow and unreliable, or have Sun broken it?
>
>Robert> In the multi-user benchmarks, Linux with a load of 16 Users was
>Robert> faster than Solaris 2 with 4. Presumably Sun can sell more MP
>Robert> machines, more memory, more ...
>
>Robert> Ok, so Linux has less functionality, but what about all those much
>Robert> vaunted performance improvements? Sun says Solaris 2 is faster than
>Robert> SunOS 4, which seems to be very dubious, considering the woes of
>Robert> those out there with 16MB RAM.
Solaris 2.4 for x86 is indeed a lot slower than other PC Unix systems.
I have run benchmarks on many different Unix versions, on many different
types of machines, and Solaris 2.4 (and also the previous 2.1 for that matter)
is indeed very slow.
I have also run a simulation of up to 15 simultaneous users, and below you
find some numbers that speek for themselves.
Note that when doing simple number crunching the same machine performs
the same with every Unix version. It's only when the kernel gets into heavy
action (switching processes, starting programs, piping, etc) that Solaris
becomes very slow.
On the machines below the AT 486-50 had 20MByte ram, the 486-66 had 32MByte
ram, (both with 256K cache) and the 386-25 had 8Mbyte ram (and 128K cache).
machine unix-version 2 5 8 11 13 15
---------------------------------------------------------------------------
AT 486-50DX Esix 4.0.4 1.0 2.5 3.8 5.3 6.0 7.1
Sparcstation 10 Sun OS 4.1.3 1.2 2.7 4.0 5.5 6.7 7.6
AT 486-50DX AT&T sVr4.0 1.5 3.5 5.3 7.5 8.9 10.3
Mips 6850 Risc/OS 4.52 1.8 4.6 6.9 9.5 10.9 12.6
Sparcstation 2 Sun OS 4.1.1 2.1 4.9 7.9 10.4 12.2 13.9
Magnum 3000 Risc/OS 4.52 2.4 4.8 7.8 11.3 13.1 14.8
AT 386-25DX System V-3.2 2.6 5.4 8.0 10.8 13.0 15.0
AT 486-66DX2 Solaris 2.1 2.4 5.9 9.3 13.0 15.1 17.3
AT 486-50DX Solaris 2.4 2.8 5.9 9.5 12.8 15.1 17.4
DecStation 3100 Ultrix 3.1 2.8 6.5 10.2 13.9 16.3 18.6
AT 486-66DX2 Solaris 2.4 2.9 6.8 10.8 15.0 17.6 20.5
AT 286-12 SCO Xenix V2.2 7.7 19.0 30.5 42.0 49.6 57.5
These number lead to a very simple conclusion: for multiuser (multitasking)
Solaris reduces the speed of a PC-class machine to about 1/3 of the speed
the same machine achieves with other versions of Unix.
Or, in still other words: a 486-66 with Solaris is about as fast as a
386-25 was, 5 years ago.
This may be sad, but it is simply true.
I'm not saying Solaris is bad, because at least for me it seems to work well.
But if you want your machine to do a lot of things simultaneously, you should
probably look for another Unix version, because it's in the multitasking that
Solaris is at its worst.
Paul.
Mark Davis
>machine unix-version 2 5 8 11 13 15
>AT 286-12 SCO Xenix V2.2 7.7 19.0 30.5 42.0 49.6 57.5
^^^^^ ^^^^^
Yikes! Why did you throw THAT in there? Wouldn't SCO Unix 5.3.2.4.2 on
a 486 50 been a better benchmarker to compare to others? Perhaps you just
had a 10 year old system lying around you wanted to try for the heck of it :)
--
/--------------------------------------------------------------------------\
| Mark A. Davis | Lake Taylor Hospital | Norfolk,VA (804)-461-5001x431 |
| Director/SysAdmin | Information Systems | ma...@taylor.infi.net |
\--------------------------------------------------------------------------/
Larry McVoy
: In article q...@fido.asd.sgi.com, l...@slovax.engr.sgi.com (Larry McVoy) writes:
: >SGI's MP's just blow the frigging doors off of Sun hardware &
: >software. Sun may have more market share but they don't have a chance
: >of competing with SGI in terms of I/O. SGI is at least a couple orders
: >of magnitude faster. Sun doesn't stand a chance - if you care about
: >I/O, you buy an SGI.
:
: Wow 500mb per second off a single disk. It's a wonder I even come
: to work the way you've got this all figured out.
Jeez Kevin, you work on performance and you don't understand aggregate
I/O bandwidth? Maybe you should stay home :-) By the way, lowercase
"mb" normally means megabits and uppercase "MB" means megabytes. We're
talking MB not mb.
Anyway, for those who care: nobody has 500MB disk drives. SGI gets
their numbers by using (a) their logical volume manager to stripe the
drives, and (b) xFS, their high performance logging file system.
The interesting thing about SGI's hardware/software is that I've
yet to see non-linear scaling in I/O performance. I striped 9
SCSI strings and it was exactly linear.
And, given the independently verified performance numbers, I can
understand that Sun performance engineers would want to just give up...
Oh, yeah, did I mention 80MByte/sec through one networking interface
running standard TCP/IP? Chuckle. I like my new job, SGI seems to
care about being fastest.
Dmitri Sergatskov
Larry McVoy <l...@slovax.engr.sgi.com> wrote:
...... < deleted > ......
>........................................... By the way, lowercase
>"mb" normally means megabits and uppercase "MB" means megabytes. We're
>talking MB not mb.
>
By the way, small m (as prefix) usually stands for "milli", so:
mb - millibits
mB - millibytes
Mb - megabits
MB - megabytes
:-)
Just passing by...
>Larry McVoy (415) 390-1804 l...@sgi.com
Dmitri.
Bryan Althaus
: Thanks for the SGI plug :-) I'll add to your fire. By way of background,
: I'm a kernel hacker that used to work at Sun and now works at SGI. This
: sort of I/O stuff is my area of expertise. You can discount my ravings
: because I work for SGI, but you should trust that I know what I'm talking
: about in this area; ask people, even Sun engineers will admit it :-)
: : -> It's not funny anymore.. Does anyone acutally like Solaris2?
: No. Never did, never will. It's part of why I left Sun.
: Larry McVoy (415) 390-1804 l...@sgi.com
Please Larry in a follow up post tell us all the reasons why you left Sun
and how great SGI is, hey isn't that why I read comp.unix.solaris? Actually
up until the Solaris comment I was impressed. Now I just see you as another
BSD lover/hacker who left for SGI where they still have BSD.
HP wasn't hiring ;-)
--
Regards,
Bryan Althaus br...@krf.com b...@netcom.com
Casper H.S. Dik
>Please Larry in a follow up post tell us all the reasons why you left Sun
>and how great SGI is, hey isn't that why I read comp.unix.solaris? Actually
>up until the Solaris comment I was impressed. Now I just see you as another
>BSD lover/hacker who left for SGI where they still have BSD.
Which is suprising as IRIX isn't exactly BSD. I think Larry's preference
for an operating system is not at the userland level but at the kernel
level. Personaly I don't care for the convoluted mess that SGI
puts on top of its kernel, but the have done a number of things right
in the kernel.
Casper
Bill Vermillion
Kevin Clarke <k...@Eng.Sun.COM> wrote:
>In article q...@fido.asd.sgi.com, l...@slovax.engr.sgi.com (Larry McVoy) writes:
>>software. Sun may have more market share but they don't have a chance
>>of competing with SGI in terms of I/O. SGI is at least a couple orders
>>of magnitude faster. Sun doesn't stand a chance - if you care about
>>I/O, you buy an SGI.
>Wow 500mb per second off a single disk. It's a wonder I even come
>to work the way you've got this all figured out.
Well I touch-type at least 30 times faster than 500
milli-bits/second. :-)
--
Bill Vermillion - bi...@bilver.oau.org | bill.ve...@oau.org
Larry McVoy
: Please Larry in a follow up post tell us all the reasons why you left Sun
: and how great SGI is, hey isn't that why I read comp.unix.solaris? Actually
: up until the Solaris comment I was impressed. Now I just see you as another
: BSD lover/hacker who left for SGI where they still have BSD.
Sorry not to indulge your wishes, Bryan. The point of the article was
to inform people about the I/O performance of SGI hardware/software.
I'm a firm believer of credit where credit is due, and SGI has done a
great job of delivering incredible I/O bandwidths to their users.
Don't you think that file systems that are twice as fast as Cray's RAM
disks is impressive?
And don't think that I'm tooting my horn, SGI did this before they even
knew I existed, I had nothing to do with it. I just think it is really
impressive from a performance point of view. I'd say the same thing if
I was still working for Sun or anywhere else. I posted here because the
topic was relevent and I don't think that many people (outside of the
supercomputer crowd) are aware of the SGI capabilities.
--
---
Bryan Althaus
: Larry McVoy (415) 390-1804 l...@sgi.com
Larry,
Now growing up as a kid did you ever wonder why the other kids use
to kick the crap out of you? Well to let you in, its because your
an assh*le. Doesn't SGI have a Newsgroup?
Get a life you complete loser....
Sorry, but this guy is obviously one of those computer geeks that *always*
knows how to do something better of faster than you. I'm sure he was one
popular guy at SUN.
Robert Davies
personal slagging, out of it, guys?
I don't get upset, because Larry works for SGI, it's a compliment that he's still interested enough to contribute to the Solaris news group. Nobody has said that
SGI haven't done something interesting, Larry should be proud of what he's doing.
Let's face it Sun have real trouble with the SC 1000 at present.
As a result of my doubts about the Review, (a default configuration with too little
RAM seems to have been tested). I grabbed a copy of their modified SSBA benchmark
suite, and a copy of Bonnie from another server.
Perhaps somebody with SGI and Sun H/W could make a comparison, with similar disks?
I shall base my final judgement on my own comparison, Solaris 2 / SunOS 4.
What I can say is that about 20% of my hosts will definitely be having RAM
upgrades, and some others will be left to RIP.
As for home usage, I'm pondering between a PC with (Solaris 2, Linux or BSD), or
an LX running Solaris 2, I'll miss having SunOS 4 / ULTRIX around for all their
faults, but warts and all, I shall learn to love (to hate?) Solaris.
-- Rob
Thomas Fritz
-> In article q...@fido.asd.sgi.com, l...@slovax.engr.sgi.com (Larry McVoy) writes:
-> >SGI's MP's just blow the frigging doors off of Sun hardware &
-> >software. Sun may have more market share but they don't have a chance
-> >of competing with SGI in terms of I/O. SGI is at least a couple orders
-> >of magnitude faster. Sun doesn't stand a chance - if you care about
-> >I/O, you buy an SGI.
->
Well from our SGI DM system, we are getting in the area of 13 Megs Sec.
IO from / to their devices, and the Solaris 2.4 Sparc 1000E, with 20x the
ram, only 7 Megs per second (After days of tuning the kernel (was 5.5))
--tlf
-> Wow 500mb per second off a single disk. It's a wonder I even come
-> to work the way you've got this all figured out.
->
->
-> ---
-> =================================================================
-> | Kevin Clarke - Solaris Perf | "To err is human, |
-> | k...@Eng.Sun.COM | to moo bovine." |
-> =================================================================
->
Thomas Fritz
-> In article <3jne8t$8...@fido.asd.sgi.com>,
-> Larry McVoy <l...@slovax.engr.sgi.com> wrote:
-> ...... < deleted > ......
-> >........................................... By the way, lowercase
-> >"mb" normally means megabits and uppercase "MB" means megabytes. We're
-> >talking MB not mb.
-> >
-> ...... < deleted > ......
-> By the way, small m (as prefix) usually stands for "milli", so:
-> mb - millibits
-> mB - millibytes
-> Mb - megabits
-> MB - megabytes
-> :-)
8-0 - big byte!
-> Just passing by...
->
-> >Larry McVoy (415) 390-1804 l...@sgi.com
->
-> Dmitri.
John DiMarco
>Larry McVoy (l...@slovax.engr.sgi.com) wrote:
>: Oh, yeah, did I mention 80MByte/sec through one networking interface
>: running standard TCP/IP? Chuckle. I like my new job, SGI seems to
>: care about being fastest.
>Now growing up as a kid did you ever wonder why the other kids use
>to kick the crap out of you? Well to let you in, its because your
>an assh*le. Doesn't SGI have a Newsgroup?
>Get a life you complete loser....
Larry has a solid track record, and plenty of us think quite highly of his
work. "Complete loser" is the last thing I'd call him.
Abuse like this sticks much more readily to the abuser than the abused.
I wonder why you insist on making a fool of yourself in front of the entire
world, including possible future employers?
Regards,
John
--
John DiMarco <j...@cdf.toronto.edu> Office: EA201B
Computing Disciplines Facility Systems Manager Phone: 416-978-1928
University of Toronto Fax: 416-978-1931
http://www.cdf.toronto.edu/personal/jdd/jdd.html
Martin Cracauer
>Thomas Fritz (t5...@mail.isp.net) wrote:
>: For example, using a Sparc 1000E server with 1gb of ram, and two raid
>: 5 disk arrays(fast and wide). This system only gets 5megs per sec. xfer rate.
>: I pull the disk arrays, and put them on a SGI DM system (basic), and run the
>: same dd command (dd if=/dev/zero of=/array_mount_point/file.test bs=1024k
>: count=19531) which SGI gives about 14 megs per sec. xfer rate. So I called
>: Sun, and they thought that the 5megs per sec. was great! Great? I think
>: they need to have another look at the device drivers / kernel.
>:
>: Now, my Linux box using the same test gets 8megs per sec. It is a P5/90
>: system.
>Thanks for the SGI plug :-) I'll add to your fire. By way of background,
>I'm a kernel hacker that used to work at Sun and now works at SGI. This
>sort of I/O stuff is my area of expertise. You can discount my ravings
>because I work for SGI, but you should trust that I know what I'm talking
>about in this area; ask people, even Sun engineers will admit it :-)
>I can happily say that SGI blows the socks off of any Sun system in
>terms of disk or network I/O. I'm currently working on being able to
>do at least 50MB/sec disk <-> net <-> remote machine. I've done my own
>testing on SGI systems and I can get 18MB/sec per fast&wide SCSI
>string using just 3 disks. Sure wish I had 100MB/sec SCSI strings...
SGI's software and hardware may be good in principle, but sometimes
SGI's way has drawbacks. I bought a second fast-SCSI controller, only
to find out that is is much slower than the build-in-port and be told
that it is limited to about 5.5 MB/sec by design. Additionally, the
Indy has fewer free slots than a eqal-priced Sun and there are no
combined SCSI/Ethernet adapters, so this particular machine is
somewhat limited in it's I/O capabilities.
[...]
>But that's no big deal, get a load of this. SGI has a *file system*
>that goes that fast.
[...]
As of Irix-5.2 this filesystem was not capable of handling files with
holes. Maybe I shouldn't, but some of my programs use holely files for
performance and space reasons and that works quite good on other
machines.
>SGI's MP's just blow the frigging doors off of Sun hardware &
>software. Sun may have more market share but they don't have a chance
>of competing with SGI in terms of I/O. SGI is at least a couple orders
>of magnitude faster. Sun doesn't stand a chance - if you care about
>I/O, you buy an SGI.
But not a low-end-SGI. A Sun or SPARC-Clone with a comparable price as
a low-end-SGI with Compiler, NFS and additionaly SCSI controller is
better/faster from my experience.
>: -> It's not funny anymore.. Does anyone acutally like Solaris2?
For low-end machines (Indy-comparable - SPARC 5 or small SPARC-10
compatibles), one can still run SunOS-4.1.x when Solaris is disliked.
I might add that Solaris' filesystems are *not* slower than
SunOS-4.1.x' on my machines (no big servers). I found Solaris-2.4 to
be quite fast in services that are used by end-user applications like
networking and filesystems. The performance critique that comes up is
for multi-user, for shell utilities and the like.
>No. Never did, never will. It's part of why I left Sun.
No doubt, SGI's technical stuff has an attitude I like more. However,
some of your manangers makes life for small customers harder, at least
compared to SPARC clone vendors.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Private email Martin....@wavehh.hanse.de Fax +4940 522 8536. No NeXTMail!
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway" - Calvin
Alan Cox
>>Having spent a depressing few hours looking at all the latest Solaris 2.4,
>>bugs and patches, and broken patches....
>>Is it Sys V rel 4 thats slow and unreliable, or have Sun broken it?
>I'm not sure what you did or on what hardware. We find Solaris 2.3/2.4
>very reliable. It also feels faster than SunOS 4.1.x.
Sunsite europe hasnt worked properly since they moved to Solaris. Last
weekend and monday it was down while they figured out why the Solaris 2.4
upgrade didnt have the desired effects...
>hardware? Solaris 2.x handles a lot more things than linux does and
>that has some disadvantage. Almost all executables need to load
[Activate salesman hat]
Can it run Descent in a DOS emulator window yet. Does it have loadable
filesystems, checksummmed version independant modules, does it have
loadable MAC 1.44Mb floppy disk support, or a tar with multivolume support.
AX.25 networking modules ? (do you care ?)
[Return to human form]
>atleast 4 dynamic libraries, which is slow. So the relative
Why is it slow. Who designed the dynamic library loader, have they been
fired. Speed loss is speed loss in any OS wherever it is.
>overhead of starting an application in Solaris 2.x is huge.
So fire the programmers and do it right.
>But this overhead is required for the support of libintl and libw which
>need the capability of dynamic linking.
Many systems have ultra fast dynamic linking.
>Solaris 2.x also has much more stuff in the kernel than Linux and
>some of it is much faster/better than Linux (networking/NFS)
Their networking in 2.4 is definitely very much better. Its very fast
its very neat, but it still has bugs and RFC violations. (I dont claim
to be better!).
>But I really wonder about these benchmarks. A lot of people have
>reported that Linux degrades very badly under load, which is something
>we don't notice on Solaris 2.x.
Correct. On the other hand Linux doesn't forget 'nice' slowly over time ;)
With the Linux development kswap diffs Im seeing good degrading now. More
scheduler work needed but no quibbles with the comment.
>We don't have much problems with 16MB machines. But you are confused.
>Solaris 2.x does require more memory but it *is* faster with sufficient
>memory (4-8MB more than SunOS 4.1.x)
So Solaris with 8Mb more than SunOS runs a bit quicker. Isn't this a little
like saying SCO on a P90 runs faster than unixware on a 386DX33 ???
I run a Sun 4/260 that has in various jobs averaged 120 continual network
connections for 18 hour periods and never crashed once the getpeername()
patch got applied. 20 local users, 80-90 irc users, a mud, a couple of
other chat type programs all in 24Mb. I wouldnt dare try running Solaris2.x
on it.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`--[Anti Kibozing Signature]-'`----------------------------''
One two three: Kibo, Lawyer, Refugee :: Green card, Compaq come read me...
Casper H.S. Dik
>[Activate salesman hat]
>Can it run Descent in a DOS emulator window yet. Does it have loadable
>filesystems, checksummmed version independant modules, does it have
>loadable MAC 1.44Mb floppy disk support, or a tar with multivolume support.
>AX.25 networking modules ? (do you care ?)
>[Return to human form]
Solaris 2.x can rn a decent DOS emulator, it doesn't come for free.
It has loadable anything (filesystems, device drivers, systemcalls,
everything can be made laodable). GNU tar is available too.
>Why is it slow. Who designed the dynamic library loader, have they been
>fired. Speed loss is speed loss in any OS wherever it is.
True enough. The starup-overhead of Solaris 2.x programs is simple
too big and it needs to be fixed.
>Many systems have ultra fast dynamic linking.
Name one. And tell us how they do it.
>Their networking in 2.4 is definitely very much better. Its very fast
>its very neat, but it still has bugs and RFC violations. (I dont claim
>to be better!).
Which RFC violations? It implements more RFCs which cuases headaches
for a lot of older implementations.
>So Solaris with 8Mb more than SunOS runs a bit quicker. Isn't this a little
>like saying SCO on a P90 runs faster than unixware on a 386DX33 ???
No. The internationalisations makes a lot of stuff heavier in Solaris 2.x
compared to SunOS 4.1.x, it is one of the reasons extra memory is required.
If I had said "Solaris 2.x runs faster on an SS10/61 than SunOS 4.1.x on
a SS1", then you would have had a point.
>I run a Sun 4/260 that has in various jobs averaged 120 continual network
>connections for 18 hour periods and never crashed once the getpeername()
>patch got applied. 20 local users, 80-90 irc users, a mud, a couple of
>other chat type programs all in 24Mb. I wouldnt dare try running Solaris2.x
>on it.
I wouldn't run such old beasts under 2.4 either as it drops FP support
for it. We don't have Solaris 2.x machines crashing on us either, though.
Multi-user performance does seem to have come last in the Solaris 2.x
performance improvements: Desktop, network and NFS server performance
seem to have been much more important and have gotten all or most of
the attention between 2.1 and 2.4. This is not too surprising since
large interactive shell multi-user machines are not all to common.
E.g., out of 150 suns here, we have only one machines that is used
by really many users at the same time.
Now that the first priorities have had their fair share of attention,
a lot of effort in 2.5 is put into multi-user performance.
But for some people that is three releases too late. (People who
bought brand-new SS2000s w/ Solaris 2.2)
Casper
Bryan Althaus
: b...@netcom.com (Bryan Althaus) writes:
: >Get a life you complete loser....
: Larry has a solid track record, and plenty of us think quite highly of his
: work. "Complete loser" is the last thing I'd call him.
I'm sure his "work" is top notch. Do you really think I believe one could
get a job at both SUN and SGI doing kernel work if they weren't Bright and
did a good job?
My comment is aimed solely at his tacklessness. Larry works for SGI yet
he's posting in a SUN group, with a @sgi.com address. That he once worked
for SUN means he is walking on even thinner ice.
When he posts statements of the nature that he does, It's fair to say that
he might be looking for a reply back from some of his former workers
@Eng.Sun.Com.
Message-ID: <3jne8t$8...@fido.asd.sgi.com> l...@slovax.engr.sgi.com(Larry McVoy)
And, given the independently verified performance numbers, I can
understand that Sun performance engineers would want to just give up...
Oh, yeah, did I mention 80MByte/sec through one networking interface
running standard TCP/IP? Chuckle. I like my new job, SGI seems to
care about being fastest.
Did you ever read Larrys posts on how SGI does rigorous testing of their OS
yet SUN barely does any? He talks about when he was at SUN what they did
as if it was complete fact.
Stuff like the above should be kept to email not a newsgroup.
: Abuse like this sticks much more readily to the abuser than the abused.
: I wonder why you insist on making a fool of yourself in front of the entire
: world, including possible future employers?
It's called a knee jerk reaction. Due from bias from his other posts. I'm
sure the world will forgive me. As for future employers, I work for the best
company on Wall St. with no want to leave. If I ever do leave I will hope
future employers will understand.
I do regret my wording but being at home with a broken arm on pain killers
will unfortunately do wonders for your vocabulary.
We all do things we regret later.
: John
: --
: John DiMarco <j...@cdf.toronto.edu> Office: EA201B
: Computing Disciplines Facility Systems Manager Phone: 416-978-1928
: University of Toronto Fax: 416-978-1931
: http://www.cdf.toronto.edu/personal/jdd/jdd.html
--
Regards,
Bryan Althaus b...@netcom.com
Robert Davies
> Did you ever read Larrys posts on how SGI does rigorous testing of their OS
> yet SUN barely does any? He talks about when he was at SUN what they did
> as if it was complete fact.
Oh, I thought we (the customers) did the testing, you mean they do that to?
;)
Jeff Bacon
: >Why is it slow. Who designed the dynamic library loader, have they been
: >fired. Speed loss is speed loss in any OS wherever it is.
: True enough. The starup-overhead of Solaris 2.x programs is simple
: too big and it needs to be fixed.
I can't believe they got rid of the ld.so cache, esp with all those
damn shlibs. (I can't believe that they have to have so
damn many of them either.)
I think what annoys me a lot is the name-switch stuff. every time
you make a call to a get*(), it reads /etc/netconfig and opens at least
two shared objects... to do a gethostbyname()??? most people don't
go changing nsswitch.conf all the time...so why all the overhead?
: >I run a Sun 4/260 that has in various jobs averaged 120 continual network
: I wouldn't run such old beasts under 2.4 either as it drops FP support
: for it. We don't have Solaris 2.x machines crashing on us either, though.
why not? in many apps, FP just isn't required.
I run 2.4 on a 4/330 with no real ill effects.
it's just a matter of having enough memory so things can breathe.
: Multi-user performance does seem to have come last in the Solaris 2.x
: ...
: E.g., out of 150 suns here, we have only one machines that is used
: by really many users at the same time.
well, yeah, that's the idea - fewer machines, but more users use them...
-bacon
--
= Jeff Bacon General Systems Hack, Michigan Technological Univ. =
= ba...@mtu.edu ph-(906)487-2197 fax-(906)487-2782 DoD#2110 I'm the NRA =
= Any war is a major war when you're the one being shot at. =
Casper H.S. Dik
>I can't believe they got rid of the ld.so cache, esp with all those
>damn shlibs. (I can't believe that they have to have so
>damn many of them either.)
Why does that matter? The Solaris 2.x library search mechanism
no longer has to take minor version numebrs into account.
Since all libraries have a fixed name, all ld.so has to do is:
for each lib in list
for each dir in search path
try to open $dir/$lib
In the trivial case this boils down to:
for each lib in list
try open /usr/lib/$dir
In SunOS 4.1.x, if there where directories to be searched by compiled
in paths (-L) or the LD_LIBRARY_PATH option, the algorithm was:
for each lib.major in list
for each dir
opendir(),
get-all-direntries
find entry with highest minor version number
The ld.so.cache was *only* used for /usr/lib libraries and only in
after searching ay compiled in or runtime specified directories.
There is no longer a gain in maintaining an ld.so.cache, unless you
count the ability to add directories to the cache.
>I think what annoys me a lot is the name-switch stuff. every time
>you make a call to a get*(), it reads /etc/netconfig and opens at least
>two shared objects... to do a gethostbyname()??? most people don't
>go changing nsswitch.conf all the time...so why all the overhead?
I only see it opening netconfig/nsswitch.conf once. (Using truss)
>why not? in many apps, FP just isn't required.
>I run 2.4 on a 4/330 with no real ill effects.
>it's just a matter of having enough memory so things can breathe.
Ah, but on the 4/330 the FP is used. But you're right, FP isn't
required for many things.
Casper
Jeff Bonwick
>I can't believe they got rid of the ld.so cache
Either our linker group or me (whoever gets the cycles first) is
planning to address this. We recognize that dynamic linking overhead
is a problem, especially for commonly-used libraries. With a little
cooperation between the linker and kernel it should be possible to
make this dirt cheap.
>I think what annoys me a lot is the name-switch stuff. every time
>you make a call to a get*(), it reads /etc/netconfig and opens at least
>two shared objects... to do a gethostbyname()??? most people don't
>go changing nsswitch.conf all the time...so why all the overhead?
This is fixed in Solaris 2.5 by the nscd (name service cache daemon).
A call to gethostbyname() turns into a door_call() to the nscd.
(Doors are a fast local IPC mechanism, also new in 2.5.) The nscd
keeps a cache of various getXbyY() mappings and consults the underlying
name service only on cache misses. This reduces latency from tens of
milliseconds (under good network conditions) to tens of microseconds
(consistently). It also improves the effective scalability of the
underlying name service because you just don't stress it as much.
If you're using YP or NIS+ this cuts your network traffic quite a bit.
It's even helpful for local files (e.g. /etc/passwd) because it's much
cheaper to do a simple hash lookup than to parse /etc/nsswitch.conf and
/etc/passwd each time -- especially for large passwd/group/hosts files.
Jeff Bonwick
Solaris Performance
Dave Madison (nophone)
I am interested in setting up my home pc with Informix Database which
runs on a UNIX environment. I know that Informix will work with
SCO Unix but I am not really interested in paying for SCO. Does anyone
know if Informix is compatible with Linux. OR is Linus compatible with
SCO Unix products?
Any insight will be greatly appreciated!
Thanks in advance!
Stuart Marks
> for it.
In article <3k8hco$m...@minerva.doe>, ba...@mtu.edu (Jeff Bacon) writes:
> why not? in many apps, FP just isn't required.
It's true that FP isn't required for many things. However,
when it is required, emulation is orders of magnitude slower
than hardware. This may result in a noticeable slowdown.
I had occasion to run Solaris 2 on an old SparcStation 1 prototype
machine that was equipped with a preliminary FP unit. The OS
detected the old FP hardware and disabled it. For many things like
moving windows, typing in terminal emulators, etc. performance
was adequate. When I ran an awk or perl script, however,
performance virtually ground to a halt! (This is because awk and
perl use floating point for all arithmetic.) FP wasn't used very
much, but where it was it slowed things down so much as to make
the machine unusable. If it weren't for FP performance, the machine
would have been OK.
Note that this was a prototype SparcStation 1. Any production SS1's
should have an FPU that is supported under Solaris 2.
s'marks
--
Stuart W. Marks stuart...@eng.sun.com
Common Desktop Environment 2550 Garcia Ave. M/S UMTV 21-122
SunSoft, Inc. Mountain View, CA 94043-1100
Jeff Bacon
: >damn shlibs. (I can't believe that they have to have so
: >damn many of them either.)
: Why does that matter? The Solaris 2.x library search mechanism
: no longer has to take minor version numebrs into account.
: for each lib in list
: try open /usr/lib/$dir
agreed. but that still adds to a lot of open() calls, especially when
there is a run path or lib path in effect, which I'd wager is
more often the case than not.
I'm nitpicking, I know. I merely find it annoying, cause I don't
find it terribly elegant. it also adds a lot of system call overhead
and filesystem access (even if in dnlc cache), which I would tend to
think slows everything down.
: The ld.so.cache was *only* used for /usr/lib libraries and only in
: after searching ay compiled in or runtime specified directories.
: There is no longer a gain in maintaining an ld.so.cache, unless you
: count the ability to add directories to the cache.
which I definitely count.
: >I think what annoys me a lot is the name-switch stuff. every time
: >you make a call to a get*(), it reads /etc/netconfig and opens at least
: >two shared objects... to do a gethostbyname()??? most people don't
: >go changing nsswitch.conf all the time...so why all the overhead?
: I only see it opening netconfig/nsswitch.conf once. (Using truss)
accepted. however, I guess I look at it from the sense of
once-per-process - and on an xterm server serving 30 or 40 active
users, that adds to a lot of processes, and a lot of wasted breath.
again, I'm nitpicking. in comparison, some of the things I have
watched WordPerfect do make me completely sick.
I am certainly not going to stop using solaris because of it -
amazing but true, you'd never get me to switch back now.
-bacon
Larry McVoy
While I think Brian's comments were a bit unreasonable, so were mine.
I shouldn't have taken a cheap shot at Sun - there are a lot of good
people working their tails off there. I was really trying to jab at
the Sun culture that makes Sun engineers lives difficult, not at the
engineers themselves. I used to work there, I know how hard it is to
do good work in that environment. I certainly didn't intend to make it
worse but that seems to be the case. For that, I apologize.
--lm
John DiMarco (j...@cdf.toronto.edu) wrote:
: b...@netcom.com (Bryan Althaus) writes:
: Regards,
--
---
Jeff Bacon
: Either our linker group or me (whoever gets the cycles first) is
: planning to address this. We recognize that dynamic linking overhead
: is a problem, especially for commonly-used libraries.
: This is fixed in Solaris 2.5 by the nscd (name service cache daemon).
: A call to gethostbyname() turns into a door_call() to the nscd.
I stand corrected. well, ok, unannoyed.
glad to see someone in there does care, unlike the picture
Larry would paint.
-bacon
though I admit that my solution to the solaris speed problem
was to throw a dualproc SS20 at it. :)
Larry McVoy
: My comment is aimed solely at his tacklessness. Larry works for SGI yet
: he's posting in a SUN group, with a @sgi.com address. That he once worked
: for SUN means he is walking on even thinner ice.
Actually, the comments were cross posted to a Linux newsgroup - I'm more
interested in Linux these days - it has more market share than Sun.
: And, given the independently verified performance numbers, I can
: understand that Sun performance engineers would want to just give up...
:
: Oh, yeah, did I mention 80MByte/sec through one networking interface
: running standard TCP/IP? Chuckle. I like my new job, SGI seems to
: care about being fastest.
I think you took this the wrong way (although, I can see how in
rereading it, it is tackless in the extreme).
The point that I was trying to make is somewhat less inflammatory: Sun
has split itself into the software side (SunSoft) and the hardware side
(SMCC). The software people had a dream of making tons of money off of
Solaris on x86 (and PowerPC and ...). Consequently, the SPARC people
kind of felt like SunSoft would like to abandon them at the first
possible opportunity since SPARC performance hasn't been at the top of
the heap for a while.
This seperation lead to a lack of the kind of intense communication and
cooperation that is necessary in order to build fast *systems*. In
order to get 90MB/sec through the network and 400MB/sec through the
disks, the hardware and software people need to meet, agree on some
goals, hash out how it is to be done, and go do it. That is a hard
thing to do if the software people work for one company and the
hardware people work for another company.
If I had said all that and then said "jeez, I can see how perf people
would want to give up" could you believe that I wasn't attacking them,
I was attacking the intractable situation? Of course, I didn't give
you the preamble, I was just thinking it so how could you know?
I was saying that I liked my new job because SGI cares enough about
performance to make sure that the right people talk and work together.
SGI works very hard to make sure that the engineers know what is going
on and that they stay focussed on cool, fast technology. That's nice,
that's all I was saying.
: Did you ever read Larrys posts on how SGI does rigorous testing of their OS
: yet SUN barely does any? He talks about when he was at SUN what they did
: as if it was complete fact.
Whoa there, my friend. I haven't been at SGI long enough to know how
they do their testing. I'm fairly sure that I wouldn't have said "SGI
does rigorous testing of their OS yet SUN barely does any". And I
didn't say Sun does barely any. I said that Sun's testing is largely
use it and fix what breaks in alpha/beta and ship the result. My point
on that thread was that people were claiming that venders do far better
testing on their OS than the Linux crowd does on their OS -- I was
pointing out that they were giving the venders more credit than was
their due (or Linux less, take your pick).
And the "complete fact" comment I don't understand. Should I talk
about my years at Sun as if they were complete fantasy? Lemme tell
you, if that is what the fantasy world is like, I'll stick to reality...
: We all do things we regret later.
Yeah, no kidding.
--
---
Larry McVoy
: SGI's way has drawbacks. I bought a second fast-SCSI controller, only
: to find out that is is much slower than the build-in-port and be told
: that it is limited to about 5.5 MB/sec by design. Additionally, the
: Indy has fewer free slots than a eqal-priced Sun and there are no
: combined SCSI/Ethernet adapters, so this particular machine is
: somewhat limited in it's I/O capabilities.
If you are using a desktop and you want serious I/O, you bought the
wrong machine. To get screaming I/O, you buy an I/O server. SGI's
I/O servers (challenge MP systems) are built to go fast. And they do.
: >But that's no big deal, get a load of this. SGI has a *file system*
: >that goes that fast.
: [...]
: As of Irix-5.2 this filesystem was not capable of handling files with
: holes. Maybe I shouldn't, but some of my programs use holely files for
: performance and space reasons and that works quite good on other
: machines.
The file system is new (option with 5.3, bundled with 6.1); it's called
xFS. I think it supports holes just fine. EFS, which is what you are
using, doesn't support holes. Get your rep to upgrade you.
: But not a low-end-SGI. A Sun or SPARC-Clone with a comparable price as
: a low-end-SGI with Compiler, NFS and additionaly SCSI controller is
: better/faster from my experience.
OK, if you are talking low end, then go compare to a PC running one of
the free Unix OS's out ther. I think you are far better off spending
your money on reusable PC hardware than Sun hardware or SGi hardware if
you want low end. We were discussing high end, big dollars, high
performance systems.
: No doubt, SGI's technical stuff has an attitude I like more. However,
: some of your manangers makes life for small customers harder, at least
: compared to SPARC clone vendors.
Well, if SGI is making life hard for you then send me mail and if I can help,
I will. Fair enough?
Casper H.S. Dik
>: for each lib in list
>: try open /usr/lib/$dir
>agreed. but that still adds to a lot of open() calls, especially when
>there is a run path or lib path in effect, which I'd wager is
>more often the case than not.
(On a point of principle: LD_LIBRARY_PATH should never be set)
But that is no difference from SunOS 4.1.x. Besides, it doesn't
add a *lot* of open calls, at most <ndirectories - 1> * <nlibs>.
And failed open calls aren't really that expensive.
I'm more concerned with the huge amoutn of mmaps en munmaps that
is done for each library.
>I'm nitpicking, I know. I merely find it annoying, cause I don't
>find it terribly elegant. it also adds a lot of system call overhead
>and filesystem access (even if in dnlc cache), which I would tend to
>think slows everything down.
It doesn't add file access when compared to SunOS 4.1.x.
Some sort of cache might be nice, but the implementation
can't just be copied from SunOS 4.1.x. The SunOS 4.1.x
cache was needed for finding /usr/lib libraries faster.
However, in Solaris 2.x, all it takes to find a library in /usr/lib
is one open().
Casper
Jeff Bacon
: >there is a run path or lib path in effect, which I'd wager is
: >more often the case than not.
: (On a point of principle: LD_LIBRARY_PATH should never be set)
ideally.
unfortunately, the world isn't an ideal place...
: I'm more concerned with the huge amoutn of mmaps en munmaps that
: is done for each library.
there's that too. but how do you get rid of those without
getting rid of shlibs entirely? hardwire the shlib's addresses in memory
a la VM/CMS shared segments, then copy-on-write against that?
(don't look at me, I'm no expert here)
: Some sort of cache might be nice, but the implementation
: can't just be copied from SunOS 4.1.x.
agreed.
like I said, it was nitpicking.
Michael knigge
: I am interested in setting up my home pc with Informix Database which
: runs on a UNIX environment. I know that Informix will work with
: SCO Unix but I am not really interested in paying for SCO. Does anyone
: know if Informix is compatible with Linux. OR is Linus compatible with
: SCO Unix products?
Hi!
You have to install the iBCS-Package and Informix will run fine ;-)
Bye
Michael
--
-----------------------------------------------------------------------
--- Michael Knigge eMail: kn...@cove.han.de ---
-----------------------------------------------------------------------
Bryan Althaus
: Thanks for the kind words, John. It's nice when people are nice.
: While I think Brian's comments were a bit unreasonable, so were mine.
: I shouldn't have taken a cheap shot at Sun - there are a lot of good
: people working their tails off there. I was really trying to jab at
: the Sun culture that makes Sun engineers lives difficult, not at the
: engineers themselves. I used to work there, I know how hard it is to
: do good work in that environment. I certainly didn't intend to make it
: worse but that seems to be the case. For that, I apologize.
: --lm
I just want to apologize for my poor attempt at a post. The language used
was overkill and uncalled for. Trust me when I say I was on pain killers.
A "bit unreasonable" is very kind.
I have learned one thing from this. I will now wait a day to cool off
before ever replying to posts off this sort, more if I'm on pain killers :)
Also, the newsgroup comp.os.linux has not existed for about a year
in most areas being replaced by comp.os.linux.* so I wrongly assumed you
were reading comp.unix.solaris.
Anyway, not that your not allowed to access this group. I and alot of other
Solaris people like your posts because bringing up problems is one way to get
them fixed, its just that each post always seemed to have a jab or two aimed
at Sun or your former engineers at SUN.
I just was sticking up for some of the @Eng.Sun.Com people who have personally
helped me over the last year, and who I knew could not respond to your
posts in this newsgroup.
Anyway life goes on....
--
Regards,
Bryan Althaus
Jens-Uwe Mager
In article <3k8rdh$7...@engnews2.Eng.Sun.COM> (comp.unix.solaris,comp.unix.sys5.r4,comp.os.linux), bon...@cathy.Eng.Sun.COM (Jeff Bonwick) writes:
> (Doors are a fast local IPC mechanism, also new in 2.5.)
Are there any papers on that doors facility? This sounds pretty
interesting.
______________________________________________________________________________
Jens-Uwe Mager j...@anubis.han.de
30177 Hannover j...@helios.de
Brahmsstr. 3 Tel.: +49 511 660238
Casper H.S. Dik
>Failure to report an ICMP error on an unconnected UDP socket doing a sendto.
>Reported in Solaris 2.1 (and back to SunOS 3.5 even). Still not fixed. Its not
>even one that the 'backward compatibility' excuse applies to. Using old RFC793
>urgent pointers is different (everyone does it). Still I suppose we should
>applaud that fact that with Solaris 2 they finally shipped a machine with
>ntalkd not the broken original talkd and with the right broadcast address.
ICMP error message are reported back in SunOS 4.x, they aren't
in Solaris 2.x and that is bad.
Solaris 2.x still ships with the old talkd, last I looked, but with
the right broadcast address. The Old urgent pointers can be turned
off as well.
Casper
Alan Cox
>Solaris 2.x can rn a decent DOS emulator, it doesn't come for free.
Thats a downer, as is the cost of compilers, multi user option. And source
code for the kernel seems to be out. Does the Solaris Dos emulator run
Descent and Heretic yet 8)
>It has loadable anything (filesystems, device drivers, systemcalls,
>everything can be made laodable). GNU tar is available too.
But no MAC HFS filesystem. In fact CAP still doesnt work well for
remote mac file serving under Solaris 2.4, and netatalk is not an option
either.
>>Many systems have ultra fast dynamic linking.
>Name one. And tell us how they do it.
Have a look at oberon for an abstract but very beautiful example. Or most
BCPL programs. Other systems have used link-caching, so that the binary
knows what library versions(precisely) and what address the library was at.
If it doesnt match you redo the cache if it does match its a run down
an offset chain adding the library base address. There is no point paying
the cost of linking ls every time you run it
[Purely an aside, my personal opinion is that things like elf are evil
and shared libraries are used too often to justify slow link times against
them].
>>Their networking in 2.4 is definitely very much better. Its very fast
>>its very neat, but it still has bugs and RFC violations. (I dont claim
>>to be better!).
>Which RFC violations? It implements more RFCs which cuases headaches
>for a lot of older implementations.
Failure to report an ICMP error on an unconnected UDP socket doing a sendto.
Reported in Solaris 2.1 (and back to SunOS 3.5 even). Still not fixed. Its not
even one that the 'backward compatibility' excuse applies to. Using old RFC793
urgent pointers is different (everyone does it). Still I suppose we should
applaud that fact that with Solaris 2 they finally shipped a machine with
ntalkd not the broken original talkd and with the right broadcast address.
>No. The internationalisations makes a lot of stuff heavier in Solaris 2.x
>compared to SunOS 4.1.x, it is one of the reasons extra memory is required.
>If I had said "Solaris 2.x runs faster on an SS10/61 than SunOS 4.1.x on
>a SS1", then you would have had a point.
Ok that sounds a reasonable answer. I've never run a big enough machine to
try SunOS 4.1.x 64Mb against Solaris 2.x 64Mb with all the memory in real
(working set) use.
Thomas Fritz
->
-> > Did you ever read Larrys posts on how SGI does rigorous testing of their OS
-> > yet SUN barely does any? He talks about when he was at SUN what they did
-> > as if it was complete fact.
->
-> Oh, I thought we (the customers) did the testing, you mean they do that to?
Well I did the testing which I did for the company which I contract for, which
I did post. It is up to the company (Sun Soft) to make sure that the OS is
stable. Look for bottle neck problems, and _IF_ (and only if), then it would be
up to Sun Soft, to fix this problem. Sun Soft, should also look at the Specs,
and see if the diff is too much, and if it is, fix it. That is why we (paying
customer + programmers) pay so much for "updates" and support.
We as customers need to make it real clear to those who make software (Sun Soft)
that we will not take poor work, proformance. It is our (companys), who make
the choice between Sun, IBM, SGI, or what ever. If we don't like the speed,
we go some where else.
--tlf
->
->
->
-> ;)
->
Hugh LaMaster
[About multi-user test results.]
Could you describe the nature of the benchmark? I agree that Solaris 2.4
is a little slower than average, but the effect you show is rather more
extreme that what I have measured. Also, in my experience, Solaris 2.4
does do better in situations when some other systems start to thrash.
It may be that this benchmark, which seems to be CPU-bound, exercises
something in Solaris 2.4 x86 which is unusually slow for some reason.
Any ideas?
>> On the machines below the AT 486-50 had 20MByte ram, the 486-66 had 32MByte
>> ram, (both with 256K cache) and the 386-25 had 8Mbyte ram (and 128K cache).
>>
>> machine unix-version 2 5 8 11 13 15
[table deleted}
>> These number lead to a very simple conclusion: for multiuser (multitasking)
>> Solaris reduces the speed of a PC-class machine to about 1/3 of the speed
>> the same machine achieves with other versions of Unix.
>>
>> Or, in still other words: a 486-66 with Solaris is about as fast as a
>> 386-25 was, 5 years ago.
Your results look interesting, but I don't know how to interpret
them without knowing what the benchmark does. Since the scale-up
is almost linear, it appears to be CPU-bound. Is the benchmark
system-call heavy, utility heavy, or user-program heavy?
--
Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster
NASA Ames Research Center Internet: lama...@ames.arc.nasa.gov
Moffett Field, CA 94035-1000 Or: lama...@george.arc.nasa.gov
Phone: 415/604-1056 #include <std_disclaimer.h>
Juergen Keil
(Hugh LaMaster) writes:
> Could you describe the nature of the benchmark?
Since the 'multi-user' benchmark (a modified version of a benchmark
that was published in the Byte magazine (1984)) is so short, I've
appended it as a shell archive below.
Here are some results for SunOS 4.1.1 and SunOS 5.4 runnning on a SS2:
sunos5 113% /bin/time mp_multi.sh 1
real 1.5
user 0.3
sys 0.8
sunos5 114% /bin/time mp_multi.sh 4
real 5.4
user 1.3
sys 2.8
sunos5 115% /bin/time mp_multi.sh 8
real 10.2
user 2.3
sys 5.7
sunos5 116% /bin/time mp_multi.sh 16
real 20.0
user 4.9
sys 11.2
sunos4 4% /bin/time mp_multi.sh 1
1.5 real 0.1 user 0.6 sys
sunos4 5% /bin/time mp_multi.sh 4
3.5 real 0.3 user 1.8 sys
sunos4 6% /bin/time mp_multi.sh 8
6.5 real 0.6 user 3.7 sys
sunos4 7% /bin/time mp_multi.sh 16
13.0 real 1.3 user 7.5 sys
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: mp_multi.sh mp_tsh.sh
# Wrapped by jk@leo on Thu Mar 30 18:30:51 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f mp_multi.sh -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"mp_multi.sh\"
else
echo shar: Extracting \"mp_multi.sh\" \(180 characters\)
sed "s/^X//" >mp_multi.sh <<'END_OF_mp_multi.sh'
X#!/bin/sh
X#
X# Script : multi.sh
X#
Xif [ -r starter ] ; then
X rm -f starter
Xfi
Xmknod starter p
X
Xi=1
Xwhile [ $i -le $1 ]
Xdo
X /bin/sh mp_tsh.sh &
X i=`expr $i + 1`
Xdone
Xwait >> starter
END_OF_mp_multi.sh
if test 180 -ne `wc -c <mp_multi.sh`; then
echo shar: \"mp_multi.sh\" unpacked with wrong size!
fi
chmod +x mp_multi.sh
# end of overwriting check
fi
if test -f mp_tsh.sh -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"mp_tsh.sh\"
else
echo shar: Extracting \"mp_tsh.sh\" \(264 characters\)
sed "s/^X//" >mp_tsh.sh <<'END_OF_mp_tsh.sh'
X#!/bin/sh
X#
X# Script : tsh.sh
X#
Xexec < starter
Xsort >sort.$$ <</*EOF 2>>mp_byte.jou
XNow
Xis
Xthe
Xtime
Xfor
Xall
Xgood
Xmen
Xto
Xcome
Xto
Xthe
Xaid
Xof
Xtheir
Xcountry
X/*EOF
Xod sort.$$ | sort -n +1 >od.$$
Xgrep the sort.$$ | tee grep.$$ | wc >wc.$$
Xrm sort.$$ grep.$$ od.$$ wc.$$
END_OF_mp_tsh.sh
if test 264 -ne `wc -c <mp_tsh.sh`; then
echo shar: \"mp_tsh.sh\" unpacked with wrong size!
fi
chmod +x mp_tsh.sh
# end of overwriting check
fi
echo shar: End of shell archive.
exit 0
--
Juergen Keil j...@tools.de ...!{uunet,mcsun}!unido!tools!jk
Paul De Bra
Hugh LaMaster <lama...@viking.arc.nasa.gov> wrote:
>de...@wsinis04.win.tue.nl (Paul De Bra) wrote:
>Could you describe the nature of the benchmark? I agree that Solaris 2.4
>is a little slower than average, but the effect you show is rather more
>extreme that what I have measured. Also, in my experience, Solaris 2.4
>does do better in situations when some other systems start to thrash.
>It may be that this benchmark, which seems to be CPU-bound, exercises
>something in Solaris 2.4 x86 which is unusually slow for some reason.
the test runs a number of shell scripts in parallel.
the shell script contains:
sort > sort.$$ <</*EOF
Now
is
the
time
for
all
good
men
to
come
to
the
aid
of
their
country
[same text repeated until the entire file is 806 lines long]
/*EOF
od sort.$$|sort -n +1 > od.$$
grep the sort.$$|tee grep.$$|wc>wc.$$
rm sort.$$ grep.$$ od.$$ wc.$$
On this test Solaris x86 2.1 and 2.4 appear to be about 3 times slower
than Esix 4.0.4 or AT&T sVr4.0, on the same machine.
Paul.
Denton Gentry
In article <3los1o$s...@wsinis04.win.tue.nl>, de...@wsinis04.win.tue.nl (Paul De Bra) writes:
>the test runs a number of shell scripts in parallel.
>the shell script contains:
>
>sort > sort.$$ <</*EOF
>Now
>is
>the
>time
>for
>/*EOF
>od sort.$$|sort -n +1 > od.$$
>grep the sort.$$|tee grep.$$|wc>wc.$$
>rm sort.$$ grep.$$ od.$$ wc.$$
>
>On this test Solaris x86 2.1 and 2.4 appear to be about 3 times slower
>than Esix 4.0.4 or AT&T sVr4.0, on the same machine.
sort in Solaris is internationalized. That means if you are running in the "C" locale, each ASCII char read in is converted to a 4 byte wchar, then gets sorted according to the locale. I am not certain that base SVr4.0 does this; extrapolating that everything in Solaris is 1/3rd the speed of Esix 4.0.4 based on this result is highly questionable.
I also find it surprising that 2.1 and 2.4 seem to have gotten the same result in your benchmark, since /usr/bin/sort sped up by a factor of 2X in 2.4 over 2.1.
Denny
Bruce Adler [Contractor]
Paul De Bra <de...@wsinis04.win.tue.nl> wrote:
>
>the test runs a number of shell scripts in parallel.
>the shell script contains:
>
>sort > sort.$$ <</*EOF
>[same text repeated until the entire file is 806 lines long]
>/*EOF
>od sort.$$|sort -n +1 > od.$$
>grep the sort.$$|tee grep.$$|wc>wc.$$
>rm sort.$$ grep.$$ od.$$ wc.$$
>
>On this test Solaris x86 2.1 and 2.4 appear to be about 3 times slower
>than Esix 4.0.4 or AT&T sVr4.0, on the same machine.
I think your benchmark incorrectly assumes that all flavors of Unix
systems have the same or comparable sort, grep, wc, and grep programs.
You've also incorrectly assumed that your script accurately models an
some sort of typical Unix users system usage.
What you're really measuring is the relative performance of the
implementations of these commands, not the relative performance of the
Unix kernels. Is that what you meant to measure?
I know that on Solaris the support for the locale features added
significant overhead to these commands. Do all the other systems you
benchmarked also support the locale features? Perhaps you should try a
benchmark which runs the *identical* programs on the target systems.
BA
Juergen Keil
Adler [Contractor]) writes:
> In article <3los1o$s...@wsinis04.win.tue.nl>,
> Paul De Bra <de...@wsinis04.win.tue.nl> wrote:
> >
> >the test runs a number of shell scripts in parallel.
> >the shell script contains:
> >
> >sort > sort.$$ <</*EOF
> > ...
> >[same text repeated until the entire file is 806 lines long]
> >/*EOF
> >od sort.$$|sort -n +1 > od.$$
> >grep the sort.$$|tee grep.$$|wc>wc.$$
> >rm sort.$$ grep.$$ od.$$ wc.$$
> >
> >On this test Solaris x86 2.1 and 2.4 appear to be about 3 times slower
> >than Esix 4.0.4 or AT&T sVr4.0, on the same machine.
Note: The script Paul De Bra has posted was his own version of this
test, the german iX magazine actually uses a version that only sorts
16 lines of text (a whopping amount 69 bytes!)
See the other article I've posted some time ago which includes iX's
version of the scripts.
The complete benchmark is available i.e. on
ftp://germany.eu.net/pub/comp/ix-magazin/benches/ix_ssba/IX_SSBA.tar.gz
> I think your benchmark incorrectly assumes that all flavors of Unix
> systems have the same or comparable sort, grep, wc, and grep programs.
> You've also incorrectly assumed that your script accurately models an
> some sort of typical Unix users system usage.
>
> What you're really measuring is the relative performance of the
> implementations of these commands, not the relative performance of the
> Unix kernels. Is that what you meant to measure?
This is perhaps not what iX intends to measure, but actually they
publish /bin/time timings of n parallel runs of this shellscript as an
indication of 'multiuser' performance of a unix system.
For a single user running gnu autoconf type configure scripts, cvs,
installpatch :-) or other programms that start lots of these small unix
utilities, this benchmark might model the unix users system usage. I
wouldn't say it models *typical* usage of a unix system nowadays.
As an indication how well a unix system supports multiple users, this
script seems to be quite useless.
> I know that on Solaris the support for the locale features added
> significant overhead to these commands. Do all the other systems you
> benchmarked also support the locale features? Perhaps you should try a
> benchmark which runs the *identical* programs on the target systems.
As stated in the iX article, this was also the explanation given from
someone at sunsoft when asked why Solaris 2.4 x68 performed so poor on
iX's benchmarks when compared to linux.
But I don't think that's the whole issue. The locale stuff perhaps costs
10% - 20% extra time in this test (see below) but can't be used to
explain a 3x - 4x slower execution time.
Here are some interesting measurements I've made on a SS2 running
SunOS 5.4 showing how you can 'speed up' the results of this 'multi
user' benchmark by a factor of three:
leo 156% setenv LANG de
leo 157% set path= ( /usr/bin /usr/sbin . )
^^^ simplify path, my default PATH gives even worse times for the
first run; note that the scripts neither sets $PATH nor invokes
the unix utilities with absolute pathnames
leo 158% cd /usr/tmp
^^^ This is on an UFS filesystem, i.e. creates and deletes of the
temporary files happen with synchronuous directory writes
leo 159% /bin/time mp_multi.sh 16
real 16.6
user 4.8
sys 9.5
leo 160% cd /tmp
^^^ now using tmpfs, eliminating the sync directory writes
(AFAIK, linux uses async directory writes)
leo 161% /bin/time mp_multi.sh 16
real 15.4
user 4.5
sys 9.5
leo 162% unsetenv LANG
^^^ eliminate all the accesses to /usr/lib/locale/de/...; avoid
mmaping of /usr/lib/locale/de/LC_COLLATE/coll.so
leo 163% /bin/time mp_multi.sh 16
real 14.6
user 4.2
sys 9.0
leo 164% set path= ( /usr/tmp/gnu /usr/bin /usr/sbin . )
^^^ use dynamically linked gnu-versions of the
executables
leo 165% /bin/time mp_multi.sh 16
real 12.7
user 3.3
sys 8.1
leo 166% set path= ( /usr/tmp/gnu-static /usr/bin /usr/sbin . )
^^^ use statically linked gnu-versions of the executables
leo 167% /bin/time mp_multi_static.sh 16
^^^ and a version of the script, that uses
/sbin/sh (statically linked) instead of /bin/sh
(AFAIK, linux uses a different shared library concept with fixed
addresses for library routines avoiding the overhead of /lib/ld.so)
real 5.6
user 0.8
sys 4.0
I think the benchmark reveals, that
- dynamically linked binaries cost a lot of performace under SunOS for
these small unix utilities, especially if they run only for a short
time.
Most time seems to be used up for runtime linking of the binaries, not
for processing of data.
- /bin/sh is statically linked under SunOS 4 and is now dynamically linked
under SunOS 5; start-up time for /sbin/sh scripts is much better than
for /bin/sh scrips under SunOS 5
- The SunOS 5 /{sbin,bin}/sh uses fork to start sub-processes, while SunOS 4
uses vfork. The use of vfork in sh could speed up SunOS 5 bourne
shell scripts.
Robert Davies
Thanks to Jurgen Keil for a very interesting and informative post.
*Note: The script Paul De Bra has posted was his own version of this
*test, the german iX magazine actually uses a version that only sorts
*16 lines of text (a whopping amount 69 bytes!)
Just wanted to say, that I believe this is deliberate, the idea is to test
fork and exec, ie. kernel things rather than Userland utilities like sort.
I believe sort uses tmpnam(3), so setting TMPDIR to /tmp is often worthwhile,
on systems with tmpfs.
I was rather wondering about the setting of LANG to de. I remember when Alpha OSF/1
came out there were disappointing results, which were improved by setting LANG C.
I thought C was a low overhead ASCII locale, roughly equivalent to what we've
grown up with. Can anyone shed light on locales?
-- Rob
Martin Cracauer
[...]
>As stated in the iX article, this was also the explanation given from
>someone at sunsoft when asked why Solaris 2.4 x68 performed so poor on
Lovely typo :-)
>iX's benchmarks when compared to linux.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Private email Martin....@wavehh.hanse.de Fax +4940 522 8536. No NeXTMail!
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway" - Calvin
Paul De Bra
Bruce Adler [Contractor] <ad...@West.Sun.COM> wrote:
>In article <3los1o$s...@wsinis04.win.tue.nl>,
>[info about tests deleted]
>I think your benchmark incorrectly assumes that all flavors of Unix
>systems have the same or comparable sort, grep, wc, and grep programs.
>You've also incorrectly assumed that your script accurately models an
>some sort of typical Unix users system usage.
My benchmark (adapted from Byte's) contains several c-programs that are
exactly the same on all machines. The benchmark contains the posted shell
script to compare how multitasking and some standard utilities perform.
>What you're really measuring is the relative performance of the
>implementations of these commands, not the relative performance of the
>Unix kernels. Is that what you meant to measure?
That is exactly what I meant to measure. How do systems perform when using
the utilities that come with the system.
Other tests measure the relative performance of the Unix kernels.
Some of those tests show that Solaris is slower (using pipes for instance)
while some show that Solaris is faster (overhead in system calls for instance)
while still others show no significant difference.
>I know that on Solaris the support for the locale features added
>significant overhead to these commands. Do all the other systems you
>benchmarked also support the locale features? Perhaps you should try a
>benchmark which runs the *identical* programs on the target systems.
I can at least give one very-close-to-identical test that has been performed
by many people: compiling XFree86 (3.1 and 3.1.1) with GNU cc.
Compiling XFree86 reportedly takes much longer (between 50% and 100%) on
Solaris x86 than on Linux or Esix.
I can hardly wait for the new and supposedly much improved Solaris x86 2.5.
For me Solaris x86 2.4 has been very reliable (more so than 2.1), easier to
configure than other PC-unix versions, and better equiped with standard
utilities. It is a joy to use. Too bad that the most frequently asked
question is "is it slow", because I have to say "yes it is". Solaris does
take a faster cpu and more memory than other PC-unix versions to run well,
but when it runs well it's a joy to use.
Paul.
Ralph Betza
|>
|> - dynamically linked binaries cost a lot of performace under SunOS for
|> these small unix utilities, especially if they run only for a short
|> time.
|> Most time seems to be used up for runtime linking of the binaries, not
|> for processing of data.
What an excellent piece of investigation!
As you also point out elsewhere, running hundreds of very short programs
and scripts is not typical usage, but I wonder...
1. There's always a shell running somewhere. Does SVR4 actually need to relink
the shell every time? This seems wrong because there is already a fully-linked
image of it in virtual memory. I suppose it may be necessary in order to find
out if it really is the same image; LD_LIBRARY_PATH and national language might
call for different versions of some shared libraries.
2. If it turns out that there is no need to relink an existing process, would the
sticky bit ( S_ISVTX ) help at all?
3. Because of the virtual memory saved by shared libraries, if you run a million
different tiny scripts at once, instead of just running a few hundred, perhaps
SVR4 is faster because less swapping.
Michael Bender
: >someone at sunsoft when asked why Solaris 2.4 x68 performed so poor on
: Lovely typo :-)
It's not a typo - we've got to do SOMETHING with all those old Sun2's and
Sun3's we've got lying around :-).
mike
p.s. For the net.monitors - we really DON'T have a Solaris 2.4 x68...
--
----------------------------------------------------------------------------
OJ - Who Cares?
----------------------------------------------------------------------------
Casper H.S. Dik - Network Security Engineer
>1. There's always a shell running somewhere. Does SVR4 actually need to relink
>the shell every time? This seems wrong because there is already a fully-linked
>image of it in virtual memory. I suppose it may be necessary in order to find
>out if it really is the same image; LD_LIBRARY_PATH and national language might
>call for different versions of some shared libraries.
It would indeed be nice if the link table at the start of the data segment
could be shared. However, these tables can be different for different
instances of the same executable (different stack limits and such and what
about LD_* env vars? You can't share then. You'd also need to make sure
that no-one can influence that data in anyway.
>2. If it turns out that there is no need to relink an existing process, would the
>sticky bit ( S_ISVTX ) help at all?
No, not at all (it's ignored).
>3. Because of the virtual memory saved by shared libraries, if you run a million
>different tiny scripts at once, instead of just running a few hundred, perhaps
>SVR4 is faster because less swapping.
No. First of all, dynamic linking only saves VM if you
use different programs linked against the same libraries,
not when you run many copies of the same program, that program
would be shared anyway.
It's not so much the shell that is used in scripting, that cuases
the slow execution speed, but all the little programs. I once tried
a script that did quite a lot of expr and seds with to versions of the
shell utilities: the standard dynamically linked ones and (from the
same source) statically linked ones. When run against statically
linked binaries it was *much* faster (factor 4-10).
Casper