Aixers,

Does anyone believe that LINUX will surpass AIX as a premire OS for
businesses? What's your reasoning for your answers??

Thanks

Ken wrote:
> Aixers,
> 
> Does anyone believe that LINUX will surpass AIX as a premire OS for
> businesses? What's your reasoning for your answers??
> 

Already has.

AFAIK, quite a bit has been done in AIX 5.x(L) to support
Linux software and the building of Linux software.

Linux wins.

There is no larger team working on any OS.

AIX is nice, but still shows it's SVR2 roots a bit.
An AIX build on top of Linux would be wondrous.
....and I think that's going to happen (someday).

Linux is still maturing, but handling some features
much better than the "ancients".  Unix(tm) has grown
stagnant (though IBM has made some enhancements on
top).

There are people who actively care about Linux.
Many of those who felt ownership over Unix(tm), are
either dead or don't care anymore (or they're working
on Linux since they were probably no longer allowed
to actively work on the Unix code base).

On Wed, 14 Apr 2004, Chris Cox wrote:

CC > Date: Wed, 14 Apr 2004 11:07:53 -0500
CC > From: Chris Cox <ccox_nopenotthis@airmail.net>
CC > Newsgroups: comp.unix.aix
CC > Subject: Re: LINUX vs AIX
CC >
CC > Ken wrote:
CC > > Aixers,
CC > >
CC > > Does anyone believe that LINUX will surpass AIX as a premire OS for
CC > > businesses? What's your reasoning for your answers??
CC > >
CC >
CC > Already has.
CC >
[ ... ]

CC > Linux is still maturing, but handling some features
CC > much better than the "ancients".  Unix(tm) has grown
CC > stagnant (though IBM has made some enhancements on
CC > top).

Some of the areas that UNIX --still-- far surpasses Linux include
fully-preemptive 64-bit kernels, processor isolation, faithull support for
POSIX threads (Pthreads), support for large SMPs, Virtual Memory / File
Caching mechanisms, RAS, large file systen support and efficiency in
high-speed I/O.

The "ancients", such as, IRIX, Solaris and AIX do much better or at least much
more careful work in the above areas. Large SMP linux installations reveal the
above weaknesses accutely.

2.6 Linux version is a big step closer to some of the above, but it remains to
be seen how well it can catch up with the ancients '-)

CC >
CC > There are people who actively care about Linux.
CC > Many of those who felt ownership over Unix(tm), are
CC > either dead or don't care anymore (or they're working
CC > on Linux since they were probably no longer allowed
CC > to actively work on the Unix code base).

Actually, UNIX has gone to a lenghty maturing phase and many mechanisms have
been tunned-up to deliver good performance in 'heav-duty' environments. The
same is not true yet for Linux. It will be ashame if UNIX experience gets lost
and not ported to Linux kernels.

Ideally, Linux will inherit ALL the good UNIX features and still be open
source, thus creating an open source Unix (not in the Open Group sense ;-)

-Michael

CC >
CC >
CC >
CC >

On 2004-04-14, Chris Cox <ccox_nopenotthis@airmail.net> wrote:
>
> Already has.

I beg to differ.  And I say this as someone who runs his own custom distro in
addition to my AIX farm.  I'm as pro-Linux as the next guy, but I'm realistic
when acknowledging its limitations.

> AFAIK, quite a bit has been done in AIX 5.x(L) to support
> Linux software and the building of Linux software.
>
> Linux wins.

AIX wins.  It continues to provide features that will take years to show up in
Linux but gains access to the entire library of software available for Linux.
AIX gets a lot more benefit from this that Linux does, in my opinion.

> There is no larger team working on any OS.

Size != superior.  There's a larger number of bodies working *part-time*, but
arguably a lot less experience, expertise, and a hell of a lot less jobs
riding on good execution.  If anything, Linux's quality in the stable series
has gotten increasing worse.  The 2.0.x series was much better in quality
control, the 2.2.x was a little less so (but in general worth it because of
the expanded feature set), and the 2.4.x series was horrible.  It wasn't
until, what, 2.4.11 that we got a decently stable kernel?  I'm not touching
2.6.x for at least another year.

> AIX is nice, but still shows it's SVR2 roots a bit.
> An AIX build on top of Linux would be wondrous.
> ...and I think that's going to happen (someday).

You have got to be kidding.  The kernel (which *is* Linux) is the weakest part
of Linux.  The strongest part of Linux (common vernacular usage) is the
userland utilities, most of which is GNU software.  Guess what:  we've already
got that.  We've already got sendmail, apache, and all the others, too.
What I'd rather see is Linux built on AIX.  That would give us the fantastic
robustness during hardware failures, dynamic resource allocation, a real
freaking LVM that you can boot off of (without having to do some kludgy initrd
crap).

> Linux is still maturing, but handling some features
> much better than the "ancients".  Unix(tm) has grown
> stagnant (though IBM has made some enhancements on
> top).

Such as?  They're both great for what they do, but outside of the remaining
difficulties of porting Linux software to AIX and the hardware support, what
does Linux do better than AIX?

> There are people who actively care about Linux.
> Many of those who felt ownership over Unix(tm), are
> either dead or don't care anymore (or they're working
> on Linux since they were probably no longer allowed
> to actively work on the Unix code base).

There are people who aren't platform bigots that love all things UNIX, and
recognise the value of all them *in certain roles*.  I like Linux, I use it,
and I'm into it deep enough to maintain my own kludgy distribution.  But
there's definitely far more that AIX has that I'd love to see in Linux than
vice-versa.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

Chris Cox wrote:

>> Does anyone believe that LINUX will surpass AIX as a premire OS for
>> businesses? What's your reasoning for your answers??

> AIX is nice, but still shows it's SVR2 roots a bit.
> An AIX build on top of Linux would be wondrous.
> ...and I think that's going to happen (someday).

I agree, that would be great! As much as I love Linux, it is still a 
child compared to the more mature AIX. One of our worst nightmares is 
device support in Linux. Give Linux a device configuration database 
similar to ODM on AIX and you've really got something!

Michael E. Thomadakis wrote:
<snip>
> Some of the areas that UNIX --still-- far surpasses Linux include
> fully-preemptive 64-bit kernels, processor isolation, faithull support for
> POSIX threads (Pthreads), support for large SMPs, Virtual Memory / File
> Caching mechanisms, RAS, large file systen support and efficiency in
> high-speed I/O.
> 
> The "ancients", such as, IRIX, Solaris and AIX do much better or at least much
> more careful work in the above areas. Large SMP linux installations reveal the
> above weaknesses accutely.

<snip>

OK, I will byte <sic>.  What is SGI not telling us about their large SMP 
boxes?  You have proof they faked their graphs they published about 
their linear SMP performance?

Or are you like the IBM guy who was trying to explain to me that Linux 
can't do more than four processors and 4 Gig of memory?

8-)

On 2004-04-15, Timothy J. Bogart <tbogart@frii.net> wrote:
>
><snip>
>
> OK, I will byte <sic>.  What is SGI not telling us about their large SMP 
> boxes?  You have proof they faked their graphs they published about 
> their linear SMP performance?

Based on this comment I'd wager you've never used SGI's IRIX.  If you did,
you'd understand that what they've accomplished is indeed impressive, but more
so due to the use of commodity hardware rather than a revolution in the OS.
IRIX, like AIX, is *tremendously* more scalable and reliable than Linux, and
relatively more bug free.  If you followed the Linux Kernel Mailing List you'd
see a lot of problems still being dealt with that the big Unices don't have
to.

In summary:  The Altix is amazing because of the power they deliver for the
price.  It is not amazing because it made IRIX (or AIX) obsolete on the
high-end, because it didn't.

> Or are you like the IBM guy who was trying to explain to me that Linux 
> can't do more than four processors and 4 Gig of memory?

He's an idiot.  Get over it.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On Wed, 14 Apr 2004, Timothy J. Bogart wrote:

TJB > Date: Wed, 14 Apr 2004 18:40:09 -0600
TJB > From: Timothy J. Bogart <tbogart@frii.net>
TJB > Newsgroups: comp.unix.aix
TJB > Subject: Re: LINUX vs AIX
TJB >
TJB > Michael E. Thomadakis wrote:
TJB > <snip>
TJB > > Some of the areas that UNIX --still-- far surpasses Linux include
TJB > > fully-preemptive 64-bit kernels, processor isolation, faithull support for
TJB > > POSIX threads (Pthreads), support for large SMPs, Virtual Memory / File
TJB > > Caching mechanisms, RAS, large file systen support and efficiency in
TJB > > high-speed I/O.
TJB > >
TJB > > The "ancients", such as, IRIX, Solaris and AIX do much better or at least much
TJB > > more careful work in the above areas. Large SMP linux installations reveal the
TJB > > above weaknesses accutely.
TJB >
TJB > <snip>
TJB >
TJB > OK, I will byte <sic>.  What is SGI not telling us about their large SMP
TJB > boxes?  You have proof they faked their graphs they published about
TJB > their linear SMP performance?
TJB >

The above statements came out of my experience from 64PE SGI O3500, 32PE IBM
p690 and a 128 PE SGI Altix. IRIX and AIX has a much better file caching
mechanism. I/O performance is very decent on the same as well. IRIX and
Solaris have a more refined kernel: pre-emptible, good POSIX thread support.
IRIX and AIX have decent RAS features. etc.

Don't get me wrong. The Altix3700 (ia64 Linux) is a very good system from the
h/w point of view.  Intel compilers are getting decent and it comes with
decent libraries for SMP code. Applications running on Altix scale up very
well. Things change when large file I/O is involved.

I am not referring to the performance of single, fine-tuned applications, but
to the efficiency and maturity of system services.There are some inherent
kernel issues in the Linux v 2.4.

As I said, v. 2.6 has addressed most of the above issues. How well it will
perform on large SMPs remains to be seen. My hope is that it will be much
better.

To get an idea on how things stand just go to
http://oss.sgi.com/archives
and review the issues mentioned there. Or just do a google search on
'Linux VM performance problems'.


TJB > Or are you like the IBM guy who was trying to explain to me that Linux
TJB > can't do more than four processors and 4 Gig of memory?
TJB >
TJB > 8-)
TJB >
TJB >

 -m

Michael E. Thomadakis <miket@hellas.tamu.edu> wrote:

MET> On Wed, 14 Apr 2004, Chris Cox wrote:

MET> CC > Ken wrote:
MET> CC > > Aixers,
MET> CC > >
MET> CC > > Does anyone believe that LINUX will surpass AIX as a premire OS for
MET> CC > > businesses? What's your reasoning for your answers??
MET> CC > >
MET> CC >
MET> CC > Already has.

MET> CC > Linux is still maturing, but handling some features
MET> CC > much better than the "ancients".  Unix(tm) has grown
MET> CC > stagnant (though IBM has made some enhancements on
MET> CC > top).

MET> Some of the areas that UNIX --still-- far surpasses Linux include
MET> fully-preemptive 64-bit kernels,

What's the difference between the preemption supported in 2.6 and
your full preemption?

MET> processor isolation, faithull support for POSIX threads

"Faithful"?

MET> (Pthreads), support for large SMPs

I'm pretty sure the core Linux developers aren't interested in
optimizing the kernel for a great many CPUs if doing so would damage
its preformance on a humble desktop.  This paper by Larry McVoy
lays out their attitude pretty well.

Regards,

Nicholas

Nicholas Dronen <ndronen@io.frii.com> wrote:

[ snip ]

ND> I'm pretty sure the core Linux developers aren't interested in
ND> optimizing the kernel for a great many CPUs if doing so would damage
ND> its preformance on a humble desktop.  This paper by Larry McVoy
ND> lays out their attitude pretty well.

Er, *this* paper:

	http://www.kanga.nu/~claw/docs/smp.pdf

Regards,

Nicholas

On Wed, 14 Apr 2004 19:22:00 +0000, Arthur Corliss wrote:

> On 2004-04-14, Chris Cox <ccox_nopenotthis@airmail.net> wrote:
>>
>> Already has.
> 
> I beg to differ.  And I say this as someone who runs his own custom
> distro in addition to my AIX farm.  I'm as pro-Linux as the next guy,
> but I'm realistic when acknowledging its limitations.
> 
>> AFAIK, quite a bit has been done in AIX 5.x(L) to support Linux
>> software and the building of Linux software.
>>
>> Linux wins.
> 
> AIX wins.  It continues to provide features that will take years to show
> up in Linux but gains access to the entire library of software available
> for Linux. AIX gets a lot more benefit from this that Linux does, in my
> opinion.
> 
>> There is no larger team working on any OS.
> 
> Size != superior.  There's a larger number of bodies working
> *part-time*, but arguably a lot less experience, expertise, and a hell
> of a lot less jobs riding on good execution.  If anything, Linux's
> quality in the stable series has gotten increasing worse.  The 2.0.x
> series was much better in quality control, the 2.2.x was a little less
> so (but in general worth it because of the expanded feature set), and
> the 2.4.x series was horrible.  It wasn't until, what, 2.4.11 that we
> got a decently stable kernel?  I'm not touching 2.6.x for at least
> another year.
> 
>> AIX is nice, but still shows it's SVR2 roots a bit. An AIX build on top
>> of Linux would be wondrous. ...and I think that's going to happen
>> (someday).
> 
> You have got to be kidding.  The kernel (which *is* Linux) is the
> weakest part of Linux.  The strongest part of Linux (common vernacular
> usage) is the userland utilities, most of which is GNU software.  Guess
> what:  we've already got that.  We've already got sendmail, apache, and
> all the others, too. What I'd rather see is Linux built on AIX.  That
> would give us the fantastic robustness during hardware failures, dynamic
> resource allocation, a real freaking LVM that you can boot off of
> (without having to do some kludgy initrd crap).
> 
>> Linux is still maturing, but handling some features much better than
>> the "ancients".  Unix(tm) has grown stagnant (though IBM has made some
>> enhancements on top).
> 
> Such as?  They're both great for what they do, but outside of the
> remaining difficulties of porting Linux software to AIX and the hardware
> support, what does Linux do better than AIX?
> 
>> There are people who actively care about Linux. Many of those who felt
>> ownership over Unix(tm), are either dead or don't care anymore (or
>> they're working on Linux since they were probably no longer allowed to
>> actively work on the Unix code base).
> 
> There are people who aren't platform bigots that love all things UNIX,
> and recognise the value of all them *in certain roles*.  I like Linux, I
> use it, and I'm into it deep enough to maintain my own kludgy
> distribution.  But there's definitely far more that AIX has that I'd
> love to see in Linux than vice-versa.

As an SA working full time with _both_ in production, and who likes both,
I believe I can contribute to the discussion.  AIX is still the better
platform for high end SMP (> 4 processors), and highly available
applications.  Until such time as Linux has a stable, integrated LVM that
is _fully supported_ by third parties (like SAN vendors), and a dynamic
software/hardware configuration method similar to the ODM in AIX, then it
cannot be the prime platform for Enterprise class applications.  It does
have embryonic sprouts of having such support, which is encouraging, but
it isn't There Yet.

However, AIX runs on _expensive_ hardware, cycle for cycle.  I can get a
fairly impressive Intel server platform for a fraction of the cost of an
equivalent pSeries.  I can implement many more Linux based servers dollar
for dollar, which (somewhat) offsets the above stated weaknesses.  What we
have ended up with is a configuration where AIX is the platform for our
big monolithic Oracle servers, and the application servers that aren't
supported in Linux.  Those machines have to stay up.  Period.  We use
Linux for environments that support it, or can be load-balanced.
Horizontal scaling works there, for thinks like Web servers and smaller
Oracle servers.  So we end up with a mix.

Vendor support is a problem for Linux.  Even a company like IBM, which
touts its Linux support, doesn't support it to the extent that it does
AIX.  SAN storage, for example.  I can hook an AIX box up to a Shark,
install the software, and it all works perfectly.  Linux is a struggle
usually, and the Shark software provided (SDD) flies in the face of
standard Linux support: I have to have specific kernel versions, which are
usually old, not just "at least this version" type support.  And, I cannot
compile my own kernel without "fooling" the Shark support software.  And
every new version of SDD is a new set of problems.  IBM gets kudos for
providing the software in the first place, but brickbats for making it so
hard to use.  Oracle is another one that supports Linux as a "step-child"
product.

On Thu, 15 Apr 2004, Nicholas Dronen wrote:

ND > Date: 15 Apr 2004 12:58:43 GMT
ND > From: Nicholas Dronen <ndronen@io.frii.com>
ND > Newsgroups: comp.unix.aix
ND > Subject: Re: LINUX vs AIX
ND >
ND > Michael E. Thomadakis <miket@hellas.tamu.edu> wrote:
ND >

[ ... ]

ND > MET> Some of the areas that UNIX --still-- far surpasses Linux include
ND > MET> fully-preemptive 64-bit kernels,
ND >
ND > What's the difference between the preemption supported in 2.6 and
ND > your full preemption?

The discussion is on existing Linux vs. UNIX kernels and my comment refers to
the 2.4 based kernels, as the ones currently deployed on large SMPs (Altix).
If you had read further down my initial reply, you would have see my
expectation on 2.6. UNIX became 'fully' preepmtive at around the early 90's
(Solaris 2.x). In this particular matter, the 2.6 kernel seems to be following
a similar path that UNIX took.

I haven't seen how well 2.6 behaves on SMPs of decent size (>=16). I hope and
expect it to be similar to UNIX.

ND >
ND > MET> processor isolation, faithull support for POSIX threads
ND >
ND > "Faithful"?

You are familiar with the SIGnal handling and other problems with the Linux
Threads Lib, I assume? The latest NPTL is supposed to be faithfull to POSIX
thread semantics. I haven't tried it out but they are being discussed as such.
For POSIX check the IEEE and the Open Group sites.

ND >
ND > MET> (Pthreads), support for large SMPs
ND >
ND > I'm pretty sure the core Linux developers aren't interested in
ND > optimizing the kernel for a great many CPUs if doing so would damage
ND > its preformance on a humble desktop.  This paper by Larry McVoy
ND > lays out their attitude pretty well.

The point of the original poster was that Linux rocks so much that it has
ALREADY surpassed UNIX in everything. I thought that it would be beneficial to
report on my experience that comes from the UNIX environment and recently from
Linux. I've mentioned a number of points were Linux STILL lags behind the
'ancient' UNIXes. The mindset of the developer is not relevant here.

Do you disagree on the points I mentioned previously that linux still lags
behind? If yes, pls provide technical evidence.

If Linux is to make it in the high-end systems, it should address all these
issues.


ND >
ND > Regards,
ND >
ND > Nicholas
ND >
ND >

regards,
Mike

On Thu, 15 Apr 2004, Nicholas Dronen wrote:

ND > Date: 15 Apr 2004 12:59:35 GMT
ND > From: Nicholas Dronen <ndronen@io.frii.com>
ND > Newsgroups: comp.unix.aix
ND > Subject: Re: LINUX vs AIX
ND >
ND > Nicholas Dronen <ndronen@io.frii.com> wrote:
ND >
ND > [ snip ]
ND >
ND > ND> I'm pretty sure the core Linux developers aren't interested in
ND > ND> optimizing the kernel for a great many CPUs if doing so would damage
ND > ND> its preformance on a humble desktop.  This paper by Larry McVoy
ND > ND> lays out their attitude pretty well.
ND >
ND > Er, *this* paper:
ND >
ND > 	http://www.kanga.nu/~claw/docs/smp.pdf
ND >

I just went through the paper and it barely scratches on the issues involved
with putting together a scalable OS. This objective is INDEED very
challenging and it has been known in the last 20 years.

Does he imply that Linux would or should, never have an efficient kernel
suitable for large SMPs? Take IRIX for example: it runs well on 1 CPU or 128
CPUs. Why wouldn't Linux be able to do this, if the right mechanisms are
implemented?

Regards,
Mike




ND > Regards,
ND >
ND > Nicholas
ND >
ND >

On 2004-04-15, F. Michael Orr <morr@utility.vccs.edu> wrote:
>
> As an SA working full time with _both_ in production, and who likes both,
> I believe I can contribute to the discussion.  AIX is still the better
> platform for high end SMP (> 4 processors), and highly available
> applications.  Until such time as Linux has a stable, integrated LVM that
> is _fully supported_ by third parties (like SAN vendors), and a dynamic
> software/hardware configuration method similar to the ODM in AIX, then it
> cannot be the prime platform for Enterprise class applications.  It does
> have embryonic sprouts of having such support, which is encouraging, but
> it isn't There Yet.

Amen, brother.  I'm in the same boat that you are, with AIX running the
enterprise and data center, and Linux providing edge services (on an HP blade
server since IBM won't touch the low-end blade server market).

> However, AIX runs on _expensive_ hardware, cycle for cycle.  I can get a
> fairly impressive Intel server platform for a fraction of the cost of an
> equivalent pSeries.  I can implement many more Linux based servers dollar
> for dollar, which (somewhat) offsets the above stated weaknesses.  What we
> have ended up with is a configuration where AIX is the platform for our
> big monolithic Oracle servers, and the application servers that aren't
> supported in Linux.  Those machines have to stay up.  Period.  We use
> Linux for environments that support it, or can be load-balanced.
> Horizontal scaling works there, for thinks like Web servers and smaller
> Oracle servers.  So we end up with a mix.

I think the price point has got to be the core of the typical Linux fan-boys
out there.  They love it, and advocate it, simply because that's usually all
they've ever touched.  The cost of the OS isn't the issue as much as it's the 
cost of the hardware.

If scalability and reliability are the priority I won't deploy Linux, I'd
deploy AIX, IRIX, or HP-UX.  I will deploy Linux when I'm replacing Solaris or
Windows, though, since the uptime will typically be as good, if not better,
and a hell of a lot cheaper.  But that's just to annoy the other half of the
IT department.  ;-)

> Vendor support is a problem for Linux.  Even a company like IBM, which
> touts its Linux support, doesn't support it to the extent that it does
> AIX.  SAN storage, for example.  I can hook an AIX box up to a Shark,
> install the software, and it all works perfectly.  Linux is a struggle
> usually, and the Shark software provided (SDD) flies in the face of
> standard Linux support: I have to have specific kernel versions, which are
> usually old, not just "at least this version" type support.  And, I cannot
> compile my own kernel without "fooling" the Shark support software.  And
> every new version of SDD is a new set of problems.  IBM gets kudos for
> providing the software in the first place, but brickbats for making it so
> hard to use.  Oracle is another one that supports Linux as a "step-child"
> product.

