[Beowulf] SuSE 9.3

[Mikhail Kuzminsky]

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 
>>than
>once
>> > a year.
>> 
>> which is sad, really.  they've been so traumatized by the dominant
>> platform that they expect that changing anything will break
>everything.
>> the very concept of a standard, let alone an interface standard 
>>(ABI)
>> is foreign to this mentality.
>
>Theory v. practice.  Implementation (i.e., compiler and linker 
>output)
>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 
>significant
>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 ? 

Yours
Mikhail 


> 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 
>>the
>> plate and saying "our application requires Linux ABI 3.14 and we 
>>will
>> fix bugs where it doesn't", the ISV just annoints a particular 
>>config
>> (OS release, firmware revision, disk setup, these magic three 
>>patches,
>> phase of moon).  certification is really an admission that the app 
>>is
>> 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 
>the
>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 
>of
>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, 
>yada.
>Despite my best efforts, they stuck with RHL x.y requirements.  They 
>too
>had a substantial history with their app that supported their 
>position;
>they also thought I was out of my mind--perhaps, but not to this 
>point.
>
>> > revenue associated with certifying an already released app on a 
>>new
>OS
>> > -- 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 
>>mean
>> that you also have to screw your customers.  hey, with a little spin
>> we can even make certification sound like we're 
>>_doing_them_a_favor_!
>
>Many customers DEMAND certification, most accepted policy 
>explanations
>and our continued specific performance in lieu of certification. 
> But,
>even so, on a couple of occasions I was ultimately required to 
>provide
>distro-release.version-specific certification to specific customers
>based solely on their insistence--this I do blame on the lawyers...
>
>-- 
>dnl
>
>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 
>http://www.beowulf.org/mailman/listinfo/beowulf