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? What happends if you change cycles_t from long long to long? Could you try running the clock_test utility? -- MST _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
