31 Aug
2020
31 Aug
'20
3:17 p.m.
I'm just experimenting with new setups of Debian for audio. When running
RealtimeConfigQuickScan it triggered a vague recollection of a
discussion (here?) that configuring hpet and rtc timers is no longer
necessary as they are not used any more. Is this true or am I
misremembering?
The wiki guide at https://wiki.linuxaudio.org/wiki/system_configuration
is still a goldmine for setup but it contains some sections of which I
am unsure whether they are still applicable, including the HW timers bit.
Cheers
Roger
1 Sep
1 Sep
10:15 p.m.
On Mon, Aug 31, 2020 at 7:17 AM Roger <gurusonic(a)gmail.com> wrote:
I'm just experimenting with new setups of Debian
for audio. When running
RealtimeConfigQuickScan it triggered a vague recollection of a
discussion (here?) that configuring hpet and rtc timers is no longer
necessary as they are not used any more. Is this true or am I
misremembering?
The wiki guide at https://wiki.linuxaudio.org/wiki/system_configuration
is still a goldmine for setup but it contains some sections of which I
am unsure whether they are still applicable, including the HW timers bit.
Hmm...doing similar, but, I can't get the cpu frequency to stay set between
boots...
2 Sep
2 Sep
2:41 a.m.
On 2/9/20 4:14 am, Mac wrote:
On Mon, Aug 31, 2020 at 7:17 AM Roger <gurusonic(a)gmail.com
<mailto:gurusonic@gmail.com>> wrote:
I'm just experimenting with new setups of Debian for audio. When
running
RealtimeConfigQuickScan it triggered a vague recollection of a
discussion (here?) that configuring hpet and rtc timers is no longer
necessary as they are not used any more. Is this true or am I
misremembering?
The wiki guide at
https://wiki.linuxaudio.org/wiki/system_configuration
is still a goldmine for setup but it contains some sections of
which I
am unsure whether they are still applicable, including the HW
timers bit.
Hmm...doing similar, but, I can't get the cpu frequency to stay set
between boots...
I get around that by using Liquorix kernel which I think is hard coded
to use performance governor. The wiki doesn't mention what to do if
scaling driver is intel_pstate although from reading it's possible to
disable that and load acpi-cpufreq scaling driver instead which is
needed to be able to set the governor to performance AFAIK. There are
several pertinent questions on StackOverflow discussing that, like -
https://stackoverflow.com/questions/53349933/specify-cpu-frequency-as-a-ker…
Back to HW timers, it's trivial to set them as explained in the wiki,
but I'm just wondering if they are actually still used?
9:18 a.m.
On 9/1/20 12:41 PM, Roger wrote:
On 2/9/20 4:14 am, Mac wrote:
I don't remember what I did on my old i7 to keep it on performance. One
involved having to push the performance setting to EACH CPU/thread, I
think that's covered on that link somewhere. May have been a script. I
don't remember how I did it, but it stuck between boots. I think I
actually tried three different things, so I really don't know which one
did the trick.
I haven't done it on my present i9. Laptops aren't really good homes for
the i9 - needs a whole lot more airflow than a laptop can provide.
Running at 900MHz right now and 115F.
On Mon, Aug 31, 2020 at 7:17 AM Roger <gurusonic(a)gmail.com
<mailto:gurusonic@gmail.com>> wrote:
I'm just experimenting with new setups of Debian for audio. When
running
RealtimeConfigQuickScan it triggered a vague recollection of a
discussion (here?) that configuring hpet and rtc timers is no longer
necessary as they are not used any more. Is this true or am I
misremembering?
The wiki guide at
https://wiki.linuxaudio.org/wiki/system_configuration
is still a goldmine for setup but it contains some sections of
which I
am unsure whether they are still applicable, including the HW
timers bit.
Hmm...doing similar, but, I can't get the cpu frequency to stay set
between boots...
I get around that by using Liquorix kernel which I think is hard coded
to use performance governor. The wiki doesn't mention what to do if
scaling driver is intel_pstate although from reading it's possible to
disable that and load acpi-cpufreq scaling driver instead which is
needed to be able to set the governor to performance AFAIK. There are
several pertinent questions on StackOverflow discussing that, like -
https://stackoverflow.com/questions/53349933/specify-cpu-frequency-as-a-ker…
Back to HW timers, it's trivial to set them as
explained in the wiki,
but I'm just wondering if they are actually still used?
Don't know about that. Wasn't that something that had to be set in the
kernel at compile time?
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
"My password is the last 8 digits of π."
3:53 p.m.
Am Mittwoch, 2. September 2020, 07:18:39 CEST schrieb david:
I don't remember what I did on my old i7 to keep
it on performance. One
involved having to push the performance setting to EACH CPU/thread, I
think that's covered on that link somewhere. May have been a script. I
don't remember how I did it, but it stuck between boots. I think I
actually tried three different things, so I really don't know which one
did the trick.
As far as I remember for SysV intit systems the way to make the scaling governor
persistent across reboots was to put a command into /etc/init.d/boot.local or some other
boot init script. The command would vary with distros, whether they used cpufreq-utils or
the newer cpupower suite for this. For cpupower, the command would be
"/usr/bin/cpupower -c all frequency-set -g performance".
Systems using systemd would accordingly need a service file added as
/etc/systemd/system/cpupower.service, and possibly enabled before it would be run at every
boot. I post mine, which I remember having created myself, but I don't remember where
I got it from. Anyway this works well for me:
----
[Unit]
Description=CPU powersave
[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower -c all frequency-set -g performance
[Install]
WantedBy=multi-user.target
----
I haven't done it on my present i9. Laptops aren't really good homes for
the i9 - needs a whole lot more airflow than a laptop can provide.
Running at 900MHz right now and 115F.
Back to HW timers, it's trivial to set them
as explained in the wiki,
but I'm just wondering if they are actually still used?
Don't know about that. Wasn't that something that had to be set in the
kernel at compile time?
4:41 p.m.
On 2/9/20 9:53 pm, Edgar Aichinger wrote:
Am Mittwoch, 2. September 2020, 07:18:39 CEST schrieb
david:
That's good info. I've noticed performance governor doesn't fix the cpu to max
frequency like it used to but varies a little eg. 2.8-3.17GHz on my nominal 3.16GHz cpu.
Still doesn't decrease right down as it does with ondemand governor. Scaling driver is
still acpi-cpufreq though.
I don't remember what I did on my old i7 to
keep it on performance. One
involved having to push the performance setting to EACH CPU/thread, I
think that's covered on that link somewhere. May have been a script. I
don't remember how I did it, but it stuck between boots. I think I
actually tried three different things, so I really don't know which one
did the trick.
As far as I remember for SysV intit systems the way to make the
scaling governor persistent across reboots was to put a command into
/etc/init.d/boot.local or some other boot init script. The command would vary with
distros, whether they used cpufreq-utils or the newer cpupower suite for this. For
cpupower, the command would be "/usr/bin/cpupower -c all frequency-set -g
performance".
Systems using systemd would accordingly need a service file added as
/etc/systemd/system/cpupower.service, and possibly enabled before it would be run at every
boot. I post mine, which I remember having created myself, but I don't remember where
I got it from. Anyway this works well for me:
----
[Unit]
Description=CPU powersave
[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower -c all frequency-set -g performance
[Install]
WantedBy=multi-user.target
----
4 Sep
4 Sep
8:55 a.m.
On 9/2/20 2:40 AM, Roger wrote:
On 2/9/20 9:53 pm, Edgar Aichinger wrote:
Pretty much all modern processors (especially Intel ones) have built-in
stuff to keep them from overheating. I think the old days of setting the
processor to run at max clock are pretty much gone. Unless you're
liquid-cooling in a desktop case with really good case ventilation.
The i9 in my laptop can nominally hit 5GHz. Best I've done so far - with
an intensely-multiprocessing application - hit 4.6GHz. I think it also
hit 200F deg, too.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
"My password is the last 8 digits of π."
Am Mittwoch, 2. September 2020, 07:18:39 CEST
schrieb david:
That's good info. I've noticed performance governor doesn't fix the
cpu to max frequency like it used to but varies a little eg.
2.8-3.17GHz on my nominal 3.16GHz cpu. Still doesn't decrease right
down as it does with ondemand governor. Scaling driver is still
acpi-cpufreq though. I don't remember what I did on my old i7 to
keep it on performance. One
involved having to push the performance setting to EACH CPU/thread, I
think that's covered on that link somewhere. May have been a script. I
don't remember how I did it, but it stuck between boots. I think I
actually tried three different things, so I really don't know which one
did the trick.
As far as I remember for SysV intit systems the way to make the
scaling governor persistent across reboots was to put a command into
/etc/init.d/boot.local or some other boot init script. The command
would vary with distros, whether they used cpufreq-utils or the newer
cpupower suite for this. For cpupower, the command would be
"/usr/bin/cpupower -c all frequency-set -g performance".
Systems using systemd would accordingly need a service file added as
/etc/systemd/system/cpupower.service, and possibly enabled before it
would be run at every boot. I post mine, which I remember having
created myself, but I don't remember where I got it from. Anyway this
works well for me:
----
[Unit]
Description=CPU powersave
[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower -c all frequency-set -g performance
[Install]
WantedBy=multi-user.target
----
2 Sep
2 Sep
10:40 a.m.
Roger wrote:
The wiki guide at
https://wiki.linuxaudio.org/wiki/system_configuration
is still a goldmine for setup but it contains some sections of which I
am unsure whether they are still applicable, including the HW timers bit.
It still mentions 2.6 kernels.
Setting max-user-freq for RTC or HPET would be required only if some
application actually accessed these devices directly from user space.
As far as I know, nobody ever did this (because ALSA has its own timer
abstraction), so this has never been applicable.
Regards,
Clemens
11:28 a.m.
On 2/9/20 4:40 pm, Clemens Ladisch wrote:
Roger wrote:
Thanks, Clemens. I was thinking to contact raboof to remove that section
from RealtimeConfigQuickScan as that's still used by quite a few people
afaik. Then to gather a task force to update the wiki!
Cheers
Roger
The wiki guide at
https://wiki.linuxaudio.org/wiki/system_configuration
is still a goldmine for setup but it contains some sections of which I
am unsure whether they are still applicable, including the HW timers bit.
It still
mentions 2.6 kernels.
Setting max-user-freq for RTC or HPET would be required only if some
application actually accessed these devices directly from user space.
As far as I know, nobody ever did this (because ALSA has its own timer
abstraction), so this has never been applicable.
Regards,
Clemens 
4 Sep
4 Sep
1:59 p.m.
On 02-09-2020 09:28, Roger wrote:
I'll look into that. More souls aboard is always welcome of course!
Best,
Jeremy
On 2/9/20 4:40 pm, Clemens Ladisch wrote:
> Roger wrote:
>> The wiki guide at https://wiki.linuxaudio.org/wiki/system_configuration
>> is still a goldmine for setup but it contains some sections of which I
>> am unsure whether they are still applicable, including the HW timers
>> bit.
> It still mentions 2.6 kernels.
>
> Setting max-user-freq for RTC or HPET would be required only if some
> application actually accessed these devices directly from user space.
> As far as I know, nobody ever did this (because ALSA has its own timer
> abstraction), so this has never been applicable.
Thanks for the clarification!
Regards,
Clemens
Thanks, Clemens. I was thinking to contact raboof to remove that section
from RealtimeConfigQuickScan as that's still used by quite a few people
afaik. Then to gather a task force to update the wiki!
2:38 p.m.
On 4/9/20 7:59 pm, Jeremy Jongepier wrote:
On 02-09-2020 09:28, Roger wrote:
I'll look into that.
More souls aboard is always welcome of course!
I sent a PR yesterday and raboof has accepted it. I think the script is
up-to-date and relevant with its current tests and recommendations
although I spotted in the code a few comments of proposals for new
features. Not sure I can help with those as I don't really know any Perl.
I'm happy to help with the wiki too, although I'm more of a sound
engineer than Linux audio configurator (is that a word? is now! ;) ).
Cheers
Roger
On 2/9/20 4:40 pm, Clemens Ladisch wrote:
> Roger wrote:
>> The wiki guide at https://wiki.linuxaudio.org/wiki/system_configuration
>> is still a goldmine for setup but it contains some sections of which I
>> am unsure whether they are still applicable, including the HW timers
>> bit.
> It still mentions 2.6 kernels.
>
> Setting max-user-freq for RTC or HPET would be required only if some
> application actually accessed these devices directly from user space.
> As far as I know, nobody ever did this (because ALSA has its own timer
> abstraction), so this has never been applicable.
Thanks for the
clarification!
Regards,
Clemens
Thanks, Clemens. I was thinking to contact raboof to remove that section
from RealtimeConfigQuickScan as that's still used by quite a few people
afaik. Then to gather a task force to update the wiki!
1330
days inactive
1334
days old
linux-audio-user@lists.linuxaudio.org
10 comments
6 participants
participants (6)
-
Clemens Ladisch -
david -
Edgar Aichinger -
Jeremy Jongepier -
Mac -
Roger