Excellent points, and one of the primary reason why I won't touch Linux for
pSeries, yet.  When all of your proprietary kernel modules are rev-locked to a
specific kernel it makes it a major pain in the ass to deal with kernel
upgrades, especially when your under pressure for, say, the three local root
exploits that have had to be patched in the kernel this year alone.

I run Linux, I like it, but it stays on commodity hardware providing edge
services.  If there isn't native support for the hardware in Linus' tree, it's
not going to be Linux touching *that* hardware.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

Arthur Corliss wrote:
> On 2004-04-15, Timothy J. Bogart <tbogart@frii.net> wrote:
> 
>><snip>
>>
>>OK, I will byte <sic>.  What is SGI not telling us about their large SMP 
>>boxes?  You have proof they faked their graphs they published about 
>>their linear SMP performance?
> 
> 
> Based on this comment I'd wager you've never used SGI's IRIX.  If you did,
> you'd understand that what they've accomplished is indeed impressive, but more
> so due to the use of commodity hardware rather than a revolution in the OS.
> IRIX, like AIX, is *tremendously* more scalable and reliable than Linux, and
> relatively more bug free.  If you followed the Linux Kernel Mailing List you'd
> see a lot of problems still being dealt with that the big Unices don't have
> to.
> 
> In summary:  The Altix is amazing because of the power they deliver for the
> price.  It is not amazing because it made IRIX (or AIX) obsolete on the
> high-end, because it didn't.
> 
> 
>>Or are you like the IBM guy who was trying to explain to me that Linux 
>>can't do more than four processors and 4 Gig of memory?
> 
> 
> He's an idiot.  Get over it.
> 


Well, let me paraphrase your answer:  'I dunno, but the other stuff 
feels cool'

No, I have hardly touched IRIX, and not since about 1995, but that 
really has nothing to do with not answering the question.  If you really 
  had anything to say, I would listen to it.

Michael E. Thomadakis wrote:
> 
> On Wed, 14 Apr 2004, Timothy J. Bogart wrote:
> 
> TJB > Date: Wed, 14 Apr 2004 18:40:09 -0600
> TJB > From: Timothy J. Bogart <tbogart@frii.net>
<snip>
> TJB >
> TJB > OK, I will byte <sic>.  What is SGI not telling us about their large SMP
> TJB > boxes?  You have proof they faked their graphs they published about
> TJB > their linear SMP performance?
> TJB >
> 
> The above statements came out of my experience from 64PE SGI O3500, 32PE IBM
> p690 and a 128 PE SGI Altix. IRIX and AIX has a much better file caching
> mechanism. I/O performance is very decent on the same as well. IRIX and
> Solaris have a more refined kernel: pre-emptible, good POSIX thread support.
> IRIX and AIX have decent RAS features. etc.

Well, I have some experiense with I/O performance being pretty ratty on 
AIX, at least for small files.  Compare a gcc compile on AIX vs even my 
laptop IDE drive.
> 
> Don't get me wrong. The Altix3700 (ia64 Linux) is a very good system from the
> h/w point of view.  Intel compilers are getting decent and it comes with
> decent libraries for SMP code. Applications running on Altix scale up very
> well. Things change when large file I/O is involved.

Funny, the article in Linux Today went into some detail on the 
improvments they made to SCSI drivers to get performance boosts and they 
posted pretty good test numbers, as I recall.  Of course, if you had any 
conflicting data to share.....
> 
> I am not referring to the performance of single, fine-tuned applications, but
> to the efficiency and maturity of system services.There are some inherent
> kernel issues in the Linux v 2.4.
> 
> As I said, v. 2.6 has addressed most of the above issues. How well it will
> perform on large SMPs remains to be seen. My hope is that it will be much
> better.

Well, I am afraid you seem a little confused.  You keep refering to SMP 
issues and then jump to file caching then to file I/O.  Do you really 
have any specifics you can point to?  This really just seems to be 
bandying about some buzz words you heard, rather than real data.  I 
mean, filesystems aren't the kernel, the compilers and libraries are not 
the kernel, and 'system services' is generic enough to be a complete cop 
out.
> 
> To get an idea on how things stand just go to
> http://oss.sgi.com/archives
> and review the issues mentioned there. Or just do a google search on
> 'Linux VM performance problems'.

Umm, I would never argue that Linux is mature, but it sure sounds like 
you have never dealt with the developers at, say, IBM or SUN.  It is 
just that the Linux laundry is quite public, and the issues with the 
'ancients' can only be glimpsed after you pay them a lot of money for a 
support contract.

You might want to review the timeframe that IBM even sold multiprocessor 
machines, and live with some J30/40/50 beasts for a few years before you 
  talk at lenght about code or hardware maturity.  Seems they approached 
high performance with clusters (SP) quite successfuly...hmmm, that 
sounds familiar.  8-)

Sure Linux is immature, but I would argue the whole software industry is 
immature.  I have gotten admissions from support staff at IBM and SUN 
that made my skin crawl.  I would be awfully surprised if HP or SGI were 
that much different.  Pleasantly so, but still surprised.  Frankly, what 
amazes me most about Linux is just how far that has come, with the 
number of folks working on it.  The whole project should have self 
destructed years ago, but it seems to be getting better at an increasing 
rate.  Chances are, it will be come truly mature before any of the 
'ancients' even though it is so much younger today.  8-)

Arthur Corliss wrote:
> On 2004-04-15, F. Michael Orr <morr@utility.vccs.edu> wrote:
> 
>>As an SA working full time with _both_ in production, and who likes both,
>>I believe I can contribute to the discussion.  AIX is still the better
>>platform for high end SMP (> 4 processors), and highly available
>>applications.  Until such time as Linux has a stable, integrated LVM that
>>is _fully supported_ by third parties (like SAN vendors), and a dynamic
>>software/hardware configuration method similar to the ODM in AIX, then it
>>cannot be the prime platform for Enterprise class applications.  It does
>>have embryonic sprouts of having such support, which is encouraging, but
>>it isn't There Yet.
> 
> 
> Amen, brother.  I'm in the same boat that you are, with AIX running the
> enterprise and data center, and Linux providing edge services (on an HP blade
> server since IBM won't touch the low-end blade server market).

Yes, I'd say with Messr. Orr, we have a winner.  At least with the lvm 
comments.  That is really the last issue that sets AIX (and maybe IRIX?) 
above all others.
> 
> 
>>However, AIX runs on _expensive_ hardware, cycle for cycle.  I can get a
>>fairly impressive Intel server platform for a fraction of the cost of an
>>equivalent pSeries.  I can implement many more Linux based servers dollar
>>for dollar, which (somewhat) offsets the above stated weaknesses.  What we
>>have ended up with is a configuration where AIX is the platform for our
>>big monolithic Oracle servers, and the application servers that aren't
>>supported in Linux.  Those machines have to stay up.  Period.  We use
>>Linux for environments that support it, or can be load-balanced.
>>Horizontal scaling works there, for thinks like Web servers and smaller
>>Oracle servers.  So we end up with a mix.
> 
> 
> I think the price point has got to be the core of the typical Linux fan-boys
> out there.  They love it, and advocate it, simply because that's usually all
> they've ever touched.  The cost of the OS isn't the issue as much as it's the 
> cost of the hardware.

And the typical guru-wannabe who says stuff like this probably isn't 
even eligable for cereberal ossifcation as that requires a cerebellum. 
Sheesh. Having cut my SA teeth largely in development groups, I have had 
to deal (under duress) with the new priesthood of the computer world. 
To replace the white coated figures who guarded the mainframe are the 
bluejean clad, punk rock fringe (probably wearing their favorite brand 
of multi plier) who have only ever seen the brand name big guys in their 
beloved data center, and that is all that is ever going to be there. 
The have their gold bound procedure manuals for backups, and that is 
about the limit of their knowledge.

Oh, well, that could get fun, but I hope the point is made.  90% of any 
given group is not in the top 10%, and let's just keep to an actual 
exchange of data and experience, eh what?
> 
> If scalability and reliability are the priority I won't deploy Linux, I'd
> deploy AIX, IRIX, or HP-UX.  I will deploy Linux when I'm replacing Solaris or
> Windows, though, since the uptime will typically be as good, if not better,
> and a hell of a lot cheaper.  But that's just to annoy the other half of the
> IT department.  ;-)
> 

Well, I guess I would need some better idea of scalability here again, 
since the introduction of the Altix gives arguably the largest 
horsepower in a single machine, the number of Linux clusters ranking 
rather high in the super computer lists keeps growing, and it works 
quite well in a number of instances of reviving old desktops and laptops 
that aren't 'powerfull' enough to run that junk from the evil empire - 
gosh, I still have to say that is pretty scalable.  As to reliablility, 
well, I am always open to data, but my experience with kernel panics is 
that they are so few and far between on anything except the evil empire, 
it is getting pretty pretty hard to really calibrate the differences.  Yes?
> 
>>Vendor support is a problem for Linux.  Even a company like IBM, which
>>touts its Linux support, doesn't support it to the extent that it does
>>AIX.  SAN storage, for example.  I can hook an AIX box up to a Shark,
>>install the software, and it all works perfectly.  Linux is a struggle
>>usually, and the Shark software provided (SDD) flies in the face of
>>standard Linux support: I have to have specific kernel versions, which are
>>usually old, not just "at least this version" type support.  And, I cannot
>>compile my own kernel without "fooling" the Shark support software.  And
>>every new version of SDD is a new set of problems.  IBM gets kudos for
>>providing the software in the first place, but brickbats for making it so
>>hard to use.  Oracle is another one that supports Linux as a "step-child"
>>product.

Yes, not as critical as the lvm issue, but still annoying is that you 
have to be carefull of what you purchase, and purchase what is well 
supported, not just advertised to be supported.  I am afraid that while 
IBM was arguably the first 'real iron' to support Linux, they have also 
been the weirdest.  At least when HP jumped on board, they supported on 
their old hardware as well as the new.
<snip>

On Thu, 15 Apr 2004, Timothy J. Bogart wrote:

TJB > Date: Thu, 15 Apr 2004 16:08:19 -0600
TJB > From: Timothy J. Bogart <tbogart@frii.net>
TJB > Newsgroups: comp.unix.aix
TJB > Subject: Re: LINUX vs AIX
TJB >
TJB > Michael E. Thomadakis wrote:
TJB > >

[ ... ]

TJB > > The above statements came out of my experience from 64PE SGI O3500, 32PE IBM
TJB > > p690 and a 128 PE SGI Altix. IRIX and AIX has a much better file caching
TJB > > mechanism. I/O performance is very decent on the same as well. IRIX and
TJB > > Solaris have a more refined kernel: pre-emptible, good POSIX thread support.
TJB > > IRIX and AIX have decent RAS features. etc.
TJB >
TJB > Well, I have some experiense with I/O performance being pretty ratty on
TJB > AIX, at least for small files.  Compare a gcc compile on AIX vs even my
TJB > laptop IDE drive.

I don't have performance data for small file I/O under AIX. How is the file
I/O for large files? We are talking files of size 10-70GBs? The code running
here often reads/writes files of these sizes.

The problem with AIX is that it is not immediately clear how to properly set
the vmtune/vmo, ioo parameters to match the I/O and the VM characterstics of
the workload. Documentation is also either too verbose, outdated or simply too
voluminus. After one gets a handle on VM and IO  tunning things proceed
smoothly. The I/O paths provide throughputs very close to the h/w limitations
of the PCI and SCSI buses. But AFTER you tune up properly. And most
importantly, after you LAY OUT the file systems on properly configured
physical and logical volumes.

If small files are importand to your environment then you need to know the
peroformance of your system in this respect. For the large file I/O that
hammer the disks 24X7, AIX is fine (with the above provisions).

I CANNOT say the same for our large Linux box. The MAX we could get out of a
theoretical MAX of 800MB/sec to the RAID was around 370MB/sec. SGI has
attributed this to limitations of the SGI's block device drivers (xscsi) that
are planning to replace in the next major release. FYI, xscsi is MUCH better
than the native Linux scsi drivers.



TJB > >
TJB > > Don't get me wrong. The Altix3700 (ia64 Linux) is a very good system from the
TJB > > h/w point of view.  Intel compilers are getting decent and it comes with
TJB > > decent libraries for SMP code. Applications running on Altix scale up very
TJB > > well. Things change when large file I/O is involved.
TJB >
TJB > Funny, the article in Linux Today went into some detail on the
TJB > improvments they made to SCSI drivers to get performance boosts and they
TJB > posted pretty good test numbers, as I recall.  Of course, if you had any
TJB > conflicting data to share.....

