George Bosilca <bosi...@icl.utk.edu> writes: > Dave, > > You are absolutely right, the parameters are now 6-7 years old, > gathered on interconnects long gone. Moreover, several discussions in > this mailing list indicated that they do not match current network > capabilities. > > I have recently reshuffled the tuned module to move all the algorithms > in the base and therefore make them available to other collective > modules (the code is available in master and 1.10 and the future > 2.0). This move has the potential for allowing different decision > schemes to coexists, and be dynamically selected at runtime based on > network properties, network topology, or even applications needs. I > continue to have hopes that network vendors will eventually get > interested in tailoring the collective selection to match their > network capabilities, and provide their users with a performance boost > by allowing for network specific algorithm selection.
That sounds useful, assuming the speed is generally dominated by the basic fabric. What's involved in making the relevant measurements and plugging them in? I did look at using OTPO(?) to check this sort of thing once. I couldn't make it work in the time I had, but Periscope might be a good alternative now. If it's fairly mechanical -- maybe even if not -- it seems like something that should just be done regardless of vendors. I'm sure plenty of people could measure QDR fat tree, for a start (at least where measurement isn't frowned upon).