Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #239127 > unrolled thread
| Started by | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| First post | 2021-08-22 02:00 +0200 |
| Last post | 2021-08-24 11:20 +0200 |
| Articles | 20 on this page of 121 — 12 participants |
Back to article view | Back to linux.debian.user
smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 02:00 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 02:50 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 03:10 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 05:00 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 05:10 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 05:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 05:30 +0200
Re: FOSS "BIOS" (UEFI) (was: Re: smart fans) Reco <recoverym4n@enotuniq.net> - 2021-08-22 07:30 +0200
Re: FOSS "BIOS" (UEFI) (was: Re: smart fans) Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 08:30 +0200
Re: FOSS "BIOS" (UEFI) (was: Re: smart fans) Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 10:30 +0200
Re: FOSS "BIOS" (UEFI) The Wanderer <wanderer@fastmail.fm> - 2021-08-22 12:10 +0200
Re: FOSS "BIOS" (UEFI) Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 13:30 +0200
Re: FOSS "BIOS" (UEFI) (was: Re: smart fans) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 15:20 +0200
Re: FOSS "BIOS" (UEFI) (was: Re: smart fans) Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 16:30 +0200
Re: FOSS "BIOS" (UEFI) (was: Re: smart fans) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 18:50 +0200
FOSS "BIOS" (UEFI) (was: Re: smart fans) Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 07:30 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-22 09:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 09:50 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-22 10:00 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 10:10 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 10:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 10:20 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 10:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 10:50 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 15:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 16:10 +0200
Re: smart fans The Wanderer <wanderer@fastmail.fm> - 2021-08-22 16:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 16:20 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 18:50 +0200
Re: smart fans Hans <hans.ullrich@loop.de> - 2021-08-22 17:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 17:50 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-22 09:50 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 10:00 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 10:20 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-22 10:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 10:40 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 10:40 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 10:40 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 10:50 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 11:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 11:50 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 15:10 +0200
Re: smart fans didier gaumet <didier.gaumet@gmail.com> - 2021-08-22 11:50 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 15:10 +0200
Re: smart fans didier gaumet <didier.gaumet@gmail.com> - 2021-08-22 11:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 11:00 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 15:10 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-22 15:50 +0200
Re: smart fans rhkramer@gmail.com - 2021-08-22 16:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 16:50 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 16:10 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-22 16:30 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 18:50 +0200
Re: smart fans Gene Heskett <gheskett@shentel.net> - 2021-08-22 23:10 +0200
Re: smart fans Gene Heskett <gheskett@shentel.net> - 2021-08-23 00:20 +0200
Re: smart fans "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-22 16:30 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 18:50 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-22 19:00 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-22 23:10 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-23 10:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 21:10 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-23 21:10 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-23 21:30 +0200
Re: smart fans <tomas@tuxteam.de> - 2021-08-23 21:40 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 22:30 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 00:30 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-22 22:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 23:20 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-22 21:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 22:00 +0200
Re: smart fans didier gaumet <didier.gaumet@gmail.com> - 2021-08-22 23:20 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 23:40 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-22 23:50 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-23 00:40 +0200
Re: smart fans didier gaumet <didier.gaumet@gmail.com> - 2021-08-23 09:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 22:20 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-22 23:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 23:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-22 23:50 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-23 00:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 02:00 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 02:10 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 02:40 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 03:00 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-23 03:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 21:00 +0200
Re: smart fans "Andrew M.A. Cater" <amacater@einval.com> - 2021-08-24 18:20 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 23:00 +0200
Re: smart fans Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-23 03:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 21:00 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-23 03:20 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 21:00 +0200
Re: smart fans "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-23 22:50 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-23 23:00 +0200
Re: smart fans "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-23 23:30 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 00:50 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 01:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 02:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 03:00 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 04:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 05:20 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 09:00 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 23:20 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 23:40 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 00:40 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 00:20 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 02:10 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 04:00 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-24 07:30 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 09:50 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-25 00:20 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-25 01:30 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-08-29 01:00 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-29 12:00 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-09-04 00:10 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-09-04 03:50 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-09-04 04:50 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-09-04 23:00 +0200
Re: smart fans Emanuel Berg <moasenwood@zoho.eu> - 2021-09-07 03:10 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-09-07 23:20 +0200
Re: smart fans David Christensen <dpchrist@holgerdanske.com> - 2021-08-24 11:20 +0200
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-08-24 05:20 +0200 |
| Message-ID | <CPv8J-7bR-1@gated-at.bofh.it> |
| In reply to | #239275 |
David Christensen wrote:
> Doubling the sound energy adds 3 db. So, the two loudest
> fans are around 19 dB.
>
> The HDD is 2.9 Bel = 29 dB.
So the total worse-case is 35.4 dB?
(With the GPU, PSU and one fan still unaccounted for.)
;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;; https://dataswamp.org/~incal/emacs-init/audio.el
(defun db (d &rest ds)
(let*((all (cons d ds))
(top (apply #'max all))
(other (- (apply #'+ all) top))
(double (/ other top 1.0))
(res (+ top (* double 3))) )
(format "%.1f dB" res) ))
;; (db 14.9 15.9 15.9 14.7 29.0) ; 35.4 dB
--
underground experts united
https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-08-24 09:00 +0200 |
| Message-ID | <CPyzE-MZ-7@gated-at.bofh.it> |
| In reply to | #239276 |
On 8/23/21 8:09 PM, Emanuel Berg wrote:
> David Christensen wrote:
>
>> Doubling the sound energy adds 3 db. So, the two loudest
>> fans are around 19 dB.
>>
>> The HDD is 2.9 Bel = 29 dB.
>
> So the total worse-case is 35.4 dB?
>
> (With the GPU, PSU and one fan still unaccounted for.)
>
> ;;; -*- lexical-binding: t -*-
> ;;;
> ;;; this file:
> ;;; https://dataswamp.org/~incal/emacs-init/audio.el
>
> (defun db (d &rest ds)
> (let*((all (cons d ds))
> (top (apply #'max all))
> (other (- (apply #'+ all) top))
> (double (/ other top 1.0))
> (res (+ top (* double 3))) )
> (format "%.1f dB" res) ))
>
> ;; (db 14.9 15.9 15.9 14.7 29.0) ; 35.4 dB
>
These are the equations and conversion factors needed:
Bel = log10(power)
power = 10 ** Bel
1 Bel = 10 dB
So, your calculation should be:
2021-08-23 23:42:34 dpchrist@dipsy ~
$ perl -e '$p=0; $p += 10**($_/10) for @ARGV; print 10*log($p)/log(10),
"\n"' 14.9 15.9 15.9 14.7 29.0
29.696732023509
That said, I would just add the continuous fan noise:
2021-08-23 23:42:49 dpchrist@dipsy ~
$ perl -e '$p=0; $p += 10**($_/10) for @ARGV; print 10*log($p)/log(10),
"\n"' 14.9 15.9 15.9 14.7
21.4058369416353
And consider the 29.0 dB HDD vibration separately.
David
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-08-24 23:20 +0200 |
| Message-ID | <CPLZU-1lh-17@gated-at.bofh.it> |
| In reply to | #239279 |
David Christensen wrote:
> These are the equations and conversion factors needed:
>
> Bel = log10(power)
>
> power = 10 ** Bel
>
> 1 Bel = 10 dB
>
> So, your calculation should be:
>
> 2021-08-23 23:42:34 dpchrist@dipsy ~
> $ perl -e '$p=0; $p += 10**($_/10) for @ARGV; print
> 10*log($p)/log(10), "\n"' 14.9 15.9 15.9 14.7 29.0
> 29.696732023509
OK, so then the data is
5 fans: 23.3 dB
5 fans and HDD: 30.0 dB
;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;; https://dataswamp.org/~incal/emacs-init/audio.el
(defun db (d &rest ds)
(let ((all (cons d ds))
(sum 0) )
(cl-loop for a in all do
(cl-incf sum (expt 10 (/ a 10.0))) )
(format "%.1f dB" (* 10 (/ (log sum) (log 10))) )))
;; (db 18.9 14.9 14.7 15.9 15.9) ; 23.3 dB
;; (db 18.9 14.9 14.7 15.9 15.9 29) ; 30.0 dB
> That said, I would just add the continuous fan noise [...]
> And consider the 29.0 dB HDD vibration separately.
Why?
--
underground experts united
https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-08-24 23:40 +0200 |
| Message-ID | <CPMjg-1rN-17@gated-at.bofh.it> |
| In reply to | #239290 |
> OK, so then the data is > > 5 fans: 23.3 dB > 5 fans and HDD: 30.0 dB OK, so if the HDD is 29 dB and all the five fans just add 1 dB maybe one shouldn't even care about the fan noise ... -- underground experts united https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-08-24 00:40 +0200 |
| Message-ID | <CPqLL-4fN-1@gated-at.bofh.it> |
| In reply to | #239262 |
On 8/23/21 1:44 PM, Thomas Schmitt wrote: > Hi, > > Emanuel Berg wrote: >> [...] maybe it isn't >> the case fans or the CPU cooling tower fans that make the >> sound anyway! > > If nothing else helps to find the culprit, then consider to unplug all > case fans to prove that it's not them. > A bit more adventurous is to run the CPU without fan for a few seconds. > > (I assume from your fan list that it is a larger box where such > manipulations are feasible.) > > > Have a nice day :) > > Thomas Unplugging the chassis fans would make it easier to focus on the CPU fans, but all the fans should be operating with the chassis closed before applying any significant load. (Or, at least the CPU fans, an open chassis, and a good floor fan.) With my Intel motherboards, if I power up and the CPU fan is unplugged or not rotating (e.g. blocked by wires), the firmware will detect this during POST and halt the CPU. David
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-08-24 00:20 +0200 |
| Message-ID | <CPqsq-49v-5@gated-at.bofh.it> |
| In reply to | #239254 |
On 8/23/21 11:41 AM, Emanuel Berg wrote: > David Christensen wrote: > >> - Set the Linux CPU governor to "powersave". > > Nothing happens when I do that. > >> Try the QFan "Silent" profile > > Same. > >> What about GPU fan(s)? Power supply fan(s)? >> What about HDD's? > > Yeah, I thought about that. I listened to the fan I had > outside of the computer, put my ear right next to it. > My impression was I didn't hear anything. So maybe it isn't > the case fans or the CPU cooling tower fans that make the > sound anyway! Use a piece of tubing as a stethoscope to isolate and identify the noise source(s). On 8/23/21 11:46 AM, Emanuel Berg wrote: > Polyna-Maude Racicot-Summerside wrote: > >> If you take the option for let say "performance" then it >> will be at max speed so the system is the coolest possible >> all the time. > > But changing the profile (governor) doesn't produce any > (noticable?) sound level change and also the temperature of > the CPU and the GPU seem unaffected. You will not notice a change in CPU fan temperature or speed profiles as a function of the Linux governor setting until the motherboard CPU fan speed control is working and you change the CPU load. Here is a Perl one-liner that should peg one core: $ perl -e "1 while 1" Press Ctrl+C to stop it. Open multiple terminals an invoke the same to peg more cores. > Heh, I have an infrared thermometer, is there some other part > of the computer I should aim for? ;) Whatever interests you -- chipset, voltage regulators, memory modules, etc.. Because the instrument is hand-held, the challenge will be measuring the same spot at the same distance and same angle every time. > No, that command sets the CPU so there is where the change > should be noticable, right? Changing the Linux CPU governor should affect the CPU frequency profile as a function of CPU load. I use the Xfce panel applet "CPU Frequency Monitor" to monitor the CPU frequency and the "CPU Graph" applet to monitor loading of each core. On 8/23/21 11:54 AM, Emanuel Berg wrote: > David Christensen wrote: > >> Changing settings and making measurements at idle is >> a starting point. You should also put the machine under load >> and make measurements. > > Yes, but I know already that even with all fans (2*CPU cooling > tower, 3*case) at "Silent" and with the powersave governor it > still - if indeed anything changed - it still makes to much > noise so I still hibernate the computer when I don't use it. > > The GPU fan looks so small it can't make a lot of noise one > would think, and the fans for the power supply/the HDD are > inside a little box even inside the computer case (don't know > if it has a name?) but if they are really noisy I guess it > could happen? On my Intel desktop and server motherboards, CPU fan speed control only works with Intel CPU fans. Aftermarket fans run at full speed all the time. Try your AMD CPU fan. Get a 3-pin and/or 4-pin fan speed controller and test the fans: https://www.amazon.com/Zalman-Fan-Speed-Controller-FANMATE-2/dp/B000292DO0/ https://www.amazon.com/Noctua-NA-FC1-4-pin-PWM-Controller/dp/B072M2HKSN/ While STFW, I found a what might be a replacement for your external fan: https://www.amazon.com/Wathai-Controller-Receiver-Playstation-Component/dp/B07VYGQPCZ/ The video card and power supply fans should have automatic fan speed control. The video card manufacturer might offer a firmware or software utility for tuning the fan speed control profile. A gamer power supply might have such a feature. That said, I expect the factor defaults should be good enough for now. I would leave them alone, unless you definitely hear too much noise coming from one or both. Small fans at high RPM can be very shrill -- e.g. the spectra has a lot of high frequency energy. I use 3.5" HDD mobile racks with two 30mm fans each (StarTech DRW115SAT). When I install four in a computer, it sounds like a B-52! David
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-08-24 02:10 +0200 |
| Message-ID | <CPsaR-5e0-3@gated-at.bofh.it> |
| In reply to | #239266 |
David Christensen wrote:
>> But changing the profile (governor) doesn't produce any
>> (noticable?) sound level change and also the temperature of
>> the CPU and the GPU seem unaffected.
>
> You will not notice a change in CPU fan temperature or speed
> profiles as a function of the Linux governor setting until
> the motherboard CPU fan speed control is working and you
> change the CPU load.
>
> Here is a Perl one-liner that should peg one core:
>
> $ perl -e "1 while 1"
OK, I wrote a script [last] and here is the result
$ temp-gov
CPU C (33.50 45.75) (100 iterations) conservative
CPU C (45.88 46.38) (100 iterations) userspace
CPU C (46.38 46.75) (100 iterations) powersave
CPU C (46.75 47.00) (100 iterations) ondemand
CPU C (47.00 47.00) (100 iterations) performance
CPU C (47.00 47.25) (100 iterations) schedutil
Hm ... the result seems to be pretty much identical for the
governors anyway?
#! /bin/zsh
#
# this file:
# https://dataswamp.org/~incal/conf/.zsh/temp
temp-gov () {
local t=100
local cpu
local cpu_min
local cpu_max
perl -e '1 while 1' &
local pid=$!
sleep 10
local i
local g
for g in $(cpufreq-info -g); do
sudo cpufreq-set -g $g
cpu_min=999
cpu_max=0
for i in {0..$t}; do
cpu=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
(( $cpu < $cpu_min )) && cpu_min=$cpu
(( $cpu > $cpu_max )) && cpu_max=$cpu
done
printf "CPU C (%.2f %.2f) (%d iterations) %s\n" $cpu_min $cpu_max $t $g
done
kill $pid
}
--
underground experts united
https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-08-24 04:00 +0200 |
| Message-ID | <CPtTj-6b9-1@gated-at.bofh.it> |
| In reply to | #239271 |
On 8/23/21 5:05 PM, Emanuel Berg wrote:
> David Christensen wrote:
>
>>> But changing the profile (governor) doesn't produce any
>>> (noticable?) sound level change and also the temperature of
>>> the CPU and the GPU seem unaffected.
>>
>> You will not notice a change in CPU fan temperature or speed
>> profiles as a function of the Linux governor setting until
>> the motherboard CPU fan speed control is working and you
>> change the CPU load.
>>
>> Here is a Perl one-liner that should peg one core:
>>
>> $ perl -e "1 while 1"
>
> OK, I wrote a script [last] and here is the result
>
> $ temp-gov
> CPU C (33.50 45.75) (100 iterations) conservative
> CPU C (45.88 46.38) (100 iterations) userspace
> CPU C (46.38 46.75) (100 iterations) powersave
> CPU C (46.75 47.00) (100 iterations) ondemand
> CPU C (47.00 47.00) (100 iterations) performance
> CPU C (47.00 47.25) (100 iterations) schedutil
>
> Hm ... the result seems to be pretty much identical for the
> governors anyway?
>
> #! /bin/zsh
> #
> # this file:
> # https://dataswamp.org/~incal/conf/.zsh/temp
>
> temp-gov () {
> local t=100
>
> local cpu
> local cpu_min
> local cpu_max
>
> perl -e '1 while 1' &
> local pid=$!
> sleep 10
>
> local i
> local g
> for g in $(cpufreq-info -g); do
> sudo cpufreq-set -g $g
> cpu_min=999
> cpu_max=0
> for i in {0..$t}; do
> cpu=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
> (( $cpu < $cpu_min )) && cpu_min=$cpu
> (( $cpu > $cpu_max )) && cpu_max=$cpu
> done
> printf "CPU C (%.2f %.2f) (%d iterations) %s\n" $cpu_min $cpu_max $t $g
> done
>
> kill $pid
> }
For a CPU with N cores (N=4 for an AMD Ryzen 3 3200G?) and an otherwise
unloaded system, your test procedure should be something like:
loop over governor choices
set governor
loop 3 times
sleep 60 seconds
print statistics
endloop
loop from 1 to N
start background process
loop 10 times
sleep 6 seconds
print statistics
endloop
endloop
kill all background processes
endloop
"print statistics" should include time, governor setting, number of
background processes running, and CPU temperature. If would be nice to
also include system loading percent, CPU frequency, and CPU fan speed.
David
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-08-24 07:30 +0200 |
| Message-ID | <CPxay-8tD-1@gated-at.bofh.it> |
| In reply to | #239274 |
David Christensen wrote:
> For a CPU with N cores (N=4 for an AMD Ryzen 3 3200G?) and
> an otherwise unloaded system, your test procedure should be
> something like:
>
> loop over governor choices
> set governor
> loop 3 times
> sleep 60 seconds
> print statistics
> endloop
> loop from 1 to N
> start background process
> loop 10 times
> sleep 6 seconds
> print statistics
> endloop
> endloop
> kill all background processes
> endloop
>
> "print statistics" should include time, governor setting,
> number of background processes running, and CPU temperature.
> If would be nice to also include system loading percent, CPU
> frequency, and CPU fan speed.
Okay, what about
#! /bin/zsh
#
# this file:
# https://dataswamp.org/~incal/conf/.zsh/cpu
cpu-stats () {
local time=$(date +%s)
local gov=$(cpufreq-info -p | awk '{print $3}')
local back=$(jobs -l | wc -l)
local temp=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
local cores=$(getconf _NPROCESSORS_ONLN)
local avg=$(awk '{print $1}' /proc/loadavg)
local load=$(( $avg * 100/$cores ))
local freq=("${(@f)$(awk '/cpu MHz/{print $4}' /proc/cpuinfo)}")
local fan=$(sensors | awk '/cpu_fan/{print $2 " RPM"}')
echo "time ${time}"
echo "governor ${gov}"
echo "background processes ${back}"
echo "CPU temperature ${temp}C"
printf "system load %.1f%%\n" $load
echo "CPU fan speed ${fan}"
echo -n "CPU frequencies "
for f in $freq; do
echo -n "$f "
done
echo "MHz"
}
test-cpu () {
local cores=$(getconf _NPROCESSORS_ONLN)
local pids=()
local g
for g in $(cpufreq-info -g); do
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
}
}
done
for p in $pids; do
kill $p
done
}
--
underground experts united
https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-08-24 09:50 +0200 |
| Message-ID | <CPzm1-1tF-3@gated-at.bofh.it> |
| In reply to | #239277 |
On 8/23/21 10:25 PM, Emanuel Berg wrote:
> David Christensen wrote:
>
>> For a CPU with N cores (N=4 for an AMD Ryzen 3 3200G?) and
>> an otherwise unloaded system, your test procedure should be
>> something like:
>>
>> loop over governor choices
>> set governor
>> loop 3 times
>> sleep 60 seconds
>> print statistics
>> endloop
>> loop from 1 to N
>> start background process
>> loop 10 times
>> sleep 6 seconds
>> print statistics
>> endloop
>> endloop
>> kill all background processes
>> endloop
>>
>> "print statistics" should include time, governor setting,
>> number of background processes running, and CPU temperature.
>> If would be nice to also include system loading percent, CPU
>> frequency, and CPU fan speed.
>
> Okay, what about
>
> #! /bin/zsh
> #
> # this file:
> # https://dataswamp.org/~incal/conf/.zsh/cpu
>
> cpu-stats () {
> local time=$(date +%s)
> local gov=$(cpufreq-info -p | awk '{print $3}')
> local back=$(jobs -l | wc -l)
> local temp=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
>
> local cores=$(getconf _NPROCESSORS_ONLN)
> local avg=$(awk '{print $1}' /proc/loadavg)
> local load=$(( $avg * 100/$cores ))
>
> local freq=("${(@f)$(awk '/cpu MHz/{print $4}' /proc/cpuinfo)}")
> local fan=$(sensors | awk '/cpu_fan/{print $2 " RPM"}')
>
> echo "time ${time}"
> echo "governor ${gov}"
> echo "background processes ${back}"
> echo "CPU temperature ${temp}C"
> printf "system load %.1f%%\n" $load
> echo "CPU fan speed ${fan}"
> echo -n "CPU frequencies "
>
> for f in $freq; do
> echo -n "$f "
> done
> echo "MHz"
> }
>
> test-cpu () {
> local cores=$(getconf _NPROCESSORS_ONLN)
> local pids=()
> local g
> for g in $(cpufreq-info -g); do
> 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
> }
> }
> done
> for p in $pids; do
> kill $p
> done
> }
I would output a header line and then output each set of statistics on a
single line. Fixed-width pretty-printing may involve a lot of
programmer effort, both to generate and to parse later. ASCII comma- or
tab-separated value (CSV/TSV) format is open source, mostly human
readable, easier on the programmer, readily ported between platforms,
and can be fed into other programs (such as LibreOffice Calc, scripts,
databases, etc.).
I would avoid doing any math on the data. Save raw values and deal with
math in post-processing:
local cores=$(getconf _NPROCESSORS_ONLN)
local load=$(( $avg * 100/$cores ))
I would put units into the headers. Save raw values and deal with units
in post processing:
echo "CPU temperature ${temp}C"
David
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-08-25 00:20 +0200 |
| Message-ID | <CPMVY-1VZ-5@gated-at.bofh.it> |
| In reply to | #239280 |
David Christensen wrote:
> I would output a header line and then output each set of
> statistics on a single line [...]
>
> I would avoid doing any math on the data. Save raw values
> and deal with math in post-processing [...]
>
> I would put units into the headers. Save raw values and deal
> with units in post processing [...]
OK, the header line is now
time, governor, background processes, CPU temperature C,
system load, CPU fan speed RPM, CPU frequencies MHz
and output can be either
1629843103, ondemand, 1, 33.25, 0.03, 0, 1807.086 2928.002 2418.211 3084.016
or
time 1629843119
governor ondemand
background processes 0
CPU temperature C 36.625
system load 0.02
CPU fan speed RPM 0
CPU frequencies MHz 1966.683 3032.553 2397.819 1399.776
I'll run it next time I go for a walk...
#! /bin/zsh
#
# this file:
# https://dataswamp.org/~incal/conf/.zsh/cpu
cpu-stats-print-raw () {
local time=$1
local gov=$2
local back=$3
local temp=$4
local load=$5
local fan=$6
shift 6
local freq=($@)
echo "${time}, ${gov}, ${back}, ${temp}, ${load}, ${fan}, ${freq}"
}
cpu-stats-print-pretty () {
local time=$1
local gov=$2
local back=$3
local temp=$4
local load=$5
local fan=$6
shift 6
local freq=($@)
echo "time $time"
echo "governor $gov"
echo "background processes $back"
echo "CPU temperature C $temp"
echo "system load $load"
echo "CPU fan speed RPM $fan"
echo -n "CPU frequencies MHz "
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 back=$1
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}')
local freq=("${(@f)$(awk '/cpu MHz/{print $4}' /proc/cpuinfo)}")
cpu-stats-print-raw $time $gov $back $temp $load $fan $freq
echo
cpu-stats-print-pretty $time $gov $back $temp $load $fan $freq
}
test-cpu () {
echo "time, governor, background processes, CPU temperature C, system load, CPU fan speed RPM, CPU frequencies MHz"
local ori=$(cpufreq-info -p | awk '{print $3}')
local cores=$(getconf _NPROCESSORS_ONLN)
local pids=()
local jbs
local g
for g in $(cpufreq-info -g); do
sudo cpufreq-set -g $g
repeat 3 {
sleep 60
jbs=$(jobs -l | wc -l)
cpu-stats $jbs
echo
}
repeat $cores {
perl -e '1 while 1' &
pids+=($!)
repeat 10 {
sleep 6
jbs=$(jobs -l | wc -l)
cpu-stats $jbs
echo
}
}
done
local p
for p in $pids; do
kill $p
done
sudo cpufreq-set -g $ori
}
--
underground experts united
https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-08-25 01:30 +0200 |
| Message-ID | <CPO1I-2xD-3@gated-at.bofh.it> |
| In reply to | #239292 |
On 8/24/21 3:17 PM, Emanuel Berg wrote: > I'll run it next time I go for a walk... You want to watch the test run, so that you can monitor progress, make adjustments, and/or stop it if things go badly. Have you identified the sound source(s) that are most annoying? David
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-08-29 01:00 +0200 |
| Message-ID | <CRfsS-gg-9@gated-at.bofh.it> |
| In reply to | #239293 |
David Christensen wrote: > You want to watch the test run, so that you can monitor > progress, make adjustments, and/or stop it if things > go badly. Don't worry about it... Here are the 20 first lines of the output: time, governor, processes, CPU temperature C, system load, CPU fan speed RPM, CPU frequencies MHz 1630072652, conservative, 157, 33.25, 0.00, 0, 1685.535 1416.164 3029.758 1415.421 1630072712, conservative, 157, 33.25, 0.00, 0, 1537.245 1402.528 3118.173 1286.090 1630072772, conservative, 157, 33.25, 0.06, 0, 1426.077 1356.078 1358.613 3049.180 1630072778, conservative, 158, 44.5, 0.14, 0, 2056.087 1620.633 3871.754 1571.838 1630072784, conservative, 158, 44.75, 0.21, 0, 2041.653 1563.035 3872.665 1599.792 1630072790, conservative, 158, 44.75, 0.55, 0, 1706.676 1610.757 3870.038 2752.512 1630072796, conservative, 158, 45, 0.59, 0, 2313.482 3446.144 3869.807 2325.238 1630072802, conservative, 158, 45, 0.62, 0, 2169.143 1572.604 3873.451 1564.032 1630072808, conservative, 158, 45.25, 0.65, 0, 1969.447 1719.104 3869.058 2789.924 1630072814, conservative, 158, 45.25, 0.70, 0, 1924.617 2776.821 3872.058 1615.040 1630072821, conservative, 158, 45.25, 0.73, 0, 2553.058 1642.274 3870.106 1636.617 1630072827, conservative, 158, 45.25, 0.75, 0, 2509.193 1643.395 3875.505 1624.528 1630072833, conservative, 158, 45.25, 0.77, 0, 2542.012 1619.204 3873.868 1608.061 1630072839, conservative, 159, 48.5, 0.87, 0, 2234.947 1624.853 3846.943 3846.329 1630072845, conservative, 159, 48.875, 1.04, 0, 2463.900 1649.777 3845.442 3845.337 1630072851, conservative, 159, 47.125, 1.12, 0, 2171.265 3848.972 3849.260 1606.988 1630072857, conservative, 159, 47, 1.19, 0, 1743.183 3846.028 3845.345 2728.237 1630072863, conservative, 159, 47, 1.26, 0, 2218.865 3846.552 3846.422 1573.131 The entire file: https://dataswamp.org/~incal/ebchw/cpu.txt -- underground experts united https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-08-29 12:00 +0200 |
| Message-ID | <CRpLz-6Xs-5@gated-at.bofh.it> |
| In reply to | #239407 |
On 8/28/21 3:55 PM, Emanuel Berg wrote: > David Christensen wrote: > >> You want to watch the test run, so that you can monitor >> progress, make adjustments, and/or stop it if things >> go badly. > > Don't worry about it... > > Here are the 20 first lines of the output: > > time, governor, processes, CPU temperature C, system load, CPU fan speed RPM, CPU frequencies MHz > 1630072652, conservative, 157, 33.25, 0.00, 0, 1685.535 1416.164 3029.758 1415.421 > 1630072712, conservative, 157, 33.25, 0.00, 0, 1537.245 1402.528 3118.173 1286.090 > 1630072772, conservative, 157, 33.25, 0.06, 0, 1426.077 1356.078 1358.613 3049.180 > 1630072778, conservative, 158, 44.5, 0.14, 0, 2056.087 1620.633 3871.754 1571.838 > 1630072784, conservative, 158, 44.75, 0.21, 0, 2041.653 1563.035 3872.665 1599.792 > 1630072790, conservative, 158, 44.75, 0.55, 0, 1706.676 1610.757 3870.038 2752.512 > 1630072796, conservative, 158, 45, 0.59, 0, 2313.482 3446.144 3869.807 2325.238 > 1630072802, conservative, 158, 45, 0.62, 0, 2169.143 1572.604 3873.451 1564.032 > 1630072808, conservative, 158, 45.25, 0.65, 0, 1969.447 1719.104 3869.058 2789.924 > 1630072814, conservative, 158, 45.25, 0.70, 0, 1924.617 2776.821 3872.058 1615.040 > 1630072821, conservative, 158, 45.25, 0.73, 0, 2553.058 1642.274 3870.106 1636.617 > 1630072827, conservative, 158, 45.25, 0.75, 0, 2509.193 1643.395 3875.505 1624.528 > 1630072833, conservative, 158, 45.25, 0.77, 0, 2542.012 1619.204 3873.868 1608.061 > 1630072839, conservative, 159, 48.5, 0.87, 0, 2234.947 1624.853 3846.943 3846.329 > 1630072845, conservative, 159, 48.875, 1.04, 0, 2463.900 1649.777 3845.442 3845.337 > 1630072851, conservative, 159, 47.125, 1.12, 0, 2171.265 3848.972 3849.260 1606.988 > 1630072857, conservative, 159, 47, 1.19, 0, 1743.183 3846.028 3845.345 2728.237 > 1630072863, conservative, 159, 47, 1.26, 0, 2218.865 3846.552 3846.422 1573.131 > > The entire file: > > https://dataswamp.org/~incal/ebchw/cpu.txt > That is a start. 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 Please fix the header line. Looking at the test procedure outline I posted previously: On 8/23/21 6:51 PM, David Christensen wrote: > For a CPU with N cores (N=4 for an AMD Ryzen 3 3200G?) and an otherwise > unloaded system, your test procedure should be something like: > > loop over governor choices > set governor > loop 3 times > sleep 60 seconds > print statistics > endloop > loop from 1 to N > start background process > loop 10 times > sleep 6 seconds > print statistics > endloop > endloop > kill all background processes > endloop > > > "print statistics" should include time, governor setting, number of > background processes running, and CPU temperature. If would be nice to > also include system loading percent, CPU frequency, and CPU fan speed. The system *must* be otherwise idle before and during the test. The data indicates it was not. The "CPU_fan_speed" was 0 throughout. Your data collection code for that field value is broken. 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). After each loading cycle, the load processes must be killed. The data indicates that they were not. Instead, your overall test accumulated 4 units of load for 6 governors, producing a system load of 24 (!). This is what I meant when I said "stop it if things go badly". (But, the fact that the CPU did not throttle or malfunction with ~15 minutes of full load indicates that the cooling is good.) Please correct your test script and try again. Then tune it: - Cool-down delay -- the output variable values (CPU_temperature, system_load, CPU_fan_speed, core1_freq, core2_freq, core3_freq, core4_freq) must be stable when each governor cool-down delay ends (3 loops * 60 seconds). Furthermore, they must be consistent across all six governor sub-runs. Adjust the cool-down delay loop count and/or time increment if and as required. Or, or add code to find stability and make the decision. - 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. Have you isolated and identified the primary noise source(s)? Have you quantified them (e.g. sound measurement)? Can you get that data into your test script? David
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-09-04 00:10 +0200 |
| Message-ID | <CTpxL-2OF-1@gated-at.bofh.it> |
| In reply to | #239424 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-09-04 03:50 +0200 |
| Message-ID | <CTsYF-4LT-7@gated-at.bofh.it> |
| In reply to | #239653 |
On 9/3/21 3:05 PM, Emanuel Berg wrote:
> David Christensen wrote:
>
>> Feeding the raw data into LibreOffice Calc was problematic
<snip>
> 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.
<snip>
>> 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.
<snip>
>> Have you isolated and identified the primary noise
>> source(s)? Have you quantified them (e.g.
>> sound measurement)?
>
> No?
If the loudest sound source is the PSU or GPU fan, then tuning the CPU
and/or chassis fans isn't going to help.
<snip>
David
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-09-04 04:50 +0200 |
| Message-ID | <CTtUJ-5pp-1@gated-at.bofh.it> |
| In reply to | #239655 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-09-04 23:00 +0200 |
| Message-ID | <CTKVz-84E-5@gated-at.bofh.it> |
| In reply to | #239658 |
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
[toc] | [prev] | [next] | [standalone]
| From | Emanuel Berg <moasenwood@zoho.eu> |
|---|---|
| Date | 2021-09-07 03:10 +0200 |
| Message-ID | <CUxMB-5Q6-1@gated-at.bofh.it> |
| In reply to | #239691 |
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 :)
> 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
GFX msi 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
PSU Seasonic Focus 100-240VAC
> Have you implemented any vibration or sound
> mitigation measures?
See the COMPUTER file for upgrades :)
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.
fan connector fan mm pin dB(A) speed duty cycle
CHA_FAN1 Corsair A1225M12S 120 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_FAN be quiet! Pure Wings 2 120 4 15.9 24% 25%
CPU_OPT be 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
<https://dataswamp.org/~incal/emacs-init/audio.el>
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 :)
--
underground experts united
https://dataswamp.org/~incal
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2021-09-07 23:20 +0200 |
| Message-ID | <CUQFz-UT-5@gated-at.bofh.it> |
| In reply to | #239765 |
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 > > GFX msi 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 > > PSU Seasonic 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. > fan connector fan mm pin dB(A) speed duty cycle > CHA_FAN1 Corsair A1225M12S 120 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_FAN be quiet! Pure Wings 2 120 4 15.9 24% 25% > CPU_OPT be 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 > <https://dataswamp.org/~incal/emacs-init/audio.el> > > 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%, 100%, etc.. What is your use-case? E.g. what services are you running 24x7? How much computing power do you need when you want the computer to be silent? Try using cpufreq-set(1) to lower the maximum CPU frequency until it matches the average CPU workload. Try turning off CPU cores. The goal is to keep the CPU low, the heat production low, and the fans at low speed at all times. Contact Corsair technical support and ask if they sell a sound absorbing material kit for your chassis, or can recommend one. And/or contact technical support for the companies that make these kits, tell them your chassis make and model, and ask them for recommendations. David
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web