The results you saw are either from xscsi or from their next proprietary scsi
drivers. You are talking in a vacuum here. How can you tell what consitutes
`good results'? See the previous paragraph.

TJB > >
TJB > > I am not referring to the performance of single, fine-tuned applications, but
TJB > > to the efficiency and maturity of system services.There are some inherent
TJB > > kernel issues in the Linux v 2.4.
TJB > >
TJB > > As I said, v. 2.6 has addressed most of the above issues. How well it will
TJB > > perform on large SMPs remains to be seen. My hope is that it will be much
TJB > > better.
TJB >
TJB > Well, I am afraid you seem a little confused.  You keep refering to SMP
TJB > issues and then jump to file caching then to file I/O.

I am sorry that you cannot follow the discussion on the point of:

``Linux vs UNIX systems''

Do you really
TJB > have any specifics you can point to?  This really just seems to be
TJB > bandying about some buzz words you heard, rather than real data.  I
TJB > mean, filesystems aren't the kernel, the compilers and libraries are not
TJB > the kernel, and 'system services' is generic enough to be a complete cop
TJB > out.

As a matter of fact I have been pointing out VERY SPECIFIC points in the
differences of Linux and UNIX. It is clear that you are confused and have lost
track of the context and points of the discussion.

TJB > >
TJB > > To get an idea on how things stand just go to
TJB > > http://oss.sgi.com/archives
TJB > > and review the issues mentioned there. Or just do a google search on
TJB > > 'Linux VM performance problems'.
TJB >
TJB > Umm, I would never argue that Linux is mature, but it sure sounds like
TJB > you have never dealt with the developers at, say, IBM or SUN.  It is
TJB > just that the Linux laundry is quite public, and the issues with the
TJB > 'ancients' can only be glimpsed after you pay them a lot of money for a
TJB > support contract.

I do not disagree on the expensive h/w or the service quality.  However, the
question is what UNIX delivers BETTER wrt Linux.  The quality of the support
service by the vendor is neither a technical point of comparison, nor relevant
here.

TJB >
TJB > You might want to review the timeframe that IBM even sold multiprocessor
TJB > machines, and live with some J30/40/50 beasts for a few years before you
TJB >   talk at lenght about code or hardware maturity.  Seems they approached
TJB > high performance with clusters (SP) quite successfuly...hmmm, that
TJB > sounds familiar.  8-)

There is no doubt that 'high-performance' of 10-20 years ago seems laughable
today. Do not forget the strides the h/w has made in the meantime.

TJB >
TJB > Sure Linux is immature, but I would argue the whole software industry is
TJB > immature.  I have gotten admissions from support staff at IBM and SUN
TJB > that made my skin crawl.  I would be awfully surprised if HP or SGI were
TJB > that much different.  Pleasantly so, but still surprised.

Feeling -- even rightfully -- frustrated on the service you've received,
cannot be converted into an argument that shows that Linux is technically
superior than mature UNIX kernels. Do not use sentiments to evaluate something
objectively.

Frankly, what
TJB > amazes me most about Linux is just how far that has come, with the
TJB > number of folks working on it.  The whole project should have self
TJB > destructed years ago, but it seems to be getting better at an increasing
TJB > rate.  Chances are, it will be come truly mature before any of the
TJB > 'ancients' even though it is so much younger today.  8-)

I think YOU will be the FIRST one to disagree with your own words after you
try to deploy Linux in a more 'heavy-duty' environment.


The strong point of Linux is currently and overwhelmingly in the APPLICATIONS
ARENA. There are many more -- and FREE -- applications for Linux than for
UNIX. I would grant you can do almost completely away with proprietary s/w in
most environments. I agree that the quality of the code in these apps is also
very good.

Again, the discussion started when someone claimed that 'Linux is so cool that
it has already surpassed everything else'. This statement was disproved as
soon as so many people (including myself) provided all the counterexamples for
which Linux currently is next to sucks. These areas are important to people
running larger SMPs, for heavy-duty computation, data or networking centers.

It is the immaturity of the kernel for THESE TYPES of environemnts. Linux 2.6
promises and I think it is BETTER in these respects. How MUCH better, remains
to be seen.

Linux currently is 'perfect' for the low to middle end centers. For 24X7,
heavy duty shops NOT really, yet.

TJB >
TJB >

-m

Michael E. Thomadakis <miket@hellas.tamu.edu> wrote:


MT> On Thu, 15 Apr 2004, Nicholas Dronen wrote:

MT> ND > Nicholas Dronen <ndronen@io.frii.com> wrote:
MT> ND >
MT> ND > [ snip ]
MT> ND >
MT> ND > ND> I'm pretty sure the core Linux developers aren't interested in
MT> ND > ND> optimizing the kernel for a great many CPUs if doing so would
MT> ND > ND> damage its preformance on a humble desktop.  This paper
MT> ND > ND> by Larry McVoy lays out their attitude pretty well.
MT> ND >
MT> ND > Er, *this* paper:
MT> ND >
MT> ND >    http://www.kanga.nu/~claw/docs/smp.pdf
MT> ND >

MT> I just went through the paper and it barely scratches on the issues
MT> involved with putting together a scalable OS. This objective is INDEED
MT> very challenging and it has been known in the last 20 years.  

MT> Does he imply that Linux would or should, never have an efficient kernel
MT> suitable for large SMPs?

Simply stated, should never have, at least not in a conventional sense.

	ABSTRACT

	We put for th the controversial idea that scaling can be a
	harmful thing to a general purpose OS if carried to far.
	The level of harm is directly proportional to the amount
	of scaling and is worse than linear in the number of
	processors.  We claim that converting a uniprocessor OS to
	a 4 way SMP OS introduces only a small amount of damage,
	but converting the 4 way SMP OS to a 32 way SMP OS does a
	much larger amount of damage. We call this phenomenon the
	``locking cliff.''

I can't find the follow-on paper.  I saw him give a lecture version
of it at a convention.  This was several years ago, so I can't
recite it faithfully, nor -- unfortunately -- can I find the
slides on his site:

	http://www.bitmover.com/lm/

The proposal (simply and probably incorrectly stated) was to fan a
kernel out to each processor at boot time and run them independently.
System-wide entities such as sockets would be coordinated by some
independent mechanism.  (Again, several years ago, foggy recollection,
etc.  Take my telling of it with a grain of salt.  I might not be
representing it correctly.)

MT> Take IRIX for example: it runs well on 1 CPU
MT> or 128 CPUs. 

McVoy used to be a kernel programmer at SGI.  I think that's where
where he picked up his lock phobia.

MT> Why wouldn't Linux be able to do this, if the right mechanisms
MT> are implemented?

Because they have a different design in mind.

Regards,

Nicholas

On Thu, 16 Apr 2004, Nicholas Dronen wrote:

ND > Date: 16 Apr 2004 01:03:56 GMT
ND > From: Nicholas Dronen <ndronen@io.frii.com>
ND > Newsgroups: comp.unix.aix
ND > Subject: Re: LINUX vs AIX
ND >
[ ... ]
ND >
ND > MT> I just went through the paper and it barely scratches on the issues
ND > MT> involved with putting together a scalable OS. This objective is INDEED
ND > MT> very challenging and it has been known in the last 20 years.
ND >
ND > MT> Does he imply that Linux would or should, never have an efficient
ND > kernel MT> suitable for large SMPs?
ND >
ND > Simply stated, should never have, at least not in a conventional sense.
ND >
ND > 	ABSTRACT
ND >
ND > 	We put for th the controversial idea that scaling can be a
ND > 	harmful thing to a general purpose OS if carried to far.
ND > 	The level of harm is directly proportional to the amount
ND > 	of scaling and is worse than linear in the number of
ND > 	processors.  We claim that converting a uniprocessor OS to
ND > 	a 4 way SMP OS introduces only a small amount of damage,
ND > 	but converting the 4 way SMP OS to a 32 way SMP OS does a
ND > 	much larger amount of damage. We call this phenomenon the
ND > 	``locking cliff.''
ND >
ND > I can't find the follow-on paper.  I saw him give a lecture version
ND > of it at a convention.  This was several years ago, so I can't
ND > recite it faithfully, nor -- unfortunately -- can I find the
ND > slides on his site:
ND >
ND > 	http://www.bitmover.com/lm/
ND >
ND > The proposal (simply and probably incorrectly stated) was to fan a
ND > kernel out to each processor at boot time and run them independently.
ND > System-wide entities such as sockets would be coordinated by some
ND > independent mechanism.  (Again, several years ago, foggy recollection,
ND > etc.  Take my telling of it with a grain of salt.  I might not be
ND > representing it correctly.)

It is definitely the case that there is overhead in synchronization and
locking within the kernel which is a function of the number of processors.
There are though applications that can benefit from large numbers of
processors and large amount of shared memory. For these cases the underline
kernel should able to support them efficiently.

Having said that, if the applications in a workload of interest cannot benefit
by the large count of processors there is NO need for shared memory MP and a
cluster maybe more approriate. Conversely, an application that requires
efficient synchronization will be adversely affected by the high latencies and
the relatively low theoughput of a standard comodity interconnect, such as
GigEthernet.

I defintely agree that it is meaningless to use large count SMPs when there
are no apps to leverage them.


ND >
ND > MT> Take IRIX for example: it runs well on 1 CPU
ND > MT> or 128 CPUs.
ND >
ND > McVoy used to be a kernel programmer at SGI.  I think that's where
ND > where he picked up his lock phobia.
ND >

Good locking performance starts from an architecture with a solid design and
low fat in cache coherence protocols. Incidentally, the SGI SMPS (Origins and
Altix) are very decent designs in terms of h/w and IRIX is very decent in
large SMPs. Linux is not there yet, but the 2.6 version is a step closer.

ND > MT> Why wouldn't Linux be able to do this, if the right mechanisms
ND > MT> are implemented?
ND >
ND > Because they have a different design in mind.

The question is then what kernel do you employ in a large count SMP? It is
nice if you can leverage the cheaper Intel/AMD processors. That is the reason
that people started using 64-bit Linux for these processors. BTW, it seems
that SGI has done good job in making the 64-bit Linux kernel scalable and
efficient.

So, there is nothing inherent in inhibiting Linux to become SMP scalable and
efficient. In my oppinion there is no point to claim 'X should not be Y'
if X can be Y and there is a need for it.

ND >
ND > Regards,
ND >
ND > Nicholas
ND >
ND >
regards again,
Mike

On 2004-04-15, Timothy J. Bogart <tbogart@frii.net> wrote:
>
> Yes, I'd say with Messr. Orr, we have a winner.  At least with the lvm 
> comments.  That is really the last issue that sets AIX (and maybe IRIX?) 
> above all others.

My LVM usage of IRIX is somewhat limited (since you have to buy a license for
plexing, etc.) but last I knew you couldn't boot off of LVM-managed volume.

> And the typical guru-wannabe who says stuff like this probably isn't 
> even eligable for cereberal ossifcation as that requires a cerebellum. 
> Sheesh. Having cut my SA teeth largely in development groups, I have had 
> to deal (under duress) with the new priesthood of the computer world. 
> To replace the white coated figures who guarded the mainframe are the 
> bluejean clad, punk rock fringe (probably wearing their favorite brand 
> of multi plier) who have only ever seen the brand name big guys in their 
> beloved data center, and that is all that is ever going to be there. 
> The have their gold bound procedure manuals for backups, and that is 
> about the limit of their knowledge.
>
> Oh, well, that could get fun, but I hope the point is made.  90% of any 
> given group is not in the top 10%, and let's just keep to an actual 
> exchange of data and experience, eh what?

Okay, and your above paragraphs offer what for data and experience?
Career-wise (post-military) I cut my teeth in the open source arena, and I see
a great deal of value there.  The irony is that the bulk of it runs just fine
on proprietary Unices, and the combination of hardware and kernel offers
features that the Open Source kernels (understandably) don't provide.  So
let's be intellectually honest:  99% of kernel development done by at-home
hackers concentrate on commodity hardware simply because it's a) prevalent,
and b) cheap to acquire.  That doesn't put me in either the white-coat clique
or the IBM-fanboy groups, it's an acknowledgement of the practical reality.

At this point of my life I run a farm of RS/6000s (S7As to an SP cluster), and
I've been exceeding impressed by them.  IRIX remains my all-time favourite
UNIX, but it doesn't solve enough of my problems for me to not spend a
considerable amount of time maintaining my own distro of Linux.  And even
then, I wish Linux would take a few tips from the *BSDs at the same time.

Take your shots, I feel pretty damned comfortable that I can hold my own.

> Well, I guess I would need some better idea of scalability here again, 
> since the introduction of the Altix gives arguably the largest 
> horsepower in a single machine, the number of Linux clusters ranking 
> rather high in the super computer lists keeps growing, and it works 
> quite well in a number of instances of reviving old desktops and laptops 
> that aren't 'powerfull' enough to run that junk from the evil empire - 
> gosh, I still have to say that is pretty scalable.  As to reliablility, 
> well, I am always open to data, but my experience with kernel panics is 
> that they are so few and far between on anything except the evil empire, 
> it is getting pretty pretty hard to really calibrate the differences.  Yes?

I don't think you completely get it.  If you've ever touched IRIX on an
Origin 3000 you'd realise that even SGI has hardware that runs circles around
their own Altix product.  What makes Altix so impressive is not what it does,
but what it does at such a low price point.  Linux (and in this case, SGI)
deserves a great deal of credit for making super-computing affordable.  SGI
even moreso since they've done so with an implementation that takes a lot of
the complexity out of the software that runs on it, in comparison to the
traditional MPI implemenations of beowulf clusters.

Furthermore, you really need to refine your definition of "scalability".  Just
because it makes more efficient use of low-end hardware (no one here is going
to contest that Linux delivers much more bang for the buck that Windows on the
same hardware) doesn't mean it scales up to massive n-way.  For comparison
just within SGI, the Origin 3000 supports over a thousand CPUs, while each
Altix node only goes up to 256.  And the MIPS RISC implementation has
traditionally offered a higher instructions-executed per clock cycle than
almost all the other RISC designs. CISC never was in the running to compete.
Itanium, of course, is a different animal, and having never touched a VILW
chip, I can't compare the two definitively, but I'd be interested to hear what
anyone else here knows.  As you stated above:  let's stick to data and
experience.

Finally, on reliability, that's probably as subjective as it gets.  I
personally know of Novell boxes on x86 that have run with years+ uptime.  For
that matter, Windows can almost be made stable if you only ask it to do one
thing, and one thing only (forget stacking services on a single n-way box).
Personally, I've only used either Linus' kernel tree (from 2.0.x to 2.4.x) and
SGI's tree (since I'm a huge fan of XFS), and I've had good reliability as
well.  But, then, I'm a SCSI bigot over IDE, and I'm pretty religious on my
NICs and so on.  But let me ask you this:  whens the last time you had to do a
*kernel* update on AIX or IRIX due to local root exploit?  It's rare, and yet
we've had three of them on Linux this year alone.

I run Linux, Solaris, AIX, HP-UX, IRIX, and the *BSDs in my environment (we're
primarily an IBM shop but we do have applications dictating platforms on the
edges, as well as budgets).  Solaris is the worst for updates, Linux is
better, but IRIX and AIX are by far the best for not having to constantly
apply patches.

In short, let's be clear where I'm coming from (contrary to your misguided
image of me above):  I *like* Linux, and I *love* the transparency of the OS.
But I'm not going to stick my head in the sand and declare that Linux is ready
to supplant all other Unices.  It has a long way to go (and keep in mind that
the traditional Unices aren't standing still, either), and there's a damned
good reason why SGI, IBM, and HP have roadmaps for their UNIX as far as they
can forecast for the future.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On 2004-04-15, Timothy J. Bogart <tbogart@frii.net> wrote:
>
> Well, let me paraphrase your answer:  'I dunno, but the other stuff 
> feels cool'

?! Do you have anything of technical merit to bring to this discussion?  For
crying out loud, at least make the effort to read the comp.sys.sgi.* forums
and talk to some of the SGI employees that lurk there.  Linux is a great OS,
but it's not ready to supplant IRIX or AIX.  <sheesh>

> No, I have hardly touched IRIX, and not since about 1995, but that 
> really has nothing to do with not answering the question.  If you really 
>   had anything to say, I would listen to it.

Let me paraphrase you:  "I acknowledge that I know nothing about the company's
products that accounts for 70% of thier business, and I refuse to enlighten
myself."

The irony here is that we both like Linux, but you're antagnostic towards
anyone who isn't a devout zealot like yourself.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

Arthur Corliss wrote:

>> OK, I will byte <sic>.  What is SGI not telling us about their large
>> SMP boxes?  You have proof they faked their graphs they published
>> about
>> their linear SMP performance?
>
> Based on this comment I'd wager you've never used SGI's IRIX.  If you
> did, you'd understand that what they've accomplished is indeed
> impressive, but more so due to the use of commodity hardware rather
> than a revolution in the OS. IRIX, like AIX, is *tremendously* more
> scalable and reliable than Linux, and relatively more bug free.  If
> you followed the Linux Kernel Mailing List you'd see a lot of
> problems still being dealt with that the big Unices don't have to.

I beg to differ. Linux of course has lots of drawbacks but IRIX isn't one of
the most bugfree OSes either. Almost every Maintenance/Feature Update breaks
some compatibility with an application or introduces a bunch of new
troubles. Of course it's always possible that a patch can cause problems but
I yet have to see this on AIX or HP-UX at the same amount than on IRIX.

IRIX is a good OS but bugfreeness isn't really part of it...

> In summary:  The Altix is amazing because of the power they deliver
> for the price.  It is not amazing because it made IRIX (or AIX)
> obsolete on the high-end, because it didn't.

Well, at least for IRIX that's not completely true. The IRIX customer base
is shrinking for some years now as is the number of available software for
it, and the MIPS CPUs still have a really awful performance compared to
other high end platforms (especially POWER3/4, Itanium2, and if You count it
also Opteron). It's an open secret that further development of SGIs
MIPS/IRIX platform will be quite limited, with increasing ressources put on
IA64/Linux.

Benjamin

Timothy J. Bogart wrote:

> Well, I have some experiense with I/O performance being pretty ratty 
> on AIX, at least for small files.  Compare a gcc compile on AIX vs 
> even my laptop IDE drive.


Say what?  Compiling is an I/O test?  Give your head a shake.  Try
running a database.  One hard drive cannot stress the smallest
of systems.

Greg.

Arthur Corliss wrote:

>Amen, brother.  I'm in the same boat that you are, with AIX running the
>enterprise and data center, and Linux providing edge services (on an HP blade
>server since IBM won't touch the low-end blade server market).
>  
>

Ahem - ever hear of the #1 selling eServer BladeCenter?  Intel blades, 
PowerPC 970 blades,
best of breed packaging.  Very nice product...Windows, Linux, and soon AIX.

Greg.

On 2004-04-17, Greg <no@spam.com> wrote:
>
> Ahem - ever hear of the #1 selling eServer BladeCenter?  Intel blades, 
> PowerPC 970 blades,
> best of breed packaging.  Very nice product...Windows, Linux, and soon AIX.

Have you even priced it?  The HP Bl10e is a hell of a lot cheaper since it
uses the P4Ms, and it packs 20 blades into a 3U shelf.  IBM owns the market on
the high-end (with Itanium and Xeon processor blades), but when all you want
to do is consolidate a collection of white boxes into a shelf, that's not what
you buy.  I don't need that level of performance for DNS, NTP, SMTP, and other
light-weight servies.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On 2004-04-16, Benjamin Gawert <bgawert@gmx.de> wrote:
>
> I beg to differ. Linux of course has lots of drawbacks but IRIX isn't one of
> the most bugfree OSes either. Almost every Maintenance/Feature Update breaks
> some compatibility with an application or introduces a bunch of new
> troubles. Of course it's always possible that a patch can cause problems but
> I yet have to see this on AIX or HP-UX at the same amount than on IRIX.
>
> IRIX is a good OS but bugfreeness isn't really part of it...

AIX is definitely better at quality control and regression testing, but I
still update my IRIX boxes a hell of a lot less than my Linux boxes.
Especially on the maintenance stream.

> Well, at least for IRIX that's not completely true. The IRIX customer base
> is shrinking for some years now as is the number of available software for
> it, and the MIPS CPUs still have a really awful performance compared to
> other high end platforms (especially POWER3/4, Itanium2, and if You count it
> also Opteron). It's an open secret that further development of SGIs
> MIPS/IRIX platform will be quite limited, with increasing ressources put on
> IA64/Linux.

As part of the customer base, and judging by the mood in comp.sys.sgi.*, I'd
disagree with that.  Yes, the customer base is shrinking, but not because of a
lack of performance or scalability, but because of a lack of
cost-competitiveness and some poor support at times.  MIPS chips have
consistently placed near the top of all RISC chips in terms of operations
executed per clock cycle, but they've suffered terribly in the clock-rate
race, something that has far more hype than reality.  Anyone running databases
should know that you can't fully compensate for a lack of parallelism by
matching aggregate clock cycles.

SGI is certainly in their waning years right now, but if there was ever a
company that could engineer the hell out of a mousepad, it was them.  ;-)

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

Michael E. Thomadakis wrote:
> 
> On Thu, 15 Apr 2004, Timothy J. Bogart wrote:
> 
<snip><
> 
> I don't have performance data for small file I/O under AIX. How is the file
> I/O for large files? We are talking files of size 10-70GBs? The code running
> here often reads/writes files of these sizes.
> 
> The problem with AIX is that it is not immediately clear how to properly set
> the vmtune/vmo, ioo parameters to match the I/O and the VM characterstics of
> the workload. Documentation is also either too verbose, outdated or simply too
> voluminus. After one gets a handle on VM and IO  tunning things proceed
> smoothly. The I/O paths provide throughputs very close to the h/w limitations
> of the PCI and SCSI buses. But AFTER you tune up properly. And most
> importantly, after you LAY OUT the file systems on properly configured
> physical and logical volumes.
> 
> If small files are importand to your environment then you need to know the
> peroformance of your system in this respect. For the large file I/O that
> hammer the disks 24X7, AIX is fine (with the above provisions).

Hmmm, perhaps the whole I/O structure favors large files.  After giving 
up trying various tricks I turned it over to IBM support, who said there 
  was nothing broken.  An striped lv over 12 drives on a  4 way p630 , 
even parrallizing the compile took 16 times longer than my laptop, 
sitting pegged in I/O.  And that was pretty much stuck on the jfs log. 
Even untarring source code takes minutes vs seconds.  We are not talking 
about a few percent tuning here.
> 
> I CANNOT say the same for our large Linux box. The MAX we could get out of a
> theoretical MAX of 800MB/sec to the RAID was around 370MB/sec. SGI has
> attributed this to limitations of the SGI's block device drivers (xscsi) that
> are planning to replace in the next major release. FYI, xscsi is MUCH better
> than the native Linux scsi drivers.

Well, are you saying you are getting the theoretical max on other boxes? 
   Every filesystem I have ever seen falls far short of theoretical, and 
heaven knows you have your choice of filesystems in Linux, with some 
rather large differences for different kinds of loads.  Seems odd to me 
you only report one side of a comparison here.  Are you saying that a dd 
on the raw channel does not get full thruput???

> 
> The results you saw are either from xscsi or from their next proprietary scsi
> drivers. You are talking in a vacuum here. How can you tell what consitutes
> `good results'? See the previous paragraph.

Your are right, I didn't say that well.  See above comment on dd.  As I 
recall from the article, they had to tweek the drivers to get the full 
thruput on a raw device.  A high ninety some thing percent of channel 
utilization is pretty good.  Guess I need to go back and look at the 
article again, as I sure don't remember less than 50% utilization on a 
raw data channel.
> 
<snip>
> TJB > Well, I am afraid you seem a little confused.  You keep refering to SMP
> TJB > issues and then jump to file caching then to file I/O.
> 
> I am sorry that you cannot follow the discussion on the point of:
> 
> ``Linux vs UNIX systems''

No need to be sorry, just please actually address the issues, or make 
some actual comparisons.
> 
> Do you really
> TJB > have any specifics you can point to?  This really just seems to be
> TJB > bandying about some buzz words you heard, rather than real data.  I
> TJB > mean, filesystems aren't the kernel, the compilers and libraries are not
> TJB > the kernel, and 'system services' is generic enough to be a complete cop
> TJB > out.
> 
> As a matter of fact I have been pointing out VERY SPECIFIC points in the
> differences of Linux and UNIX. It is clear that you are confused and have lost
> track of the context and points of the discussion.

ibid
> 
> TJB > >
> TJB > > To get an idea on how things stand just go to
> TJB > > http://oss.sgi.com/archives
> TJB > > and review the issues mentioned there. Or just do a google search on
> TJB > > 'Linux VM performance problems'.
> TJB >
> TJB > Umm, I would never argue that Linux is mature, but it sure sounds like
> TJB > you have never dealt with the developers at, say, IBM or SUN.  It is
> TJB > just that the Linux laundry is quite public, and the issues with the
> TJB > 'ancients' can only be glimpsed after you pay them a lot of money for a
> TJB > support contract.
> 
> I do not disagree on the expensive h/w or the service quality.  However, the
> question is what UNIX delivers BETTER wrt Linux.  The quality of the support
> service by the vendor is neither a technical point of comparison, nor relevant
> here.

And I am not following the discussion?  Where did quality of service 
support come up - once again, you pointed out the 'immature' level of 
the code by looking a public discussion, and I pointed out that you can 
see much of the same thing or worse if you have a support contract and 
deal with enough proprietary developers in the course of solving your 
problem.

Quality of support services??????
> 
> TJB >
> TJB > You might want to review the timeframe that IBM even sold multiprocessor
> TJB > machines, and live with some J30/40/50 beasts for a few years before you
> TJB >   talk at lenght about code or hardware maturity.  Seems they approached
> TJB > high performance with clusters (SP) quite successfuly...hmmm, that
> TJB > sounds familiar.  8-)
> 
> There is no doubt that 'high-performance' of 10-20 years ago seems laughable
> today. Do not forget the strides the h/w has made in the meantime.
> 
> TJB >
> TJB > Sure Linux is immature, but I would argue the whole software industry is
> TJB > immature.  I have gotten admissions from support staff at IBM and SUN
> TJB > that made my skin crawl.  I would be awfully surprised if HP or SGI were
> TJB > that much different.  Pleasantly so, but still surprised.
> 
> Feeling -- even rightfully -- frustrated on the service you've received,
> cannot be converted into an argument that shows that Linux is technically
> superior than mature UNIX kernels. Do not use sentiments to evaluate something
> objectively.

ibid.  You really missed the boat here
> 
> Frankly, what
> TJB > amazes me most about Linux is just how far that has come, with the
> TJB > number of folks working on it.  The whole project should have self
> TJB > destructed years ago, but it seems to be getting better at an increasing
> TJB > rate.  Chances are, it will be come truly mature before any of the
> TJB > 'ancients' even though it is so much younger today.  8-)
> 
> I think YOU will be the FIRST one to disagree with your own words after you
> try to deploy Linux in a more 'heavy-duty' environment.

Well, here you answer a prediction about future events by reiterating 
your claims about the present.  I guess I shouldn't be surprised you 
can't follow the details if you can't follow the tense.  Sigh.
> 
> 
> The strong point of Linux is currently and overwhelmingly in the APPLICATIONS
> ARENA. There are many more -- and FREE -- applications for Linux than for
> UNIX. I would grant you can do almost completely away with proprietary s/w in
> most environments. I agree that the quality of the code in these apps is also
> very good.

Well, please enlighten me, as this is the first I have heard anyone 
claim this.  Of all the software running on the 'ancients', a subset 
(though more all the time) also sell their code for Linux.  And a very 
high percentage of free code comes with things like the 'configure' 
script as it is designed to  be portable to any of the operating systems 
that abide bye the UNIX standard, including Linux.  Not to mention that 
the subject OS of this newsgroup has even gone so far as to extend 
programming interfaces to that subset of free code that addresses APIs 
unique to Linux.

> 
> Again, the discussion started when someone claimed that 'Linux is so cool that
> it has already surpassed everything else'. This statement was disproved as
> soon as so many people (including myself) provided all the counterexamples for
> which Linux currently is next to sucks. These areas are important to people
> running larger SMPs, for heavy-duty computation, data or networking centers.
> 
> It is the immaturity of the kernel for THESE TYPES of environemnts. Linux 2.6
> promises and I think it is BETTER in these respects. How MUCH better, remains
> to be seen.

Thank you, for pointing out again that you keep thinking that the kernel 
has something to do with even the one (one sided) data point you try to 
put forth, with nothing addressing SMP, heavy duty computation, data or 
networking centers
> 
> Linux currently is 'perfect' for the low to middle end centers. For 24X7,
> heavy duty shops NOT really, yet.

Or relieability, for that matter.

I happen to have my own reasons for still believing that AIX is the best 
and easiest OS to admin, but I can't abide by people who knock something 
they don't seem to have any real understanding of.

Cheers.

Nicholas Dronen wrote:
> Michael E. Thomadakis <miket@hellas.tamu.edu> wrote:
> 
> 
> MT> On Thu, 15 Apr 2004, Nicholas Dronen wrote:
> 
> MT> ND > Nicholas Dronen <ndronen@io.frii.com> wrote:
> MT> ND >
> MT> ND > [ snip ]
> MT> ND >
> MT> ND > ND> I'm pretty sure the core Linux developers aren't interested in
> MT> ND > ND> optimizing the kernel for a great many CPUs if doing so would
> MT> ND > ND> damage its preformance on a humble desktop.  This paper
> MT> ND > ND> by Larry McVoy lays out their attitude pretty well.
> MT> ND >
> MT> ND > Er, *this* paper:
> MT> ND >
> MT> ND >    http://www.kanga.nu/~claw/docs/smp.pdf
> MT> ND >
> 
> MT> I just went through the paper and it barely scratches on the issues
> MT> involved with putting together a scalable OS. This objective is INDEED
> MT> very challenging and it has been known in the last 20 years.  
> 
> MT> Does he imply that Linux would or should, never have an efficient kernel
> MT> suitable for large SMPs?
> 
> Simply stated, should never have, at least not in a conventional sense.
> 
> 	ABSTRACT
> 
> 	We put for th the controversial idea that scaling can be a
> 	harmful thing to a general purpose OS if carried to far.
> 	The level of harm is directly proportional to the amount
> 	of scaling and is worse than linear in the number of
> 	processors.  We claim that converting a uniprocessor OS to
> 	a 4 way SMP OS introduces only a small amount of damage,
> 	but converting the 4 way SMP OS to a 32 way SMP OS does a
> 	much larger amount of damage. We call this phenomenon the
> 	``locking cliff.''
> 
> I can't find the follow-on paper.  I saw him give a lecture version
> of it at a convention.  This was several years ago, so I can't
> recite it faithfully, nor -- unfortunately -- can I find the
> slides on his site:
> 
> 	http://www.bitmover.com/lm/
> 
> The proposal (simply and probably incorrectly stated) was to fan a
> kernel out to each processor at boot time and run them independently.
> System-wide entities such as sockets would be coordinated by some
> independent mechanism.  (Again, several years ago, foggy recollection,
> etc.  Take my telling of it with a grain of salt.  I might not be
> representing it correctly.)

I think you are representing this correctly, but drawing the wrong 
conclusion.  To say that the same kernel cannot be optimized for both 
environments does not preclude that if that were true, at installation 
time, you could install different kernels for different class machines, 
number of processors, etc, much like you now install an athelon kernel 
or an i386,486,586 optimized kernel now.

Sure sounds like your are referring to the shindig at the TechCenter 
outside Dever a few years ago.....???
> 
> MT> Take IRIX for example: it runs well on 1 CPU
> MT> or 128 CPUs. 
> 
> McVoy used to be a kernel programmer at SGI.  I think that's where
> where he picked up his lock phobia.

Well, he was at SUN too, FWIW
> 
> MT> Why wouldn't Linux be able to do this, if the right mechanisms
> MT> are implemented?
> 
> Because they have a different design in mind.

