On Wed, Sep 9, 2009 at 6:38 PM, Bart Van Assche<bart.vanassche@gmail.com> wrote:
quoted text
> On Wed, Sep 9, 2009 at 12:29 AM, Chris Worley <worleys@gmail.com> wrote:
>> I'm wondering why it's so easily repeatable by me, and those I work
>> with, and nobody else?  I have another completely different
>> configuration w/ the same issue...
>
> It would help if you could run the following test:
> * Connect an SRP initiator back-to-back to the SRP target.

Many of my tests have been back-to-back, and using different switches,
with  no effect.

quoted text
> * Install an operating system combination on initiator and target with
> which SRP did not work properly under heavy load.

I'm not sure what test is being requested.  I have tried many tests
using the same OS/Dirtro/etc... combination on both target/initiator
sides.

quoted text
> * Install and run OpenSM on the target if this software is not yet
> running on the target.

I do generally avoid running it in the target, so will try this test.

quoted text
> * Repeat the SRP stress test on the initiator system that is connected
> back-to-back to the SRP target.

Does "SRP Stress Test" mean some specific test included w/ SCST?

quoted text
>
> This will tell us whether or not the IB switch or its firmware is
> causing the SRP issues.

I've definitely removed the switch/firmware from being the cause.

I'm thinking the reason you can't repeat the test may be latency
related.  We get ~50usecs average latency (on small block sizes),
which can't be achieved using regular SSD's (and rotating drives are
nowhere close).  Maybe a ramdisk would help repeat the issue.

Thanks,

Chris
quoted text
>
> Bart.
>
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general