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

[Nishanth Aravamudan]

On 24.01.2006 [01:39:07 +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 [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?

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