<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 24, 2014 at 7:55 AM, Michael Rasmussen <span dir="ltr"><<a href="mailto:mir@miras.org" target="_blank">mir@miras.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>I think the issue here is that OpenSM is a single threaded application<br>
so when the CPU which is assigned to it maxes out performance will<br>
drop. So I guess it comes down to a trade-off between the<br>
performance of the host CPU and the performance of the switch hardware.<br></blockquote><div><br></div><div>You're right in a general sort of sense; if the opensm process is resource starved, that will result in slower performance for subnet manager operations. That said, the subnet manager isn't involved in data transfers, except to program switch forwarding tables and answer path requests. Neither of these are particularly important for data transfers, unless the topology is constantly changing (like if links are flapping), or the network is otherwise sick. I wouldn't expect subnet manager performance to effect infiniband transfer performance, unless it was picking poor routes. That would be a function of opensm routing algorithm choice/implementation, not of opensm performance. </div><div><br></div><div>I'd be much more concerned about fixing bugs in the subnet manager, which is trickier in the case of switch-based subnet managers. I've seen all sorts of weird subnet manager failures over the years, including the subnet manager completely going out to lunch, which can be fixed by upgrading to newer versions. </div><div> -nld</div></div></div></div>