Well -- it's not just the cores -- what was the usage of the cores that
were being used? were 3 out the 8 'pegged'? Are these 'real' cores, or
HT cores? In the Core2 and P4 archs, HT's actually slowed down a good
many workloads unless they were tightly constructed to work on the same
data in cache. Else, those HT's did just enough extra work to block cache
contents more than anything else.
What's the disk I/O look like? I mean don't just focus on idle cores --
if the wait is on disk, maybe the cores can't get the data fast enough.
If the network is involved, well, that's a drag on any message checking.
I'm seeing times of .3msgs/sec, but I think that's with networking turned
on. Pretty Ugly.
poifgh wrote:
Henrik K wrote:
Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
used
and any nondefault rules/settings? Certainly sounds strange that 1 core
could top out the same. Anyone else have figures? Maybe I've borked
something myself..
The problem is not with 22 being a low number, but when we have other free
cores to run different SA parallely why doesnt the throughput scale linearly
.. I expect for 8 cores with 8 SA running simultaneously the number to be
150+ msgs/sec but it is 1/3rd at 50 msgs/sec
