Slow on v210?
Marius Strobl
marius at alchemy.franken.de
Sat Apr 28 21:38:47 UTC 2012
On Mon, Apr 23, 2012 at 02:26:15PM +0000, Tim Hogard wrote:
>
> I'm at the inital stages of looking into the problems here.
>
> I just put Release 9.0 on a single CPU v210 and it is much slower
> than I expected. A simple perl program runs at 1/6th the speed of
> the Solaris 9 machine I'm testing aginst. Other things involing
> basic utils also seem to run about that ratio. Compiles are also
> very slow.
>
> For testing I've got a Sol 9 dual 1.33 Ghz netra 210 with
> 4 gig of ram and a single 1.33 ghz v210 with 2 gig of ram.
> My tests show both system have about 1 gig free and I run
> 4 processes per core:
>
> #!/usr/bin/perl
> foreach $i (1..1000000) {
> $i{$i}=$i;
> }
>
> The FreeBSD 9.0 and perl 5.12 (from ports) with no load is running
> much slower than the Sol 9 with perl 5.10 a few other things running.
>
> sol$ time ./p
>
> real 0m4.110s
> user 0m3.430s
> sys 0m0.610s
>
> f9$ time ./p
> 27.24 real 6.10 user 21.00 sys
>
> 2 on f9 take 55 or so seconds, 4 on the dual cpu take about 8 seconds.
>
> Other things also seem slower but I haven't benchmarked them but they should in the are ballpark.
> The disks on the n210 are 2.5 and 3.5 on the v210. Both are 7200 rpm but everything is in cache.
> The ram seems identical.
>
> The freeBSD machine should not be 7 times slower.
Could you please do some profiling in order to determine where (i.e.
which syscall etc) the time is spent?
>
> Other issues:
> 1) The machine needed the vm.kmem_size="1024" in /etc/loader.conf or it wouldn't boot.
> (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2012-01/msg00414.html)
> fixed by stopping boot and typing something like set vm.kmem_size="1024m" at
> the laoder prompt.
Apparently, this is a bug in the machine independent parts of the VM
triggered by extra sparse physical memory layouts as seen with USIIIi-
based machines with 2 GB of RAM. You can work around this without
sacrificing physical memory by setting the vm.kmem_size_scale loader
tunable to 2. Until the underlying problem is fixed, stable/9 defaults
to the same scaling.
>
> 2) base.txz just wouldn't end up with the right sha-256 hash even when checked
> on other machines. Fixed by using net install.
>
ATA_CAM broke ATAPI DMA for some chipsets causing data corruption.
You can work around it by manually reverting to PIO mode. For a
v210, setting the loader tunable hint.ata.2.mode to PIO4 should do
this. Until the underlying problem is fixed, stable/9 defaults to
not using ATAPI DMA along with ATA_CAM for the chipsets identified
so far.
Marius
More information about the freebsd-sparc64
mailing list