[openib-general] ia64 perf and FMR

[Grant Grundler]

On Mon, Apr 04, 2005 at 04:43:21PM -0700, Roland Dreier wrote:
> A binary search to find the changeset that makes the difference would
> be really useful.  I read through the svn log from r2046 through r2082
> and I don't see anything that should make a difference to IPoIB.

I've worked backwards and didn't see any changes with netperf TCP_STREAM.
I can't establish why the perfomance is substantially
different with r2050 compared to before:

	SVN Rev		Best	Worst
	r2104-MSIX	3609	2623
	r2081-MSIX	3580    2639
	r2062-MSIX	3609	2618
	r2054-MSIX	3602	2635
	r2050-MSIX	3598	2636

	r2050-IRQ	3594	2433
	r2050-orig	1738(*)

Numbers are in Mbits/s. 3600 is ~450 MB/s. 2600 is ~325 MB/s.

Differences between Best/Worst are caused by binding netperf and
netserver to the same (or different) CPU as the one handling
interrupts. See "-T" in netperf 2.4.0-rc1 "experimental"
release.

(*) I didn't use -T with netperf to explore IRQ assignment.

I think differences in "Best" column are not significant.
(Except for the r2050-orig number of course...)


...
> So I wonder what obvious thing I'm missing...

I'm using gcc-3.3.5 (Debian 1:3.3.5-8) now and may have used gcc 3.4
or a slightly older gcc-3.3.  I might be confusing gcc version
with other work I've done too.  I'm of course kicking myself for being
sloppy and not tracking that precisely.

I'm also using s different version of netperf (2.4.0-rc1).
But I don't expect substantial changes in TCP_STREAM implementation
that might cause 2x difference in performance.
TCP_STREAM test is "mature" code.

My best/worst theory right now is the TS90 switch was in a semi-comatose
state when I collected the perf numbers in January. When I tried to collect
perf data in March, the TS90 switch was non-responsive at the serial
console and a power cycle took care of that. I hadn't cycled power
on the switch since installing it in June 2004 or so.

thanks,
grant