[Beowulf] SuSE 9.3
kus at free.net
Wed Jul 13 08:17:58 PDT 2005
In message from "Lombard, David N" <david.n.lombard at intel.com> (Wed,
13 Jul 2005 07:23:57 -0700):
>From: Mark Hahn on Tuesday, July 12, 2005 5:27 PM
>> > Corporate users and ISVs don't want to see the OS revised more
>> > a year.
>> which is sad, really. they've been so traumatized by the dominant
>> platform that they expect that changing anything will break
>> the very concept of a standard, let alone an interface standard
>> is foreign to this mentality.
>Theory v. practice. Implementation (i.e., compiler and linker
>can substantially impact performance and correctness.
>As example, the 2.4.6-2.4.18 range of kernels saw a steady rise in
>short/small I/O performance at the expense of a steady and
>loss of large-I/O performance.
Sorry, does it incorrect for latest 2.4.x, for example 2.4.21 ?
BTW, if you say about ext2fs/ext3fs, and need huge I/O, why not to use
xfs file system ?
> In a cluster that we built, we had to
>have an I/O monster app run on 2.6.3 nodes and another app run on
>2.6.10? nodes so that both apps made their performance targets.
>> > On the user side, it takes a lot of effort to install, certify,
>> > and then deploy a new OS. On the ISV side, there is little to no
>> certification is bad for users. instead of an ISV stepping up to
>> plate and saying "our application requires Linux ABI 3.14 and we
>> fix bugs where it doesn't", the ISV just annoints a particular
>> (OS release, firmware revision, disk setup, these magic three
>> phase of moon). certification is really an admission that the app
>> buggy in indeterminate ways, and that the ISV doesn't care.
>When I was responsible for such a statement, I had a "batch" app that
>was truly only sensitive to kernel and glibc -- and that's EXACTLY
>requirement I enumerated, a minimal set of kernel and glibc
>requirements; eventually it needed to become a bounded range. I also
>had a substantial history with the app and a sufficient understanding
>the kernel and glibc to confidently make the claim.
>A sister app, a large graphic app was much more sensitive to the
>environment, e.g., C++ libs, graphics device drivers, yada, yada,
>Despite my best efforts, they stuck with RHL x.y requirements. They
>had a substantial history with their app that supported their
>they also thought I was out of my mind--perhaps, but not to this
>> > revenue associated with certifying an already released app on a
>> > -- it's purely a cost factor unless the ISV is releasing new code.
>> managing cost is a good thing. but doing so does not necessarily
>> that you also have to screw your customers. hey, with a little spin
>> we can even make certification sound like we're
>Many customers DEMAND certification, most accepted policy
>and our continued specific performance in lieu of certification.
>even so, on a couple of occasions I was ultimately required to
>distro-release.version-specific certification to specific customers
>based solely on their insistence--this I do blame on the lawyers...
>My comments represent my opinions, not those of Intel Corporation.
>Beowulf mailing list, Beowulf at beowulf.org
>To change your subscription (digest mode or unsubscribe) visit
More information about the Beowulf