Another one bites the dust - SGI

This is a discussion on Another one bites the dust - SGI ; hamei writes: > If SGI HAS made Linux work well in smp mode, then there's > something very very fishy going on in light of the GPL ... Please elaborate. *p...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 64

Thread: Another one bites the dust

  1. Re: Another one bites the dust

    hamei writes:

    > If SGI HAS made Linux work well in smp mode, then there's
    > something very very fishy going on in light of the GPL ...


    Please elaborate.

    *p

  2. Re: Another one bites the dust

    In article , Per Ekman
    wrote:

    : hamei writes:
    :
    : > If SGI HAS made Linux work well in smp mode, then there's
    : > something very very fishy going on in light of the GPL ...
    :
    : Please elaborate.

    I suspect it's something like the following:

    Hamei thinks linux doesn't work (well) with multiple CPUs. (which is incorrect)

    Hamei thinks that SGI has some magic SMP elixir that they've added to their
    Linux to make it handle SMP better. (which is mostly correct)

    Hamei thinks that just because SGI added code to their linux kernel, that it
    instantly has to appear in linus' kernel too or they'd be breaking the GPL.
    (which is incorrect)


    With the help of SGI, IBM and the usual crew of linux folk, the recent linux
    kernels have had very good multi-cpu scaleability, covering both SMP and NUMA
    systems (of which SGI is not the only vendor, of course).

    While in a perfect world SGI could just dump a truckload of code into the linux
    kernel and make it scale perfectly, in the real world the code and concepts need
    to be reworked a lot just to work at all in linux, and then reworked even more
    to be acceptable for inclusion into any mainstream kernel branch.

    In a commercial environment you can get by with functional but not quite
    beautiful code, but in open source projects such things are much less practical.
    So even when the code works, it often needs to be reworked a few more times to
    better integrate with the rest of the project and keep the maintainability
    factor of the whole project. (Of course, there's plenty of other open source
    projects that don't get this, but they have nothing to do with this discussion)

    As such, vendor trees (such as SGI's Altix kernel) tend to be out of sync with
    the more mainline trees more often than not. Eventually, though, I see nothing
    stopping SGI from incorperating into linux everything good about IRIX, while
    leaving behind plenty of unneeded baggage at the same time.

    This is good for SGI, good for Linux, and good for customers. The only people
    who get shafted are the rabid IRIX fanboys who will never let go of the OS
    regardless of whether everyone else in the world moves on to something better.

    I love IRIX as much as anyone else, but I know that SGI either a: doesn't have
    the skills and ability to move the goodness of IRIX to Linux, in which case it's
    doubtful if they have the skills to keep IRIX a viable platform either, or b:
    has all the skills and ability needed to make Linux as good as and better than
    IRIX, in which case the future looks pretty bright, no matter what the OS is
    called.


    So, to all the rabid IRIX fanboys: can the Linux hate. You're not doing anyone
    any good, and it's very tiresome to read. Go look at how much good it's done the
    Amiga or BeOS fanboys.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --

  3. Re: Another one bites the dust

    Tony 'Nicoya' Mantler wrote:

    >
    > So, to all the rabid IRIX fanboys: can the Linux hate. You're not doing anyone
    > any good, and it's very tiresome to read. Go look at how much good it's done the
    > Amiga or BeOS fanboys.


    not that i'm a irix fanboy; but if linux didn't have that vapid penguin, it would
    be much more appealing (not to mention some standardization). freebsd is much
    easier to deal with. too bad mosix wasn't available for it anymore.

    >
    >
    > Cheers - Tony 'Nicoya' Mantler
    >
    > --
    > Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    > -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --



  4. Re: Another one bites the dust

    In article <4128DDE8.903D58D5@mrnutty.com>, SkyWriter
    wrote:

    : Tony 'Nicoya' Mantler wrote:
    :
    : >
    : > So, to all the rabid IRIX fanboys: can the Linux hate. You're not doing
    : > anyone
    : > any good, and it's very tiresome to read. Go look at how much good it's
    : > done the
    : > Amiga or BeOS fanboys.
    :
    : not that i'm a irix fanboy; but if linux didn't have that vapid penguin, it
    : would
    : be much more appealing (not to mention some standardization). freebsd is much
    : easier to deal with. too bad mosix wasn't available for it anymore.

    At least it's not a big ugly 'sgi'.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --

  5. Re: Another one bites the dust

    Tony 'Nicoya' Mantler wrote:

    > In article <4128DDE8.903D58D5@mrnutty.com>, SkyWriter
    > wrote:
    >
    > : Tony 'Nicoya' Mantler wrote:
    > :
    > : >
    > : > So, to all the rabid IRIX fanboys: can the Linux hate. You're not doing
    > : > anyone
    > : > any good, and it's very tiresome to read. Go look at how much good it's
    > : > done the
    > : > Amiga or BeOS fanboys.
    > :
    > : not that i'm a irix fanboy; but if linux didn't have that vapid penguin, it
    > : would
    > : be much more appealing (not to mention some standardization). freebsd is much
    > : easier to deal with. too bad mosix wasn't available for it anymore.
    >
    > At least it's not a big ugly 'sgi'.
    >


    not 'ugly', it's 'nasty'. and three of them found a new owner. so i'm left with my
    namesake.
    plus all the other octanes, o2's, origins,indy's, indigo2's. and a second
    TUXcluster, as well.
    the first one should make a nice graphics cluster, and the second one a openmosix
    compute
    cluster, maybe run lustre as well.

    >
    > Cheers - Tony 'Nicoya' Mantler
    >
    > --
    > Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    > -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --



  6. Re: Another one bites the dust

    hamei writes:

    >barefoot wrote:


    >> I'd say it's the other way round, they probably listened too much... look
    >> at the different country's home page, here in the Aus backwater it's all
    >> MIPS/Irix on the home page still, and I would guess that SGI wouldn't do
    >> that unless they still sell lots of MIPS/Irix systems here.


    >I think you're agreeing with me :-)


    Probably, depends how things are read, but ....

    >In Ozz they don't have to try to please a bunch of ignerant
    >Wall-Streeters. Hence, the emphasis on the true strengths of


    Only because the Linux fever has not spread thru. to mainstream yet
    (research institutions/university not included).

    >SGI ... Who the hell CARES about Altix ? It's a stinking Linux
    >box. If you had purchasing responsibility for a large outfit,
    >would you choose going-down-the-tubes SGI who can't even afford
    >a decent Internet connection these days, or IBM for your Linux


    :-), I am guessing you've been trying to download 6.5.25

    >implementation ? Or HP ? And here we are talking about 1024

    ^^^^^
    This is the company ALL SGI fanboys should despise. Notice every broad
    market promotion of late has been targeted at SGI:

    -Shrek <-> graphics/media
    -HP Remote Graphics <-> VAN??
    -HPC Linux <-> Altix (granted they're in there first)

    Cheers
    barefot

    >What do they have left to sell ? Buildings are gone. Alias
    >is gone. Engineering is gone. Irix looks to be on its way
    >out. Quality has taken a hike. Doesn't seem real likely
    >that all the hot air around Linux is gonna do the job ...
    >looks like the Defense Dep't may have to do a rescue
    >operation one of these days ...




    >Sad, that's what it is.


  7. Re: Another one bites the dust

    On 2004-08-21, Benjamin Gawert wrote:
    >
    > But since You think You're the source of wisdom for the whole world, please
    > explain me clueless why a multi-cpu computer with slower CPUs is better than
    > one with fast CPUs...


    Christ, Benjamin, we've been going over that in your concurrent attack on
    MIPS in comp.sys.aix. Anyone who's actually managed enterprise systems
    knows that concurrency cannot always be made up for by clock-rate, *even* on
    x86/Itanium. Database servers in particular are typically much better off
    with multiple slower CPUs than with a single CPU with an equivalent
    aggregate clock rate if you have to scale among a large number of users.

    Now couple this simple reality with a decent architecture that allows
    simultaneous full-bandwidth point-to-point communications betweent the CPU
    and various I/O devices. You don't think separate CPUs gain significantly
    from that? And have you already forgotten that the fastest CPU is worthless
    if it can't get data fast enough to keep it busy?

    You have certainly been consistent in your mantra against MIPS, but I have
    yet to see any convincing logic behind it. It's an absurdly poor systems
    engineer that thinks you can scale a system purely by increasing the CPU
    clock rate.

    --
    --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

  8. Re: Another one bites the dust

    Arthur Corliss wrote:

    > Christ, Benjamin, we've been going over that in your concurrent
    > attack on MIPS in comp.sys.aix. Anyone who's actually managed
    > enterprise systems knows that concurrency cannot always be made up
    > for by clock-rate, *even* on x86/Itanium. Database servers in
    > particular are typically much better off with multiple slower CPUs
    > than with a single CPU with an equivalent aggregate clock rate if you
    > have to scale among a large number of users.


    Sure. So what? You can get multi CPU systems with x86 and Itanium as well,
    and especially Itanium scales very well...

    > Now couple this simple reality with a decent architecture that allows
    > simultaneous full-bandwidth point-to-point communications betweent
    > the CPU and various I/O devices. You don't think separate CPUs gain
    > significantly from that? And have you already forgotten that the
    > fastest CPU is worthless if it can't get data fast enough to keep it
    > busy?


    You obviously didn't read my postings carefully enough. I didn't say I/O is
    unimportant, I just said I/O performance can't compensate for low CPU
    performance. And unlike SGI MIPS an SGI Altix offers both high I/O
    performance and very fast CPUs, and that's why SGI should continue this
    way...

    > You have certainly been consistent in your mantra against MIPS, but I
    > have yet to see any convincing logic behind it. It's an absurdly
    > poor systems engineer that thinks you can scale a system purely by
    > increasing the CPU clock rate.


    Sure, but I didn't say that. I really suggest You re-read again what I
    wrote...

    Benjamin


  9. Re: Another one bites the dust

    On 2004-08-22, Tony 'Nicoya' Mantler wrote:



    > So, to all the rabid IRIX fanboys: can the Linux hate. You're not doing anyone
    > any good, and it's very tiresome to read. Go look at how much good it's done the
    > Amiga or BeOS fanboys.


    Amen, well put, and it's been needed to be said for quite some time. I happily
    manage six or seven flavours of UNIX at work, and not one is the perfect OS.
    Linux hasn't gotten to the level of integration with hardware that I'd
    trust it to replace my HA systems, but it's getting closer all the time, and
    it has a few good ideas of its own, as well.

    I'm actually curious to see what it'll be able to do on the LPAR pSeries
    hardware I just bought. I may just have to retire that piece of crap HP
    Blade server I bought last year for edge services. I've hit over a 50%
    failure rate for hard drives in less than one year of ownership. :-P Can't
    wait to see what will go next...

    --
    --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

  10. Re: Another one bites the dust

    Arthur Corliss wrote:

    > On 2004-08-22, Tony 'Nicoya' Mantler wrote:
    >


    [meaningless religious backlash snipped]

    >
    >
    > I'm actually curious to see what it'll be able to do on the LPAR pSeries
    > hardware I just bought. I may just have to retire that piece of crap HP
    > Blade server I bought last year for edge services. I've hit over a 50%
    > failure rate for hard drives in less than one year of ownership. :-P Can't
    > wait to see what will go next...
    >


    you will love the pSeries. IBM does a great job on their mainframes.
    always a pleasure to reverse engineer them :-)

    What vendor drives failed at that rate? current enterprise drives should
    have a MTBF of 200,000 to 800,000 hours.

    >
    > --
    > --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



  11. Re: Another one bites the dust

    SkyWriter writes:

    >What vendor drives failed at that rate? current enterprise drives should
    >have a MTBF of 200,000 to 800,000 hours.


    Compaq/Fujitsu - we had 8 compaq drives failed in 6 months Compaq replaced
    the other 4 before it had a chance to fail.

    Cheers
    barefoot

  12. Re: Another one bites the dust

    barefoot wrote:

    > SkyWriter writes:
    >
    > >What vendor drives failed at that rate? current enterprise drives should
    > >have a MTBF of 200,000 to 800,000 hours.

    >
    > Compaq/Fujitsu - we had 8 compaq drives failed in 6 months Compaq replaced
    > the other 4 before it had a chance to fail.
    >
    > Cheers
    > barefoot


    capacity/rpm? model numbers? please.
    thanks!



  13. Re: Another one bites the dust

    SkyWriter writes:
    >> Compaq/Fujitsu - we had 8 compaq drives failed in 6 months Compaq replaced
    >> the other 4 before it had a chance to fail.


    >capacity/rpm? model numbers? please.
    >thanks!


    It's been a few years and my memory is not what it used to be in fact come
    to think of it it never was that good :-).

    20GB/rpm??? model numbers???, but here is a link:
    http://wwss1pro.compaq.com/support/r..._CW01.xml&dt=3

    Note, our drives did come from a Compaq Deskpro but weren't on the list
    and so were replaced on support rather than the exchange program, until we
    threatened to complain on the basis of 'not fit for purpose' to consumer
    affairs, Compaq then decided to replace all hard drives (including
    ones that have not failed).

    IIRC Fujitsu owned up to about 300,000 of these drives being defective.

    Cheers
    barefoot



  14. Re: Another one bites the dust

    SkyWriter writes:

    > What vendor drives failed at that rate? current enterprise drives
    > should have a MTBF of 200,000 to 800,000 hours.


    That's way low. I'd say 1.2M to 1.4M (with 1M for non-enterprise
    drives). Yes, I know that is what the manufacturers claim and has no
    relation to reality. Reliable numbers are hard to impossible to find.

    *p


  15. Re: Another one bites the dust

    Per Ekman wrote:

    > SkyWriter writes:
    >
    > > What vendor drives failed at that rate? current enterprise drives
    > > should have a MTBF of 200,000 to 800,000 hours.

    >
    > That's way low. I'd say 1.2M to 1.4M (with 1M for non-enterprise
    > drives). Yes, I know that is what the manufacturers claim and has no
    > relation to reality. Reliable numbers are hard to impossible to find.
    >
    > *p


    unless you happen to have a statistically significant sample


  16. Re: Another one bites the dust

    barefoot wrote:
    > SkyWriter writes:
    >
    >>What vendor drives failed at that rate?

    >
    > Compaq/Fujitsu -



    anything with the name Compaq on it is to be avoided at all costs.

  17. Re: Another one bites the dust

    SkyWriter writes:

    > Per Ekman wrote:
    >
    > > SkyWriter writes:
    > >
    > > > What vendor drives failed at that rate? current enterprise drives
    > > > should have a MTBF of 200,000 to 800,000 hours.

    > >
    > > That's way low. I'd say 1.2M to 1.4M (with 1M for non-enterprise
    > > drives). Yes, I know that is what the manufacturers claim and has no
    > > relation to reality. Reliable numbers are hard to impossible to find.
    > >
    > > *p

    >
    > unless you happen to have a statistically significant sample


    True. It's usually pretty hard to get though, even if you have a
    couple of hundred drives they tend to be from the same batch (such as
    in a cluster) and are sensitive to skewing the result on that basis.

    But for the hell of it, back-of-the-envelope for one of our clusters
    with around 350 disks real MTBF is in the order of 100,000 hours, but
    that is not enterprise disks. Enterprise disks in my experience is
    about a factor of 10 more reliable than desktop disks, and tape
    another factor of 10 (Magstar that is). Reliability for certain
    desktop disks goes to hell fast after 2 years.

    *p



  18. Re: Another one bites the dust

    On 2004-08-24, SkyWriter wrote:
    >
    > you will love the pSeries. IBM does a great job on their mainframes.
    > always a pleasure to reverse engineer them :-)


    I'm replacing some S7As, and SP cluster, and other assorted H50s, etc., which
    have definitely done the job, but support it too expensive. It will be
    nice upgrade moving from SSA DASD to a FAStT SAN as well. :-)

    > What vendor drives failed at that rate? current enterprise drives should
    > have a MTBF of 200,000 to 800,000 hours.


    Keep in mind that these are low-end blades that use laptop drives. Complete
    crap. As I said, these are non-critical edge services that I don't want
    to waste serious hardware on. Even so, I expected more from HP, and I sadly
    didn't get 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

  19. Re: Another one bites the dust

    On 2004-08-25, barefoot wrote:
    >
    > It's been a few years and my memory is not what it used to be in fact come
    > to think of it it never was that good :-).
    >
    > 20GB/rpm??? model numbers???, but here is a link:
    > http://wwss1pro.compaq.com/support/r..._CW01.xml&dt=3
    >
    > Note, our drives did come from a Compaq Deskpro but weren't on the list
    > and so were replaced on support rather than the exchange program, until we
    > threatened to complain on the basis of 'not fit for purpose' to consumer
    > affairs, Compaq then decided to replace all hard drives (including
    > ones that have not failed).
    >
    > IIRC Fujitsu owned up to about 300,000 of these drives being defective.


    All of the ones used now are Hitachis (DK23EB 40GB, 5400RPM).

    --
    --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

  20. Re: Another one bites the dust

    On 2004-08-24, Benjamin Gawert wrote:
    >
    > Sure. So what? You can get multi CPU systems with x86 and Itanium as well,
    > and especially Itanium scales very well...


    Did I not point that out? Again: *even* on x86/Itanium SMP w/slower
    clock-rates typically provide better throughput than faster single CPU
    boxes for database servers. About the only time you can realistically say
    that a single faster CPU is equal is for single-user systems, where the tasks
    are serialised. With large numbers of users cache-coherency plays a key
    role, so spreading it among multiple processors is better.

    Keep on the subject -- you specifically asked why a single faster CPU
    wouldn't be better than slower multiple CPUs, and this is a real world
    example.

    > You obviously didn't read my postings carefully enough. I didn't say I/O is
    > unimportant, I just said I/O performance can't compensate for low CPU
    > performance. And unlike SGI MIPS an SGI Altix offers both high I/O
    > performance and very fast CPUs, and that's why SGI should continue this
    > way...


    I have read your posts, I just don't agree with you that the CPUs are so
    slow that they're holding up the Origin. It has to be one of the best
    balanced architectures out there. Could the CPUs be faster? Yes. But given
    the type of work they do, and the current I/O limitations of the hardware
    I'd wager that they're fast enough.

    > Sure, but I didn't say that. I really suggest You re-read again what I
    > wrote...


    You implied as much when asked the single versus multple cpu question. I
    suggest you re-read what *you* wrote as well.


    --
    --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

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast