subject:"Re\: smart fans"

Re: smart fans

2021-09-07 Thread David Christensen


On 9/6/21 6:03 PM, Emanuel Berg wrote:

David Christensen wrote:


You seem to have got the old file again, check it out again,
because some of those issues have already been
mentioned/fixed:
   https://dataswamp.org/~incal/ebchw/cpu.txt


Much better:
   http://www.holgerdanske.com/pub/dpchrist/debian-user/20210821-smart-fans/


OK, what stuff remains, remove the spaces? Let's do it good
now that we spent so much time on it :)



Different people have different ideas of what "CSV format" means.  The 
example CSV output I posted on 9/3/21 6:45 PM was created by LibreOffice 
Calc.  If you can match that, you should be able to read it with most 
programs that accept CSV input.




Have you isolated and identified the primary sound source(s)
in the computer?


I removed the HDD, now I have an SSD (M.2), so that should be
no more 29 dB (worst case) from the HDD. Also... the M.2 is
much faster so now Debian boots much faster and stuff
like that. Amazing :)

Where does it come from?

I still don't know the dB of the GPU

   GFXmsi Nvidia Geforce GT 710 · 2GB DDR3 · PCI-E2.0 · HDMI+DL-DVI-D

and I also don't know the dB of the PSU, however I did find
out it is a

   PSUSeasonic Focus 100-240VAC



We need a complete model name or part number for the Seasonic -- they 
make several "Focus" models.



STFW I am unable find noise specifications for either.



Have you implemented any vibration or sound
mitigation measures?


See the COMPUTER file for upgrades :)



https://dataswamp.org/~incal/ebchw/COMPUTER

I do not see any vibration or sound mitigation measures (?).


Please provide complete manufacturer names, model names, part numbers, etc..



I finally understand it, I think, the first digit isn't the
minimum duty cycle (that's the second digit) but the _minimum
speed_, so we see that the DC fans can only go as low as 60%,
while the 140 mm PWM fan can get down to 20% and the 120 mm
dittos 24%.

However one can in the BIOS/UEFI/Setup explicitly say DCs
should disable when not even 60% is needed because of whatever
temperature function one has defined (I just choose the
optimal which was computed live BTW, cool)

So the problem was, perhaps, that the 2 DCs were running at
60% all the time, even when the computer was idle?

So Maybe I should get away with the "Corsair A1225M12S" and
the DC version of "be quiet! Shadow Wings 2" and replace with
the PWM versions I already have (but too few), then all 140 mm
will run at 20% and all 120 mm will run at 24%?
  min.   min.
fanconnector  fan  mm  pin dB(A) speed  duty cycle
CHA_FAN1   Corsair A1225M12S120  3  18.9  60%34%
CHA_FAN2   be quiet! Shadow Wings 2 140  4  14.9  20%17%
CHA_FAN3   be quiet! Shadow Wings 2 140  3  14.7  60%24%
CPU_FANbe quiet! Pure Wings 2   120  4  15.9  24%25%
CPU_OPTbe quiet! Pure Wings 2   120  4  15.9  24%25%


If you have magnetic HDD's, switching to SSD's would
eliminate those vibrations.


I had the SSD M.2 mounted on the motherboard all along,
without ever using it!

Now worst-case has gone from

   (db 18.9 14.9 14.7 15.9 15.9 29.0) ; 30.0 dB

to

   (db 14.9 15.9 15.9) ; 20.36 dB
   

since the DC fans stop. However when idling shouldn't be the
"worst case", so the PWM fans at 20%, 24%, and 24%
respectively shouldn't do that kind of noise, so my guess is
it is the GPU ...

But I didn't try to read and see if it still annoys me (or if
I even notice a difference), so let's do that now :)



Fan speed and noise data would help in making rational decisions, such 
as what happens to CPU temperature for a given workload when you reduce 
fan speeds or turn them off, etc..



The CMOS Setup should be able to tell you fan speeds, CPU temperatures, 
voltages, and other internal parameters.



For noise measurements, you want a sound meter, a smart phone with a 
sound measuring app, a microphone and a PC with Audacity, a microphone 
and a multi-meter, etc..  Or, make subjective noise measurements by ear.



