Re: [epilogue] cpu frequence

2020-02-05 Thread Ólafur Jens Sigurðsson
On Mon, Feb 03, 2020 at 11:57:18AM -0500, Stefan Monnier wrote:
> > in fact when I restarted my laptop the problem returned.
> > By reading the link  https://wiki.debian.org/CpuFrequencyScaling more 
> > carefully
> 
> Note that this page is pretty old/outdated.  AFAIK nowadays the better
> option is to just throw away most of those tools and configs and just
> use the default (unless your needs are unusual and you know what you're
> doing).

Then please someone with knowledge about the topic update the wiki.

Cheers, Oli



Re: [epilogue] cpu frequence

2020-02-03 Thread Stefan Monnier
> in fact when I restarted my laptop the problem returned.
> By reading the link  https://wiki.debian.org/CpuFrequencyScaling more 
> carefully

Note that this page is pretty old/outdated.  AFAIK nowadays the better
option is to just throw away most of those tools and configs and just
use the default (unless your needs are unusual and you know what you're
doing).


Stefan



Re:[epilogue] cpu frequence

2020-02-03 Thread Gerard ROBIN
On Sat, Feb 01, 2020 at 10:37:55PM +0100, Gerard ROBIN wrote:
> Date: Sat, 1 Feb 2020 22:37:55 +0100
> From: Gerard ROBIN 
> To: debian-user@lists.debian.org
> Subject: Re: cpu frequence
 
> On Sat, Feb 01, 2020 at 08:11:17PM +0100, Jörg-Volker Peetz wrote:
> > Date: Sat, 1 Feb 2020 20:11:17 +0100
> > From: Jörg-Volker Peetz 
> > To: debian-user@lists.debian.org
> > Subject: Re: cpu frequence
> 
> > Then, take a look at the available governors:
> > 
> > $ cat /sys/devices/system/cpu/cpufreq/policy?/scaling_available_governors
> > 
> > or using cpupower, if available. As the name says, "powersave" would be the
> > better choice.
> > Take a look at https://wiki.debian.org/CpuFrequencyScaling as how to change 
> > the
> > cpufreq governor permanently even when rebooting. I suppose, you somehow 
> > changed
> > the default behavior.
> 
> Thanks so much I selected performance powersave (I installed
> linux-cpupower) and now the frequency oscillates between 800 MHZ
> and 2.8 GHz. as with Buster. :)
 
I answered too quickly:
in fact when I restarted my laptop the problem returned.
By reading the link  https://wiki.debian.org/CpuFrequencyScaling more carefully
I understood that the laptop-mode-tools package was concerned and I noticed that
the laptop-mode-tools package is not installed in BUSTER and so I simply
uninstalled it in BULLSEYE and now it's really OK.

-- 
Gerard
___
***
Created with Mutt  1.13.2 
under Debian Linux BULLSEYE
***



Re: cpu frequence

2020-02-01 Thread Gerard ROBIN
On Sat, Feb 01, 2020 at 08:11:17PM +0100, Jörg-Volker Peetz wrote:
> Date: Sat, 1 Feb 2020 20:11:17 +0100
> From: Jörg-Volker Peetz 
> To: debian-user@lists.debian.org
> Subject: Re: cpu frequence

> Then, take a look at the available governors:
> 
> $ cat /sys/devices/system/cpu/cpufreq/policy?/scaling_available_governors
> 
> or using cpupower, if available. As the name says, "powersave" would be the
> better choice.
> Take a look at https://wiki.debian.org/CpuFrequencyScaling as how to change 
> the
> cpufreq governor permanently even when rebooting. I suppose, you somehow 
> changed
> the default behavior.

Thanks so much I selected performance powersave (I installed
linux-cpupower) and now the frequency oscillates between 800 MHZ
and 2.8 GHz. as with Buster. :)

-- 
Gerard
___
***
Created with Mutt  1.13.2 
under Debian Linux BULLSEYE
***



Re: cpu frequence

2020-02-01 Thread Jörg-Volker Peetz
Then, take a look at the available governors:

$ cat /sys/devices/system/cpu/cpufreq/policy?/scaling_available_governors