Umm, it would, and the discussion was all around whether specific 
improvments for one regime would really harm the other, or whether the 
code would be clever enough to work well in both.
> 
> Regards,
> 
> Nicholas
> 

Arthur Corliss wrote:
> On 2004-04-15, Timothy J. Bogart <tbogart@frii.net> wrote:
> 
>>Yes, I'd say with Messr. Orr, we have a winner.  At least with the lvm 
>>comments.  That is really the last issue that sets AIX (and maybe IRIX?) 
>>above all others.
> 
> 
> My LVM usage of IRIX is somewhat limited (since you have to buy a license for
> plexing, etc.) but last I knew you couldn't boot off of LVM-managed volume.

Eeek!  Which concludes that AIX really is the  only one to get it right? 
  Wow.
> 
> 
>>And the typical guru-wannabe who says stuff like this probably isn't 
>>even eligable for cereberal ossifcation as that requires a cerebellum. 
>>Sheesh. Having cut my SA teeth largely in development groups, I have had 
>>to deal (under duress) with the new priesthood of the computer world. 
>>To replace the white coated figures who guarded the mainframe are the 
>>bluejean clad, punk rock fringe (probably wearing their favorite brand 
>>of multi plier) who have only ever seen the brand name big guys in their 
>>beloved data center, and that is all that is ever going to be there. 
>>The have their gold bound procedure manuals for backups, and that is 
>>about the limit of their knowledge.
>>
>>Oh, well, that could get fun, but I hope the point is made.  90% of any 
>>given group is not in the top 10%, and let's just keep to an actual 
>>exchange of data and experience, eh what?
> 
> 
> Okay, and your above paragraphs offer what for data and experience?

Umm, I guess the point that it is easy to spew meaningless but somewhat 
clever insults without really saying anything - and that could get fun, 
but lets please get back to business.  ??

> Career-wise (post-military) I cut my teeth in the open source arena, and I see
> a great deal of value there.  The irony is that the bulk of it runs just fine
> on proprietary Unices, and the combination of hardware and kernel offers
> features that the Open Source kernels (understandably) don't provide.  So
> let's be intellectually honest:  99% of kernel development done by at-home
> hackers concentrate on commodity hardware simply because it's a) prevalent,
> and b) cheap to acquire.  That doesn't put me in either the white-coat clique
> or the IBM-fanboy groups, it's an acknowledgement of the practical reality.

Hmmm, and what do you think is hardware dependent in this kernel 
hacking?  Sure, there are device driver issues and such, but do you 
really think that real kernel issues care about whether the code is on 
top of any given hardware, or hardware simulator?  Are you really 
talking about the optimizations for the device specific code below the 
kernel?

Not to mention that a small excursion to ebay will show you that the 
budget required to afford RS6K, SUN or HP propietary beasties is just 
not what it used to be - as long as you don't need the very latest.

But really, asking whether a kernel runs well on a particular brand or 
model is not the same as asking whether it is a well designed and 
efficient kernel.
> 
> At this point of my life I run a farm of RS/6000s (S7As to an SP cluster), and
> I've been exceeding impressed by them.  IRIX remains my all-time favourite
> UNIX, but it doesn't solve enough of my problems for me to not spend a
> considerable amount of time maintaining my own distro of Linux.  And even
> then, I wish Linux would take a few tips from the *BSDs at the same time.
> 
> Take your shots, I feel pretty damned comfortable that I can hold my own.

OK, here is what may be my best shot.  With all that going for you, 
please don't make silly comments about 'linux fan boys', 'IBM fan boys' 
or anything else that makes puts you solidly in a large group of very 
stupid people who really don't have a clue.  I mean, I honestly can't 
think of any Linux fan in my personal experience who has only ever seen 
Linux.  Let alone considering where you are posting this.  Bigotry isn't 
pretty in any guise.
> 
> 
>>Well, I guess I would need some better idea of scalability here again, 
>>since the introduction of the Altix gives arguably the largest 
>>horsepower in a single machine, the number of Linux clusters ranking 
>>rather high in the super computer lists keeps growing, and it works 
>>quite well in a number of instances of reviving old desktops and laptops 
>>that aren't 'powerfull' enough to run that junk from the evil empire - 
>>gosh, I still have to say that is pretty scalable.  As to reliablility, 
>>well, I am always open to data, but my experience with kernel panics is 
>>that they are so few and far between on anything except the evil empire, 
>>it is getting pretty pretty hard to really calibrate the differences.  Yes?
> 
> 
> I don't think you completely get it.  If you've ever touched IRIX on an
> Origin 3000 you'd realise that even SGI has hardware that runs circles around
> their own Altix product.  What makes Altix so impressive is not what it does,
> but what it does at such a low price point.  Linux (and in this case, SGI)
> deserves a great deal of credit for making super-computing affordable.  SGI
> even moreso since they've done so with an implementation that takes a lot of
> the complexity out of the software that runs on it, in comparison to the
> traditional MPI implemenations of beowulf clusters.

Well, that at least is trying to get to the point.  As I pointed out 
elsewhere, I don't have the experience with the Origin big iron, and I 
am just looking for something better than 'if you touched it you would 
know'.  I say, if you have any actual data, you would be exclaiming it 
loudly.  I guess not, eh?  The published benchmarks by SGI show the 
Altix running circles around the Origin.  I guess nobody using that code 
  ever touched IRIX, eh?
> 
> Furthermore, you really need to refine your definition of "scalability".  Just
> because it makes more efficient use of low-end hardware (no one here is going
> to contest that Linux delivers much more bang for the buck that Windows on the
> same hardware) doesn't mean it scales up to massive n-way.  For comparison
> just within SGI, the Origin 3000 supports over a thousand CPUs, while each
> Altix node only goes up to 256.  And the MIPS RISC implementation has
> traditionally offered a higher instructions-executed per clock cycle than
> almost all the other RISC designs. CISC never was in the running to compete.
> Itanium, of course, is a different animal, and having never touched a VILW
> chip, I can't compare the two definitively, but I'd be interested to hear what
> anyone else here knows.  As you stated above:  let's stick to data and
> experience.

OK, I have direct experience with the low end.  I read the specs on the 
big iron because I don't own any.  I am waiting for someone to give data 
and experience that actually relates to performance differences, rather 
than 'you just don't get it, and if you were cool like me, and touched 
one of these things, you would JUST KNOW'.  Well, frankly, in my 25 
years of dealing with things, I have yet to gain that level of 
performance understanding by touching a machine.  Perhaps, you could do 
us all a favor and concentrate on explaining how you do this.

Now if I just look at things like benchmarks, you might see the SGI says 
the fp_rate, for  example, of a 64 way Altix with 1500 MHz processors is 
more than 4 times the output of the 64 way Origin with 600 Mhz 
processors (the fastest results available on the SPEC site).  Now, 
without touching an Origin, I would conclude that it would take more 
than 4 times the number  of processors to perform the actual work.  But, 
then, as I say,  I haven't touched one.  Perhaps you can see why I am so 
confused by using un-data like data such as company published benchmark 
results.
> 
> Finally, on reliability, that's probably as subjective as it gets.  I
> personally know of Novell boxes on x86 that have run with years+ uptime.  For
> that matter, Windows can almost be made stable if you only ask it to do one
> thing, and one thing only (forget stacking services on a single n-way box).
> Personally, I've only used either Linus' kernel tree (from 2.0.x to 2.4.x) and
> SGI's tree (since I'm a huge fan of XFS), and I've had good reliability as
> well.  But, then, I'm a SCSI bigot over IDE, and I'm pretty religious on my
> NICs and so on.  But let me ask you this:  whens the last time you had to do a
> *kernel* update on AIX or IRIX due to local root exploit?  It's rare, and yet
> we've had three of them on Linux this year alone.

Well, I would have to go back and look and the specific reasons I had to 
do the particular kernel update, and though I am not in front of an AIX 
box right now, but I will put down a large amount of money on my memory 
that the number associated with the kernel is larger than 5 on my 5.2 
box.  And frankly, since I started maintaining AIX in about 1991 or so, 
there has been more than one instance of kernel or other packages that 
had to be updated within a week of even a full blown maintenance release 
(with is, as you know, a set of patches TESTED together for reliability) 
due to problems introuduced.  As you say, it is rather subjective, but 
at least the kind of fix data you are referring to is available - and I 
will stand by the posistion that all the vendors should be ashamed of 
themselves.
> 
> I run Linux, Solaris, AIX, HP-UX, IRIX, and the *BSDs in my environment (we're
> primarily an IBM shop but we do have applications dictating platforms on the
> edges, as well as budgets).  Solaris is the worst for updates, Linux is
> better, but IRIX and AIX are by far the best for not having to constantly
> apply patches.

Hmmm, I would put in one question, having dealt mostly with the first 
three - you perhaps mean 'required security patch' frequency?  Someone 
passed me an interesting presentation some months ago.  Seems the VMS 
people put together a statistical analysis of CERT activity since it's 
inception.  I would have to look up the specifics again to quote the 
numbers, but as you would expect, Windows was obscenely huge, with 
Solaris and Linux neck and neck, and AIX and TRUE-64 as being the best 
of the UNIX world.  But the spread of the UNIX world was so tiny 
compared to the jump up to the you know who.  It may be a bit of an 
overstatement, but it is almost like picking the proverbial flyshit out 
ot the pepper to nitpick withing the UNIX world.  Of course, there will 
be small stretches of time where one my bloat compared to the others.
> 
> In short, let's be clear where I'm coming from (contrary to your misguided
> image of me above):  I *like* Linux, and I *love* the transparency of the OS.
> But I'm not going to stick my head in the sand and declare that Linux is ready
> to supplant all other Unices.  It has a long way to go (and keep in mind that
> the traditional Unices aren't standing still, either), and there's a damned
> good reason why SGI, IBM, and HP have roadmaps for their UNIX as far as they
> can forecast for the future.

I am not going to stick my head in the sand either, but I will say here 
(and I think in another post or two) that I am tired of non-data bearing 
criticisms in this day and age.  If Linux has proved anything, it has 
proved that the position of the major players in not at all safe, and 
real, serious analysis must be made to see what is best for a given 
need.  One could reliably laugh at the Windows onslaught, but not the 
Linux one.

And I say that in confidence without touching a single Origin box.
> 

Arthur Corliss wrote:
> On 2004-04-15, Timothy J. Bogart <tbogart@frii.net> wrote:
> 
>>Well, let me paraphrase your answer:  'I dunno, but the other stuff 
>>feels cool'
> 
> 
> ?! Do you have anything of technical merit to bring to this discussion?  For
> crying out loud, at least make the effort to read the comp.sys.sgi.* forums
> and talk to some of the SGI employees that lurk there.  Linux is a great OS,
> but it's not ready to supplant IRIX or AIX.  <sheesh>

Well, I might, but then there seem to be those who would not recognize 
it.  To go back to part of what you snipped

"> OK, I will byte <sic>.  What is SGI not telling us about their large 
SMP boxes?  You have proof they faked their graphs they published about 
their linear SMP performance?
Based on this comment I'd wager you've never used SGI's IRIX."

Now, the person who thinks that using IRIX - under whatever 
circumstances - say on a single processor workstation, would somehow 
answer the stated question, in turn asks me if I have any technical 
merit to bring to a discussion?  I have enough technical merit to know 
that knowledge of an operating system doesn't tell me SQUAT about the 
claimed linearity of SMP performance on any give bloody box!
> 
>>No, I have hardly touched IRIX, and not since about 1995, but that 
>>really has nothing to do with not answering the question.  If you really 
>>  had anything to say, I would listen to it.
> 
> 
> Let me paraphrase you:  "I acknowledge that I know nothing about the company's
> products that accounts for 70% of thier business, and I refuse to enlighten
> myself."
> 
> The irony here is that we both like Linux, but you're antagnostic towards
> anyone who isn't a devout zealot like yourself.

Well, if I need to explain that knowing about IRIX still wouldn't tell 
me much about 70% of their product line, it might not be worth it.  But 
to get back grounded here; you are making claims, I would be very 
interested in the data to back up these claims.  The more we have to 
deal with the laying of hands as opposed to data to back up your 
arguments, the sillier you argument becomes.  Particularly when it seems 
to contradict what the people who build the stuff say.

I don't have squat for experience with IRIX or SGI products, but I have 
gone to their techical shows and listened to their developers and Linux 
conferences and have looked at at least some of their published 
benchmarks and journal articles.  The big difference here seems to be 
that I have understood some of these data sources.
> 

Greg wrote:
> Timothy J. Bogart wrote:
> 
>> Well, I have some experiense with I/O performance being pretty ratty 
>> on AIX, at least for small files.  Compare a gcc compile on AIX vs 
>> even my laptop IDE drive.
> 
> 
> 
> Say what?  Compiling is an I/O test?  Give your head a shake.  Try
> running a database.  One hard drive cannot stress the smallest
> of systems.
> 
> Greg.

Believe me, it didn't start out that way, and my head was shaking 
violently.  But when a gcc compile took overnight on a p630 it got my 
attention.  And that is spread out over 12 disks, not one.  I didn't 
have a filesystem based database to play with at the time, but I hope to 
get around to that.

Databases that don't use the filesystem would be a different animal, now 
  wouldn't it?

Arthur Corliss wrote:

> AIX is definitely better at quality control and regression testing,
> but I still update my IRIX boxes a hell of a lot less than my Linux
> boxes. Especially on the maintenance stream.

Can't say much to Linux since I want to avoid that until it is somewhat
mature. But from what I heard the current situation with Linux is chaotic...

> As part of the customer base, and judging by the mood in
> comp.sys.sgi.*, I'd disagree with that.

Well, I wouldn't give too much on the mood at comp.sys.sgi.*. Unlike other
newsgroups for commercial UNIXes in the SGI groups there is a strong
antipaty against everything which is non-IRIX and especially against Linux,
but not based on arguments but on stupid bashing and trolling. The remaining
people that kept a view for reality also seem to agree that MIPS/IRIX isn't
the way to go for most problems today...

>  Yes, the customer base is
> shrinking, but not because of a lack of performance or scalability,
> but because of a lack of cost-competitiveness and some poor support
> at times.

Yes, support is poor, especially here in Germany. But the poor support is
just a part of it.

> MIPS chips have consistently placed near the top of all
> RISC chips in terms of operations executed per clock cycle, but
> they've suffered terribly in the clock-rate race, something that has
> far more hype than reality.  Anyone running databases should know
> that you can't fully compensate for a lack of parallelism by matching
> aggregate clock cycles.

Well, MIPS indeed is good at performance per clock cycle, but that doesn't
help when the absolute performance is bad. And absolute performance is what
is more important than performance per clock cycle or a high clock rate. And
the absolute performance of the current MIPS CPUs is really bad, especially
when also opting in the price.

> SGI is certainly in their waning years right now, but if there was
> ever a company that could engineer the hell out of a mousepad, it was
> them.  ;-)

Maybe. But then, SGI often had some good ideas but executed them poorly. A
lot of their hardware has had design flaws:

- Personal IRIS 4D3x: stupid and insufficient cooling design (often lead to
dead Mainboards because the RAMDACs cooked themselves), high PSU failure
rate (this seems to be some kind sof SGI trademark)
- Indigo: NVRAM battery soldered on the mainboard on R4000 models (makes it
hard to replace when empty, so a dead 3$ battery required a 1200$ CPU Board
replacement)
- Challenge L/XL/DM and Onyx: High PSU failure rate with danger of PSU
cathing fire (SGI replaced the PSUs several years later), dying IO4-Boards,
high failure rate with R8000 boards (cache)
- O2: high PSU failure rate, dying ethernet ports, a design flaw makes O2s
with R10000 CPU (150Mhz and 195MHz models) unuseable for video capturing due
to timing problems, R7000 O2s were sold and recalled because of CPU design
flaws
- SGI320/540: high PSU failure rate, high mainboard failure rate (especially
if the SGI/QLogic SCSI Controller has been used), stupid memory sockets
which lock the module only on one side (leads to memory contact problems),
useless firewire ports due to the lack of working drivers, buggy gfx
drivers, and (really stupid) no way of changing the brightness on the SGI
1600SW TFT display (which is even more sad since this display is really
good!)
- Octane: high PSU failure rate, stupid cooling design wich even at room
temperature operates near its limits, SI/SSI/MXI Texture RAM modules got so
hot that the pins of the RDRAM memory ICs desoldered themselves, dying
ethernet ports, older CPU boards had contact problems with some ICs on the
board, the extremely sensible High Pressure Connectors often had contact
problems and made the Octane unreliable
- Origin 2000/2100: high PSU failure rate, lots of dead CPU modules

We had tons of SGI equipment but the little flaws and and the bad support
brought us away from SGI. I can't remember any HP9000 or RS/6000 making that
much trouble like the SGIs we had.

Benjamin

Timothy J. Bogart wrote:

> Greg wrote:
>
>> Timothy J. Bogart wrote:
>>
>>> Well, I have some experiense with I/O performance being pretty ratty 
>>> on AIX, at least for small files.  Compare a gcc compile on AIX vs 
>>> even my laptop IDE drive.
>>
>>
>>
>>
>> Say what?  Compiling is an I/O test?  Give your head a shake.  Try
>> running a database.  One hard drive cannot stress the smallest
>> of systems.
>>
>> Greg.
>
>
> Believe me, it didn't start out that way, and my head was shaking 
> violently.  But when a gcc compile took overnight on a p630 it got my 
> attention.  And that is spread out over 12 disks, not one.  I didn't 
> have a filesystem based database to play with at the time, but I hope 
> to get around to that.
>
> Databases that don't use the filesystem would be a different animal, 
> now  wouldn't it?


Depends, JFS and JFS2 can do read ahead and write behind on their own
and large memory systems can use all the spare memory for file caching,
hopefully minimizing the I/O to disk entirely.  Look how much better HP
and IBM did on TPC-C after Stupidome and p690 went to 1TB of
memory supported.  (Extreme case, yes)

There is no way a compile on p630 should take longer than a laptop.  It's
probably GCC.  Try downloading a trial copy of a much better compiler:
C for AIX.

Greg.

> >>> Well, I have some experiense with I/O performance being pretty ratty
> >>> on AIX, at least for small files.  Compare a gcc compile on AIX vs
> >>> even my laptop IDE drive.

Take a closer look, what takes so much time building the gcc suite:
On AIX every library is built in different configurations for different
CPUs.

Another time-eater is the Korn Shell during the configuration phase.
AIX' ksh is very slow when expanding very large commandlines.

My 2ct to the main thread:
Linux breaks kernel interfaces quite often.
Often it looks like: first code, then think.


---
Uli

(Reply to ulrich <dot> link <domain-delimiter> epost <dot> de)

On 2004-04-16, Arthur Corliss <acorliss@bifrost.nevaeh-linux.org> wrote:

> But let me ask you this:  whens the last time you had to do a *kernel*
> update on AIX or IRIX due to local root exploit?  It's rare, and yet
> we've had three of them on Linux this year alone.

AIX and Irix may or may not be more secure than Linux, but in
general I would be very wary of arguments based on equating
"security" with "few published alerts" (or fixes).

Not long ago, there have been a couple studies "proving" that
Windows was more secure than Linux, through artful
misinterpretation of security alerts statistics.

-- 
Andr� Majorel <URL:http://www.teaser.fr/~amajorel/>
"Finally I am becoming stupider no more." -- Paul Erd�s' epitaph

Greg wrote:
> Timothy J. Bogart wrote:
> 
>> Greg wrote:
>>
>>> Timothy J. Bogart wrote:
>>>
>>>> Well, I have some experiense with I/O performance being pretty ratty 
>>>> on AIX, at least for small files.  Compare a gcc compile on AIX vs 
>>>> even my laptop IDE drive.
>>>
>>>
>>>
>>>
>>>
>>> Say what?  Compiling is an I/O test?  Give your head a shake.  Try
>>> running a database.  One hard drive cannot stress the smallest
>>> of systems.
>>>
>>> Greg.
>>
>>
>>
>> Believe me, it didn't start out that way, and my head was shaking 
>> violently.  But when a gcc compile took overnight on a p630 it got my 
>> attention.  And that is spread out over 12 disks, not one.  I didn't 
>> have a filesystem based database to play with at the time, but I hope 
>> to get around to that.
>>
>> Databases that don't use the filesystem would be a different animal, 
>> now  wouldn't it?
> 
> 
> 
> Depends, JFS and JFS2 can do read ahead and write behind on their own
> and large memory systems can use all the spare memory for file caching,
> hopefully minimizing the I/O to disk entirely.  Look how much better HP
> and IBM did on TPC-C after Stupidome and p690 went to 1TB of
> memory supported.  (Extreme case, yes)
> 
> There is no way a compile on p630 should take longer than a laptop.  It's
> probably GCC.  Try downloading a trial copy of a much better compiler:
> C for AIX.
> 
> Greg.
Well, maybe they are supposed to, but the point is the behaviour doesn't 
match the promise.  I/0 bound the whold way thru.  And the 4 gigs of RAM 
on the 630 didn't seem to help much.

Umm, right, must be that nasty free software eh?  Well, I don't need to 
download a trial version as I even own the compiler at home.  And no, it 
didn't make a noticable difference doing the stage one compile with the 
IBM compiler, or using the in-line logging of JFS2.

Even wierder, the compiler was faster by about 25% on my home 43p-150 
(single drive) than the p630.

I don'y have access to the 630 anymore, but I hope to look into this 
more when I have my SSA set up at home. 8-)

Uli Link wrote:
>>>>>Well, I have some experiense with I/O performance being pretty ratty
>>>>>on AIX, at least for small files.  Compare a gcc compile on AIX vs
>>>>>even my laptop IDE drive.
> 
> 
> Take a closer look, what takes so much time building the gcc suite:
> On AIX every library is built in different configurations for different
> CPUs.

If you make the assumption you are building the optimized for the target 
machine, which doesn't match here, let alone have anything to do with 
observed behavior of saturating I/O.

In fact, since only a subset of the code is built for AIX, the actual 
disparity is higher.
> 
> Another time-eater is the Korn Shell during the configuration phase.
> AIX' ksh is very slow when expanding very large commandlines.
> 
> My 2ct to the main thread:
> Linux breaks kernel interfaces quite often.
> Often it looks like: first code, then think.

