[openib-general] Re: Re: Userspace testing results (many kernels, many svn trees)

[Michael S. Tsirkin]

Quoting r. Nishanth Aravamudan <nacc at us.ibm.com>:
> 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 <nacc at us.ibm.com>:
> > > 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 <xma at us.ibm.com>:
> > > > > > 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