Open the case, disconnect the PSU from everything, remove the GPU card, 
and disconnect all the fans.  Then, turn the PSU on, make a noise 
measurement, and turn the PSU off.  Repeat until you get a reliable 
measurement.  Then connect the PSU to the motherboard and repeat; but 
only briefly (~10 seconds) while the CPU fan(s) are disconnected.  Allow 
 the CPU and heat pipe time to cool between trials (~2 minutes).  Then 
connect the GPU to the motherboard and PSU, and repeat; again, briefly, 
etc..  Then connect the other fans one at a time and repeat, starting 
with CPU fans.  Once you have both CPU fans connected, then you can use 
the CMOS Setup utility to get fan speed data and CPU temperature data. 
Check if your CMOS Setup utility can apply load the CPU.  If so, gather 
data under varying load conditions -- 0%, 25%, 50%, 75%,

Re: smart fans

2021-09-04 Thread David Christensen


On 9/3/21 7:42 PM, Emanuel Berg wrote:

David Christensen wrote:


OK, changed.


Your data format still has issues.


You seem to have got the old file again, check it out again,
because some of those issues have already been
mentioned/fixed:

   https://dataswamp.org/~incal/ebchw/cpu.txt



Much better:

http://www.holgerdanske.com/pub/dpchrist/debian-user/20210821-smart-fans/


Looking at the graph of CPU Temperature vs. Time by Governor, there are 
minor differences when running 1 or 2 cores.  After that, it really does 
not matter.



Have you isolated and identified the primary sound source(s) in the 
computer?



Have you implemented any vibration or sound mitigation measures?


If you have magnetic HDD's, switching to SSD's would eliminate those 
vibrations.



David

Re: smart fans

2021-09-04 Thread Emanuel Berg

David Christensen wrote:

>> OK, changed.
>
> Your data format still has issues.

You seem to have got the old file again, check it out again,
because some of those issues have already been
mentioned/fixed:

  https://dataswamp.org/~incal/ebchw/cpu.txt

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

2021-09-03 Thread Emanuel Berg

David Christensen wrote:

> Feeding the raw data into LibreOffice Calc was problematic
> -- header line field names do not have a one-to-one with
> data line field values. I reworked the header line as
> follows:
>
>   time, governor, processes, CPU_temperature, system_load,
>   CPU_fan_speed, core1_freq, core2_freq, core3_freq,
>   core4_freq

OK, changed.

> The system *must* be otherwise idle before and during the
> test. The data indicates it was not.

I didn't use the computer and there was no download or
anything explicit run by me in the background, so I don't know
what more to do in that regard?

> The "CPU_fan_speed" was 0 throughout. Your data collection
> code for that field value is broken.

That's what's reported by sensors(1), I don't know how else
one would retrieve that information?

> There is supposed to be a cool-down delay at the start of
> each governor sub-run. My WAG was 3 minutes. Your test did 2
> minutes (off by 1 error).

Weird, if you mean this part of the pseudocode

  loop 3 times
sleep 60 seconds
print statistics
  endloop

then that's this part of the zsh code

  repeat 3 {
sleep 60
cpu-stats
  }

so I don't know what that isn't 3 minutes ... ?

> After each loading cycle, the load processes must be killed.

OK.

> Incremental load period -- the output variables must have
> reached their steady-state values when each incremental load
> period ends (10 loops * 6 seconds). Adjust and/or
> code accordingly.

Again I don't understand why that isn't what

  repeat 10 {
sleep 6
cpu-stats
  }

does?

> Have you isolated and identified the primary noise
> source(s)? Have you quantified them (e.g.
> sound measurement)?

No?

> Can you get that data into your test script?

I don't know?

Anyway here is the new script with a URL to the output:

#! /bin/zsh
#
# this file:
#   https://dataswamp.org/~incal/conf/.zsh/cpu
#
# example output:
#   https://dataswamp.org/~incal/ebchw/cpu.txt

cpu-stats-print () {
local time=$1
local gov=$2
local pro=$3
local temp=$4
local load=$5
local fan=$6
shift 6
local freq=($@)
echo -n "${time}, ${gov}, ${pro}, ${temp}, ${load}, ${fan}"
for f in $freq; do
echo -n ", $f"
done
echo
}

