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
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit 
http://www.beowulf.org/mailman/listinfo/beowulf

Reply via email to