netdev - Re: AIM9 regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <31318813.77411222702581550.JavaMail.root@tahiti.vyatta.com>
Date:	Mon, 29 Sep 2008 08:36:21 -0700 (PDT)
From:	Stephen Hemminger <stephen.hemminger@...tta.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	David Miller <davem@...emloft.net>, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Subject: Re: AIM9 regression


----- Original Message -----
From: "Christoph Lameter" <cl@...ux-foundation.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc: "David Miller" <davem@...emloft.net>, shemminger@...tta.com, herbert@...dor.apana.org.au, netdev@...r.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.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html