From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 24 09:39:14 2005 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 539E916A4CE; Thu, 24 Feb 2005 09:39:14 +0000 (GMT) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51C1C43D5C; Thu, 24 Feb 2005 09:39:13 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([192.168.2.2]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j1O9d4V2075186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2005 10:39:05 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <421DA0B5.4060705@portaone.com> Date: Thu, 24 Feb 2005 11:39:01 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050224011924.992A65D07@ptavv.es.net> In-Reply-To: <20050224011924.992A65D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: acpi@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 09:39:14 -0000 Kevin Oberman wrote: >>Date: Wed, 23 Feb 2005 11:25:52 -0800 >>From: Nate Lawson >> >>Kevin Oberman wrote: >> >>>Well, it all seems working, but the performance is not proportional to >>>the "frequency". I am attaching the results of testing. The fisrt column >>>is value of freq and the second is the transfer rate from dd to md5. >>> >>>FWIW, when I did have TCC working I had 31 freq_levels, but if I set the >>>freq below about 200, my system freezes and requires a hard power >>>cycle. I am running ULE but no PREEMPTION. The exact point at which it >>>locks up is not consistent. >> >>Please cvsup and test. I imported a bugfixed version of p4tcc. I've >>run an R32 at 50 Mhz, no problems. > > > No joy. I set it to 262 and it was fine. The next step killed the system > again. > > I'm also concerned that taking TCC out of automatic mode might not be a > great idea, at least until things like _PSV are supported. When I do a > buildkernel, buildworld or any big compile job, I need to slow down the > CPU to keep the CPU form frying. It quickly jumps to 185 F. or higher if > I don't. If I understand automatic TCC, it should throttle the CPU all > by itself to prevent this. Taking TCC out of automatic mode doesn't disable thermal controlling circuitry completely, so that if the processor overheats it will shut down the machine anyway: --- Regardless of enabling of the automatic or On-Demand modes, in the event of a catastrophic cooling failure, the processor will automatically shut down when the silicon has reached a temperature of approximately 135 °C. At this point the system bus signal THERMTRIP# will go active and stay active until RESET# has been initiated. THERMTRIP# activation is independent of processor activity and does not generate any bus cycles. If THERMTRIP# is asserted, processor core voltage (Vcc) must be removed within the timeframe defined in Table 16. --- > Between throttling and frequency adjustment I can get about 16 > performance levels and I don' see a good reason for another 15. Also, > the change is frequency is so non-linear that small changes often don't > make sense. The first three step are fairly straight, but then things > get bumpy. It looks to me like all frequency settings are not created > equal. I wonder this too. I think in the presence of several independent regulators we need some form of calibration to get more or less precise results. BTW, looks like you have forgotten to attach the spreadsheet. -Maxim > I should read the code, but what is the presidence between throttling > the CPU and TCC? The increase in performance when freq is dropped from > 1378 to 1350, 984 to 900, 703 to 675, 506 to 450, and 337 to 300 is > clearly not what I would expect. > > I am attaching a spreadsheet (Excel format, but generated by Gnumeric) > showing 4 runs made in single-user mode. If the graph is not showing > properly, I can send it in gnumeric format. I will also attach the > trivial Perl script I run to do generate the raw data. > > > ------------------------------------------------------------------------ > > #!/usr/bin/perl > $min_speed = 250; > ($freq) = `sysctl dev.cpu.0.freq_levels`; > @freq = split ' ', $freq; > @freq = grep /\d+\/-?\d+/, @freq; > foreach (@freq) {s/^(\d+).+$/$1/;} > foreach (@freq) { > if ($_ < $min_speed) {next;} > `sysctl dev.cpu.0.freq=$_`; > `dd if=/dev/zero bs=1m count=100 2>/tmp/testresult | md5`; > @result = `cat /tmp/testresult`; > $result = $result[2]; > $result =~ /secs \((\d+) bytes\/sec/; > printf "%4d %s\n", $_, $1; > } > # Now do it backwards (speed up) > for ($i=$#freq; $i>=0; $i--) { > if ($freq[$i] < $min_speed) {next;} > `sysctl dev.cpu.0.freq=$freq[$i]`; > `dd if=/dev/zero bs=1m count=100 2>/tmp/testresult | md5`; > @result = `cat /tmp/testresult`; > $result = $result[2]; > $result =~ /secs \((\d+) bytes\/sec/; > printf "%4d %s\n", $freq[$i], $1; > } > `sysctl dev.cpu.0.freq=1800`; > unlink "/tmp/testresult"; > exit; > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"