Date: Mon, 25 Apr 2011 20:26:42 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Bartosz Fabianowski <freebsd@chillt.de> Cc: freebsd-stable@freebsd.org, John <john@theusgroup.com>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: System extremely slow under light load Message-ID: <20110425184728.C73992@sola.nimnet.asn.au> In-Reply-To: <4DB51F27.5010508@chillt.de> References: <4DA596D3.1090803@chillt.de> <op.vt1efdn68527sy@pinky> <BANLkTik5Jq1QP776xQ0zQvQ5MKYe4LQZUA@mail.gmail.com> <4DB44DA3.5060509@chillt.de> <4DB4589B.2020909@ksu.ru> <4DB45D6C.20203@chillt.de> <20110424182456.9DD03589@server.theusgroup.com> <4DB46ED4.2010500@chillt.de> <20110425004818.GA22579@icarus.home.lan> <4DB51F27.5010508@chillt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Apr 2011, Bartosz Fabianowski wrote: [Jeremy wrote:] > > As the processor gets hotter, internal clocks and so on are throttled > > within the hardware to try and stabilise the temperature (to keep the > > thermal trip point being reached, re: "emergency shutdown"), which > > greatly decreases performance. I'm not sure if there's a way to > > detect this, but I would hope (?) that it would be visible via the > > CPU clock frequency (on FreeBSD this would be sysctl > > dev.cpu.X.freq). > > sysctl dev.cpu.X.freq is used to set the frequency. I have not found any > way to read back its internal state so far. dev.cpu.X.freq does reflect the current frequency; I don't know whether or how any internal clock throttling might be exposed. Jeremy's right, it's running very hot, probably 20C too hot. I was just going to mention a couple of things you could try when it began to seem all too familiar .. a bit of hunting found your previous overheating problems on a Dell Studio 1557 from April last year: http://lists.freebsd.org/pipermail/freebsd-acpi/2010-April/006415.html and your eventual apparent solution which included some fiddling with thermal parameters but primarily by disabling p4tcc and acpi_throttle hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" in loader.conf; I'm surprised you haven't tried that again on this one? > hw.acpi.cpu.cx_lowest: C1 See below. > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 26.8C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 100.0C > hw.acpi.thermal.tz0._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 tz0 looks to be a fan. It seems unlikely that any temp. sensor inside a machine with CPU temp. at 82C could possibly be as low as 26.8C, so this value is likely as bogus as the 0.0C CPU reported by tz1. This fan should come on at 55C and run fastest above 71C. If your CPU is at 82C and the fan isn't running flat out, it'd overheat for sure. tz0.active is -1, not running - but maybe the BIOS is controlling it? > hw.acpi.thermal.tz1.temperature: 0.0C > hw.acpi.thermal.tz1.active: -1 > hw.acpi.thermal.tz1.passive_cooling: 1 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: 95.0C > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: 100.0C > hw.acpi.thermal.tz1._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: 0 > hw.acpi.thermal.tz1._TC2: 2 > hw.acpi.thermal.tz1._TSP: 10 _ACx is N/A here, unless there's a separate CPU fan? Anyway at bogus 0.0C it's never going to trigger passive or active cooling. You said before that with the fixed DSDT to get proper temperature reading here, it shut down due to over temperature, which of course it should .. does that fixed DSDT include fixing detected tz0 temperature .. if so the fan might behave itself without having to use .thermal.user_override=1 > dev.cpu.0.temperature: 82.0C > dev.cpu.0.freq: 1333 Are you limiting it to 1333 manually, or with powerd's -M switch? > dev.cpu.0.freq_levels: 1734/45000 1599/41741 1466/38582 1333/35485 1199/32426 > 1066/29457 933/26552 816/23233 699/19914 583/16595 466/13276 349/9957 > 233/6638 116/3319 Clearly including p4tcc and/or acpi_throttle N*12.5% rates; compare to dev.est.0.freq_settings below to figure the freqs added by throttling. Hopefully this machine will respond as well to disabling both methods as your earlier one, as you reported here (same subject, later thread): http://lists.freebsd.org/pipermail/freebsd-acpi/2010-April/006443.html The more I review those threads, the more it seems likely that this is your main problem on this one too. > dev.cpu.0.cx_supported: C1/3 C2/245 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 285us Try using C2. It helps more with some CPUs than others, but it's worth a try for further reducing heat, especially at idle. Ie in rc.conf: performance_cx_lowest="C2" economy_cx_lowest="C2" Latency 245us isn't long compared to the delays you're experiencing :) > dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 > 1333/35485 1199/32426 1066/29457 933/26552 With throttling disabled, those are what you should be left with for dev.cpu.0.freq_levels. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110425184728.C73992>