Well, rather than making rash assumptions, you could actually look at 
the discussions that go on for these decisions, but then that would 
spoil things wouldn't it.  It would be one thing if you actually 
disagreed with a decision being made, but you don't even bother to look.

Timothy J. Bogart wrote:
> Arthur Corliss wrote:
>> plexing, etc.) but last I knew you couldn't boot off of LVM-managed 
>> volume.
> Eeek!  Which concludes that AIX really is the  only one to get it right? 
>  Wow.

Dec/Compaq/hp Tru64 can boot via lvm-based volumes (advfs). too bad it's 
on the way out (though advfs is slated to be incorporated in future hpux 
versions). advfs is.. 'odd' for an lvm but does implement the basic 
features of an lv structure (dynamic pv addition, volume growth AND 
reduction).

also, some OSs may boot off veritas volumes if so installed.. at least 
when we talked to them hp-booting was in the works.

> Not to mention that a small excursion to ebay will show you that the 
> budget required to afford RS6K, SUN or HP propietary beasties is just 
> not what it used to be - as long as you don't need the very latest.

... or testament being the second bedroom of some geek abodes (like mine 
:) with better than three PLATFORMS (not OS, but platform.. 
hp/alpha/ibm/sgi/intel and someday a sun :)

-r

Timmy,

I started makign a good faith effort to help you separate reality from your
misconceptions, but as I was reading your 'reply' I realized that you are too
clueless and too obnoxious to waste my time answering you..

-m





On Fri, 16 Apr 2004, Timothy J. Bogart wrote:

t|  > I don't have performance data for small file I/O under AIX. How is the file
t|  > I/O for large files? We are talking files of size 10-70GBs? The code running
t|  > here often reads/writes files of these sizes.
t|  >
t|  > The problem with AIX is that it is not immediately clear how to properly set
t|  > the vmtune/vmo, ioo parameters to match the I/O and the VM characterstics of
t|  > the workload. Documentation is also either too verbose, outdated or simply too
t|  > voluminus. After one gets a handle on VM and IO  tunning things proceed
t|  > smoothly. The I/O paths provide throughputs very close to the h/w limitations
t|  > of the PCI and SCSI buses. But AFTER you tune up properly. And most
t|  > importantly, after you LAY OUT the file systems on properly configured
t|  > physical and logical volumes.
t|  >
t|  > If small files are importand to your environment then you need to know the
t|  > peroformance of your system in this respect. For the large file I/O that
t|  > hammer the disks 24X7, AIX is fine (with the above provisions).
t|
t|  Hmmm, perhaps the whole I/O structure favors large files.  After giving
t|  up trying various tricks I turned it over to IBM support, who said there
t|    was nothing broken.  An striped lv over 12 drives on a  4 way p630 ,
t|  even parrallizing the compile took 16 times longer than my laptop,

AIX can have bad performance if tuned up in the WRONG way. Example: if you
want to maximize small file I/O, then GOOD LUCK with that from a 12-way
striped LV! Why do you need 12-way striped LVs? This is appropriarte for
sequential files of large size. For small and frequent file I/O you need to
spread the I/O accross as many drives as possible.

What is the amount of max read ahead ?




t|  sitting pegged in I/O.  And that was pretty much stuck on the jfs log.
t|  Even untarring source code takes minutes vs seconds.  We are not talking
t|  about a few percent tuning here.

Your I/O is not tuned up for the frequent small file I/O for code files.

t|  >
t|  > I CANNOT say the same for our large Linux box. The MAX we could get out of a
t|  > theoretical MAX of 800MB/sec to the RAID was around 370MB/sec. SGI has
t|  > attributed this to limitations of the SGI's block device drivers (xscsi) that
t|  > are planning to replace in the next major release. FYI, xscsi is MUCH better
t|  > than the native Linux scsi drivers.
t|
t|  Well, are you saying you are getting the theoretical max on other boxes?
t|     Every filesystem I have ever seen falls far short of theoretical, and

AIX behaves VERY WELL if properly tuned. We are seeing close to the
theoretical, i.e., the bus bandwidths.

t|  heaven knows you have your choice of filesystems in Linux, with some
t|  rather large differences for different kinds of loads.  Seems odd to me
t|  you only report one side of a comparison here.  Are you saying that a dd
t|  on the raw channel does not get full thruput???

It was a dd to a striped volume where the slices are seen across all four FC
channels. It was a plain data write to disk to measure the i/o path's
throughput. It came out a little less than 1/2 of 800MB/sec

t|
t|  >
t|  > The results you saw are either from xscsi or from their next proprietary scsi
t|  > drivers. You are talking in a vacuum here. How can you tell what consitutes
t|  > `good results'? See the previous paragraph.
t|
t|  Your are right, I didn't say that well.  See above comment on dd.  As I
t|  recall from the article, they had to tweek the drivers to get the full
t|  thruput on a raw device.  A high ninety some thing percent of channel
t|  utilization is pretty good.  Guess I need to go back and look at the
t|  article again, as I sure don't remember less than 50% utilization on a
t|  raw data channel.

What was the max of that channel? What kind of channel?

t|  >
t|  <snip>
t|  > TJB > Well, I am afraid you seem a little confused.  You keep refering to SMP
t|  > TJB > issues and then jump to file caching then to file I/O.
t|  >
t|  > I am sorry that you cannot follow the discussion on the point of:
t|  >
t|  > ``Linux vs UNIX systems''
t|
t|  No need to be sorry, just please actually address the issues, or make
t|  some actual comparisons.

Advice: Read, think, answer;

What issue are you adressing? Where are your comparisons?

Lost again? Long sentences are hard to comprehend?


t|  >
t|  > Do you really
t|  > TJB > have any specifics you can point to?  This really just seems to be
t|  > TJB > bandying about some buzz words you heard, rather than real data.  I
t|  > TJB > mean, filesystems aren't the kernel, the compilers and libraries are not
t|  > TJB > the kernel, and 'system services' is generic enough to be a complete cop
t|  > TJB > out.
t|  >
t|  > As a matter of fact I have been pointing out VERY SPECIFIC points in the
t|  > differences of Linux and UNIX. It is clear that you are confused and have lost
t|  > track of the context and points of the discussion.
t|
t|  ibid
t|  >
t|  > TJB > >
t|  > TJB > > To get an idea on how things stand just go to
t|  > TJB > > http://oss.sgi.com/archives
t|  > TJB > > and review the issues mentioned there. Or just do a google search on
t|  > TJB > > 'Linux VM performance problems'.
t|  > TJB >
t|  > TJB > Umm, I would never argue that Linux is mature, but it sure sounds like
t|  > TJB > you have never dealt with the developers at, say, IBM or SUN.  It is
t|  > TJB > just that the Linux laundry is quite public, and the issues with the
t|  > TJB > 'ancients' can only be glimpsed after you pay them a lot of money for a
t|  > TJB > support contract.
t|  >
t|  > I do not disagree on the expensive h/w or the service quality.  However, the
t|  > question is what UNIX delivers BETTER wrt Linux.  The quality of the support
t|  > service by the vendor is neither a technical point of comparison, nor relevant
t|  > here.
t|
t|  And I am not following the discussion?  Where did quality of service
t|  support come up - once again, you pointed out the 'immature' level of
t|  the code by looking a public discussion, and I pointed out that you can
t|  see much of the same thing or worse if you have a support contract and
t|  deal with enough proprietary developers in the course of solving your
t|  problem.
t|
t|  Quality of support services??????
t|  >
t|  > TJB >
t|  > TJB > You might want to review the timeframe that IBM even sold multiprocessor
t|  > TJB > machines, and live with some J30/40/50 beasts for a few years before you
t|  > TJB >   talk at lenght about code or hardware maturity.  Seems they approached
t|  > TJB > high performance with clusters (SP) quite successfuly...hmmm, that
t|  > TJB > sounds familiar.  8-)
t|  >
t|  > There is no doubt that 'high-performance' of 10-20 years ago seems laughable
t|  > today. Do not forget the strides the h/w has made in the meantime.
t|  >
t|  > TJB >
t|  > TJB > Sure Linux is immature, but I would argue the whole software industry is
t|  > TJB > immature.  I have gotten admissions from support staff at IBM and SUN
t|  > TJB > that made my skin crawl.  I would be awfully surprised if HP or SGI were
t|  > TJB > that much different.  Pleasantly so, but still surprised.
t|  >
t|  > Feeling -- even rightfully -- frustrated on the service you've received,
t|  > cannot be converted into an argument that shows that Linux is technically
t|  > superior than mature UNIX kernels. Do not use sentiments to evaluate something
t|  > objectively.
t|
t|  ibid.  You really missed the boat here
t|  >
t|  > Frankly, what
t|  > TJB > amazes me most about Linux is just how far that has come, with the
t|  > TJB > number of folks working on it.  The whole project should have self
t|  > TJB > destructed years ago, but it seems to be getting better at an increasing
t|  > TJB > rate.  Chances are, it will be come truly mature before any of the
t|  > TJB > 'ancients' even though it is so much younger today.  8-)
t|  >
t|  > I think YOU will be the FIRST one to disagree with your own words after you
t|  > try to deploy Linux in a more 'heavy-duty' environment.
t|
t|  Well, here you answer a prediction about future events by reiterating
t|  your claims about the present.  I guess I shouldn't be surprised you
t|  can't follow the details if you can't follow the tense.  Sigh.
t|  >
t|  >
t|  > The strong point of Linux is currently and overwhelmingly in the APPLICATIONS
t|  > ARENA. There are many more -- and FREE -- applications for Linux than for
t|  > UNIX. I would grant you can do almost completely away with proprietary s/w in
t|  > most environments. I agree that the quality of the code in these apps is also
t|  > very good.
t|
t|  Well, please enlighten me, as this is the first I have heard anyone
t|  claim this.  Of all the software running on the 'ancients', a subset
t|  (though more all the time) also sell their code for Linux.  And a very
t|  high percentage of free code comes with things like the 'configure'
t|  script as it is designed to  be portable to any of the operating systems
t|  that abide bye the UNIX standard, including Linux.  Not to mention that
t|  the subject OS of this newsgroup has even gone so far as to extend
t|  programming interfaces to that subset of free code that addresses APIs
t|  unique to Linux.
t|
t|  >
t|  > Again, the discussion started when someone claimed that 'Linux is so cool that
t|  > it has already surpassed everything else'. This statement was disproved as
t|  > soon as so many people (including myself) provided all the counterexamples for
t|  > which Linux currently is next to sucks. These areas are important to people
t|  > running larger SMPs, for heavy-duty computation, data or networking centers.
t|  >
t|  > It is the immaturity of the kernel for THESE TYPES of environemnts. Linux 2.6
t|  > promises and I think it is BETTER in these respects. How MUCH better, remains
t|  > to be seen.
t|
t|  Thank you, for pointing out again that you keep thinking that the kernel
t|  has something to do with even the one (one sided) data point you try to
t|  put forth, with nothing addressing SMP, heavy duty computation, data or
t|  networking centers
t|  >
t|  > Linux currently is 'perfect' for the low to middle end centers. For 24X7,
t|  > heavy duty shops NOT really, yet.
t|
t|  Or relieability, for that matter.
t|
t|  I happen to have my own reasons for still believing that AIX is the best
t|  and easiest OS to admin, but I can't abide by people who knock something
t|  they don't seem to have any real understanding of.
t|
t|  Cheers.
t|
t|

> >>>>>Well, I have some experiense with I/O performance being pretty ratty
> >>>>>on AIX, at least for small files.  Compare a gcc compile on AIX vs
> >>>>>even my laptop IDE drive.

I assume, the notebook with IDE drive is _not_ running AIX.

> > Take a closer look, what takes so much time building the gcc suite:
> > On AIX every library is built in different configurations for different
> > CPUs.
> 
> If you make the assumption you are building the optimized for the target
> machine, which doesn't match here, let alone have anything to do with
> observed behavior of saturating I/O.

I made the assumption that it was a build of the gcc opposed to a build
using the gcc. If you talk about I/O, there are more kinds of I/O than
only disk I/O.
But you surely know this better ;-)

> >
> > My 2ct to the main thread:
> > Linux breaks kernel interfaces quite often.
> > Often it looks like: first code, then think.
> 
> Well, rather than making rash assumptions, you could actually look at
> the discussions that go on for these decisions, but then that would
> spoil things wouldn't it.  It would be one thing if you actually
> disagreed with a decision being made, but you don't even bother to look.

Feel free to ignore my 2ct. I make my money with
supporting/configuring/building Linux for industry PC and embedded
devices. No more as a sys admin for software development. It does not
matter what I like, it's what customers pay for ;-)

Final answer to post of TJB. No more fish ;-)

---
Uli

(Reply to ulrich <dot> link <domain-delimiter> epost <dot> de)

Nobody wrote:
> Timothy J. Bogart wrote:
> 
>> Arthur Corliss wrote:
>>
>>> plexing, etc.) but last I knew you couldn't boot off of LVM-managed 
>>> volume.
>>
>> Eeek!  Which concludes that AIX really is the  only one to get it 
>> right?  Wow.
> 
> 
> Dec/Compaq/hp Tru64 can boot via lvm-based volumes (advfs). too bad it's 
> on the way out (though advfs is slated to be incorporated in future hpux 
> versions). advfs is.. 'odd' for an lvm but does implement the basic 
> features of an lv structure (dynamic pv addition, volume growth AND 
> reduction).

Ah yes, I had forgotten about that one - but please help my memory. 
That was only added well after it was called True64, and still was not 
the default way to do things, you had to do some serious homework to 
make that happen  - right?  I also recall they made some serious 
improvements to their exuivalent to SMIT....
> 
> also, some OSs may boot off veritas volumes if so installed.. at least 
> when we talked to them hp-booting was in the works.

Right, it is just that the discussion was directed to what you got from 
the vendors.......
> 
>> Not to mention that a small excursion to ebay will show you that the 
>> budget required to afford RS6K, SUN or HP propietary beasties is just 
>> not what it used to be - as long as you don't need the very latest.
> 
> 
> .. or testament being the second bedroom of some geek abodes (like mine 
> :) with better than three PLATFORMS (not OS, but platform.. 
> hp/alpha/ibm/sgi/intel and someday a sun :)
> 
> -r

Ah, but is that MCA,PCI or both?  8-)

Michael E. Thomadakis wrote:
> Timmy,
> 
> I started makign a good faith effort to help you separate reality from your
> misconceptions, but as I was reading your 'reply' I realized that you are too
> clueless and too obnoxious to waste my time answering you..
> 
> -m
> 
> 
> 
> 
> 
> On Fri, 16 Apr 2004, Timothy J. Bogart wrote:
> 
<snip>
> t|
> t|  Hmmm, perhaps the whole I/O structure favors large files.  After giving
> t|  up trying various tricks I turned it over to IBM support, who said there
> t|    was nothing broken.  An striped lv over 12 drives on a  4 way p630 ,
> t|  even parrallizing the compile took 16 times longer than my laptop,
> 
> AIX can have bad performance if tuned up in the WRONG way. Example: if you
> want to maximize small file I/O, then GOOD LUCK with that from a 12-way
> striped LV! Why do you need 12-way striped LVs? This is appropriarte for
> sequential files of large size. For small and frequent file I/O you need to
> spread the I/O accross as many drives as possible.

So, stiped across 12 drives (on 4 I/O channels) is not spread across as 
many drives as possible.  And increasing the max raw thruput over 
multiple drives and multiple channels doesn't improve both small and 
large file access?
> 
> What is the amount of max read ahead ?

Small percentage tuning doesn't address large issues, nor does read 
ahead address I/O spent on writing the JFS log.
> 
> 
> 
> 
> t|  sitting pegged in I/O.  And that was pretty much stuck on the jfs log.
> t|  Even untarring source code takes minutes vs seconds.  We are not talking
> t|  about a few percent tuning here.
> 
> Your I/O is not tuned up for the frequent small file I/O for code files.

No matter how many time you repeat it, it doesn't fit.
> 
> t|  >
> t|  > I CANNOT say the same for our large Linux box. The MAX we could get out of a
> t|  > theoretical MAX of 800MB/sec to the RAID was around 370MB/sec. SGI has
> t|  > attributed this to limitations of the SGI's block device drivers (xscsi) that
> t|  > are planning to replace in the next major release. FYI, xscsi is MUCH better
> t|  > than the native Linux scsi drivers.
> t|
> t|  Well, are you saying you are getting the theoretical max on other boxes?
> t|     Every filesystem I have ever seen falls far short of theoretical, and
> 
> AIX behaves VERY WELL if properly tuned. We are seeing close to the
> theoretical, i.e., the bus bandwidths.
> 
> t|  heaven knows you have your choice of filesystems in Linux, with some
> t|  rather large differences for different kinds of loads.  Seems odd to me
> t|  you only report one side of a comparison here.  Are you saying that a dd
> t|  on the raw channel does not get full thruput???
> 
> It was a dd to a striped volume where the slices are seen across all four FC
> channels. It was a plain data write to disk to measure the i/o path's
> throughput. It came out a little less than 1/2 of 800MB/sec
> 
> t|
> t|  >
> t|  > The results you saw are either from xscsi or from their next proprietary scsi
> t|  > drivers. You are talking in a vacuum here. How can you tell what consitutes
> t|  > `good results'? See the previous paragraph.
> t|
> t|  Your are right, I didn't say that well.  See above comment on dd.  As I
> t|  recall from the article, they had to tweek the drivers to get the full
> t|  thruput on a raw device.  A high ninety some thing percent of channel
> t|  utilization is pretty good.  Guess I need to go back and look at the
> t|  article again, as I sure don't remember less than 50% utilization on a
> t|  raw data channel.
> 
> What was the max of that channel? What kind of channel?

Well, I am going to try and be charitable here.  You mean you wrote to 
the raw device?  What was your data source?  I am not familiar with 
plain vs fancy data writes, but if I assume you are actually talking 
about the appropriate data.  Then I can say, good question, now that you 
have given a good data point, the next logical would be that you are 
using devices not covered in the article.  IT makes it doubly 
interesting, given the effort they made to address performance then sell 
a configuration to a customer that is so out of whack.
> 
> t|  >
> t|  <snip>
> t|  > TJB > Well, I am afraid you seem a little confused.  You keep refering to SMP
> t|  > TJB > issues and then jump to file caching then to file I/O.
> t|  >
> t|  > I am sorry that you cannot follow the discussion on the point of:
> t|  >
> t|  > ``Linux vs UNIX systems''
> t|
> t|  No need to be sorry, just please actually address the issues, or make
> t|  some actual comparisons.
> 
> Advice: Read, think, answer;
> 
> What issue are you adressing? Where are your comparisons?
> 
> Lost again? Long sentences are hard to comprehend?

Well, since your asking, your non-sequitors are rather difficult.  And 
since you don't seem to be following along yet, perhaps you could spend 
some time analyzing why anyone would provide comparisons when they are 
asking you to back up all the sweeping claims you made?

And, of course, while still not addressing at all any of the other 
claims you made about kenel preemption, etc, you jump right to what must 
pass for wit on your home planet.  And top posting to boot.

How sad.

On 2004-04-17, Timothy J. Bogart <tbogart@frii.net> wrote:
>
> Eeek!  Which concludes that AIX really is the  only one to get it right? 
>   Wow.

AIX has the best LVM implementation on any platform I've seen to date.

> Umm, I guess the point that it is easy to spew meaningless but somewhat 
> clever insults without really saying anything - and that could get fun, 
> but lets please get back to business.  ??

And where did I do that?  I offered my experience and perspective, and you
attempted to type-cast me.  Sounds like you should have taken your own advice
and skipped those two paragraphs.

> Hmmm, and what do you think is hardware dependent in this kernel 
> hacking?  Sure, there are device driver issues and such, but do you 
> really think that real kernel issues care about whether the code is on 
> top of any given hardware, or hardware simulator?  Are you really 
> talking about the optimizations for the device specific code below the 
> kernel?

Oh my freaking god -- do you even *read* the Linux kernel mailing list?!  It
looks to me like about almost half are hardware-specific, either clean-ups to 
make new code work consistently on other architectures, or device-specific
problems.  If you think kernel hackers rarely deal with hardware-related
issues, you're day dreaming.  As Linux advocate, you seem to know surprisingly 
little about what goes on in the Linux camp.  

That aside, you've managed to completely miss the point once more.  Hardware
plays a huge role in what features the kernel can provide.  Let's talk about
how hard it is to emulate completely non-executable stacks on x86 *because*
there isn't hardware support on the platform.  Let's talk about AIX 5.3's
ability to do multiple partitions per processor, but *only* on the Power5.
See a trend here?

And if that doesn't quite explain it enough to you, let's talk about "generic"
algorithms that you seem to think can be oblivious to the hardware details.
One problem the Linux kernel hackers have had to deal with with the scheduler
is the problem of hyperthreading looking to the scheduler as an SMP box.  When
you consider that each virtual core is not a fully functioning core it should
be obvious that it's a bad idea to schedule just any workload for what appears
to be a separate processor.  It'll cause all kinds of performance problems.

If it hasn't been sufficiently illustrated by now let me spell it out for you:
it is ignorant to think you can do much in the way of kernel hacking without
being cognizant of the details of the hardware.  Ask the ReiserFS guys whether
they had to do any extra work making thier filesystem 64-bit clean an endian
agnostic.

> Not to mention that a small excursion to ebay will show you that the 
> budget required to afford RS6K, SUN or HP propietary beasties is just 
> not what it used to be - as long as you don't need the very latest.

I think that's true of everything.  What's your point?

> But really, asking whether a kernel runs well on a particular brand or 
> model is not the same as asking whether it is a well designed and 
> efficient kernel.

I can agree with that, but you'd have to acknowledge the caveat that a kernel
is going to be preferrentially tuned for the architecture that most of the
developers are using.  It is asinine to expect the same generic code to run
equally will on all systems.

> OK, here is what may be my best shot.  With all that going for you, 
> please don't make silly comments about 'linux fan boys', 'IBM fan boys' 
> or anything else that makes puts you solidly in a large group of very 
> stupid people who really don't have a clue.  I mean, I honestly can't 
> think of any Linux fan in my personal experience who has only ever seen 
> Linux.  Let alone considering where you are posting this.  Bigotry isn't 
> pretty in any guise.

Boys are boys, but hopefully at some point they grow up.  I'm a fan of Linux,
but I'm not a fan boy, having experienced a lot of different architectures in
a lot of different environments, I understand that Linux needs to grow in a
lot of areas.  You may not like the moniker, but I don't think I need to
apologise for it.

