Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Rui Nuno Capela]

Jack O'Quin wrote:
>
> [...] Looking at the graph, it appears that your DSP load is hovering
> above 70% most of the time.  This happens to be the default threshold
> for revoking realtime privileges.  Perhaps that is the problem.  Try
> running it with the threshold set to 90%.  (I don't recall exactly
> how, but I think there's a /proc/sys/kernel control somewhere.)
>

It would be nice to know which one really is :) Here are what I have here:

# grep . /proc/sys/kernel
/proc/sys/kernel/bootloader_type:2
/proc/sys/kernel/cad_pid:1
/proc/sys/kernel/cap-bound:-257
/proc/sys/kernel/core_pattern:core
/proc/sys/kernel/core_uses_pid:1
/proc/sys/kernel/ctrl-alt-del:0
/proc/sys/kernel/debug_direct_keyboard:0
/proc/sys/kernel/domainname:(none)
/proc/sys/kernel/hostname:lambda
/proc/sys/kernel/hotplug:/sbin/hotplug
/proc/sys/kernel/kernel_preemption:1
/proc/sys/kernel/modprobe:/sbin/modprobe
/proc/sys/kernel/msgmax:8192
/proc/sys/kernel/msgmnb:16384
/proc/sys/kernel/msgmni:16
/proc/sys/kernel/ngroups_max:65536
/proc/sys/kernel/osrelease:2.6.11-rc1-RT-V0.7.35-01.0
/proc/sys/kernel/ostype:Linux
/proc/sys/kernel/overflowgid:65534
/proc/sys/kernel/overflowuid:65534
/proc/sys/kernel/panic:0
/proc/sys/kernel/panic_on_oops:0
/proc/sys/kernel/pid_max:32768
/proc/sys/kernel/printk:3	4	1	7
/proc/sys/kernel/printk_ratelimit:5
/proc/sys/kernel/printk_ratelimit_burst:10
/proc/sys/kernel/prof_pid:-1
/proc/sys/kernel/sem:250	32000	32	128
/proc/sys/kernel/shmall:2097152
/proc/sys/kernel/shmmax:33554432
/proc/sys/kernel/shmmni:4096
/proc/sys/kernel/sysrq:1
/proc/sys/kernel/tainted:0
/proc/sys/kernel/threads-max:8055
/proc/sys/kernel/unknown_nmi_panic:0
/proc/sys/kernel/version:#1 Mon Jan 17 15:15:21 WET 2005

My eyes can't find anything related, but you know how intuitive these
things are ;)


>
> [...]  The old problem with more than 14 clients has been
> fixed.  I routinely run 30 or 40 without trouble.
>

Yes, but that is with (old) jack_test3 where clients were stand-alone,
without being connected to anyother. With (new) jack_test4, each client
gets all its inputs connected to all the output ports of the preceding
one. In my experience, with this (new) setup you achieve a much greater
workload with a lesser number of running clients.

If seems funny, but highly suspicious, that in both of my machines, a
P4@xxxxxx/UP laptop and a P4@xxxxxx/SMP desktop, the limit is somewhat the
same: jackd stops responding as soon the 15th client enters the chain.

Currently on jackd 0.99.47 (cvs), but I'm quite sure that was occurring
before.


> Perhaps we're running out of some port resource?
>

Probably. That was what I thought and then worked around by increasing the
maximum number of ports jackd preallocates (-p/--port-max option), but I
guess it is not enough. It was on jack_test3, but it isn't for jack_test4.

Go figure ;)

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@xxxxxxxxx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/