Re: patch: p4tcc and speedstep cpufreq drivers

Kevin Oberman wrote:
>>Date: Wed, 23 Feb 2005 11:25:52 -0800
>>From: Nate Lawson <nate_at_root.org>
>>
>>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`;
> _at_freq = split ' ', $freq;
> _at_freq = grep /\d+\/-?\d+/, _at_freq;
> foreach (_at_freq) {s/^(\d+).+$/$1/;}
> foreach (_at_freq) {
>   if ($_ < $min_speed) {next;}
>   `sysctl dev.cpu.0.freq=$_`;
>   `dd if=/dev/zero bs=1m count=100 2>/tmp/testresult |  md5`;
>   _at_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`;
>   _at_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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"