Date: Mon, 25 Apr 2011 08:56:46 -0700 From: "Kevin Oberman" <oberman@es.net> To: Ian Smith <smithi@nimnet.asn.au> Cc: Bartosz Fabianowski <freebsd@chillt.de>, freebsd-stable@freebsd.org, John <john@theusgroup.com>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: System extremely slow under light load Message-ID: <20110425155646.26D5C1CC0F@ptavv.es.net> In-Reply-To: Your message of "Mon, 25 Apr 2011 23:58:39 %2B1000." <20110425232429.N85801@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Mon, 25 Apr 2011 23:58:39 +1000 (EST) > From: Ian Smith <smithi@nimnet.asn.au> > Sender: owner-freebsd-stable@freebsd.org > > On Mon, 25 Apr 2011, Bartosz Fabianowski wrote: > [..] > > See above: Unfortunately, the machine did nor respond well at all. Instead, > > it is overheating even worse. > > Sorry to hear none of that helped. It seems a very serious problem, and > it would be useful to know if it behaves any better under linux or not. > > > > 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" > > > > I have set dev.cpu.X.cx_lowest="C2" at run-time. If I understand correctly, > > this should achieve the same effect. The CPU does not seem to ever make it to > > C2 though, even after I enable it: > > > > %sysctl dev.cpu | grep cx_usage > > dev.cpu.0.cx_usage: 100.00% 0.00% last 270us > > dev.cpu.1.cx_usage: 100.00% 0.00% last 399us > > dev.cpu.2.cx_usage: 100.00% 0.00% last 403us > > dev.cpu.3.cx_usage: 100.00% 0.00% last 404us > > dev.cpu.4.cx_usage: 100.00% 0.00% last 323us > > dev.cpu.5.cx_usage: 100.00% 0.00% last 313us > > dev.cpu.6.cx_usage: 100.00% 0.00% last 174us > > dev.cpu.7.cx_usage: 100.00% 0.00% last 137us > > You need sysctl hw.acpi.cpu.cx_lowest="C2" instead .. that's what > /etc/rc.d/power_profile adjusts when you apply or remove power. > I doubt it's likely to help much given the scale of overheating. > > > > > 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. > > > > Yes, these are the frequencies I have available now. 1333 makes the machine > > idle around 85°C, 1999 leads to 78-80°C. > > That's pretty sad. Not sure what the first two differing by only 1MHz > means .. but I'm out of ideas, and my depth. As several have either discovered or pointed out, the dev.cpu.X.freq is telling you what FreeBSD is requesting, not what the CPU is actually doing. Particularly, if high temperatures cause TCC to kick in, this will not show up. IF you really want to monitor CPU temperature on an Intel CPU, use the coretemp kernel module. I use it on Intel systems that lack ACPI support for temperature monitoring. It uses a junction on the die, so it will be somewhat higher than the package temperature. TCC works by simply skipping 'n' out of 8 clock cycles. It really does not change the clock speed at all. Typically, only EST or the AMD equivalent actually does this. FreeBSD attempts to use TCC for power management, for which it was not intended. As has been repeatedly reported, it is of no use for this. I always recommend that it be turned off. But this has NO effect on its use for temperature management. So turning off TCC (or p4tcc, as it is called on FreeBSD) does nothing. TCC will automatically skip cycles when the _PSV temperature is exceeded. On some CPUs, this can be VERY high. My old Pentium-M ThinkPad starts throttling at 95C and will shut down at 99C. Compared to desktop systems, this is REALLY high, but the output you posted shows yours at 100C! I would assume that means that TCC should kick in at about 95 or 96C which does not entirely explain what you are seeing. Unfortunately, your system does not provide a value for _PSV, so I have no idea when it will actually kick in, but it should be in the data sheet for the CPU. If ACPI does not hange it, it runs in a purely automated fashion with no human intervention available. I wish I could provide some easy way to detect when it kicks in, but I don't think there is one. You can force it while monitoring performance. Try running md5 or sha256 on a bunch of random (/dev/random) data. Collect the time it takes to do a bunch of these and you will see it increase by .125 every time throttling adds another step to the pause time. It will be fairly dramatic and very close to steps of exactly .125 of the original time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110425155646.26D5C1CC0F>