cpu-stats () {
local time=$(date +%s)
local gov=$(cpufreq-info -p | awk '{print $3}')
local pro=$(ps -ea | wc -l) # 'jobs -l' DNC
local temp=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
local load=$(awk '{print $1}' /proc/loadavg)
local fan=$(sensors | awk '/cpu_fan/{print $2}') # always 0
local freq=("${(@f)$(awk '/cpu MHz/{print $4}' /proc/cpuinfo)}")
cpu-stats-print $time $gov $pro $temp $load $fan $freq
}

test-cpu () {
echo -n "time, governor, processes, CPU_temperature, system_load, 
CPU_fan_speed"
local cores=$(getconf _NPROCESSORS_ONLN)
for c in {1..$cores}; do
echo -n ", core${c}_freq"
done
echo

local ori=$(cpufreq-info -p | awk '{print $3}')
local pids
local g
local p
for g in $(cpufreq-info -g); do
pids=()
sudo cpufreq-set -g $g
repeat 3 {
sleep 60
cpu-stats
}
repeat $cores {
perl -e '1 while 1' &
pids+=($!)
repeat 10 {
sleep 6
cpu-stats
}
}
for p in $pids; do
  kill $p
done
done
sudo cpufreq-set -g $ori
}

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

2021-09-03 Thread David Christensen

On 9/3/21 3:05 PM, Emanuel Berg wrote:

David Christensen wrote:

Feeding the raw data into LibreOffice Calc was problematic

OK, changed.

Your data format still has issues. This is what LibreOffice Calc wants:

time,governor,processes,CPU_temperature,system_load,CPU_fan_speed,core1_freq,core2_freq,core3_freq,core4_freq
1630072652,conservative,157,33.25,0,0,1685.535,1416.164,3029.758,1415.421
1630072712,conservative,157,33.25,0,0,1537.245,1402.528,3118.173,1286.09
1630072772,conservative,157,33.25,0.06,0,1426.077,1356.078,1358.613,3049.18

Note:

1. No extraneous characters anywhere -- e.g. spaces.

2. No spaces in column names; use underscores and abbreviations.

3. One column name for each and every column.

4. Number of columns is same in every row.

5. Commas (field separator) between every row item.

5. Newlines (record separator) at the end of every row.

The system *must* be otherwise idle before and during the
test. The data indicates it was not.

I didn't use the computer and there was no download or
anything explicit run by me in the background, so I don't know
what more to do in that regard?

Then the "cpu-stats" function must be causing the spikes in the
"core*_freq" values, by the several child processes it creates in rapid
succession. Get rid of the useless CPU_fan_speed call. Insert a 1
second sleep ahead of each of the remaining data point collection calls.
Adjust the iteration counts and the sleep times in the calling loops
to compensate.

There is supposed to be a cool-down delay at the start of
each governor sub-run. My WAG was 3 minutes. Your test did 2
minutes (off by 1 error).

Weird, if you mean this part of the pseudocode

loop 3 times
sleep 60 seconds
print statistics
endloop

then that's this part of the zsh code

repeat 3 {
sleep 60
cpu-stats
}

so I don't know what that isn't 3 minutes ... ?

I was off-by-one -- there is no "print statistics" at the top of the
script, which means the first data row comes out after 60 seconds.
Please add a 10 second sleep and a call to "cpu-stats" prior to the
governor loop.

But, a fundamental reality is the Nyquist–Shannon sampling theorem:

https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

Each of the data points your script is collecting has some signal
processing behind it; notably a sampling period. Please RTFM and see if
you can determine the periods of the CPU temperature sensor readings and
the core frequency readings, and if you can adjust those periods so that
they are longer than your data collection period.

It might be best to rework the loops so that the data collection period
is constant throughout the entire test.

After each loading cycle, the load processes must be killed.

OK.

Looking at the "processes", "system_load", and "core*_freq" fields, the
overall test data indicates that the "conservative" sub-run loaded the
machine to 100% and that the loading processes never were killed. The
second and subsequent governor sub-runs just added more load. Debug the
code related to "pids" and kill.

1 2 >

1 - 100 of 117 matches

Mail list logo