Re: AIM9 regression

[Stephen Hemminger <stephen.hemminger@vyatta.com>]

----- Original Message -----
From: "Christoph Lameter" <cl@linux-foundation.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: "David Miller" <davem@davemloft.net>, shemminger@vyatta.com, herbert@gondor.apana.org.au, netdev@vger.kernel.org
Sent: Monday, September 29, 2008 4:54:11 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: AIM9 regression

Ilpo Järvinen wrote:

> ...I was thinking earlier to answer "time?", but now once been there, it 
> seems that more time is more appropriate... So far I haven't been able to 
> find a way to create a reproducable serie of result numbers with aim9 
> tcp_test... it seems that the results vary within that (at least) 20% 
> margin. Can Christoph actually get stable numbers out of it with 27-rcs
> (I haven't extensively tested .22 yet with long test durations but it 
> seems that same problem occurs with it as well if short tests were used)?

Results fluctuate between 10 - 25%. The problem occurs with the short
durations as well. If this is due to the additional code complexity in later
kernels as we suspect then it may be an issue with cpu cache effectiveness.

Going to 64 bit binaries also yields a significant hit (as high as 30%) which
also indicates caching issues.

Both 64 bit kernels and later kernels cause the variability of results to
increase. 64 bit has double the effect than a 2.6.27 kernel. All indications
of cpu caching issues. The L1 cache may become ineffective due to the
increased cache footprint.

-------------
One of the items showing up in the profile is the local side port allocation.
Is the ephemeral port range getting full? If it is then the random port scan
could take a long time to find the next free slot, especially now that source
ports are randomized.