Date: Sat, 28 Apr 2012 23:38:36 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Tim Hogard <thogard@abnormal.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: Slow on v210? Message-ID: <20120428213836.GA12730@alchemy.franken.de> In-Reply-To: <201204231426.q3NEQFSm066866@v.abnormal.com> References: <20120423120040.01C8C106582A@hub.freebsd.org> <201204231426.q3NEQFSm066866@v.abnormal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120428213836.GA12730>