[Beowulf] Three notes from ISC 2006

Patrick Geoffray patrick at myri.com
Wed Jun 28 13:25:40 PDT 2006

Kevin Ball wrote:
>   I have two large concerns.
>   One is that finding a software stack that works with the latest
> interconnect products may or may not correlate well with what end users
> are interested in.  For some protocols (particularly MPI) this doesn't

I would only care for MPI, at least at the beginning, and I would only 
use the native MPI implementation. It would also be possible to choose 
the environment you want, among a list of various distros and kernel. 
Yes, it's possible to tune to death, but usually customers don't go that 
far. Using standard kernels/distro should be good enough. If an 
interconnect requires kernel patching, nodes could be rebooted with the 
right kernel before each test. You have to reboot anyway, so it does not 
cost much to boot a different image. I would not impose a unique 
kernel/distros for all interconnect, free range to use the best one is 
fine by me.

>   The second concern is keeping up with N different release cycles in
> terms of having things at the latest stable software version, and

That's a fair concern. The problem would be running the previous 
benchmarks/applications when a new driver is uploaded. If the release 
cycle is too small or if there are too many benchmarks to run, it may 
take too much time. To solve that, you can impose an update window, 
every quarter for example. All of the contributed benchmarks are rerun 
every quarter if there is a new driver for a specific interconnect. So 
your results are globally up to date.

>   So in short... yes, I like the idea a lot, and I think it could
> potentially get us into a better place than we are now in terms of
> vendors and customers knowing how things compare.  However, there are

I think it would solve the problem of Linpack and HPCC not being good 
enough and use real application for driving improvement.

> I'd support such an effort... I do wonder what would happen in terms of
> marketing and/or vendor support if a situation like the last 3 years of
> AMD/Intel were to arise for Interconnects.  If some vendors became
> clearly technically inferior, would they withdraw support of the
> project?

After the initial hardware contribution, the vendors don't have much 
support to do, except providing updates and check that the environment 
is the best one (kernel, lib, etc). Of course, the hardware would have 
to be updated every 3 years or so, but if the vendors want to show their 
latest gear and if the momentum from a business point of view is there 
(think SPEC), then it would make sense for a vendor to keep providing 

I just hope this will be picked up by an academic that can convince 
vendors to donate. Tax break is usually a good incentive for that :-)

Patrick Geoffray
Myricom, Inc.

More information about the Beowulf mailing list