Once again, the irony:  above you accuse me of being a bigot when I've plainly
stated in several threads all over usenet that I *like* and *use* Linux.  But
I hardly think it's ready to replace the traditional unices as the one true
UNIX.  Who's the bigot here?

> Well, that at least is trying to get to the point.  As I pointed out 
> elsewhere, I don't have the experience with the Origin big iron, and I 
> am just looking for something better than 'if you touched it you would 
> know'.  I say, if you have any actual data, you would be exclaiming it 
> loudly.  I guess not, eh?  The published benchmarks by SGI show the 
> Altix running circles around the Origin.  I guess nobody using that code 
>   ever touched IRIX, eh?

On a processor to processor comparison, yes, the Altix will beat an Origin,
but this is where your claims of scalability are called into question.  You
can build a bigger system with IRIX/MIPS on the Origin than you can with
Linux/ia64 on the Altix.  This is especially important when performance
demands that memory I/O latency be minimal by running in the same large system
image.  Altix, right now, maxes out at 256 CPUs per image.  The 2,048 CPU
Origin that Wright-Patterson AFB just bought last year uses four nodes of 512
processors per image.  They could have bought an Altix, but didn't.

> OK, I have direct experience with the low end.  I read the specs on the 
> big iron because I don't own any.  I am waiting for someone to give data 
> and experience that actually relates to performance differences, rather 
> than 'you just don't get it, and if you were cool like me, and touched 
> one of these things, you would JUST KNOW'.  Well, frankly, in my 25 
> years of dealing with things, I have yet to gain that level of 
> performance understanding by touching a machine.  Perhaps, you could do 
> us all a favor and concentrate on explaining how you do this.

All right, now you're just quibbling.  I will give you pointers to the
necessary resources, but I'm *not* going to hold your hand through the entire
exercise.  At some point you need to exercise a little initiative.  If someone
says you need to look at another system, research it.  That would be much
better than doing a poor paraphrase of a comment taken out of context.

> Now if I just look at things like benchmarks, you might see the SGI says 
> the fp_rate, for  example, of a 64 way Altix with 1500 MHz processors is 
> more than 4 times the output of the 64 way Origin with 600 Mhz 
> processors (the fastest results available on the SPEC site).  Now, 
> without touching an Origin, I would conclude that it would take more 
> than 4 times the number  of processors to perform the actual work.  But, 
> then, as I say,  I haven't touched one.  Perhaps you can see why I am so 
> confused by using un-data like data such as company published benchmark 
> results.

This shows how little you understand when it comes to systems architectures.
Total real world performance depends on a lot more than a fast core.  You also
need great I/O to get stuff to it.  MIPS/IRIX wouldn't have lasted as long as
they have if they didn't have that going for them.  They certainly haven't
pushed the clock rate much over the last ten years.  x86 architecture has
tradionally been nothing *but* bottlenecks outside of the processor,
especially in n-way configurations.  Read up on the lastest issues with
Intel's memory I/O bottlenecks, and how AMD is getting around this with
hyperchannel matrices.

> Well, I would have to go back and look and the specific reasons I had to 
> do the particular kernel update, and though I am not in front of an AIX 
> box right now, but I will put down a large amount of money on my memory 
> that the number associated with the kernel is larger than 5 on my 5.2 
> box.  And frankly, since I started maintaining AIX in about 1991 or so, 
> there has been more than one instance of kernel or other packages that 
> had to be updated within a week of even a full blown maintenance release 
> (with is, as you know, a set of patches TESTED together for reliability) 
> due to problems introuduced.  As you say, it is rather subjective, but 
> at least the kind of fix data you are referring to is available - and I 
> will stand by the posistion that all the vendors should be ashamed of 
> themselves.

Finally, I can agree with the last sentence.  My required patching on my AIX
systems appears to be a lot less than yours.

> Hmmm, I would put in one question, having dealt mostly with the first 
> three - you perhaps mean 'required security patch' frequency?  Someone 
> passed me an interesting presentation some months ago.  Seems the VMS 
> people put together a statistical analysis of CERT activity since it's 
> inception.  I would have to look up the specifics again to quote the 
> numbers, but as you would expect, Windows was obscenely huge, with 
> Solaris and Linux neck and neck, and AIX and TRUE-64 as being the best 
> of the UNIX world.  But the spread of the UNIX world was so tiny 
> compared to the jump up to the you know who.  It may be a bit of an 
> overstatement, but it is almost like picking the proverbial flyshit out 
> ot the pepper to nitpick withing the UNIX world.  Of course, there will 
> be small stretches of time where one my bloat compared to the others.

Statistics are easy to twist any way you want, but I read the numbers
differently.  First off, I disagree with the theory that Windows is the most
hacked because they're so many of them.  Any serious hacker needs a network of
semi-permanent hosts to hide their tracks through.  From the inception of the
commercial Internet UNIX has been the most prevalent platform on the server
side.  I don't see a great deal of value hacking dial-up Windows boxes outside
of bragging rights amoung script-kiddies.  Because of that, I take the view 
that Windows is so frequently hacked becuase it's a damned easy target.  

