On 24.01.2006 [01:39:07 +0200], Michael S. Tsirkin wrote: > Quoting r. Nishanth Aravamudan <[EMAIL PROTECTED]>: > > Subject: Re: Re: Userspace testing results (many kernels,many svn trees) > > > > On 23.01.2006 [23:22:45 +0200], Michael S. Tsirkin wrote: > > > Quoting r. Nishanth Aravamudan <[EMAIL PROTECTED]>: > > > > Subject: Re: Re: Userspace testing results (many kernels,many svn trees) > > > > > > > > On 23.01.2006 [10:24:12 -0800], Nishanth Aravamudan wrote: > > > > > On 23.01.2006 [19:55:05 +0200], Michael S. Tsirkin wrote: > > > > > > Quoting r. Shirley Ma <[EMAIL PROTECTED]>: > > > > > > > Subject: Re: Re: Userspace testing results (many kernels,?many > > > > > > > svn trees) > > > > > > > > > > > > > > > > > > > > > >If true, it seems that this line > > > > > > > >typedef unsigned long long cycles_t; > > > > > > > >should be replaced by > > > > > > > >typedef unsigned long cycles_t; > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > OK, I did it this way. > > > > > > # svn ci get_clock.h > > > > > > Sending get_clock.h > > > > > > Transmitting file data . > > > > > > Committed revision 5163. > > > > > > > > > > > > You might want to try this rev out. > > > > > > > > > > heh, ok. I'm going to let the 5162 version of a 32/32 setup finish, > > > > > then run 5163. > > > > > > > > Looks like 5162/5163 is fine building wise. Here is what I got for > > > > rdma_lat for a 32-bit server and 32-bit client: > > > > > > > > loading libehca local address: LID 0x0d QPN 0x140406 PSN 0x253f3e > > > > RKey 0x2340032 VAddr 0x00000010019001 > > > > remote address: LID 0x08 QPN 0x140406 PSN 0xa79d77 RKey 0x2340032 > > > > VAddr 0x00000010019001 > > > > Latency typical: 3.25746e+09 usec > > > > Latency best : 3.19975e+09 usec > > > > Latency worst : 4.21767e+10 usec > > > > > > > > and for rdma_bw: > > > > > > > > loading libehca local address: LID 0x0d, QPN 0x150406, PSN 0x1b3ee5 > > > > RKey 0x23a0032 VAddr 0x000000f7fce000 > > > > remote address: LID 0x08, QPN 0x150406, PSN 0x2fa0a9, RKey 0x23a0032 > > > > VAddr 0x000000f7fb8000 > > > > Bandwidth peak (#0 to #999): 4.3446e-07 MB/sec > > > > Bandwidth average: 4.3446e-07 MB/sec > > > > Service Demand peak (#0 to #999): 17301 cycles/KB > > > > Service Demand Avg : 0 cycles/KB > > > > > > > > So it's still present... > > > > > > > > Thanks, > > > > Nish > > > > > > Hmm. Could you please try running e.g. rdma_lat with -H to get all the > > > results? > > > > rdma_lat -H: > > > > loading libehca local address: LID 0x0d QPN 0x140406 PSN 0x304b04 RKey > > 0x2340032 VAddr 0x00000010019001 > > remote address: LID 0x08 QPN 0x140406 PSN 0xc99ca RKey 0x2340032 VAddr > > 0x00000010019001 > > #, usec > > Latency typical: 3.25746e+09 usec > > Latency best : 3.20378e+09 usec > > Latency worst : 4.0715e+10 usec > > Could the high/low bits be swapped?
I was thinking that might be it, but wasn't sure. > What happends if you change cycles_t from long long to long? > Could you try running the clock_test utility? I'll try the latter first (I found the usage from the file and it is built by make). Could you send me a patch to do the former, in case I need to? It can be a patch that applies directly in the perftest directory. Thanks, Nish _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
