Re: about powerpc version of in{,4}_cksum

[Bill Studenmund <wrstuden%netbsd.org@localhost>]

On Wed, 31 Jul 2002, Simon Burge wrote:

> On Wed, Jul 31, 2002 at 12:05:15AM +0900, enami tsugutomo wrote:
>
> > Could you please provide me your test case?  As I wrote in my mail, I
> > just test only single pattern.
>
> I'll put my test code on ftp.netbsd.org a bit latter today.  I do
> have a static binary (static because it uses a soft-float libc) at
> ftp://ftp.netbsd.org/pub/NetBSD/misc/simonb/ppc-cksum

I tried Simon's tester on my Beige G3 (266 G3). Here are some results:

tanis> ./ppc-cksum 1000000 5 1532
align:2 old=3e8d new=3e8d oldt=4.791922 sec (465 clocks) newt=4.019249 sec (396 
clocks)
align:2 old=9aa1 new=9aa1 oldt=4.661676 sec (465 clocks) newt=3.953436 sec (395 
clocks)
align:1 old=b3e8 new=b3e8 oldt=4.691076 sec (468 clocks) newt=4.000052 sec (400 
clocks)
align:0 old=9eb1 new=9eb1 oldt=4.631008 sec (463 clocks) newt=3.937790 sec (393 
clocks)
align:1 old=c4ed new=c4ed oldt=4.702039 sec (469 clocks) newt=4.008972 sec (399 
clocks)
tanis> ./ppc-cksum 100000 5 1504 1504 1504 1504 1504 672
align:232031 old=0dfe new=0dfe oldt=2.474448 sec (247 clocks) newt=2.099424 sec 
(210 clocks)
align:110112 old=fa4e new=fa4e oldt=2.476022 sec (248 clocks) newt=2.102895 sec 
(210 clocks)
align:203303 old=cc29 new=cc29 oldt=2.480910 sec (247 clocks) newt=2.121875 sec 
(209 clocks)
align:111231 old=7a86 new=7a86 oldt=2.493162 sec (248 clocks) newt=2.113013 sec 
(211 clocks)
align:032332 old=4cd2 new=4cd2 oldt=2.484821 sec (248 clocks) newt=2.104897 sec 
(209 clocks)
tanis> ./ppc-cksum 100000 5 40 1440 40 1440 40 1440 40 1440 40 1440 40 672
align:222303212220 old=503c new=503c oldt=2.661700 sec (266 clocks) 
newt=2.311122 sec (231 clocks)
align:112223201321 old=fd3a new=fd3a oldt=2.684226 sec (268 clocks) 
newt=2.331070 sec (233 clocks)
align:032103132022 old=ee75 new=ee75 oldt=2.680048 sec (266 clocks) 
newt=2.324729 sec (232 clocks)
align:111200033033 old=7379 new=7379 oldt=2.686052 sec (269 clocks) 
newt=2.325758 sec (232 clocks)
align:211202312333 old=da2c new=da2c oldt=2.699350 sec (270 clocks) 
newt=2.336112 sec (233 clocks)

The first case looks at a small packet. The second case looks at a fat
chained mbuf, and the third case tries to simulate the UDP packets I was
seeing in the NFS debugs I saw. The 40 byte mbufs are what's left of
various IP headers that were assembled (AFAICT). A "better" test would
have the small ones be all zero (as they really are), but we don't have
that. :-) The main thing is that "real" udp reassemblies have big & little
mbufs to look at.

Looks like the new code is faster across the board. :-)

Take care,

Bill