On Fri, Jan 31, 2020 at 12:11:49AM +0100, Linux-Fan wrote:
> Date: Fri, 31 Jan 2020 00:11:49 +0100
> From: Linux-Fan <ma_sys...@web.de>
> To: debian-user@lists.debian.org
> Subject: Re: cpu frequence
>
> Gerard ROBIN writes:
>
> > Hello,
> > the maximum frequency of my cpu is 2.8 GHz and under "bullseye" the
> > frequency
> > of my cpu is always higher than 2.7 GHz. If this is a bug how can we
> > determine which package is affected ?
>
> Normally, modern CPUs go to high frequency only if they are "loaded". Thus,
> I'd suggest to check if there is any process obviously taking a lot of CPU
> time. `top` might be enough for a glance, but I normally like `htop` and
> `atop` outputs more (`htop` is more "friendly", but `atop` is more
> informative IMHO).
atop (buster):
PRC | sys 0.31s | user 0.70s | #proc 205 | #trun 1 | #tslpi
252 | #tslpu 0 | #zombie 0 | #exit 6 |
CPU | sys 2% | user 4% | irq 0% | idle 393% | wait
0% | ipc notavail | curf 872MHz | curscal 31% |
cpu | sys 0% | user 1% | irq 0% | idle 98% | cpu001
w 0% | ipc notavail | curf 851MHz | curscal 30% |
cpu | sys 1% | user 2% | irq 0% | idle 98% | cpu000
w 0% | ipc notavail | curf 850MHz | curscal 30% |
cpu | sys 1% | user 1% | irq 0% | idle 98% | cpu003
w 0% | ipc notavail | curf 881MHz | curscal 31% |
cpu | sys 1% | user 1% | irq 0% | idle 98% | cpu002
w 0% | ipc notavail | curf 906MHz | curscal 32% |
CPL | avg1 0.01 | avg5 0.15 | avg15 0.09 | | csw
9428 | intr 4327 | | numcpu 4 |
MEM | tot 7.7G | free 5.6G | cache 768.7M | buff 25.6M | slab
127.6M | shmem 57.2M | vmbal 0.0M | hptot 0.0M |
SWP | tot 7.9G | free 7.9G | | |
| | vmcom 2.5G | vmlim 11.8G |
DSK | sda | busy 0% | read 0 | write 27 | KiB/w
5 | MBr/s 0.0 | MBw/s 0.0 | avio 0.59 ms |
atop (bullseye):
PRC | sys 0.33s | user 0.63s | #proc 189 | #trun 1 | #tslpi
260 | #tslpu 1 | #zombie 0 | clones 6 | #exit 6 |
CPU | sys 2% | user 4% | irq 0% | idle 393% | wait
0% | ipc notavail | cycl unknown | curf 2.75GHz | curscal 98% |
cpu | sys 1% | user 2% | irq 0% | idle 97% | cpu000 w
0% | ipc notavail | cycl unknown | curf 2.77GHz | curscal 98% |
cpu | sys 0% | user 1% | irq 0% | idle 99% | cpu001 w
0% | ipc notavail | cycl unknown | curf 2.74GHz | curscal 97% |
cpu | sys 0% | user 1% | irq 0% | idle 98% | cpu003 w
0% | ipc notavail | cycl unknown | curf 2.74GHz | curscal 98% |
cpu | sys 1% | user 1% | irq 0% | idle 99% | cpu002 w
0% | ipc notavail | cycl unknown | curf 2.73GHz | curscal 97% |
CPL | avg1 0.10 | avg5 0.11 | avg15 0.09 | | csw
14895 | | intr 6027 | | numcpu 4 |
MEM | tot 7.8G | free 5.6G | cache 730.0M | buff 51.5M | slab
125.2M | shmem 105.2M | vmbal 0.0M | hptot 0.0M | hpuse 0.0M |
SWP | tot 7.9G | free 7.9G | | |
| | | vmcom 2.9G | vmlim 11.8G |
PSI | cs 0/0/0 | ms 0/0/0 | mf 0/0/0 | is 0/0/0 | if
0/0/0 | | | | |
DSK | sdb | busy 0% | read 0 | write 1 | KiB/r
0 | KiB/w 28 | MBr/s 0.0 | MBw/s 0.0 | avio 4.00 ms |
PID SYSCPU USRCPU VGROW RGROW RUID EUID ST
EXC THR S CPUNR CPU CMD
1935 0.11s 0.26s -8K -372K root root --
- 10 S 3 4% Xorg
2302 0.06s 0.16s 0K 0K user user --
- 7 S 2 2% xfwm4
3716 0.01s 0.04s 0K 0K user user --
- 4 S 0 1% gnome-terminal
3656 0.01s 0.04s 0K 0K user user --
- 4 S 0 1% panel-17-weath
3594 0.01s 0.02s 0K 0K user user --
- 3 S 0 0% panel-25-cpugr
> The other thing is: As long as it is always below or equal to 2.8 GHz, it
> need not be wrong. However, most machines with U-processors (especially
> notebooks) have a cooling system which does not permit them to sustain the
> maximum frequency for long. You might investigate this by generating load on
> all cores e.g. like this:
>
> dd if=/dev/urandom bs=4M count=1024 | pv | xz -T 0 -9 > /dev/null
192+0 records out (bullseye)
805306368 bytes (805 MB, 768 MiB) copied, 20.5577 s, 39.2 MB/s
768MiB 0:00:20 [1.18MiB/s] [ <=>
> > With "buster" on the same machine the problem does not occur. The cpu
> > frequency
> > is between 900 MHz and 1.8 GHz
>
> That sounds very low? What happens if you generate some load. Does it stay
> this way or go (temporarily?) up to the 2.3 or 2.8 GHz?
go up to about 2.8 GHz (buster)
> Test (vary the `count` to check for longer times, add `-T` parameters to
> `xz` to check a specific number of cores):
>
> dd if=/dev/urandom bs=4M count=10 | xz -9 > /dev/null
10+0 records in (bullseye)
10+0 records out
41943040 bytes (42 MB, 40 MiB) copied, 15.7084 s, 2.7 MB/s
> In case it would be missing on your system, `xz` is part of package
> `xz-utils`. It is not a "proper" benchmark tool btw. In case it is not
> obvious: None of these tests outputs anything useful, the idea is to
> check the frequencies while the tests are running and see how they differ
> from before/afterwards as to find out if the frequency behaves as expected.
> I'd generally expect the following results (in the absence of bugs :) )
>
> * Loading a single core (`xz -9` without `-T 0`) brings it to maximum
> frequency (2.8 GHz).
> * Loading multiple cores (`xz -9 -T 0`) brings them to the max frequency
> for a short time and then has them drop to the base frequency or even
> below.
> * Not having any load on the machine should go in the low requency range,
> the 800 MHz to 1.8 GHz range sounds plausible for this.
>
> Another interesting check: Which of the two behaviours seen (low freq range
> vs. high freq range) is exposed if you run a backported Kernel on the Buster
> system such as to have the comparison for similar kernel versions?
I installed kernel 5.4.0-0.bpo.2-amd64 on buster and the frequency is the same
as with kernel 4.19.0-6-amd64.
> Linux-Fan
--
Gerard
_____________________________
*****************************
Created with "mutt 1.13.2-1"
under Debian Linux BULLSEYE
*****************************