or using cpupower, if available. As the name says, "powersave" would be the
better choice.
Take a look at https://wiki.debian.org/CpuFrequencyScaling as how to change the
cpufreq governor permanently even when rebooting. I suppose, you somehow changed
the default behavior.

Regards,
Jörg.




Re: cpu frequence

2020-02-01 Thread Gerard ROBIN
On Sat, Feb 01, 2020 at 04:04:29PM +0100, Jörg-Volker Peetz wrote:
> Date: Sat, 1 Feb 2020 16:04:29 +0100
> From: Jörg-Volker Peetz 
> To: debian-user@lists.debian.org
> Subject: Re: cpu frequence
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bendel.debian.org
> X-Spam-Level: 
> X-Spam-Status: No, score=-10.5 required=4.0
>  tests=FREEMAIL_FORGED_FROMDOMAIN,
>  FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,LDOSUBSCRIBER, LDO_WHITELIST
>  autolearn=unavailable autolearn_force=no version=3.4.2
> 
> what is the outcome of the following command:
> 
> $ cat /sys/devices/system/cpu/cpufreq/policy?/scaling_governor
performance
performance
performance
performance

> Regards,
> Jörg.

-- 
Gerard
_
*
 Created with "mutt 1.13.2-1"
 under Debian Linux BULLSEYE
*



Re: cpu frequence

2020-02-01 Thread Jörg-Volker Peetz
what is the outcome of the following command:

$ cat /sys/devices/system/cpu/cpufreq/policy?/scaling_governor

Regards,
Jörg.



Re: cpu frequence

2020-01-31 Thread Gerard ROBIN
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 
> 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 |  sys0.31s |  user   0.70s |  #proc205  | #trun  1  |  #tslpi  
 252 |  #tslpu 0 |  #zombie0  | #exit  6  |
CPU |  sys   2% |  user  4% |  irq   0%  | idle393%  |  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 |  avg10.01 |  avg50.15 |  avg15   0.09  |   |  csw 
9428 |  intr4327 || numcpu 4  |
MEM |  tot 7.7G |  free5.6G |  cache 768.7M  | buff   25.6M  |  slab  
127.6M |  shmem  57.2M |  vmbal   0.0M  | hptot   0.0M  |
SWP |  tot 7.9G |  free7.9G ||   |  
 |   |  vmcom   2.5G  | vmlim  11.8G  |
DSK |   sda |  busy  0% |  read   0  | write 27  |  KiB/w   
   5 |  MBr/s0.0 |  MBw/s0.0  | avio 0.59 ms  |

atop (bullseye):
PRC |  sys0.33s |  user   0.63s |  #proc189 |  #trun  1 |  #tslpi   
260  | #tslpu 1  | #zombie0  | clones 6  | #exit  6  |
CPU |  sys   2% |  user  4% |  irq   0% |  idle393% |  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 |  avg10.10 |  avg50.11 |  avg15   0.09 |   |  csw
14895  |   | intr6027  |   | numcpu 4  |
MEM |  tot 7.8G |  free5.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 |  free7.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/s0.0  | MBw/s0.0  | avio 4.00 ms  |

PID   SYSCPU USRCPUVGROW RGROWRUID  EUID ST 
  EXC  THRS 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 sust

Re: cpu frequence

2020-01-30 Thread Linux-Fan

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).

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


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?

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

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?


cpu: intel i5-6200U
Base frequency: 2.3 GHz
Max Frequency: 2.8 GHz


HTH
Linux-Fan

[...]


_
*
*  Created with "mutt 1.10.1-2.1"
*  under Debian Linux BUSTER 10.1
*


[begin humor/OT]
Oh no, why are there no asterisks on the right side? It looks so asymmetrical?
SCNR, see also: https://xkcd.com/859/
[end humor/OT]


pgp_Q9pY4mZrp.pgp
Description: PGP signature


cpu frequence

2020-01-30 Thread Gerard ROBIN
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 ?
With "buster" on the same machine the problem does not occur. The cpu frequency
is between 900 MHz and 1.8 GHz

cpu: intel i5-6200U 
Base frequency: 2.3 GHz
Max Frequency: 2.8 GHz
 
-- 
Gerard
_
*
*  Created with "mutt 1.10.1-2.1"
*  under Debian Linux BUSTER 10.1
*