But let's get back to the specific vulnerabilities I was talking about:
kernel exploits.  AIX has been remarkably stable over the years, Sun and Linux
less so.  Again, we've had three this year alone on Linux due to memory
handling issues (again, this isn't in userland libs, but in the kernel), and
the last one a freaking ISO CD mounting issue?!

> I am not going to stick my head in the sand either, but I will say here 
> (and I think in another post or two) that I am tired of non-data bearing 
> criticisms in this day and age.  If Linux has proved anything, it has 
> proved that the position of the major players in not at all safe, and 
> real, serious analysis must be made to see what is best for a given 
> need.  One could reliably laugh at the Windows onslaught, but not the 
> Linux one.
>
> And I say that in confidence without touching a single Origin box.

I certainly have not said that Linux will never amount to anything, I've
merely said that it isn't everything *yet*.  And by the time it gets close to
what all the major Unices are today, the active ones will have still moved
farther.  I see a bit of a perpetual race going on.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On 2004-04-17, Andre Majorel <amajorel@teezer.fr> wrote:
>
> AIX and Irix may or may not be more secure than Linux, but in
> general I would be very wary of arguments based on equating
> "security" with "few published alerts" (or fixes).
>
> Not long ago, there have been a couple studies "proving" that
> Windows was more secure than Linux, through artful
> misinterpretation of security alerts statistics.

I would not make that leap.  However, I wouldn't point out that with IBM
storing a majority chunk of the world's financial data on its systems there's
plenty of incentive for the system to be subverted.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On 2004-04-17, Timothy J. Bogart <tbogart@frii.net> wrote:
>
> Well, I might, but then there seem to be those who would not recognize 
> it.  To go back to part of what you snipped
>
> "> OK, I will byte <sic>.  What is SGI not telling us about their large 
> SMP boxes?  You have proof they faked their graphs they published about 
> their linear SMP performance?
> Based on this comment I'd wager you've never used SGI's IRIX."
>
> Now, the person who thinks that using IRIX - under whatever 
> circumstances - say on a single processor workstation, would somehow 
> answer the stated question, in turn asks me if I have any technical 
> merit to bring to a discussion?  I have enough technical merit to know 
> that knowledge of an operating system doesn't tell me SQUAT about the 
> claimed linearity of SMP performance on any give bloody box!

Oh, I see, since you're the sparkling example of clarity here, I need to be
that much more explicit.  I merely assumed that if you had *any* significant
exposure to the platform that you'd have a working knowledge of the features
it has.  I guess that was a stretch were you are concerned.

> Well, if I need to explain that knowing about IRIX still wouldn't tell 
> me much about 70% of their product line, it might not be worth it.  But 
> to get back grounded here; you are making claims, I would be very 
> interested in the data to back up these claims.  The more we have to 
> deal with the laying of hands as opposed to data to back up your 
> arguments, the sillier you argument becomes.  Particularly when it seems 
> to contradict what the people who build the stuff say.

Good try ducking that.  I still find it odd that you want to hang some press
release benchmarks out there proclaiming Linux to be the be-all, end-all, all
the while knowing *jack* about the primary platform of the company.  If Linux
was that damned good in all respects wouldn't you think *it* would be their
primary platform?  And yet it isn't, and you still can't follow a simple train
of thought.

> I don't have squat for experience with IRIX or SGI products, but I have 
> gone to their techical shows and listened to their developers and Linux 
> conferences and have looked at at least some of their published 
> benchmarks and journal articles.  The big difference here seems to be 
> that I have understood some of these data sources.

Right.  You've really demonstrated a firm grasp of the technical points in
these threads.  You don't understand scalability, what it means, what
architectural models benefit what type of computation, whether a gcc compile
is really an adequate benchmark for comparing an IDE laptop drive to some
unknown hardware running AIX, and so on.  If this is what you've understood, I
shudder to think of those poor souls dependent on your expertise.

Typical Diltertian PFB behaviour:  "I don't understand anything about what's
going on in the box, but I completely got the brochure!"

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On Sun, 18 Apr 2004, Timothy J. Bogart wrote:

t%  Date: Sun, 18 Apr 2004 17:59:31 -0600
t%  From: Timothy J. Bogart <tbogart@frii.net>
t%  Newsgroups: comp.unix.aix
t%  Subject: Re: LINUX vs AIX
t%
t%  > AIX can have bad performance if tuned up in the WRONG way. Example: if you
t%  > want to maximize small file I/O, then GOOD LUCK with that from a 12-way
t%  > striped LV! Why do you need 12-way striped LVs? This is appropriarte for
t%  > sequential files of large size. For small and frequent file I/O you need to
t%  > spread the I/O accross as many drives as possible.
t%
t%  So, stiped across 12 drives (on 4 I/O channels) is not spread across as
t%  many drives as possible.  And increasing the max raw thruput over
t%  multiple drives and multiple channels doesn't improve both small and
t%  large file access?

STRIPED accross 12 drives means that file blocks are interleaved (modulo 12)
over ALL drives and ANY I/O reads / writes to ALL of them. STRIPING is good
for sequential access of LARGE files.

Compilations usually involve many small files. Striping is the enemy of small
files. It is better to define an LV on a volume group containing these drives
and let LVM spread PP to MAX different phy. vol. allocation. In this way I/O
to multiple files can take place concurrently if the files are spread to
different phy. volumes. With your striping you are asking the system to carry
out excessive I/O that takes up file cache and that you most likely throw
away.

Read up on what striping is, what it is good at and when to avoid it.



t%  >
t%  > What is the amount of max read ahead ?
t%
t%  Small percentage tuning doesn't address large issues, nor does read
t%  ahead address I/O spent on writing the JFS log.

The log is not written to when you read.

t%  >
t%  >
t%  >
t%  >
t%  > t|  sitting pegged in I/O.  And that was pretty much stuck on the jfs log.
t%  > t|  Even untarring source code takes minutes vs seconds.  We are not talking
t%  > t|  about a few percent tuning here.
t%  >

Log LV placement is critical in your 12-way striping. You need to use a volume
group that is not so active.



t%  > Your I/O is not tuned up for the frequent small file I/O for code files.
t%
t%  No matter how many time you repeat it, it doesn't fit.
t%  >
t%  > t|  >
t%  > t|  > I CANNOT say the same for our large Linux box. The MAX we could get out of a
t%  > t|  > theoretical MAX of 800MB/sec to the RAID was around 370MB/sec. SGI has
t%  > t|  > attributed this to limitations of the SGI's block device drivers (xscsi) that
t%  > t|  > are planning to replace in the next major release. FYI, xscsi is MUCH better
t%  > t|  > than the native Linux scsi drivers.
t%  > t|
t%  > t|  Well, are you saying you are getting the theoretical max on other boxes?
t%  > t|     Every filesystem I have ever seen falls far short of theoretical, and
t%  >
t%  > AIX behaves VERY WELL if properly tuned. We are seeing close to the
t%  > theoretical, i.e., the bus bandwidths.
t%  >
t%  > t|  heaven knows you have your choice of filesystems in Linux, with some
t%  > t|  rather large differences for different kinds of loads.  Seems odd to me
t%  > t|  you only report one side of a comparison here.  Are you saying that a dd
t%  > t|  on the raw channel does not get full thruput???
t%  >
t%  > It was a dd to a striped volume where the slices are seen across all four FC
t%  > channels. It was a plain data write to disk to measure the i/o path's
t%  > throughput. It came out a little less than 1/2 of 800MB/sec
t%  >
t%  > t|
t%  > t|  >
t%  > t|  > The results you saw are either from xscsi or from their next proprietary scsi
t%  > t|  > drivers. You are talking in a vacuum here. How can you tell what consitutes
t%  > t|  > `good results'? See the previous paragraph.
t%  > t|
t%  > t|  Your are right, I didn't say that well.  See above comment on dd.  As I
t%  > t|  recall from the article, they had to tweek the drivers to get the full
t%  > t|  thruput on a raw device.  A high ninety some thing percent of channel
t%  > t|  utilization is pretty good.  Guess I need to go back and look at the
t%  > t|  article again, as I sure don't remember less than 50% utilization on a
t%  > t|  raw data channel.
t%  >
t%  > What was the max of that channel? What kind of channel?
t%
t%  Well, I am going to try and be charitable here.  You mean you wrote to
t%  the raw device?  What was your data source?  I am not familiar with
t%  plain vs fancy data writes, but if I assume you are actually talking
t%  about the appropriate data.  Then I can say, good question, now that you
t%  have given a good data point, the next logical would be that you are
t%  using devices not covered in the article.  IT makes it doubly
t%  interesting, given the effort they made to address performance then sell
t%  a configuration to a customer that is so out of whack.
t%  >
t%  > t|  >
t%  > t|  <snip>
t%  > t|  > TJB > Well, I am afraid you seem a little confused.  You keep refering to SMP
t%  > t|  > TJB > issues and then jump to file caching then to file I/O.
t%  > t|  >
t%  > t|  > I am sorry that you cannot follow the discussion on the point of:
t%  > t|  >
t%  > t|  > ``Linux vs UNIX systems''
t%  > t|
t%  > t|  No need to be sorry, just please actually address the issues, or make
t%  > t|  some actual comparisons.
t%  >
t%  > Advice: Read, think, answer;
t%  >
t%  > What issue are you adressing? Where are your comparisons?
t%  >
t%  > Lost again? Long sentences are hard to comprehend?
t%
t%  Well, since your asking, your non-sequitors are rather difficult.  And
 (non-sequitur)
t%  since you don't seem to be following along yet, perhaps you could spend

I really do not wish to follow your eratic (errant) really thought 'process'.

t%  some time analyzing why anyone would provide comparisons when they are
t%  asking you to back up all the sweeping claims you made?

t%
t%  And, of course, while still not addressing at all any of the other
t%  claims you made about kenel preemption, etc, you jump right to what must

After you study about operating systems, their kernels, UNIX, SVr4, BSD Linux,
you will realize that it is not me the person making the claims but the OS
designers.

The only 'technical' info you have provided so far is something you read in a
web site with articles whose contents are not refereed. You are trying to pass
it off as the 'proof' that my statements are wrong. This is laughable really.

I WISH you would pose questions of technical nature to have an interesting
discussion. I WISH you could contradict me on a technical basis.

t%  pass for wit on your home planet.  And top posting to boot.

Thanks God it has nothing to do with what passes as wit in yours ;-)

t%
t%  How sad.

Dont' be sad, just study. I can be charitable and recommend books and
articles. It may take some time but it will well worth it.

If you want to reply be:

1. Informative, OR
2. Funny, OR
3. BOTH.

-mt

"Timothy J. Bogart" <tbogart@frii.net> wrote in message news:<40808cb6$0$203$75868355@news.frii.net>...

> Hmmm, perhaps the whole I/O structure favors large files.  After giving 
> up trying various tricks I turned it over to IBM support, who said there 
>   was nothing broken.  An striped lv over 12 drives on a  4 way p630 , 
> even parrallizing the compile took 16 times longer than my laptop, 
> sitting pegged in I/O.  And that was pretty much stuck on the jfs log. 
> Even untarring source code takes minutes vs seconds.  We are not talking 
> about a few percent tuning here.

Let me guess...
object files did go to the same stripe set?
jfslog is in the same stripe set?
You parallelized the I/O toward the a stripe set?


I don't want to express my opinion about AIX is slower on 
the I/O than Your laptop. It might be. But I defintely want 
to express my opinion about the way *You* are handling I/O.
Everything You did was increasing the number of transactions toward
a storage device that was intended for handling large, sequential I/O.

Arthur Corliss <acorliss@bifrost.nevaeh-linux.org> wrote in message news:<slrnc81288.2vv.acorliss@bifrost.nevaeh-linux.org>...
> On 2004-04-17, Greg <no@spam.com> wrote:
> >
> > Ahem - ever hear of the #1 selling eServer BladeCenter?  Intel blades, 
> > PowerPC 970 blades,
> > best of breed packaging.  Very nice product...Windows, Linux, and soon AIX.
> 
> Have you even priced it?  The HP Bl10e is a hell of a lot cheaper since it
> uses the P4Ms, and it packs 20 blades into a 3U shelf.  IBM owns the market on
> the high-end (with Itanium and Xeon processor blades), but when all you want
> to do is consolidate a collection of white boxes into a shelf, that's not what
> you buy.  I don't need that level of performance for DNS, NTP, SMTP, and other
> light-weight servies.

WOW, I didn't know that my post about if LINUX would equal and/or
surpass AIX would spark such a debate. I know many businesses are
going to LINUX for their business needs and forgoing AIX for the shere
reason of cost but in reality, is the cost systems worth the cost of
maintenance and intrusions and possible downtime?

any debate on this new related topic??

On 2004-04-17, Benjamin Gawert <bgawert@gmx.de> wrote:
>
> Can't say much to Linux since I want to avoid that until it is somewhat
> mature. But from what I heard the current situation with Linux is chaotic...

It is, to an extent.  But what it does it does well, so I still use it.  Of
course, I'm not relying on any vendor for OS support, only hardware support.

> Well, I wouldn't give too much on the mood at comp.sys.sgi.*. Unlike other
> newsgroups for commercial UNIXes in the SGI groups there is a strong
> antipaty against everything which is non-IRIX and especially against Linux,
> but not based on arguments but on stupid bashing and trolling. The remaining
> people that kept a view for reality also seem to agree that MIPS/IRIX isn't
> the way to go for most problems today...

I'll give you that, some of those chuckleheads give make Mac fanatics look
positively docile.  That said, there's some solid expertise in that list
including some SGI employees (Alexis has been particularly helpful) that has
some insight on why certain design decisions were made, and the benefits.

> Well, MIPS indeed is good at performance per clock cycle, but that doesn't
> help when the absolute performance is bad. And absolute performance is what
> is more important than performance per clock cycle or a high clock rate. And
> the absolute performance of the current MIPS CPUs is really bad, especially
> when also opting in the price.

I wholeheartedly agree that SGI hasn't been pushing the envelope hard, and
that has let a lot of inferior architectures compensate with clock-rate, and
in some cases, compensate enough to surpass.  But I still think the chips hold
a valuable niche, partly because of the overall system architecture and OS.
Obviously, they scale very well (and so still perform due to the number of
processors you can throw at a problem) and the overall I/O architecture is
damned good.  Outside of a Cray, I don't think you can do much better on a
UNIX system.

> Maybe. But then, SGI often had some good ideas but executed them poorly. A
> lot of their hardware has had design flaws:
>
> - Personal IRIS 4D3x: stupid and insufficient cooling design (often lead to
> dead Mainboards because the RAMDACs cooked themselves), high PSU failure
> rate (this seems to be some kind sof SGI trademark)
> - Indigo: NVRAM battery soldered on the mainboard on R4000 models (makes it
> hard to replace when empty, so a dead 3$ battery required a 1200$ CPU Board
> replacement)
> - Challenge L/XL/DM and Onyx: High PSU failure rate with danger of PSU
> cathing fire (SGI replaced the PSUs several years later), dying IO4-Boards,
> high failure rate with R8000 boards (cache)
> - O2: high PSU failure rate, dying ethernet ports, a design flaw makes O2s
> with R10000 CPU (150Mhz and 195MHz models) unuseable for video capturing due
> to timing problems, R7000 O2s were sold and recalled because of CPU design
> flaws
> - SGI320/540: high PSU failure rate, high mainboard failure rate (especially
> if the SGI/QLogic SCSI Controller has been used), stupid memory sockets
> which lock the module only on one side (leads to memory contact problems),
> useless firewire ports due to the lack of working drivers, buggy gfx
> drivers, and (really stupid) no way of changing the brightness on the SGI
> 1600SW TFT display (which is even more sad since this display is really
> good!)
> - Octane: high PSU failure rate, stupid cooling design wich even at room
> temperature operates near its limits, SI/SSI/MXI Texture RAM modules got so
> hot that the pins of the RDRAM memory ICs desoldered themselves, dying
> ethernet ports, older CPU boards had contact problems with some ICs on the
> board, the extremely sensible High Pressure Connectors often had contact
> problems and made the Octane unreliable
> - Origin 2000/2100: high PSU failure rate, lots of dead CPU modules
>
> We had tons of SGI equipment but the little flaws and and the bad support
> brought us away from SGI. I can't remember any HP9000 or RS/6000 making that
> much trouble like the SGIs we had.

I've got a handful of I2s (which are built like tanks) and two Onyx VTXs.
Aging hardware, but damned fine hardware still.   I'm surprised that you've
had the power supply issues on the Onyx in particular, and IO4, I haven't seen
that at all.  I've never used the R8k boards, using instead the R4400 and R10k
boards.

I've heard a lot of complaints about the Octanes, and no one really like the
Wintel boxes (though part of that is simple IRIX bigotry).

Your experience, if it is the norm, is indeed terrible, and hard to justify
how a company stays in business.  But based on the fact that they have managed
to do so, all while shooting themselves in the foot for a lack of
cost-competitiveness, I'd have to say there's got be some satisfied customers.
One thing that I've found, and this is with all vendors, including IBM & HP,
is that when you get a run of bad components they're typically from the same
bad lot (assuming you bought them at the same time).  It's just one of those
things that quality-control just doesn't catch with spot-checks.  If you get
hammered, you *really* get hammered.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On 2004-04-19, Ken <ucstyle@hotmail.com> wrote:
>
> WOW, I didn't know that my post about if LINUX would equal and/or
> surpass AIX would spark such a debate. I know many businesses are
> going to LINUX for their business needs and forgoing AIX for the shere
> reason of cost but in reality, is the cost systems worth the cost of
> maintenance and intrusions and possible downtime?
>
> any debate on this new related topic??

;-) It wasn't your fault the thread took on a life of its own, it's the
typical inertia of usenet.  From my corner of the planet I see value in both
of them, and will be using them to complement each other.  It'll be another
five years at least before Linux will be ready to displace AIX on my DB2
servers (unless IBM really pushes the hardware support and AIX features into
Linux), but Linux has already replaced a lot of other Unices and Windows
outside of the data center.

As to your new line of questioning:  I'm in the middle of doing a technology
refresh (maintenance costs on an S7A is about $55,000/3yrs, and all for a box
you can get off the street now for under $10,000) for hardware that's
successfully met the 99.99% uptime guarantees we gave.  With the latest
features of AIX and pSeries that we'll be moving to management is thinking
about adding another 9 to the uptime guarantee, and it's something I feel
comfortable we can achieve.  And all while decreasing our maintenance costs by
a third.  So, is AIX worth it?  Yes.  Would I feel comfortable attempting the
same uptime guarantee on Linux?  No.

I think the one thing most people overlook with asking this question is that
it rarely has to be one *or* the other, especially in a non-Windows
environment where hetergenous networks are simply assumed by default.  Linux
is making its way into the enterprise, but in a complementary fashion.  Move
non-critical services (or critical services where Linux has demonstrated
capability) to the edge and reallocate the existing horsepower to your
databases, etc., to put off what would otherwise be a mandatory hardware
upgrade cycle.

For the record, I'll also point out that it's not just Linux.  Here we treat
Linux and FreeBSD as somewhat interchangable.  Linux definitely has the
advantage in LVM/FS arena, but you can't get much better stability and network
I/O than with FreeBSD.  So, we use them all, depending on the application.
:-)

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

ucstyle@hotmail.com (Ken) wrote in message news:<d526473a.0404140611.732cd70a@posting.google.com>...
> Aixers,
> 
> Does anyone believe that LINUX will surpass AIX as a premire OS for
> businesses? What's your reasoning for your answers??
> 
> Thanks



Isn't Linux SUPPOSED to surpass Microsoft Windows instead 
of suppassing or replacing other operating systems??? 

Are the other Operating systems are just casuality of war 
between Linux and big bad Microsoft Windows??

"F. Michael Orr" <morr@utility.vccs.edu> wrote in 
news:pan.2004.04.15.16.12.19.845255@utility.vccs.edu:

> Vendor support is a problem for Linux.  Even a company like IBM, which
> touts its Linux support, doesn't support it to the extent that it does
> AIX.  SAN storage, for example.  I can hook an AIX box up to a Shark,
> install the software, and it all works perfectly.  Linux is a struggle
> usually, and the Shark software provided (SDD) flies in the face of
> standard Linux support:

SDD is just a temporary solution, until the OS supports multiple paths to 
devices with the same function level as sdd.  After that point sdd is no 
longer needed.


-- 
Doing AIX support was the most monty-pythonesque
activity available at the time.
Eagerly awaiting my thin chocolat mint.

Arthur Corliss <acorliss@bifrost.nevaeh-linux.org> wrote in
news:slrnc7r3qo.3n7.acorliss@bifrost.nevaeh-linux.org: 

> You have got to be kidding.  The kernel (which *is* Linux) is the
> weakest part of Linux.  The strongest part of Linux (common vernacular
> usage) is the userland utilities, most of which is GNU software. 
> Guess what:  we've already got that.  We've already got sendmail,
> apache, and all the others, too. What I'd rather see is Linux built on
> AIX.  That would give us the fantastic robustness during hardware
> failures, dynamic resource allocation, a real freaking LVM that you
> can boot off of (without having to do some kludgy initrd crap).

Actualy, AIX has something aking to initrd.

An AIX boot is composed of:
- A boot loader (similar to the boot loader on block 0 of any intel PC)
- Boot device (say, HD5) which contains a current copy of the kernel, and a 
RAM filesystem image (with device drivers and some ODM entries).

The bosboot command writes both the boot loader and the HD5 image.
The savebase command updates the ODM entry.

PS: there were times I wished I could have a grub to load multiple AIX 
images on the same VG.

-- 
Doing AIX support was the most monty-pythonesque
activity available at the time.
Eagerly awaiting my thin chocolat mint.

On Fri, 23 Apr 2004 11:29:49 +0000, Jose Pina Coelho wrote:

> "F. Michael Orr" <morr@utility.vccs.edu> wrote in
> news:pan.2004.04.15.16.12.19.845255@utility.vccs.edu:
> 
>> Vendor support is a problem for Linux.  Even a company like IBM, which
>> touts its Linux support, doesn't support it to the extent that it does
>> AIX.  SAN storage, for example.  I can hook an AIX box up to a Shark,
>> install the software, and it all works perfectly.  Linux is a struggle
>> usually, and the Shark software provided (SDD) flies in the face of
>> standard Linux support:
> 
> SDD is just a temporary solution, until the OS supports multiple paths
> to devices with the same function level as sdd.  After that point sdd is
> no longer needed.

That may be true.  It is, however, the only game in town right now, so to
speak.  What you propose, however, would require a standard SAN interface
protocol, part of which is multipathing, which all storage array vendors
adhere to. Something akin to SCSI, but for SAN storage.  I remember when
SCSI first really started becoming popular; it was a standard, but woe be
onto the poor soul who tried to mix and match SCSI adapters and drives.
We're on a similar point in the curve for storage array technology, I
think.  When such a standard is adopted, each OS would have the apropriate
drivers to multi-path to any storage array.

I do not think, though, we're going to see that any time soon.  The profit
margins are too high right now on this equipment for the vendors to risk
allowing real competition after a client gets into the technology.  And
that is what a standard would allow, after all: if I didn't like IBM, I
could buy Hitachi or EMC next purchasing cycle.  Or Joe's Storage Array
technology, if it adhered to the standard.

Arthur Corliss wrote:
> On 2004-04-17, Timothy J. Bogart <tbogart@frii.net> wrote:
> 
>>Eeek!  Which concludes that AIX really is the  only one to get it right? 
>>  Wow.
> 
> 
> AIX has the best LVM implementation on any platform I've seen to date.
> 
> 
>>Umm, I guess the point that it is easy to spew meaningless but somewhat 
>>clever insults without really saying anything - and that could get fun, 
>>but lets please get back to business.  ??
> 
> 
> And where did I do that?  I offered my experience and perspective, and you
> attempted to type-cast me.  Sounds like you should have taken your own advice
> and skipped those two paragraphs.

Very simply, the 'linxu fan-boy' tripe.  If you hadn't snipped it, you 
might have been able to follow it.  I laid out how one could respond in 
kind - - and then said 'that could be fun, but lets please get back to 
business'.  Maybe you could get a sighted co-worker to draw it out for you?
> 
> 
>>Hmmm, and what do you think is hardware dependent in this kernel 
>>hacking?  Sure, there are device driver issues and such, but do you 
>>really think that real kernel issues care about whether the code is on 
>>top of any given hardware, or hardware simulator?  Are you really 
>>talking about the optimizations for the device specific code below the 
>>kernel?
> 
> 
> Oh my freaking god -- do you even *read* the Linux kernel mailing list?!  It
> looks to me like about almost half are hardware-specific, either clean-ups to 
> make new code work consistently on other architectures, or device-specific
> problems.  If you think kernel hackers rarely deal with hardware-related
> issues, you're day dreaming.  As Linux advocate, you seem to know surprisingly 
> little about what goes on in the Linux camp.  

Oh my freaking higher power, do you even comprehend what you claim to 
read?  I don't really mind knowing surprisingly little, as it is 
prefferable to knowing a whole lot that ain't so - as the saying sortof 
goes.
> 
> That aside, you've managed to completely miss the point once more.  Hardware
> plays a huge role in what features the kernel can provide.  Let's talk about
> how hard it is to emulate completely non-executable stacks on x86 *because*
> there isn't hardware support on the platform.  Let's talk about AIX 5.3's
> ability to do multiple partitions per processor, but *only* on the Power5.
> See a trend here?

You need to go back and look at the start of the thread if you really 
wanted to even know what the point was.  The claim you jumped in on was 
on kernet preemptive qualities and virtual memory management.  Kinda 
fundamental stuff.  And you seem amazed that after roughly 12 years of 
kenel hacking, most of what is left over is dealing with hardware 
issues?  sheesh.
> 
> And if that doesn't quite explain it enough to you, let's talk about "generic"
> algorithms that you seem to think can be oblivious to the hardware details.
> One problem the Linux kernel hackers have had to deal with with the scheduler
> is the problem of hyperthreading looking to the scheduler as an SMP box.  When
> you consider that each virtual core is not a fully functioning core it should
> be obvious that it's a bad idea to schedule just any workload for what appears
> to be a separate processor.  It'll cause all kinds of performance problems.
Sigh.  So they replaced the algorythm, or  how it was applied.  Tuning 
the algorythm is what I was referring to as real kernel hacking.

> 
> If it hasn't been sufficiently illustrated by now let me spell it out for you:
> it is ignorant to think you can do much in the way of kernel hacking without
> being cognizant of the details of the hardware.  Ask the ReiserFS guys whether
> they had to do any extra work making thier filesystem 64-bit clean an endian
> agnostic.

And you don't seem to know the difference between a file system and a 
kernel.  Nonetheless, even in that example, do you think that you 
require a 64 bit system to do the code clean up?  Or just to test it at 
the end?  A good example is that the folks who did the clustering code 
for Digital Unix did it largely on IA32 laptops - kind of far removed 
from the target hardware, but, as I recall, they said well above 90% of 
the code was not done on the native hardware.
> 
> 
>>Not to mention that a small excursion to ebay will show you that the 
>>budget required to afford RS6K, SUN or HP propietary beasties is just 
>>not what it used to be - as long as you don't need the very latest.
> 
> 
> I think that's true of everything.  What's your point?
Oh, stretch your mind into the concept that linux-boys only deal with 
Intel hardware because of price point.
> 
> 
>>But really, asking whether a kernel runs well on a particular brand or 
>>model is not the same as asking whether it is a well designed and 
>>efficient kernel.
> 
> 
> I can agree with that, but you'd have to acknowledge the caveat that a kernel
> is going to be preferrentially tuned for the architecture that most of the
> developers are using.  It is asinine to expect the same generic code to run
> equally will on all systems.

Gee, I don't know, that sounds an awful lot like the argument that the 
more developers, the better something will be.  Didn't you reject that 
earlier?  Maybe it runs better on some platform because the folks using 
that platform are really good?  Nah, I guess that couldn't happen.
> 
> 
>>OK, here is what may be my best shot.  With all that going for you, 
>>please don't make silly comments about 'linux fan boys', 'IBM fan boys' 
>>or anything else that makes puts you solidly in a large group of very 
>>stupid people who really don't have a clue.  I mean, I honestly can't 
>>think of any Linux fan in my personal experience who has only ever seen 
>>Linux.  Let alone considering where you are posting this.  Bigotry isn't 
>>pretty in any guise.
> 
> 
> Boys are boys, but hopefully at some point they grow up.  I'm a fan of Linux,
> but I'm not a fan boy, having experienced a lot of different architectures in
> a lot of different environments, I understand that Linux needs to grow in a
> lot of areas.  You may not like the moniker, but I don't think I need to
> apologise for it.
> 
> Once again, the irony:  above you accuse me of being a bigot when I've plainly
> stated in several threads all over usenet that I *like* and *use* Linux.  But
> I hardly think it's ready to replace the traditional unices as the one true
> UNIX.  Who's the bigot here?

I don't know, who?  You insist on using insulting terms towards others 
who you percieve as liking linux - I guess just because you are so cool 
you are the only one who could guage it's value properly.  Here, I have 
objected to the crap spewed, rather than data.  That's it.  If you had 
paid attention, Linux isn't my favorite OS, and had the discussion 
presented the same mindless junk on another subject, I would object as 
well.  But you just assume that I believe that Linux is the 'one true 
UNIX'.  It isn't, and I have said so.

You can say you like Linux, but when you make those 'fan-boy' statements 
you are no better than the old folks you used to say 'I'm not a bigot, 
why some of my best frends are <insert racial epitath here>'.
> 
> 
>>Well, that at least is trying to get to the point.  As I pointed out 
>>elsewhere, I don't have the experience with the Origin big iron, and I 
>>am just looking for something better than 'if you touched it you would 
>>know'.  I say, if you have any actual data, you would be exclaiming it 
>>loudly.  I guess not, eh?  The published benchmarks by SGI show the 
>>Altix running circles around the Origin.  I guess nobody using that code 
>>  ever touched IRIX, eh?
> 
> 
> On a processor to processor comparison, yes, the Altix will beat an Origin,
> but this is where your claims of scalability are called into question. 

Ok, right there.  You have completely lost touch.  Where are my claims 
of scalablity?  Go back to the thread you jumped in on.  The claim was 
made Linux was not scalable.  I have been asking for the data.  I note 
the vendor who sells this claims scalability.

All I get in response is that somehow if I used IRIX enough I would know 
  Linux is not scalable.

What crap.

  >You
> can build a bigger system with IRIX/MIPS on the Origin than you can with
> Linux/ia64 on the Altix.  This is especially important when performance
> demands that memory I/O latency be minimal by running in the same large system
> image.  Altix, right now, maxes out at 256 CPUs per image.  The 2,048 CPU
> Origin that Wright-Patterson AFB just bought last year uses four nodes of 512
> processors per image.  They could have bought an Altix, but didn't.
> 
> 
>>OK, I have direct experience with the low end.  I read the specs on the 
>>big iron because I don't own any.  I am waiting for someone to give data 
>>and experience that actually relates to performance differences, rather 
>>than 'you just don't get it, and if you were cool like me, and touched 
>>one of these things, you would JUST KNOW'.  Well, frankly, in my 25 
>>years of dealing with things, I have yet to gain that level of 
>>performance understanding by touching a machine.  Perhaps, you could do 
>>us all a favor and concentrate on explaining how you do this.
> 
> 
> All right, now you're just quibbling.  I will give you pointers to the
> necessary resources, but I'm *not* going to hold your hand through the entire
> exercise.  At some point you need to exercise a little initiative.  If someone
> says you need to look at another system, research it.  That would be much
> better than doing a poor paraphrase of a comment taken out of context.

Well, I asked someone else a question, and you came in with zero data. 
No, you are not going to hold my hand thru anything, since you are 
obviously incapable.
> 
> 
>>Now if I just look at things like benchmarks, you might see the SGI says 
>>the fp_rate, for  example, of a 64 way Altix with 1500 MHz processors is 
>>more than 4 times the output of the 64 way Origin with 600 Mhz 
>>processors (the fastest results available on the SPEC site).  Now, 
>>without touching an Origin, I would conclude that it would take more 
>>than 4 times the number  of processors to perform the actual work.  But, 
>>then, as I say,  I haven't touched one.  Perhaps you can see why I am so 
>>confused by using un-data like data such as company published benchmark 
>>results.
> 
> 
> This shows how little you understand when it comes to systems architectures.
> Total real world performance depends on a lot more than a fast core.  You also
> need great I/O to get stuff to it.  MIPS/IRIX wouldn't have lasted as long as
> they have if they didn't have that going for them.  They certainly haven't
> pushed the clock rate much over the last ten years.  x86 architecture has
> tradionally been nothing *but* bottlenecks outside of the processor,
> especially in n-way configurations.  Read up on the lastest issues with
> Intel's memory I/O bottlenecks, and how AMD is getting around this with
> hyperchannel matrices.

Ah yes, I used to call this the 'lemming defence' but others tell me a 
better term is the 'eat shit - a billion flies can't be wrong' defence. 
  In spite of every opportunity to offer up any real experience you have 
in how one platform handles loads any better than another, you now 
resort to referring to others parties buying decisions - oh I am sure 
they did all the right homework.
> 
> 
>>Well, I would have to go back and look and the specific reasons I had to 
>>do the particular kernel update, and though I am not in front of an AIX 
>>box right now, but I will put down a large amount of money on my memory 
>>that the number associated with the kernel is larger than 5 on my 5.2 
>>box.  And frankly, since I started maintaining AIX in about 1991 or so, 
>>there has been more than one instance of kernel or other packages that 
>>had to be updated within a week of even a full blown maintenance release 
>>(with is, as you know, a set of patches TESTED together for reliability) 
>>due to problems introuduced.  As you say, it is rather subjective, but 
>>at least the kind of fix data you are referring to is available - and I 
>>will stand by the posistion that all the vendors should be ashamed of 
>>themselves.
> 
> 
> Finally, I can agree with the last sentence.  My required patching on my AIX
> systems appears to be a lot less than yours.
> 
> 
>>Hmmm, I would put in one question, having dealt mostly with the first 
>>three - you perhaps mean 'required security patch' frequency?  Someone 
>>passed me an interesting presentation some months ago.  Seems the VMS 
>>people put together a statistical analysis of CERT activity since it's 
>>inception.  I would have to look up the specifics again to quote the 
>>numbers, but as you would expect, Windows was obscenely huge, with 
>>Solaris and Linux neck and neck, and AIX and TRUE-64 as being the best 
>>of the UNIX world.  But the spread of the UNIX world was so tiny 
>>compared to the jump up to the you know who.  It may be a bit of an 
>>overstatement, but it is almost like picking the proverbial flyshit out 
>>ot the pepper to nitpick withing the UNIX world.  Of course, there will 
>>be small stretches of time where one my bloat compared to the others.
> 
> 
> Statistics are easy to twist any way you want, but I read the numbers
> differently.  First off, I disagree with the theory that Windows is the most
> hacked because they're so many of them.  Any serious hacker needs a network of
> semi-permanent hosts to hide their tracks through.  From the inception of the
> commercial Internet UNIX has been the most prevalent platform on the server
> side.  I don't see a great deal of value hacking dial-up Windows boxes outside
> of bragging rights amoung script-kiddies.  Because of that, I take the view 
> that Windows is so frequently hacked becuase it's a damned easy target.  

Now you are just making stuff up.  Where did I contend that about 
Windows?  WHERE?  How many decades ago was it demonstrated that writing 
viruses for DOS/Windows/MacOS was easier than for any of the unices due 
to the way they were linked/loaded?  How many uninces come out of the 
box configured so that mail attachments are, if possible executed?  Of 
course the number of CERTs is related to the how easy it is to exploit 
the platform - that is why I brought it up.

Oh, by the way, beyond bragging rights, you might consider the number of 
hackers who like whacking into Windows boxes because it makes such a 
nice launching point for DDOS attacks.
> 
> But let's get back to the specific vulnerabilities I was talking about:
> kernel exploits.  AIX has been remarkably stable over the years, Sun and Linux
> less so.  Again, we've had three this year alone on Linux due to memory
> handling issues (again, this isn't in userland libs, but in the kernel), and
> the last one a freaking ISO CD mounting issue?!

What's to get back to?  I never defended them as good in any way, and 
said that they should be ashamed - I only said others should be ashamed 
as well.
> 
> 
>>I am not going to stick my head in the sand either, but I will say here 
>>(and I think in another post or two) that I am tired of non-data bearing 
>>criticisms in this day and age.  If Linux has proved anything, it has 
>>proved that the position of the major players in not at all safe, and 
>>real, serious analysis must be made to see what is best for a given 
>>need.  One could reliably laugh at the Windows onslaught, but not the 
>>Linux one.
>>
>>And I say that in confidence without touching a single Origin box.
> 
> 
> I certainly have not said that Linux will never amount to anything, I've
> merely said that it isn't everything *yet*.  And by the time it gets close to
> what all the major Unices are today, the active ones will have still moved
> farther.  I see a bit of a perpetual race going on.
> 

Well, I can only hope that there still is an active UNIX down the road. 
   Competition certainly won't come from the evil empire.

Arthur Corliss wrote:
> On 2004-04-17, Timothy J. Bogart <tbogart@frii.net> wrote:
> 
>>Well, I might, but then there seem to be those who would not recognize 
>>it.  To go back to part of what you snipped
>>
>>"> OK, I will byte <sic>.  What is SGI not telling us about their large 
>>SMP boxes?  You have proof they faked their graphs they published about 
>>their linear SMP performance?
>>Based on this comment I'd wager you've never used SGI's IRIX."
>>
>>Now, the person who thinks that using IRIX - under whatever 
>>circumstances - say on a single processor workstation, would somehow 
>>answer the stated question, in turn asks me if I have any technical 
>>merit to bring to a discussion?  I have enough technical merit to know 
>>that knowledge of an operating system doesn't tell me SQUAT about the 
>>claimed linearity of SMP performance on any give bloody box!
> 
> 
> Oh, I see, since you're the sparkling example of clarity here, I need to be
> that much more explicit.  I merely assumed that if you had *any* significant
> exposure to the platform that you'd have a working knowledge of the features
> it has.  I guess that was a stretch were you are concerned.
Well, duh, since I came right out and said I had no significant exposure 
- but of  course the real point is that you really are stuck in the 
concept that exposure to IRIX would somehow answer the question about 
linux capabilities.
> 
> 
>>Well, if I need to explain that knowing about IRIX still wouldn't tell 
>>me much about 70% of their product line, it might not be worth it.  But 
>>to get back grounded here; you are making claims, I would be very 
>>interested in the data to back up these claims.  The more we have to 
>>deal with the laying of hands as opposed to data to back up your 
>>arguments, the sillier you argument becomes.  Particularly when it seems 
>>to contradict what the people who build the stuff say.
> 
> 
> Good try ducking that.  I still find it odd that you want to hang some press
> release benchmarks out there proclaiming Linux to be the be-all, end-all, all
> the while knowing *jack* about the primary platform of the company.  If Linux
> was that damned good in all respects wouldn't you think *it* would be their
> primary platform?  And yet it isn't, and you still can't follow a simple train
> of thought.
Ah, benchmarks are press releases.  Particularly SPEC.  be-all, end-all? 
  Geeze, you must be pretty darn twitchy  to jump that far.  ROFL
> 
> 
>>I don't have squat for experience with IRIX or SGI products, but I have 
>>gone to their techical shows and listened to their developers and Linux 
>>conferences and have looked at at least some of their published 
>>benchmarks and journal articles.  The big difference here seems to be 
>>that I have understood some of these data sources.
> 
> 
> Right.  You've really demonstrated a firm grasp of the technical points in
> these threads.  You don't understand scalability, what it means, what
> architectural models benefit what type of computation, whether a gcc compile
> is really an adequate benchmark for comparing an IDE laptop drive to some
> unknown hardware running AIX, and so on.  If this is what you've understood, I
> shudder to think of those poor souls dependent on your expertise.

Well, I understand 'scalability' is a buzzword and despite repeated 
attempts to find out how you even think you are trying to use it, you 
don't even try to define it.  'Some unknown hardware running AIX'?  I 
will give you one hint - it is not an Origin!
> 
> Typical Diltertian PFB behaviour:  "I don't understand anything about what's
> going on in the box, but I completely got the brochure!"

Classic.  Running a gcc compile is something real, and repeatable, and 
avaliable to you at no cost if you wanted to do a comparison.  So 
instead of actually DOING something that shows something interesting - 
you demonstrate you read comics with the same lack of comprehension as 
you do anything else.  Well done.
> 

Michael E. Thomadakis wrote:
> On Sun, 18 Apr 2004, Timothy J. Bogart wrote:
> 
> t%  Date: Sun, 18 Apr 2004 17:59:31 -0600
> t%  From: Timothy J. Bogart <tbogart@frii.net>
> t%  Newsgroups: comp.unix.aix
> t%  Subject: Re: LINUX vs AIX
> t%
> t%  > AIX can have bad performance if tuned up in the WRONG way. Example: if you
> t%  > want to maximize small file I/O, then GOOD LUCK with that from a 12-way
> t%  > striped LV! Why do you need 12-way striped LVs? This is appropriarte for
> t%  > sequential files of large size. For small and frequent file I/O you need to
> t%  > spread the I/O accross as many drives as possible.
> t%
> t%  So, stiped across 12 drives (on 4 I/O channels) is not spread across as
> t%  many drives as possible.  And increasing the max raw thruput over
> t%  multiple drives and multiple channels doesn't improve both small and
> t%  large file access?
> 
> STRIPED accross 12 drives means that file blocks are interleaved (modulo 12)
> over ALL drives and ANY I/O reads / writes to ALL of them. STRIPING is good
> for sequential access of LARGE files.
> 
> Compilations usually involve many small files. Striping is the enemy of small
> files. It is better to define an LV on a volume group containing these drives
> and let LVM spread PP to MAX different phy. vol. allocation. In this way I/O
> to multiple files can take place concurrently if the files are spread to
> different phy. volumes. With your striping you are asking the system to carry
> out excessive I/O that takes up file cache and that you most likely throw
> away.
> 
> Read up on what striping is, what it is good at and when to avoid it.

Rather than go further down the silliness of this rabit trail here, how 
about getting back a little closer to the point.  Start with the picture 
of a slow little IDE hard drive in a laptop.  Got that picture?  Now, 
one might expect that a UNIX workstation with a reasonable speed SCSI 
drive could to similar work even better.  Just to make the comparison 
simple, a single drive on the laptop where all drive I/O activitiy 
occurs, and the same deal on the workstation. When it doesn't go faster 
on the workstation, and in fact gets hung up on I/O, you move over to a 
really snazzy, newish small UNIX server with fast proccessors, faster 
SCSI bus, newer, faster  SCSI drives - and you find it doesn't do any 
better than the workstation - maybe worse.  So, as a last resort, you 
try to move the I/O over to the rather expensive SSA, which you happen 
to stripe over 12 drives - because you can, and it still goes slow. 
Now, you focus on whether or not the bloody SSA stipe was the best way 
to go when you should be focusing on why neither of the UNIX platforms 
comes anywhere close to expected performance.  The very fact that both 
the single drive workstation and the 12 drive stripe are both out of 
whack might just give you a clue that tuning the 12 drive configuration 
might not be the way to go.  Maybe to go from a laptop where you are 
seeing , oh 20 or 30% I/O to a SCISI drive that is 90% + I/O bound for 
12 hours is something interesting.
> 
> 
> 
> t%  >
> t%  > What is the amount of max read ahead ?
> t%
> t%  Small percentage tuning doesn't address large issues, nor does read
> t%  ahead address I/O spent on writing the JFS log.
> 
> The log is not written to when you read.

Which is sort of why I said it was hanging up on the log.
> 
> t%  >
> t%  >
> t%  >
> t%  >
> t%  > t|  sitting pegged in I/O.  And that was pretty much stuck on the jfs log.
> t%  > t|  Even untarring source code takes minutes vs seconds.  We are not talking
> t%  > t|  about a few percent tuning here.
> t%  >
> 
> Log LV placement is critical in your 12-way striping. You need to use a volume
> group that is not so active.
Aw geez.  There is one SSA array, and there is only this going on on the 
box for the test.

Or even to consider - where is this seperate, unused huge I/O channel 
for the log for the reiser fs on the laptop.  You think maybe all this 
points to the fact that the log on AIX is causing performance problems?

You haven't lost sight of the forest for the trees, you are studying 
shrubbery.
> 
> 
> 
> t%  > Your I/O is not tuned up for the frequent small file I/O for code files.
> t%
> t%  No matter how many time you repeat it, it doesn't fit.
> t%  >
> t%  > t|  >
> t%  > t|  > I CANNOT say the same for our large Linux box. The MAX we could get out of a
> t%  > t|  > theoretical MAX of 800MB/sec to the RAID was around 370MB/sec. SGI has
> t%  > t|  > attributed this to limitations of the SGI's block device drivers (xscsi) that
> t%  > t|  > are planning to replace in the next major release. FYI, xscsi is MUCH better
> t%  > t|  > than the native Linux scsi drivers.
> t%  > t|
> t%  > t|  Well, are you saying you are getting the theoretical max on other boxes?
> t%  > t|     Every filesystem I have ever seen falls far short of theoretical, and
> t%  >
> t%  > AIX behaves VERY WELL if properly tuned. We are seeing close to the
> t%  > theoretical, i.e., the bus bandwidths.
> t%  >
> t%  > t|  heaven knows you have your choice of filesystems in Linux, with some
> t%  > t|  rather large differences for different kinds of loads.  Seems odd to me
> t%  > t|  you only report one side of a comparison here.  Are you saying that a dd
> t%  > t|  on the raw channel does not get full thruput???
> t%  >
> t%  > It was a dd to a striped volume where the slices are seen across all four FC
> t%  > channels. It was a plain data write to disk to measure the i/o path's
> t%  > throughput. It came out a little less than 1/2 of 800MB/sec
> t%  >
> t%  > t|
> t%  > t|  >
> t%  > t|  > The results you saw are either from xscsi or from their next proprietary scsi
> t%  > t|  > drivers. You are talking in a vacuum here. How can you tell what consitutes
> t%  > t|  > `good results'? See the previous paragraph.
> t%  > t|
> t%  > t|  Your are right, I didn't say that well.  See above comment on dd.  As I
> t%  > t|  recall from the article, they had to tweek the drivers to get the full
> t%  > t|  thruput on a raw device.  A high ninety some thing percent of channel
> t%  > t|  utilization is pretty good.  Guess I need to go back and look at the
> t%  > t|  article again, as I sure don't remember less than 50% utilization on a
> t%  > t|  raw data channel.
> t%  >
> t%  > What was the max of that channel? What kind of channel?
> t%
> t%  Well, I am going to try and be charitable here.  You mean you wrote to
> t%  the raw device?  What was your data source?  I am not familiar with
> t%  plain vs fancy data writes, but if I assume you are actually talking
> t%  about the appropriate data.  Then I can say, good question, now that you
> t%  have given a good data point, the next logical would be that you are
> t%  using devices not covered in the article.  IT makes it doubly
> t%  interesting, given the effort they made to address performance then sell
> t%  a configuration to a customer that is so out of whack.
> t%  >
> t%  > t|  >
> t%  > t|  <snip>
> t%  > t|  > TJB > Well, I am afraid you seem a little confused.  You keep refering to SMP
> t%  > t|  > TJB > issues and then jump to file caching then to file I/O.
> t%  > t|  >
> t%  > t|  > I am sorry that you cannot follow the discussion on the point of:
> t%  > t|  >
> t%  > t|  > ``Linux vs UNIX systems''
> t%  > t|
> t%  > t|  No need to be sorry, just please actually address the issues, or make
> t%  > t|  some actual comparisons.
> t%  >
> t%  > Advice: Read, think, answer;
> t%  >
> t%  > What issue are you adressing? Where are your comparisons?
> t%  >
> t%  > Lost again? Long sentences are hard to comprehend?
> t%
> t%  Well, since your asking, your non-sequitors are rather difficult.  And
>  (non-sequitur)

Ah good, if you can't understand, at least you can spell.
> t%  since you don't seem to be following along yet, perhaps you could spend
> 
> I really do not wish to follow your eratic (errant) really thought 'process'.
> 
> t%  some time analyzing why anyone would provide comparisons when they are
> t%  asking you to back up all the sweeping claims you made?
> 
> t%
> t%  And, of course, while still not addressing at all any of the other
> t%  claims you made about kenel preemption, etc, you jump right to what must
> 
> After you study about operating systems, their kernels, UNIX, SVr4, BSD Linux,
> you will realize that it is not me the person making the claims but the OS
> designers.
Ah, so the 'designers of UNIX, SVr4, BSD Linux' (I assume you meant BSD, 
Linux) are who wrote on 4/14

> Some of the areas that UNIX --still-- far surpasses Linux include
> fully-preemptive 64-bit kernels, processor isolation, faithull support for
> POSIX threads (Pthreads), support for large SMPs, Virtual Memory / File
> Caching mechanisms, RAS, large file systen support and efficiency in
> high-speed I/O.
> 
> The "ancients", such as, IRIX, Solaris and AIX do much better or at least much
> more careful work in the above areas. Large SMP linux installations reveal the
> above weaknesses accutely.
> 
> 2.6 Linux version is a big step closer to some of the above, but it remains to
> be seen how well it can catch up with the ancients '-)

Let's see, you want me to go ask Linus about this?
> 
> The only 'technical' info you have provided so far is something you read in a
> web site with articles whose contents are not refereed. You are trying to pass
> it off as the 'proof' that my statements are wrong. This is laughable really.
> 
> I WISH you would pose questions of technical nature to have an interesting
> discussion. I WISH you could contradict me on a technical basis.

Well, go back to my original post then - it isn't even that large.  You 
made claims with no data - I was trully curious if you had any actual 
data or experience to back them up.  Guess not.
> 
> t%  pass for wit on your home planet.  And top posting to boot.
> 
> Thanks God it has nothing to do with what passes as wit in yours ;-)
> 
> t%
> t%  How sad.
> 
> Dont' be sad, just study. I can be charitable and recommend books and
> articles. It may take some time but it will well worth it.
How about just addressing the original question?
> 
> If you want to reply be:
> 
> 1. Informative, OR
> 2. Funny, OR
> 3. BOTH.
> 
> -mt

