Ingo Molnar <[EMAIL PROTECTED]> writes:
> i suspect the confusion comes from the API hacks i'm using: user-space
> tracing is started/stopped via:
>
> gettimeofday(0,1);
> gettimeofday(0,0);
>
> while 'jackd does not want to be scheduled' flag is switched on/off via:
>
>
Ingo Molnar [EMAIL PROTECTED] writes:
i suspect the confusion comes from the API hacks i'm using: user-space
tracing is started/stopped via:
gettimeofday(0,1);
gettimeofday(0,0);
while 'jackd does not want to be scheduled' flag is switched on/off via:
Ingo Molnar <[EMAIL PROTECTED]> writes:
> - if everything fails and automatic latency tracing does not show
> anything out of ordinary, then you could try to do "user-triggered
> tracing" of jackd's critical path. This is more laborous to do, but
> should pinpoint the latency reason in a
Ingo Molnar [EMAIL PROTECTED] writes:
- if everything fails and automatic latency tracing does not show
anything out of ordinary, then you could try to do user-triggered
tracing of jackd's critical path. This is more laborous to do, but
should pinpoint the latency reason in a pretty
Matt Mackall <[EMAIL PROTECTED]> writes:
> On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote:
>> >> 4. is undocumented and has never been tested in any real music studios
>> >
>> > Well you'll have a bit to test it before it goes to Linus.
>>
>> Andrew Morton <[EMAIL PROTECTED]> writes:
>> > Does anyone have serious objections to this approach?
> On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote:
>> 1. is likely to introduce multiuser system security holes like the one
>> created r
Andrew Morton [EMAIL PROTECTED] writes:
Does anyone have serious objections to this approach?
On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote:
1. is likely to introduce multiuser system security holes like the one
created recently when the mlock() rlimits bug was fixed (DoS
Matt Mackall [EMAIL PROTECTED] writes:
On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote:
4. is undocumented and has never been tested in any real music studios
Well you'll have a bit to test it before it goes to Linus.
Only toy tests will be possible without the required
Andrew Morton <[EMAIL PROTECTED]> writes:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>>
>> I think Chris Wright's last rlimit patch is more sensible and ready to
>> go.
>
> I must say that I like rlimits - very straightforward, although somewhat
> awkward to use from userspace due to shortsighted
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> Still. It seems to be what we deserve if all that fancy stuff we have
>> cannot address this very simple and very real-world problem.
Ingo Molnar <[EMAIL PROTECTED]> writes:
> please describe this "very simple and very real-world problem" in
* Andrew Morton [EMAIL PROTECTED] wrote:
Still. It seems to be what we deserve if all that fancy stuff we have
cannot address this very simple and very real-world problem.
Ingo Molnar [EMAIL PROTECTED] writes:
please describe this very simple and very real-world problem in simple
terms.
Andrew Morton [EMAIL PROTECTED] writes:
Matt Mackall [EMAIL PROTECTED] wrote:
I think Chris Wright's last rlimit patch is more sensible and ready to
go.
I must say that I like rlimits - very straightforward, although somewhat
awkward to use from userspace due to shortsighted shell design.
[direct reply bounced, resending via gmail]
Andrew Morton <[EMAIL PROTECTED]> writes:
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > >
> > >
> > >
[direct reply bounced, resending via gmail]
Andrew Morton [EMAIL PROTECTED] writes:
Christoph Hellwig [EMAIL PROTECTED] wrote:
On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
Werner Almesberger <[EMAIL PROTECTED]> writes:
> [ Cc:s trimmed, added abiss-general ]
>
> Con Kolivas wrote:
>> Possibly reiserfs journal related. That has larger non-preemptible code
>> sections.
>
> If I understand your workload right, it should consist mainly of
> computation, networking
Werner Almesberger [EMAIL PROTECTED] writes:
[ Cc:s trimmed, added abiss-general ]
Con Kolivas wrote:
Possibly reiserfs journal related. That has larger non-preemptible code
sections.
If I understand your workload right, it should consist mainly of
computation, networking (?), and disk
Ingo Molnar <[EMAIL PROTECTED]> writes:
> i believe RT-LSM provides a way to solve this cleanly: you can make your
> audio app setguid-audio (note: NOT setuid), and make the audio group
> have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you
> could have a finegrained per-app way of
Peter Williams <[EMAIL PROTECTED]> writes:
> Paul Davis wrote:
>> There are several kernel-side attributes that would make JACK better
>> from my perspective:
>> * better ways to acquire and release RT scheduling
>
> I'm no expert on the topic but it would seem to me that the mechanisms
>
Peter Williams [EMAIL PROTECTED] writes:
Paul Davis wrote:
There are several kernel-side attributes that would make JACK better
from my perspective:
* better ways to acquire and release RT scheduling
I'm no expert on the topic but it would seem to me that the mechanisms
associated
Ingo Molnar [EMAIL PROTECTED] writes:
i believe RT-LSM provides a way to solve this cleanly: you can make your
audio app setguid-audio (note: NOT setuid), and make the audio group
have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you
could have a finegrained per-app way of
> Jack O'Quin wrote:
>> Temporarily dropping privileges gains no security whatsoever. It is
>> nothing more than a coding convenience.
Peter Williams <[EMAIL PROTECTED]> writes:
> Yes, to help avoid accidentally misusing the privileges.
>> The program remain
Peter Williams <[EMAIL PROTECTED]> writes:
>>> If you have the source code for the programs then they could be
>>> modified to drop the root euid after they've changed policy. Or
>>> even do the
> Paul Davis wrote:
>> This is insufficient, since they need to be able to drop RT
>> scheduling and
Ingo Molnar <[EMAIL PROTECTED]> writes:
> so forgive us this stubborness, it's not directed against you in person
> or against any group of users, it's always directed at the problem at
> hand. I think we can do the LSM thing, and if this problem comes up in
> the future again, then maybe by that
> On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
>> Is nobody responsible for figuring out what users need? I didn't
>> realize kernel development had become so disconnected.
Lee Revell <[EMAIL PROTECTED]> writes:
> IMHO the requirements gathering process u
Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> Also, as media apps get more sophisticated they're going to need some
> kind of access to the some traditional softirq facilities, possibily
> migrating it into userspace safely somehow, with how it handles IO
> processing such as iSCSI, FireWire,
[trimming the Cc: list]
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>> Remember when I asked how you handle changes to sizeof(struct rusage)?
>> That was a serious question. I hope there's a solution. [...]
Ingo Molnar <[EMAIL PROTECTED]> writes:
> what does any of
[trimming the Cc: list]
* Jack O'Quin [EMAIL PROTECTED] wrote:
Remember when I asked how you handle changes to sizeof(struct rusage)?
That was a serious question. I hope there's a solution. [...]
Ingo Molnar [EMAIL PROTECTED] writes:
what does any of what we've talking about have to do
Bill Huey (hui) [EMAIL PROTECTED] writes:
Also, as media apps get more sophisticated they're going to need some
kind of access to the some traditional softirq facilities, possibily
migrating it into userspace safely somehow, with how it handles IO
processing such as iSCSI, FireWire,
On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
Is nobody responsible for figuring out what users need? I didn't
realize kernel development had become so disconnected.
Lee Revell [EMAIL PROTECTED] writes:
IMHO the requirements gathering process usually works well. When
someone
Ingo Molnar [EMAIL PROTECTED] writes:
so forgive us this stubborness, it's not directed against you in person
or against any group of users, it's always directed at the problem at
hand. I think we can do the LSM thing, and if this problem comes up in
the future again, then maybe by that time
Peter Williams [EMAIL PROTECTED] writes:
If you have the source code for the programs then they could be
modified to drop the root euid after they've changed policy. Or
even do the
Paul Davis wrote:
This is insufficient, since they need to be able to drop RT
scheduling and then reacquire
Jack O'Quin wrote:
Temporarily dropping privileges gains no security whatsoever. It is
nothing more than a coding convenience.
Peter Williams [EMAIL PROTECTED] writes:
Yes, to help avoid accidentally misusing the privileges.
The program remains *inside* the system security perimeter
Ingo,
I hope we can get past this anger and continue working together. We
have too much to gain by cooperating. It would be a shame to let hurt
feelings get in the way for either of us.
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>> Well, this extremely long discussion started
Ingo,
I hope we can get past this anger and continue working together. We
have too much to gain by cooperating. It would be a shame to let hurt
feelings get in the way for either of us.
* Jack O'Quin [EMAIL PROTECTED] wrote:
Well, this extremely long discussion started with a request
Con Kolivas <[EMAIL PROTECTED]> writes:
> Good work. Looks like you're probably right about the accounting. It
> may be as simple as the fact that it is on the timer tick that we're
> getting rescheduled and this ends up being accounted as more since the
> accounting happens only at the scheduler
> Jack O'Quin wrote:
>> The corrected version works noticeably better, but still nowhere near
>> as well as SCHED_FIFO. The first run had a cluster of really bad
>> xruns. The second and third were much better, but still with numerous
>> small xruns.
>>
>&
Con Kolivas <[EMAIL PROTECTED]> writes:
> Sure enough I found the bug in less than 5 mins, and it would
> definitely cause this terrible behaviour.
>
> A silly bracket transposition error on my part :P
The corrected version works noticeably better, but still nowhere near
as well as SCHED_FIFO.
Con Kolivas <[EMAIL PROTECTED]> writes:
> Jack O'Quin wrote:
>> Loading the realtime-lsm and then running with SCHED_FIFO *does* work
>> as expected on this kernel. I should retry the test with *exactly*
>> the expected patch sequence. What would that be?
>
> Su
Con Kolivas <[EMAIL PROTECTED]> writes:
> While it is not clear what form the final soft real time
> implementation is, we should complete the partial implementation of
> SCHED_ISO that is in 2.6.11-rc2-mm1.
I finally had a chance to try this today. I applied a slightly
different patch
Con Kolivas [EMAIL PROTECTED] writes:
While it is not clear what form the final soft real time
implementation is, we should complete the partial implementation of
SCHED_ISO that is in 2.6.11-rc2-mm1.
I finally had a chance to try this today. I applied a slightly
different patch
Con Kolivas [EMAIL PROTECTED] writes:
Jack O'Quin wrote:
Loading the realtime-lsm and then running with SCHED_FIFO *does* work
as expected on this kernel. I should retry the test with *exactly*
the expected patch sequence. What would that be?
Sure enough I found the bug in less than 5
Con Kolivas [EMAIL PROTECTED] writes:
Sure enough I found the bug in less than 5 mins, and it would
definitely cause this terrible behaviour.
A silly bracket transposition error on my part :P
The corrected version works noticeably better, but still nowhere near
as well as SCHED_FIFO. The
Jack O'Quin wrote:
The corrected version works noticeably better, but still nowhere near
as well as SCHED_FIFO. The first run had a cluster of really bad
xruns. The second and third were much better, but still with numerous
small xruns.
http://www.joq.us/jack/benchmarks/sched-iso-fix
Con Kolivas [EMAIL PROTECTED] writes:
Good work. Looks like you're probably right about the accounting. It
may be as simple as the fact that it is on the timer tick that we're
getting rescheduled and this ends up being accounted as more since the
accounting happens only at the scheduler tick.
Peter Williams <[EMAIL PROTECTED]> writes:
>
> If the average usage rate is estimated over longer periods it will be
> lower allowing lower limits to be used. Also if the task's own usage
> rate estimates are used to test the limits then the limit can be lower.
>
> If the default limits can be
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> > i'm wondering, couldnt Jackd solve this whole issue completely in
>> > user-space, via a simple setuid-root wrapper app that does nothing else
>> > but valid
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> And finally, with rlimit support, is there any reason why lockup
>> detection and correction can't go into userspace? Even RT throttling
>> could probably be done in a userspace daemon.
>
> that is correct.
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> But the important elements are lost. The standard provides a
>> deterministic scheduling order, and a deterministic scheduling latency
>> (of course this doesn't mean a great deal for Linux, but I think we're
Ingo Molnar [EMAIL PROTECTED] writes:
* Nick Piggin [EMAIL PROTECTED] wrote:
But the important elements are lost. The standard provides a
deterministic scheduling order, and a deterministic scheduling latency
(of course this doesn't mean a great deal for Linux, but I think we're
good enough
Ingo Molnar [EMAIL PROTECTED] writes:
* Nick Piggin [EMAIL PROTECTED] wrote:
And finally, with rlimit support, is there any reason why lockup
detection and correction can't go into userspace? Even RT throttling
could probably be done in a userspace daemon.
that is correct. Jackd already
Ingo Molnar [EMAIL PROTECTED] writes:
* Jack O'Quin [EMAIL PROTECTED] wrote:
i'm wondering, couldnt Jackd solve this whole issue completely in
user-space, via a simple setuid-root wrapper app that does nothing else
but validates whether the user is in the 'jackd' group and then keeps
Peter Williams [EMAIL PROTECTED] writes:
If the average usage rate is estimated over longer periods it will be
lower allowing lower limits to be used. Also if the task's own usage
rate estimates are used to test the limits then the limit can be lower.
If the default limits can be made
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>>
>> > I'm a bit concerned about this kind of policy and breakage of
>> > userspace APIs going into t
Cal <[EMAIL PROTECTED]> writes:
> Consideringthe amount and rate of work in progress, this may well be
> no longer be pertinent, but I'm consistently getting an oops running
> the basic jack_test3.2 with rt-limit-2.6.11-rc2-D7 on SMP (P3 993 x
> 2). The oops and jacktest log are at
>
Nick Piggin <[EMAIL PROTECTED]> writes:
> I'm a bit concerned about this kind of policy and breakage of
> userspace APIs going into the kernel. I mean, if an app is
> succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
> scheduler does something else, that could be undesirable in some
>
Cal <[EMAIL PROTECTED]> writes:
> Jack O'Quin wrote:
>> I notice that JACK's call to mlockall() is failing. This is one
>> difference between your system and mine (plus, my machine is UP).
>> As an experiment, you might try testing with `ulimit -l unlimited'.
>
>
Ingo Molnar <[EMAIL PROTECTED]> writes:
> - exported the current RT-average value to /proc/stat (it's the last
>field in the cpu lines)
> e.g. the issue Con and others raised: privileged tasks. By default, the
> root user will likely have a 0 rlimit, for compatibility. _But_ i can
> easily
Ingo Molnar <[EMAIL PROTECTED]> writes:
> (My current thinking is that the default RT_CPU rlimit should be 0.)
How about a kernel .config option allowing us to easily compile in a
different default?
That should tide over most of the audio users for the next 6 months or
so until we get userspace
Ingo Molnar [EMAIL PROTECTED] writes:
(My current thinking is that the default RT_CPU rlimit should be 0.)
How about a kernel .config option allowing us to easily compile in a
different default?
That should tide over most of the audio users for the next 6 months or
so until we get userspace
Ingo Molnar [EMAIL PROTECTED] writes:
- exported the current RT-average value to /proc/stat (it's the last
field in the cpu lines)
e.g. the issue Con and others raised: privileged tasks. By default, the
root user will likely have a 0 rlimit, for compatibility. _But_ i can
easily
Cal [EMAIL PROTECTED] writes:
Jack O'Quin wrote:
I notice that JACK's call to mlockall() is failing. This is one
difference between your system and mine (plus, my machine is UP).
As an experiment, you might try testing with `ulimit -l unlimited'.
I went for the panic retraction
Nick Piggin [EMAIL PROTECTED] writes:
I'm a bit concerned about this kind of policy and breakage of
userspace APIs going into the kernel. I mean, if an app is
succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
scheduler does something else, that could be undesirable in some
Cal [EMAIL PROTECTED] writes:
Consideringthe amount and rate of work in progress, this may well be
no longer be pertinent, but I'm consistently getting an oops running
the basic jack_test3.2 with rt-limit-2.6.11-rc2-D7 on SMP (P3 993 x
2). The oops and jacktest log are at
Nick Piggin [EMAIL PROTECTED] writes:
On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
Nick Piggin [EMAIL PROTECTED] writes:
I'm a bit concerned about this kind of policy and breakage of
userspace APIs going into the kernel. I mean, if an app is
succeeds in gaining SCHED_FIFO
Ingo Molnar <[EMAIL PROTECTED]> writes:
> pretty much the only criticism of the RT-CPU patch was that the global
> sysctl is too rigid and that it doesnt allow privileged tasks to ignore
> the limit. I've uploaded a new RT-CPU-limit patch that solves this
> problem:
>
>
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> At around 55 seconds into the run, JACK got in trouble and throttled
>> itself back to approximately the 30% limit (actually a little above).
>> Then, around second 24
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> It works great...
>>
>> http://www.joq.us/jack/benchmarks/rt_cpu_limit
>> http://www.joq.us/jack/benchmarks/rt_cpu_limit+compile
>> http://www.joq.us
Con Kolivas <[EMAIL PROTECTED]> writes:
> There were numerous bugs in the SCHED_ISO design prior to now, so it
> really was not performing as expected. What is most interesting is
> that the DSP load goes to much higher levels now if xruns are avoided
> and stay at those high levels. If I push
Con Kolivas [EMAIL PROTECTED] writes:
There were numerous bugs in the SCHED_ISO design prior to now, so it
really was not performing as expected. What is most interesting is
that the DSP load goes to much higher levels now if xruns are avoided
and stay at those high levels. If I push the cpu
Ingo Molnar [EMAIL PROTECTED] writes:
* Jack O'Quin [EMAIL PROTECTED] wrote:
It works great...
http://www.joq.us/jack/benchmarks/rt_cpu_limit
http://www.joq.us/jack/benchmarks/rt_cpu_limit+compile
http://www.joq.us/jack/benchmarks/.SUMMARY
I'll experiment with it some more
Ingo Molnar [EMAIL PROTECTED] writes:
* Jack O'Quin [EMAIL PROTECTED] wrote:
At around 55 seconds into the run, JACK got in trouble and throttled
itself back to approximately the 30% limit (actually a little above).
Then, around second 240 it got in trouble again, this time collapsing
Ingo Molnar [EMAIL PROTECTED] writes:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> First, only SCHED_FIFO worked reliably in my tests. In Con's tests
>> even that did not work. My system is probably better tuned for low
>> latency than his. Unti
Ingo Molnar [EMAIL PROTECTED] writes:
* Jack O'Quin [EMAIL PROTECTED] wrote:
First, only SCHED_FIFO worked reliably in my tests. In Con's tests
even that did not work. My system is probably better tuned for low
latency than his. Until we can determine why there were so many
xruns
Con Kolivas <[EMAIL PROTECTED]> writes:
> Jack O'Quin wrote:
>> I'll try building a SCHED_RR version of JACK. I still don't think it
>> will make any difference. But my intuition isn't working very well
>> right now, so I need more data.
>
> Could be that despit
Ingo Molnar <[EMAIL PROTECTED]> writes:
> just finished a short testrun with nice--20 compared to SCHED_FIFO, on a
> relatively slow 466 MHz box:
Has anyone done this kind of realtime testing on an SMP system? I'd
love to know how they compare. Unfortunately, I don't have access to
one at the
Jack O'Quin <[EMAIL PROTECTED]> writes:
> Will post the correct numbers shortly. Sorry for the screw-up.
Here they are...
http://www.joq.us/jack/benchmarks/sched-isoprio
http://www.joq.us/jack/benchmarks/sched-isoprio+compile
I moved the previous runs to the sched-fifo* director
Jack O'Quin <[EMAIL PROTECTED]> writes:
> These results are indistinguishable from SCHED_FIFO...
Disregard my previous message, it was an idiotic mistake. The results
were indistinguishable form SCHED_FIFO because they *were* SCHED_FIFO.
I'm running everything again, this time with th
Con Kolivas <[EMAIL PROTECTED]> writes:
>>>Second the patch I sent you is fine for testing; I was hoping you
>>>would try it. What you can't do with it is spawn lots of userspace
>>>apps safely SCHED_ISO with it - it will crash, but it not take down
>>>your hard disk. I've had significantly
Con Kolivas <[EMAIL PROTECTED]> writes:
> There are two things that the SCHED_ISO you tried is not that
> SCHED_FIFO is - As you mentioned there is no priority support, and it
> is RR, not FIFO. I am not sure whether it is one and or the other
> responsible. Both can be added to SCHED_ISO. I
Ingo Molnar <[EMAIL PROTECTED]> writes:
> thanks for the testing. The important result is that nice--20
> performance is roughly the same as SCHED_ISO. This somewhat
> reduces the urgency of the introduction of SCHED_ISO.
Doing more runs and a more thorough analysis has driven me to a
different
Ingo Molnar [EMAIL PROTECTED] writes:
thanks for the testing. The important result is that nice--20
performance is roughly the same as SCHED_ISO. This somewhat
reduces the urgency of the introduction of SCHED_ISO.
Doing more runs and a more thorough analysis has driven me to a
different
Con Kolivas [EMAIL PROTECTED] writes:
There are two things that the SCHED_ISO you tried is not that
SCHED_FIFO is - As you mentioned there is no priority support, and it
is RR, not FIFO. I am not sure whether it is one and or the other
responsible. Both can be added to SCHED_ISO. I haven't
Con Kolivas [EMAIL PROTECTED] writes:
Second the patch I sent you is fine for testing; I was hoping you
would try it. What you can't do with it is spawn lots of userspace
apps safely SCHED_ISO with it - it will crash, but it not take down
your hard disk. I've had significantly better results with
Jack O'Quin [EMAIL PROTECTED] writes:
These results are indistinguishable from SCHED_FIFO...
Disregard my previous message, it was an idiotic mistake. The results
were indistinguishable form SCHED_FIFO because they *were* SCHED_FIFO.
I'm running everything again, this time with the correct
Jack O'Quin [EMAIL PROTECTED] writes:
Will post the correct numbers shortly. Sorry for the screw-up.
Here they are...
http://www.joq.us/jack/benchmarks/sched-isoprio
http://www.joq.us/jack/benchmarks/sched-isoprio+compile
I moved the previous runs to the sched-fifo* directories where
Ingo Molnar [EMAIL PROTECTED] writes:
just finished a short testrun with nice--20 compared to SCHED_FIFO, on a
relatively slow 466 MHz box:
Has anyone done this kind of realtime testing on an SMP system? I'd
love to know how they compare. Unfortunately, I don't have access to
one at the
Con Kolivas [EMAIL PROTECTED] writes:
Jack O'Quin wrote:
I'll try building a SCHED_RR version of JACK. I still don't think it
will make any difference. But my intuition isn't working very well
right now, so I need more data.
Could be that despite what it appears, FIFO behaviour may
Jack O'Quin <[EMAIL PROTECTED]> writes:
>
> I ran three sets of tests with three or more 5 minute runs for each
> case. The results (log files and graphs) are in these directories...
>
> 1) sched-fifo -- as a baseline
> http://www.joq.us/jack/benchmarks/sched
Con Kolivas <[EMAIL PROTECTED]> writes:
> Meanwhile, I have the priority support working (but not bug free), and
> the preliminary results suggest that the results are better. Do I
> recall someone mentioning jackd uses threads at different priority?
Yes, it does.
I'm not sure whether that
Con Kolivas <[EMAIL PROTECTED]> writes:
> Jack O'Quin wrote:
> [snip lots of valid points]
>> suggest some things to try. First, make sure the JACK tmp directory
>> is mounted on a tmpfs[1]. Then, try the test with ext2, instead of
>
> Looks like the tmpfs i
Con Kolivas <[EMAIL PROTECTED]> writes:
> Jack O'Quin wrote:
>> Neither run exhibits reliable audio performance. There is some low
>> latency performance problem with your system. Maybe ReiserFS is
>> causing trouble even with logging turned off. Perhaps the p
Ingo Molnar <[EMAIL PROTECTED]> writes:
> thanks for the testing. The important result is that nice--20
> performance is roughly the same as SCHED_ISO. This somewhat
> reduces the urgency of the introduction of SCHED_ISO.
I can see why you feel that way, but don't share your conclusion.
Con Kolivas <[EMAIL PROTECTED]> writes:
> So let's try again, sorry about the noise:
>
> ==> jack_test4-2.6.11-rc1-mm2-fifo.log <==
> *
> XRUN Count . . . . . . . . . : 3
> Delay Maximum . . . . . . . . : 20161 usecs
>
Con Kolivas [EMAIL PROTECTED] writes:
So let's try again, sorry about the noise:
== jack_test4-2.6.11-rc1-mm2-fifo.log ==
*
XRUN Count . . . . . . . . . : 3
Delay Maximum . . . . . . . . : 20161 usecs
Ingo Molnar [EMAIL PROTECTED] writes:
thanks for the testing. The important result is that nice--20
performance is roughly the same as SCHED_ISO. This somewhat
reduces the urgency of the introduction of SCHED_ISO.
I can see why you feel that way, but don't share your conclusion.
First,
Con Kolivas [EMAIL PROTECTED] writes:
Jack O'Quin wrote:
Neither run exhibits reliable audio performance. There is some low
latency performance problem with your system. Maybe ReiserFS is
causing trouble even with logging turned off. Perhaps the problem is
somewhere else. Maybe some
Con Kolivas [EMAIL PROTECTED] writes:
Jack O'Quin wrote:
[snip lots of valid points]
suggest some things to try. First, make sure the JACK tmp directory
is mounted on a tmpfs[1]. Then, try the test with ext2, instead of
Looks like the tmpfs is probably the biggest problem. Here's
Con Kolivas [EMAIL PROTECTED] writes:
Meanwhile, I have the priority support working (but not bug free), and
the preliminary results suggest that the results are better. Do I
recall someone mentioning jackd uses threads at different priority?
Yes, it does.
I'm not sure whether that matters
Jack O'Quin [EMAIL PROTECTED] writes:
I ran three sets of tests with three or more 5 minute runs for each
case. The results (log files and graphs) are in these directories...
1) sched-fifo -- as a baseline
http://www.joq.us/jack/benchmarks/sched-fifo
2) sched-iso -- Con's
1 - 100 of 154 matches
Mail list logo
