[5716] in Release_7.7_team
Re: Athena machine graphics drivers
daemon@ATHENA.MIT.EDU (Charles Shubert)
Tue Feb 13 14:29:56 2007
In-Reply-To: <C8E17167-3000-482D-86D2-114A4C4A7ADB@mit.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A3761FD8-9E0B-4306-821C-6EB0AB477379@mit.edu>
Cc: Charles Shubert <cshubert@mit.edu>, Ivica Ceraj <ceraj@mit.edu>,
Justin Riley <jtriley@mit.edu>, owls@mit.edu, release-team@mit.edu,
Dave Wyman <dwyman@mit.edu>, Phillip Long <longpd@mit.edu>
Content-Transfer-Encoding: 7bit
From: Charles Shubert <cshubert@MIT.EDU>
Date: Tue, 13 Feb 2007 14:29:49 -0500
To: William Cattey <wdc@mit.edu>
X-Spam-Flag: NO
X-Spam-Score: 0.00
Bill,
It would seem that this paragraph defines our only alternative:
> Instead what you would need to do is override the generic OS
> installs on specific machines. Athena offers the ability to install
> special RPMs and even to prevent OS updates from displacing them.
> This sort of hand-tooling is done by the system owners. For systems
> owned by MIT, the way we did this in the past was to have
> designated special purpose clusters or groups of systems. But
> there again, the work was not done by Athena developers, and not
> part of the mainline release. Someone affiliated with a department
> or with the Faculty Liaisons was the designated person to make sure
> the hand tooling was done and kept up to date.
The primary issue is that we will be using StarBiochem in 7.01x
(Intro to Biology) for about 800 students per year. As a first order
guess, probably 80% of the students would be using their own machines
for this homework. I'd guess that the rest use Athena clusters in
their dorms and maybe a few other places. We may be able to
determine where students are when they are using StarBiochem from our
logs.
It is good to know what is doable.
Thanks,
--Chuck
On Feb 13, 2007, at 1:08 PM, William Cattey wrote:
> Hi Chuck,
>
> I'm actually no longer in the Athena reporting chain, so my answer
> is definitely NOT definitive. I've added the owls (Athena
> strategy) and the release-team (Athena implementation) team lists
> to the CC list here.
>
> Summary: The Athena Release is the victim of 20 years of evolution
> to be very low-cost, and very generic. To try and take it in the
> direction of offering a non-generic high performance graphic aspect
> to all or most of the systems served by the Release is extremely
> difficult, effectively impossible.
>
> Probably the best way to proceed is with a designated small group
> of systems where some person takes on the responsibility of making
> tweaking performance on those systems.
>
> Detail:
>
> What you propose is extremely problematic logistically from a
> number of standpoints:
>
> 1. The Athena Release is in a period of rampdown where the IS&T
> decision has been made to put progressively less energy into
> evolving it over time.
>
> 2. The Athena Release, to minimize the maintenance effort, has been
> HEAVILY focused on using components as generic as possible, and to
> MINIMIZE, effectively to zero, the number of special purpose
> drivers we fetch off the net and hand install to match particular
> hardware.
>
> 3. The distribution model for the Athena Release is basically,
> "anyone who knows how can run the installer and get it without
> accepting any special licenses". This means that graphics drivers,
> most of which come with "click through" licenses applicable to
> individuals are a PARTICULAR no-no for inclusion in Athena.
>
> 4. The diverse equipment base of Athena and the generic OS setup of
> Athena means that we'd be talking about fetching, testing,
> integrating, and maintaining, not one or two, but more like 8 or 10
> special purpose graphics drivers, most of which we really would not
> be supposed to be redistributing.
>
> Instead what you would need to do is override the generic OS
> installs on specific machines. Athena offers the ability to install
> special RPMs and even to prevent OS updates from displacing them.
> This sort of hand-tooling is done by the system owners. For systems
> owned by MIT, the way we did this in the past was to have
> designated special purpose clusters or groups of systems. But
> there again, the work was not done by Athena developers, and not
> part of the mainline release. Someone affiliated with a department
> or with the Faculty Liaisons was the designated person to make sure
> the hand tooling was done and kept up to date.
>
> The future vision for Athena is that it gets out of the business of
> offering the operating system, and instead offers services on top
> of a pre-installed OS. By sacrificing generic-ness, and middle-of-
> the-road-ness, it will be easier in the future to expect systems in
> the field to already have the highest performance graphics drivers
> installed. But we're still in the "explore the Vision" stage.
>
> Sorry to be unable to give the solution you hope for. Perhaps
> someone on owls or release-team sees something I have missed, but I
> think that by giving you the answer, "we've always given in the
> past", that you'll get an early version of what the "real answer is
> right now."
>
> Sorry,
>
> -Bill
>
> ----
>
> William Cattey
> Linux Platform Coordinator
> MIT Information Services & Technology
>
> W92-176, 617-253-0140, wdc@mit.edu
> http://web.mit.edu/wdc/www/
>
>
> On Feb 13, 2007, at 9:12 AM, Charles Shubert wrote:
>
>> Hi Bill,
>>
>> I'm not sure if you are the person to answer this question, but
>> I've had 3 people point the finger at you. So ...
>>
>>
>> Problem:
>>
>> We have a protein visualization program that is built on top of
>> Java3D (http://web.mit.edu/star/biochem/). It is pretty demanding
>> on graphics drivers. The graphics drivers drivers on the Athena
>> cluster machines in the clusters seem to us the generic driver.
>> This creates a performance problem for us for rotation of
>> molecules with the atoms showing.
>>
>> We get reasonable performance when we replace the generic driver
>> with the the native driver for a particular graphics card.
>>
>> This particular performance problem becomes a real big problem as
>> the size of the molecule gets bigger. With the current
>> performance students are limited to looking at fairly small
>> molecules. Our program is setup to retrieve any of the molecules
>> in the Protein Data Bank. Last year there were about 30,000
>> proteins in the Protein Data Bank. This year there are about
>> 40,000 and the crystallographers are submitting larger and larger
>> molecules. So, poor rendering performance is a problem.
>>
>>
>> Solution:
>>
>> To address the performance problem I'm rewriting the way our
>> program renders molecules, but it would be helpful if we could
>> improve the performance by taking advantage of fast graphics drivers.
>>
>>
>> Timeframe:
>>
>> I'd like to have my new version of the software and fast graphics
>> drivers for Athena cluster machines in place for Fall, 2007.
>>
>>
>> How can we make this happen?
>>
>> Thanks,
>>
>> --Chuck
>>
>
