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
hardware.
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
--
Patrick Geoffray
Myricom, Inc.
http://www.myri.com