2.4/2.6/ppc/powerpc/8245/8347e

[Marc Leeman]

a small update:

> 8245: 2.4.34
> 8237e: 2.6.21.1

I've tried the following setup:
multicast stream @8192 kbps, one process taking in and dumping the data
on each board [1].

a) 8245/2.4.34/e100: 2.3.43-k1, @400 MHz
b) 8245/2.6.17/e100: 2.3.43-k1 [2] @350 MHz
c) 8347e/2.6.21.1/gianfar @400 Mhz
c) XScale-IXP42x/2.6.18-4/ixp4xx @266 MHz (NSLU2)

(2.3.43-k1 is the e100 driver version).

The process load for taking in the data is:

a) 4-5% [3]
b) 10-11%
c) 13-14%
d) 4-5%

While the current 8347/gianfar platform is the worst performer, the
2.6 kernel with the 2.4 e100 (before the rewrite) seems to perform
poorly too [4].

So the 834x preforms worse wrt the 8245 based configuration even though
it is slightly higher clocked.

It seems as if I bumped into the problem that lead me stick with the 2.4
in the first place for this 8245 platform; but never got round to
investigating. I find these results especially intriguing when
considering an ARM platform (NSLU2 device) that I had around, clocked at
only 66% of the 8347 and at 80% of the 8245 performs certainly in par
with the last one...

Even though I will need to recheck this (results to follow), a quick
test didn't reveal any significant difference between a ppc and powerpc
arch in the kernel.

It does look like, on our 8245/83xx platforms, the 2.6.x kernel performs
worse wrt the 2.4 ppc kernels and the 83xx configuration is worse wrt
the 8245 based configuration [5]. In retrospect, we had signals that
there was a problem with the 8245/83xx performance over the network last
year when investigating gstreamer, but due to time pressure but assumed
it was due to gstreamer and not the processor. This came as a suprise to
some of the ppl on the gstreamer mailing list that reported performant
ports to ARM architectures.

The results with the NSLU2 will certainly put heat on us from management
when redesigning or for follow up designs :(

Anyhow, I'm currently extending my test setups since this is an
important problem and set back.

If anyone has a hint to explaining what is going on here, please do
since solving this will certainly beat redesigning (esp. considering the
timeframe we've been assigned).


I've only found one relevant reference to 2.4/2.6 network performance
decrease at this point [6].


[1] sources attached
    mcrecv -p 225.1.2.3 -a 12345
    mcsend -p 225.1.2.3 -a 12345 -b 8192
    I'm preparing more tests in the next days, in trying to figure out
    what really is going on here.
[2] 2.4 driver ported to 2.6 kernel.
[3] This figure is read from top and not from the app since it seems to
    be an underestimate (./fs/proc/array.c).
[4] I believe I ported the 2.4 e100 to the 2.6 2 years ago because it
performed much better, but I'll verify that in the next days.
[5] Obviously, testing 834x against the 2.4 kernel is not really an
option  :)
[6] http://www.mail-archive.com/linux-net@vger.kernel.org/msg01283.html

-- 
  greetz, marc
Don't think I'm going to miss you, any of you. I'm not. Well, maybe
a little bit.
	Rygel - Into the Lion's Den - Wolf in Sheep's Clothing
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recv_mcast.c
Type: text/x-csrc
Size: 9462 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070628/92c4ca3d/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: send_mcast.c
Type: text/x-csrc
Size: 8854 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070628/92c4ca3d/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070628/92c4ca3d/attachment.pgp>