On Sat, Jan 16, 2010 at 2:36 PM, Sasha Khapyorsky <[email protected]> wrote: > On 15:11 Wed 13 Jan , Hal Rosenstock wrote: >> > >> > In my tests I found that '8' is more optimal number (the tool works >> > faster and without drops) than '4' used in OpenSM. >> > >> > Of course it would be helpful to run this over bigger cluster than >> > what I have to see that the results are consistent. >> >> This is exactly my concern. Not only cluster size but use cases >> including concurrent diag discover and SM operation where SMPs are >> heavily in use. > > Was it investigated? What was a conclusions?
I was pointing out testing that needs to be done rather than testing already done. The use cases I mentioned are based on current experience. I'm sure there are more. >> There already have been a number of reports of dropped SMPs on this >> list with the current diags and this change will only make things >> worse IMO. >> >> Also, the OpenSM default should be at least as large as the diags for this. > > I don't know where concurrent MADs are used in the current "diags", do > you? > > This utility is not 'diags' at all. It is placed in ibsim/tests and I > wrote it for test purpose. In your original email on this, you proposed that this algorithm be incorporated in the diags (you wrote "I think that similar implementation in libibnetdisc (I can do it if we are in agreement :)) would improve its performance") so this comment thread appears relevant to me. -- Hal > Sasha > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
