28 Sep
2005
28 Sep
'05
12:06 p.m.
Hi to the list,
I've compiled a 2.6.12 kernel in my debian system (using the debian
sources). I want to obtain the best latency possible without using the
realtime patch. I've noted that there are three i/o scheduler in the
kernel config:
Device Drivers --->
Block devices --->
IO Schedulers --->
<*> Anticipatory I/O scheduler
<*> Deadline I/O scheduler
<*> CFQ I/O scheduler
I've compiled them all as built-in. Which is best for low-latency audio
work? Can I change the scheduler while the system is running (I read it
somewhere)?
The file /sys/block/hda/queue/scheduler contains:
noop [anticipatory] deadline cfq
so which scheduler am I using now? I've tried to echo cfg to that file
but it remains the same.
I appreciate any information, link or other to make light on the matter.
Thanks for any answer,
~ Antonio
28 Sep
28 Sep
12:18 p.m.
I believe that you are using anticipatory. I don't know which one is
best for low latency.
You can try each one (I think) by adding a boot time option to grub.conf
elevator=deadline
or
elevator=cfq
for example.
I've been interested in this also, but not enough to try and develop a
real test. I suspect you'll have to run for a while to make a real
determination.
Good luck, and report back.
cheers,
Mark
On 9/28/05, Antonio <debian(a)fastwebnet.it> wrote:
Hi to the list,
I've compiled a 2.6.12 kernel in my debian system (using the debian
sources). I want to obtain the best latency possible without using the
realtime patch. I've noted that there are three i/o scheduler in the
kernel config:
Device Drivers --->
Block devices --->
IO Schedulers --->
<*> Anticipatory I/O scheduler
<*> Deadline I/O scheduler
<*> CFQ I/O scheduler
I've compiled them all as built-in. Which is best for low-latency audio
work? Can I change the scheduler while the system is running (I read it
somewhere)?
The file /sys/block/hda/queue/scheduler contains:
noop [anticipatory] deadline cfq
so which scheduler am I using now? I've tried to echo cfg to that file
but it remains the same.
I appreciate any information, link or other to make light on the matter.
Thanks for any answer,
~ Antonio
1:03 p.m.
I believe that you are using anticipatory.
Yes, your using the one in brackets
I don't know which one is best for low latency.
I don't either, but judging from this it might be anticipatory:
http://kerneltrap.org/node/616.
I really doubt (from an ordinary audio users POV) you'll see
that much difference in latency tough. I'd rather make sure my hdparm
values are correct.
You can try each one (I think) by adding a boot time
option to grub.conf
elevator=deadline
or
elevator=cfq
or you can change the running scheduler w/o rebooting by doing
echo deadline > /sys/block/hda/queue/scheduler
For latency, I'd run the latest 2.6.13 (it's .2 now).
2.6.12 had some bugs in its rlimits code that's fixed in 13.
Also make sure you have the patched PAM and an adusted
/etc/security/limits.conf to make proper use of rlimits.
- Peder
2:05 p.m.
Hi Peder, Mark,
On Wed, 2005-09-28 at 17:03 +0200, Peder Hedlund wrote:
Yes, I've noted it now ;-)
I've jet optimised my hd with hdparm. Thanks to remember this though.
Ok I've tried and both methods work. Before I was bad spelling the name
of the scheduler so it weren't changed. (I'm not sure if I right spelled
this sentence, though :-( ).
To follow Mark's advice to experiment myself I done a little, non
scientific, test. I've tried to uninstall and reinstall (with apt)
openoffice (~ 150 MB) while listening a good album (say Holy Diver, Dio)
with beep-media-player. I've found that the anticipatory scheduler
gives lots of gaps (too much) in the music during the process. The
deadline scheduler gives less gaps, but there are at least a long gap (~
0.5 sec) during the uninstal-install process. If, in the meantime, I
also open/close evolution the gaps become more and more long. With the
cfq scheduler instead I don't have a single (audible) gap in the music,
also using evolution or other programs during the uninstall-install
process. The noop scheduler is the worse in my test.
This is only my little test. Probably if your aim is to do multi-track
recording with ardour you can have opposite results (regarding wich
scheduler is the best), or the same, I don't know. I've reported it only
for the record.
I believe that
you are using anticipatory.
Yes, your using the one in brackets I don't
know which one is best for low latency.
I don't either, but judging from this it might be anticipatory:
http://kerneltrap.org/node/616.
I really doubt (from an ordinary audio users POV) you'll see
that much difference in latency tough. I'd rather make sure my hdparm
values are correct. You can try
each one (I think) by adding a boot time option to grub.conf
elevator=deadline
or
elevator=cfq
or you can change the running scheduler w/o rebooting by doing
echo deadline > /sys/block/hda/queue/scheduler For latency, I'd run the latest 2.6.13 (it's
.2 now).
2.6.12 had some bugs in its rlimits code that's fixed in 13.
Also make sure you have the patched PAM and an adusted
/etc/security/limits.conf to make proper use of rlimits.
And yes I'm going to try the 2.6.13 too. Do you know if I can use the
realtime-lsm module with the .13? I don't care about security risk on
this machine.
Anyhow, many thanks for the useful answer you give me so far ;-).
Best Regards,
~ Antonio
9:10 p.m.
On 9/28/05, Antonio <debian(a)fastwebnet.it> wrote:
<SNIP>
And yes I'm going to try the 2.6.13 too. Do you
know if I can use the
realtime-lsm module with the .13? I don't care about security risk on
this machine.
<SNIP>
Absolutely. I'm running it right now on a 2.6.13 kernel I built. No
problems. It works great.
1) Create a group called realtime and give it a unique number. Add
your user account to the group:
mark@lightning ~ $ cat /etc/group | grep realtime
realtime:x:600:mark
mark@lightning ~ $
2) Load the realtime-lsm module:
mark@lightning ~ $ cat /etc/modules.autoload.d/kernel-2.6 | grep realtime
realtime gid=600 any=1
mark@lightning ~ $
3) Run Jack using realtime capabilities as a user
Cheers,
Mark
29 Sep
29 Sep
7:17 a.m.
Hi Mark,
On Wed, 2005-09-28 at 16:10 -0700, Mark Knecht wrote:
On 9/28/05, Antonio <debian(a)fastwebnet.it>
wrote:
<SNIP>
Thanks for the detailed instructions. It works like charm here too, with
the vanilla 2.6.13.
Best regards,
~ Antonio
And yes I'm going to try the 2.6.13 too. Do
you know if I can use the
realtime-lsm module with the .13? I don't care about security risk on
this machine.
<SNIP>
Absolutely. I'm running it right now on a 2.6.13 kernel I built. No
problems. It works great.
1) Create a group called realtime and give it a unique number. Add
your user account to the group:
mark@lightning ~ $ cat /etc/group | grep realtime
realtime:x:600:mark
mark@lightning ~ $
2) Load the realtime-lsm module:
mark@lightning ~ $ cat /etc/modules.autoload.d/kernel-2.6 | grep realtime
realtime gid=600 any=1
mark@lightning ~ $
3) Run Jack using realtime capabilities as a user
11:57 a.m.
On 9/29/05, Antonio <debian(a)fastwebnet.it> wrote:
Hi Mark,
On Wed, 2005-09-28 at 16:10 -0700, Mark Knecht wrote:
My pleasure.
- Mark
On 9/28/05, Antonio <debian(a)fastwebnet.it>
wrote:
<SNIP>
Thanks for the detailed instructions. It works like charm here too, with
the vanilla 2.6.13.
Best regards,
~ Antonio
And yes I'm going to try the 2.6.13 too. Do
you know if I can use the
realtime-lsm module with the .13? I don't care about security risk on
this machine.
<SNIP>
Absolutely. I'm running it right now on a 2.6.13 kernel I built. No
problems. It works great.
1) Create a group called realtime and give it a unique number. Add
your user account to the group:
mark@lightning ~ $ cat /etc/group | grep realtime
realtime:x:600:mark
mark@lightning ~ $
2) Load the realtime-lsm module:
mark@lightning ~ $ cat /etc/modules.autoload.d/kernel-2.6 | grep realtime
realtime gid=600 any=1
mark@lightning ~ $
3) Run Jack using realtime capabilities as a user
28 Sep
28 Sep
10:04 p.m.
On 9/28/05, Peder Hedlund <peder(a)musikhuset.org> wrote:
Peder,
Interesting. Thanks.
This method allows you to change the scheduler for an individual
drive. I presume that my method changes the default scheduler for
everything, but I have not tested that.
One thing that seems to not exist in ck-sources that I used
successfully in one of the kernels I ran that has Ingo's stuff in it
was the ability to set certain ISRs to threaded or non-threaded
operation. I used to echo a 1 or 0 to /proc/irq/5/hdsp (or something
like that) and this would make the ISR threaded or non-threaded.
Soes naythign like this exist in ck-sources?
Thanks,
Mark
You can try
each one (I think) by adding a boot time option to grub.conf
elevator=deadline
or
elevator=cfq
or you can change the running scheduler w/o rebooting by doing
echo deadline > /sys/block/hda/queue/scheduler
For latency, I'd run the latest 2.6.13 (it's .2 now).
2.6.12 had some bugs in its rlimits code that's fixed in 13.
Also make sure you have the patched PAM and an adusted
/etc/security/limits.conf to make proper use of rlimits.
- Peder
30 Sep
30 Sep
8:25 a.m.
Hi!
Alle 16:18, mercoledì 28 settembre 2005, Mark Knecht ha scritto:
I believe that you are using anticipatory. I don't
know which one is
best for low latency.
You can try each one (I think) by adding a boot time option to grub.conf
elevator=deadline
or
elevator=cfq
for example.
I've been interested in this also, but not enough to try and develop a
real test. I suspect you'll have to run for a while to make a real
determination.
I read at
http://www.jacklab.net/index.php?option=com_content&task=blogcategory&a…
that you should use the Realtime Preemption Patch and then enable it.
I'm running a 2.6.12 kernel patched with this and using also the realtime-lsm
module.
But now I'm confused, because
1) "less /sys/block/hda/queue/scheduler" gives me "noop [anticipatory]
deadline cfq", so where is the realtime preemption? Is it useful since you do
not even mention it?
2)I discovered that the rlimits way it's better: is it true? Is it also
simpler than loading the realtime module, which I can do in a straightforward
way?
Byez!
Carotinho
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
2:52 p.m.
On Fri, 2005-09-30 at 12:18 +0200, Carotinho wrote:
[cut]
I read at
http://www.jacklab.net/index.php?option=com_content&task=blogcategory&a…
that you should use the Realtime Preemption Patch and then enable it.
I'm running a 2.6.12 kernel patched with this and using also the realtime-lsm
module.
But now I'm confused, because
1) "less /sys/block/hda/queue/scheduler" gives me "noop [anticipatory]
deadline cfq", so where is the realtime preemption? Is it useful since you do
not even mention it?
Maybe you are confusing the Realtime Preemption Patch with the I/O
scheduler. The I/O scheduler do the scheduling for the hd access. While
the Realtime Preemption Patch modifies the processes's scheduler, I
think. They are two different and indipendent things.
2)I discovered that the rlimits way it's better:
is it true? Is it also
simpler than loading the realtime module, which I can do in a straightforward
way?
The rlimits is the new (mainline) way to give the user realtime
privileges. The realtime-lsm module wasn't accepted in the mainline
kernel for security risk. So if you don't mind the security risk and you
already know how to compile and load the module, you can continue to use
the realtime-lsm module. At least until your distribution don't include
all the pieces needed to use rlimits. This is my understanding, please
correct me if I'm wrong.
Best regards,
~ Antonio
4:02 p.m.
On 9/30/05, Antonio <debian(a)fastwebnet.it> wrote:> On Fri, 2005-09-30 at 12:18
+0200, Carotinho wrote:> [cut]> > I read at> >
http://www.jacklab.net/index.php?option=com_content&task=blogcategory&a…
> that you should use the Realtime Preemption Patch and then enable it.> >
I'm running a 2.6.12 kernel patched with this and using also the realtime-lsm> >
module.> > But now I'm confused, because> > 1) "less
/sys/block/hda/queue/scheduler" gives me "noop [anticipatory]> > deadline
cfq", so where is the realtime preemption? Is it useful since you do> > not
even mention it?>> Maybe you are confusing the Realtime Preemption Patch with the
I/O> scheduler. The I/O scheduler do the scheduling for the hd access. While> the
Realtime Preemption Patch modifies the processes's scheduler, I> think. They are
two different and indipendent things.>> > 2)I discovered that the rlimits way
it's better: is it true? Is it also> > simpler than loading the realtime module,
which I can do in a straightforward> > way?>> The rlimits is the new
(mainline) way to give the user realtime> privileges. The realtime-lsm module
wasn't accepted in the mainline> kernel for security risk. So if you don't mind
the security risk and you> already know how to compile and load the module, you can
continue to use> the realtime-lsm module. At least until your distribution don't
include> all the pieces needed to use rlimits. This is my understanding, please>
correct me if I'm wrong.>> Best regards,>> ~ Antonio
Hi, Yes, I believe these schedulers has different responsibilities.
Probably I should report this in a separate thread. I do not intendto do any thread
hijacking here but it does seem related.
Yesterday I finally managed to build 2.6.14-rc2-rt7 for my AMD64system. Out of the box
it's working very, very well. I've doneabsolutely no configuration of the system.
I've not set anythingspecial. Just booted it, started Jack at 128/2 as a user
usingrealtime-lsm, and have been streaming ogg files for 4 hours from oneof my 1394a audio
drives. In that time I've been browsing the web,doing email and updating the system.
I've built a new kernel, copied abunch of files from drive to drive and run a couple
of existing Ardoursessions. While all of that was going on I fired up xine and played aDVD
movie in the background on my EIDE DVD drive just to create somemore system usage.
I've not had a single operational xrun in nearly 4 hours. The onlyones I've had
come when starting and stopping apps.
Everything's working great for me, but this is less than 24 hoursso far so take it
with a grain of salt.
This is Gentoo, AMD64 3000+, 512MB, 250GB SATA drive, 4 1394 harddrives( three 1394a
and one 1394b) , PCI-Express 16X ATI.
Note: Executables seem larger on this AMD64 system. I'll needanother 512MB one day
soon as I do seee a small amount of swapping onthis system. (<30KB) I never saw that
when running 32-bit.
Cheers,Mark
7022
days inactive
7024
days old
linux-audio-user@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Antonio -
Carotinho -
Mark Knecht -
Peder Hedlund