Florian Heigl wrote:
> "Timothy J. Bogart" <tbogart@frii.net> wrote in message news:<40808cb6$0$203$75868355@news.frii.net>...
> 
> 
>>Hmmm, perhaps the whole I/O structure favors large files.  After giving 
>>up trying various tricks I turned it over to IBM support, who said there 
>>  was nothing broken.  An striped lv over 12 drives on a  4 way p630 , 
>>even parrallizing the compile took 16 times longer than my laptop, 
>>sitting pegged in I/O.  And that was pretty much stuck on the jfs log. 
>>Even untarring source code takes minutes vs seconds.  We are not talking 
>>about a few percent tuning here.
> 
> 
> Let me guess...
> object files did go to the same stripe set?
> jfslog is in the same stripe set?
> You parallelized the I/O toward the a stripe set?
> 
> 
> I don't want to express my opinion about AIX is slower on 
> the I/O than Your laptop. It might be. But I defintely want 
> to express my opinion about the way *You* are handling I/O.
> Everything You did was increasing the number of transactions toward
> a storage device that was intended for handling large, sequential I/O.

Well, in a different thread we could discuss the options available, but 
the real point here is not to to claim it is the best 12 drive 
configuration - but whether any sloppy 12 drive  configuration should 
out perform a single drive configuration.

On 2004-04-25, Timothy J. Bogart <tbogart@frii.net> wrote:
>
> Very simply, the 'linxu fan-boy' tripe.  If you hadn't snipped it, you 
> might have been able to follow it.  I laid out how one could respond in 
> kind - - and then said 'that could be fun, but lets please get back to 
> business'.  Maybe you could get a sighted co-worker to draw it out for you?

Sounds like I hit too close to home on that one.  Deal with it.  No one on 
usenet is obligated to make you feel better about your own shortcomings.

> Oh my freaking higher power, do you even comprehend what you claim to 
> read?  I don't really mind knowing surprisingly little, as it is 
> prefferable to knowing a whole lot that ain't so - as the saying sortof 
> goes.

In other words, no, you haven't read the LKML, and once again you're spouting 
off crap that you know absolutely nothing about.  You'd think you'd learn by
now.  Any one here can judge for themselves via the list archives whether its
easy to tinker in the kernel while being completely oblivious to the hardware.

> You need to go back and look at the start of the thread if you really 
> wanted to even know what the point was.  The claim you jumped in on was 
> on kernet preemptive qualities and virtual memory management.  Kinda 
> fundamental stuff.  And you seem amazed that after roughly 12 years of 
> kenel hacking, most of what is left over is dealing with hardware 
> issues?  sheesh.

You are really becoming tiresome.  Once again:  in theory, yes, even those 
features can be coded in ignorance of the hardware, but I guarantee you it'll
run like shit.  You have to know about the architecture before you can 
attempt to code it so it doesn't hurt to use it.  How hard is that to 
understand?

> Sigh.  So they replaced the algorythm, or  how it was applied.  Tuning 
> the algorythm is what I was referring to as real kernel hacking.

Sigh.  The rest of our educated readers most likely understood that this is
exactly why even your "generic" algorithms would do well to understand the
hardware.  Thank god you're not the one coding these features.

> And you don't seem to know the difference between a file system and a 
> kernel.  Nonetheless, even in that example, do you think that you 
> require a 64 bit system to do the code clean up?  Or just to test it at 
> the end?  A good example is that the folks who did the clustering code 
> for Digital Unix did it largely on IA32 laptops - kind of far removed 
> from the target hardware, but, as I recall, they said well above 90% of 
> the code was not done on the native hardware.

?!  Let's see:  by your proclamation here filesystems need know nothing about 
the kernel?!  Just where do you think all the filesystem support in Linux is
implemented?  Idiot.  As a former DEC employee I can tell you that alot of
the later code that our engineers developed was tested in emulators.  I'll 
give you a gold star if you can figure out precisely *what* they were 
emulating.  :-P  That's right, real freaking hardware.

> Oh, stretch your mind into the concept that linux-boys only deal with 
> Intel hardware because of price point.

I never said they only deal with Intel, but it's obvious to everyone but you
for some reason that the focus is stronger on Intel than on any other
architecture.

> Gee, I don't know, that sounds an awful lot like the argument that the 
> more developers, the better something will be.  Didn't you reject that 
> earlier?  Maybe it runs better on some platform because the folks using 
> that platform are really good?  Nah, I guess that couldn't happen.

Boy, your comprehension just sank to an all-time low.  I know it's a waste
of my time trying to get you to understand, but if you recall I pointed out 
that sheer numbers != superiority, *especially* when you're talking about
part-time hobbyists with no financial/legal investment as compared to full 
time professionals.  Yes, Linux has professionals, but the vast majority of
participants (myself included) have day jobs that don't involve the 
furtherance of Linux.  Linux runs very well on Intel, but largely due to 
the large number of people who suffered and identified bugs, who then went
to the small handful skilled enough to search and eliminate them.  Contrast
that with the stability of AIX which runs on a much smaller test pool of
hardware.  Yes, they don't have to test as many variations, but even on the
best supported hardware Linux isn't as stable as the least-used RS/6000.

> I don't know, who?  You insist on using insulting terms towards others 
> who you percieve as liking linux - I guess just because you are so cool 
> you are the only one who could guage it's value properly.  Here, I have 
> objected to the crap spewed, rather than data.  That's it.  If you had 
> paid attention, Linux isn't my favorite OS, and had the discussion 
> presented the same mindless junk on another subject, I would object as 
> well.  But you just assume that I believe that Linux is the 'one true 
> UNIX'.  It isn't, and I have said so.

All right, wipe the drool of your lip, dumb-ass, and repeat after me:  I 
*like* Linux.  Therefore it is stupid for me to insult anyone who likes 
Linux, since I would have to target myself.  Now, what I do dislike is 
idiots like you spouting off crap and press releases when you clearly 
demonstrate no command of the facts involved, much less even a rudimentary
understanding of the technology.

If I insulted you it wasn't (initially) intentional, but it's becoming 
very clear that it's well deserved.

> You can say you like Linux, but when you make those 'fan-boy' statements 
> you are no better than the old folks you used to say 'I'm not a bigot, 
> why some of my best frends are <insert racial epitath here>'.

Get a clue.  I'm one of the Linux users, not a mere friend of a user.  I
simply don't have unrealistic expectations for the platform in its current
incarnation.

> Ok, right there.  You have completely lost touch.  Where are my claims 
> of scalablity?  Go back to the thread you jumped in on.  The claim was 
> made Linux was not scalable.  I have been asking for the data.  I note 
> the vendor who sells this claims scalability.

Okay, just because you're that damned stupid, I'll bite.  You said:

  "OK, I will byte <sic>.  What is SGI not telling us about their large SMP
  boxes?  You have proof they faked their graphs they published about 
  their linear SMP performance?"

and:

  "...since the introduction of the Altix gives arguably the largest 
  horsepower in a single machine..."

The first is a query of yours regarding scalability (in case you don't 
understand what's implied by "linear SMP performance"), and the second is
*your* claim, but with no data to back it up.  And yet your run at the mouth
even after being informed of the Origin running IRIX that goes twice the
number of processors per node.

Now, I never disputed that the Altix generates some impressive numbers, but 
I did dispute your misguided statement above when the vendor in question has
a *primary* platform that (for now) scales far beyond what Linux on the Altix
can do.

Follow me, here:  I *also* note the vendor that has a more scalable product 
which, to date, you have done nothing to research yourself.

> All I get in response is that somehow if I used IRIX enough I would know 
>   Linux is not scalable.
>
> What crap.

I concur (though not of the same matter, obviously).

> Well, I asked someone else a question, and you came in with zero data. 
> No, you are not going to hold my hand thru anything, since you are 
> obviously incapable.

You know, just because you're incapable of understanding the data doesn't
mean it doesn't exist.  Try to live in less denial.

> Ah yes, I used to call this the 'lemming defence' but others tell me a 
> better term is the 'eat shit - a billion flies can't be wrong' defence. 
>   In spite of every opportunity to offer up any real experience you have 
> in how one platform handles loads any better than another, you now 
> resort to referring to others parties buying decisions - oh I am sure 
> they did all the right homework.

I gave you a specific example of the shortcomings of Intel's architecture,
and an x86 clone vendor that's done work to work around it, and that's not
evidence that the bottleneck exists?  You're as blind as you are stupid.

> Now you are just making stuff up.  Where did I contend that about 
> Windows?  WHERE?  How many decades ago was it demonstrated that writing 
> viruses for DOS/Windows/MacOS was easier than for any of the unices due 
> to the way they were linked/loaded?  How many uninces come out of the 
> box configured so that mail attachments are, if possible executed?  Of 
> course the number of CERTs is related to the how easy it is to exploit 
> the platform - that is why I brought it up.

And I was clearly demonstrating how different conclusions can be arrived at 
from the same set of data.  But that was obviously beyond your ability to
comprehend.  I'll try to stick to mono-syllabic words in the future.

> What's to get back to?  I never defended them as good in any way, and 
> said that they should be ashamed - I only said others should be ashamed 
> as well.

It gets back to the quality of code in the kernel, you moron.  Which 
impacts reliablity and scalability, among other things.

> Well, I can only hope that there still is an active UNIX down the road. 
>    Competition certainly won't come from the evil empire.

I agree, but I'm also pretty confident that the ecosystem will support 
multiple flavours of UNIX for the forseeable future.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

On 2004-04-25, Timothy J. Bogart <tbogart@frii.net> wrote:
>
> Well, duh, since I came right out and said I had no significant exposure 
> - but of  course the real point is that you really are stuck in the 
> concept that exposure to IRIX would somehow answer the question about 
> linux capabilities.

No, duh, I'm stuck with the obvious reality that *you* can't compare Linux
to *any* platform when you know *squat* about it.  Since you're learning-
impaired:  exposure to IRIX will not answer questions about Linux's 
capabilities.  It will, however, answer some questions about IRIX's 
capabilities.  This may <gasp> help when comparing the two.

> Ah, benchmarks are press releases.  Particularly SPEC.  be-all, end-all? 
>   Geeze, you must be pretty darn twitchy  to jump that far.  ROFL

I can only work with what you give me, and to date, that hasn't been much.

> Well, I understand 'scalability' is a buzzword and despite repeated 
> attempts to find out how you even think you are trying to use it, you 
> don't even try to define it.  'Some unknown hardware running AIX'?  I 
> will give you one hint - it is not an Origin!

I define scalability as a measureable metric.  If a computation takes x units
of time to compute on one processor, and adding processors makes that 
computation decrease linearly in proportion to the number of processors, 
*that's* scalable.  No platform meets the scalable definition perfectly, but 
AIX and IRIX come closer to Linux.  Linux is coming along, but there's a lot
of improvements still to be made.

> Classic.  Running a gcc compile is something real, and repeatable, and 
> avaliable to you at no cost if you wanted to do a comparison.  So 
> instead of actually DOING something that shows something interesting - 
> you demonstrate you read comics with the same lack of comprehension as 
> you do anything else.  Well done.

Running a gcc compile to compare disk I/O is absurdly stupid, but you did it
anyway.  You made no attempt to account for processor capabilities for 
something that is largely CPU-bound (and the different types of CPUs running
your little benchmark), nor did you make any attempt to discern how the 
filesystems were configured on either platform to see if they were tuned 
for that kind of work.  You've demonstrated absolutely no ability to define
a scientifically valid benchmark.  Well done.

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto