From owner-freebsd-stable@FreeBSD.ORG Wed Sep 22 16:43:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F9C1065696 for ; Wed, 22 Sep 2010 16:43:17 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDCF8FC12 for ; Wed, 22 Sep 2010 16:43:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o8MGh6Vg036504; Thu, 23 Sep 2010 02:43:06 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 23 Sep 2010 02:43:06 +1000 (EST) From: Ian Smith To: Tom Evans In-Reply-To: Message-ID: <20100923012846.V11124@sola.nimnet.asn.au> References: <10b0bdef-2bb1-44c8-9ffb-7d3167147a4f@q2g2000vbk.googlegroups.com> <20100922081230.GA20489@server.vk2pj.dyndns.org> <20100922230552.D11124@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-724426006-1285172803=:11124" Content-ID: <20100923022750.X11124@sola.nimnet.asn.au> Cc: Adam Vande More , Bryce , freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: SuperMicro i7 (UP) - very slow performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 16:43:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-724426006-1285172803=:11124 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20100923022750.V11124@sola.nimnet.asn.au> On Wed, 22 Sep 2010, Tom Evans wrote: > On Wed, Sep 22, 2010 at 2:50 PM, Ian Smith wrote: > > It seems far more than just CPU performance is awry.  Adam's data from > > his i7 shows 2.7 times Bryce's speed for the md5 -t, maybe a lower EST > > rate? - but that could no way account for buildworld taking 22.5 hours. > > > > Recent buildworld (albeit i386) on my Thinkpad T23 ran just shy of 3.5 > > hours, without -j on an 1133MHz P3-M, 768MB of 133MHz RAM, 5400rpm UFS > > disk - with X/KDE running meanwhile (~5-7% CPU penalty). > > md5 -t is quite a small benchmark, even with his misfunctioning CPU it > took <6 seconds to complete. > > If his problem is a misapplied heatsink/fan, then his CPU could be > throttling when it gets hot, the hotter it gets the more it throttles, > which could explain his massive buildworld walltime. Perhaps running > something like: > > apply -0 "md5 -t" `jot 10` > > would display a notable difference. > > Intel chips are quite good at running without much cooling and not > dieing, using thermal throttling to preserve the CPU. I guess you mean on-package, without p4tcc or ACPI throttle support? >From Bryce's original message: # Disable throttle control (and rely on EIST) hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" which is sensible, and seems to have been applied to all CPUs, but from http://www.bryce.net/files/dmesg.boot we see for each of cpu[0-7]: est0: on cpu0 est0: Invalid id16 (set, cur) = (20, 21) est0: Can't check freq 2667, it may be invalid est0: Invalid id16 (set, cur) = (19, 21) est0: Can't check freq 2533, it may be invalid est0: Invalid id16 (set, cur) = (18, 21) est0: Can't check freq 2400, it may be invalid est0: Invalid id16 (set, cur) = (17, 21) est0: Can't check freq 2267, it may be invalid est0: Invalid id16 (set, cur) = (16, 21) est0: Can't check freq 2133, it may be invalid est0: Invalid id16 (set, cur) = (15, 21) est0: Can't check freq 2000, it may be invalid est0: Invalid id16 (set, cur) = (14, 21) est0: Can't check freq 1867, it may be invalid est0: Invalid id16 (set, cur) = (13, 21) est0: Can't check freq 1733, it may be invalid est0: Invalid id16 (set, cur) = (12, 21) est0: Can't check freq 1600, it may be invalid which looks a bit ominous? What does 'sysctl hw.acpi dev.cpu' say? Running multiple md5s or say 'dd if=/dev/random of=/dev/null bs=1M &' in a short sleep loop echoing "`date` `sysctl -n dev.cpu.0.freq` plus indicative coretemp sysctls might reveal something as it heats up? Surprisingly (?) the dmesg shows no ACPI thermal zones (detected). cheers, Ian --0-724426006-1285172803=:11124--