On Fri, Aug 15, 2008 at 06:31, Greg Smith <[EMAIL PROTECTED]>
wrote:
> Hi All,
>
> I'd like to take a moment to respectfully mark the passing of Randy
> Pausch.
>
> I wasn't aware of him before he died but it looks like his work
> (http://download.srv.cs.cmu.edu/~pausch/Randy/oldRandyPage.html
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
victor wrote:
| Is that documented? I don't see it in man page. I can try it, if
| I have a code example (says there it does not take a priority
| value, so is it just a matter of setting the policy?)
Unfortunately, SCHED_ISO is only available in a pa
you are absolutely right. I can use very large buffers; however there
are two things: I was using quite large ones (but not the immense ones you
quoted)
but say 8192 samples, and I was still getting dropouts. The larger
the buffer the longer the dropouts were lasting for. Yes, I can try
with large
Ok; My suggestion would then be for us to test allowing
RTPRIO to 99 (the max value), if possible, so we can
test its impact. Then it will be possible to test lower
priorities to see what would be a reasonable limit.
There has also been a question of testing stronger
RT kernel patches in future re
On Sat, Aug 16, 2008 at 10:15:08PM +0100, victor wrote:
> Aren't these priorities the same ones set in /etc/security/limits.conf?
> Or are they set by other means?
/etc/security/limits.conf is simply one vehicle (specifically, the one
used by PAM) for getting a uid-0 process (hence a process w/
CA
Is that documented? I don't see it in man page. I can try it, if
I have a code example (says there it does not take a priority
value, so is it just a matter of setting the policy?)
Victor
- Original Message -
From: "Benjamin M. Schwartz" <[EMAIL PROTECTED]>
To: "Michael Stone" <[EMAIL PRO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Stone wrote:
| According to "man sched_setscheduler" you want either CAP_SYS_NICE or a
| non-zero RLIMIT_RTPRIO and giving these to you means that you can
| hardlock the machine anytime by busywaiting.
As noted in a conversation with Michael,
Aren't these priorities the same ones set in /etc/security/limits.conf?
Or are they set by other means?
Victor
- Original Message -
From: "Michael Stone" <[EMAIL PROTECTED]>
To: "victor" <[EMAIL PROTECTED]>
Cc: "Jim Gettys" <[EMAIL PROTECTED]>;
Sent: Saturday, August 16, 2008 8:40 PM
Sub
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
victor wrote:
...
| Comparing the RT audio performance of the two, I must say
| I am disappointed with how worse it has got.
...
| One of the things I have been playing with is a little MIDI file player
| (one of the test/example activities in
devel.la
According to "man sched_setscheduler" you want either CAP_SYS_NICE or a
non-zero RLIMIT_RTPRIO and giving these to you means that you can
hardlock the machine anytime by busywaiting. Audio performance is
clearly important to us in this release -- probably more important than
stopping random malicio
On 16 Aug 2008, at 06:57, riccardo wrote:
> Hi Gary
>
> On Fri, 2008-08-15 at 23:18 +0100, Gary C Martin wrote:
>> Hi Michael,
>>
>> On 15 Aug 2008, at 21:58, Michael Stone wrote:
>>
>>> On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote:
I was curious to see (when testing in joyri
Sameer Verma <[EMAIL PROTECTED]> writes:
> Sorry, but I couldn't make it. Meeting conflict on campus. Does anyone
> have notes/irc logs?
Here is what I have:
[18:03]*** You have joined channel #olpc
*** Topic for #olpc: Web support: http://forum.laptop.org | IRC
support: #olpc
Sorry if I was not clear. Here is the code that currently fails
under rainbow:
/* set scheduling policy and priority */
if (priority > 0) {
p.sched_priority = priority;
if (sched_setscheduler(0, SCHED_RR, &p) != 0) {
csound->Message(csound,"csound: cannot set scheduling po
But as it is, if you are playing MIDI or audio through an Activity launched
by rainbow, there is no way AFAIK you can renice it. The
code I am testing was set to either change scheduler priority
or to renice the process. None is possible.
Note that what I am proposing here would not affect you,
be
14 matches
Mail list logo