On 2009-03-05 01:32, Dennis Peterson wrote:
> RedHat Linux, AMD Athlon 2Mhz, signatures are uncompressed and include all
> Sane
> Security signatures and MSRBL signatures. The following is unscientific and
> anecdotal, but repeatable:
>
> [...]
>
> Time: 2.242 sec (0 m 2 s)
>
> [...]
>
> Solaris 9, Sparc, single 500Mhz cpu (Dual proc returns similar numbers)
>
> Time: 27.203 sec (0 m 27 s)
On 2009-03-04 22:45, Dennis Peterson wrote:
> I think this cannot be cpu speed alone but you never know.
>
There are lots of differences: Intel CPU vs Sparc CPU, gcc 3.4 vs Sun
Studio 12 vs gcc 4.3, Linux vs Solaris, and maybe more
(what frequency does the memory module run at, ..)
So I did a test on the same box: measure time it takes to load DB in
Linux, and Solaris10 (running in VMware, so that might slow it down a bit):
Debian Linux, Intel Core2 Quad, gcc version 4.3.3 (Debian 4.3.3-5):
cvd: 1.2s, cld: 0.7s, cvd + 3rdparty: 1.4s
Solaris10 (32-bit) VMware, Intel Core2 Quad @2.83Ghz, Sun C 5.9
SunOS_i386 Patch 124868-08 2008/11/25:
cvd: 2.9s, cld: 1.8s
Solaris10 (32-bit) VMware, Intel Core2 Quad @2.83Ghz, gcc 3.4.3
(csl-sol210-3_4-branch+sol_rpath):
cvd: 2.6s, cld: 1.6s
Solaris10 (32-bit) VMware, Intel Core2 Quad @2.83Ghz, gcc 4.3.3 [*]:
cvd: 2.4s, cld: 1.3s
Solaris10 (64-bit) VMware, Intel Core2 Quad @2.83Ghz, Sun C 5.9
SunOS_i386 Patch 124868-08 2008/11/25, -m64 -O2 [*]:
cld: 1.34s
Solaris10 (64-bit) VMware, Intel Core2 Quad @2.83Ghz, gcc 3.4.3, -m64 -O2:
cld: 1.31s
If looking only at Solaris, then clearly the 64-bit version is the
winner (not much difference between gcc and SunC), and on 32-bit gcc
4.3.3 is the winner.
Still even on Solaris running in VMware, the DB is loaded in 1.8s worst
case, not 14s as on the T2000.
So I don't think Solaris is the reason for the slower DB load times, at
least not on Intel CPUs.
I also tested Solaris vs Linux on sparc (though they are not identical
sparc boxes this time, only similar):
Debian Linux, UltraSparc IIe (Hummingbird) @0.5Ghz, gcc 4.3.3 (GCC):
cld: 8.4s
Debian Linux, UltraSparc IIe (Hummingbird) @0.5Ghz, gcc 4.3.3 (GCC),
-mcpu=ultrasparc -O2
cld: 8.16s
Debian Linux, UltraSparc IIe (Hummingbird) @0.5Ghz, gcc 4.3.3 (GCC), -m64
cld: 9s
Solaris10, Netra t1 (UltraSPARC-IIi 440MHz), gcc 3.4.6:
cld: 17.1s
Looks like -mcpu=ultrasparc helped a bit [*]
On 2009-03-04 22:54, Jose-Marcio Martins da Cruz wrote:
> Time: 14.949 sec (0 m 14 s)
>
> A T2000 with 8 cores looks like this :
>
> # psrinfo -v
> Status of virtual processor 0 as of: 03/04/2009 21:44:58
> on-line since 01/30/2009 12:56:40.
> The sparcv9 processor operates at 1000 MHz,
> and has a sparcv9 floating point processor.
> ...
> Status of virtual processor 31 as of: 03/04/2009 21:44:58
> on-line since 01/30/2009 12:56:42.
> The sparcv9 processor operates at 1000 MHz,
> and has a sparcv9 floating point processor.
>
What gcc version did you use? Did you set -mcpu flag?
Looks like the Linux/gcc-4.3.3 on sparc beats Solaris10 on a sparc
T2000, at least for DB load times.
It wouldn't surprise me to find out that gcc-4.3.3 is responsible for
the speedup, gcc's optimizers improved a lot in the past years.
You might want to try CFLAGS="-m64 -O2 -g -mcpu=niagara", and
CFLAGS="-mcpu=niagara -O2 -g", and see if any of them is faster
than the defaults.
On 2009-03-05 00:16, shuttlebox wrote:
> Those T2000's are not that fast executing a single thread, the main
> benefit with that platform is the large number of threads they can
> execute in parallel which of course is of great benefit in many real
> world cases. But I assume this case is single threaded and so the
> speed difference is not that impressive.
>
> With the use of DTrace you could probably see where it spends its time.
Indeed, you can handle more parallel scans with so many cores.
Make sure you increase MaxThreads in clamd.conf to something like 17 or
65, see which one is faster when you run clamdscan -m /largedirectory.
[*]
The gcc 4.3.3 is a gcc I bootstrapped myself on Solaris, since I found
no gcc 4.3.x package.
Also on Solaris 64-bit I used -m64 -O2 as CFLAGS, otherwise it would
default to 32-bit.
The default CPU target for gcc on SPARC is v7:
$ file clamscan
clamscan: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for
GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux
2.4.1, not stripped
Using -mcpu=ultrasparc -O2 I get:
clamscan: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version
1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs),
for GNU/Linux 2.4.1, not stripped
And with -m64 -O2 I get (however -m64 is slower in this case):
clamscan: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for
GNU/Linux 2.4.18, dynamically linked (uses shared libs), for GNU/Linux
2.4.18, not stripped
Best regards,
--Edwin
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
