[Musix-usuarios] URGENTE: Scheduling y opciones de JACK (para un trabajo práctico )

Jue Ago 21 00:17:53 CEST 2008

El Jueves, 21 de Agosto de 2008 01:21, trece ocho escribió:
 | Por ahí esta lista no tiene mucho que ver... pero como musix tiene
 | kernel rt:

Tiene todo que ver!

 | Estaba viendo sobre los kernels rt y en algún punto decía que los
 | kernels normales hacen scheduling con frecuencia de 250 Hz, y el
 | linux realtime lo hace con frecuencia de 1000 Hz....
 |

Mmm..... disculpa mi ignorancia, no sé si eso tiene relación, sé que 
hay un aspecto referente a la sincronización MIDI, no sé si tendrá 
que ver con lo que afirmás.

 | Lo que no entiendo es por qué JACK te deja setear opciones
 | estúpidas, como poner frecuencia de muestreo de 44100 Hz y 16
 | frames de buffer... si eso va a hacer que necesite hacer algo a
 | 44100/16 Hz... o sea, 2756 Hz... y eso va a hacer xruns,
 | obviamente!.

No sé

 |
 | Por otra parte, qué hace exactamente JACK-latencia?
 |

Cambia la latencia modificando en tiempo real los valores de jackd, 
sin reiniciar jackd

 |
 | Por favor, si alguno me pudiera aclarar estas dudas y decirme si
 | estoy en lo correcto o equivocado, ayudaría mucho.
 | (Y si es para mañana antes de las 2 de la tarde, mejor! :P)

<marcos> si, eso lo hablamos y explicamos varias veces en las listas 
de mail :P
<marcos> podés manejar los IRQ como si fueran procesos
<marcos> corré rtirq status
<marcos> y otras cosas también, ahora disculpá pero no tengo tiempo :(
<trece_ocho> ta
<trece_ocho> si podÃ©s me lo explicÃ¡s por la lista de mail? Porfa
<trece_ocho> necesito esa info para maÃ±ana antes de las 12 del 
mediodÃa
<trece_ocho> para un tp que estoy haciendo re urgente
<marcos> pero, trece_ocho , yo tampoco es que sé tanto
<marcos> Holborn, sabe más, por ejemplo
<marcos> holborn <holborn en telefonica.net>
<marcos> te aconsejo que te subscribas rápido a la lista de mail, 
titules: "URGENTE: necesito saber sobre blablabla"

De lo que estoy seguro es sobre los IRQ: podés manejarlos como si 
fueran procesos, eso con kernels no parcheados con parches RT, no lo 
podés hacer

Es decir, que con un kernel rt podés hacer que la placa de sonido 
tenga la máxima prioridad con respecto a otros dispositivos.

Viendo un poco la config de un kernel rt parcheado:

cat config-2.6.23-rt1 | grep -i pree
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU_BOOST=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_CRITICAL_PREEMPT_TIMING is not set

Viendo la config de un kernel rt sin algunos parches

cat config-2.6.21 | grep -i pree
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_DEBUG_PREEMPT is not set

Yendo a la consecuencia en el usuario, con estos dos kernels con 
PREEMPT habilitado, te permiten, por ejemplo que si vos estás 
grabando en Ardour un canal de una máquina de ritmos, ejemplo 
Hydrogen, y al mismo tiempo un canal con un bajo acústico/eléctrico 
metido por línea, no quede desfasado. 

En un kernel sin PREEMPT habilitado, el bajo quedaría quizá unos 90ms 
atrasado con respecto a la batería: lo hemos probado, y pasó eso, 
dado que no podés habilitar RT (tiempo real) en Qjackctl (jackd)

¿Se entiende?

¿alguien tiene mejor info?

Además de la mayor latencia, en un kernel no RT, se producen más 
pérdidas de datos (xruns), al menos es lo que he comprobado.

Esto está interesante: 
http://www.osadl.org/Realtime-Preempt-Kernel.kernel-rt.0.html

 Built-in tools

The kernel global variable kernel_preemption is now logical true,

# cat /proc/sys/kernel/kernel_preemption
1

or something went completely wrong, otherwise.

The built-in latency trace can be used as an overall test to ensure 
that the system behaves correctly. This function, however, must be 
initialized before meaningful values can be obtained:

# echo 0 >/proc/sys/kernel/preempt_max_latency

If the kernel configuration item wakeup latency histogram is enabled, 
the latency trace is enabled implicitly at boot time. The worst-case 
latency that was observed since latency tracing was enabled is 
available in the latency_trace entry of the /proc file system:

# cat /proc/latency_trace
preemption latency trace v1.1.5 on 2.6.19-1.rt10.0001
--------------------------------------------------------------------
 latency: 39 us, #2/2, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1 #P:1)
    -----------------
    | task: posix_cpu_timer-3 (uid:0 nice:0 policy:1 rt_prio:99)
    -----------------

                 _------=> CPU#
                / _-----=> irqs-off
               | / _----=> need-resched
               || / _---=> hardirq/softirq
               ||| / _--=> preempt-depth
               |||| /
               |||||     delay
   cmd     pid ||||| time  |   caller
      \   /    |||||   \   |   /
   <...>-3     0...1   39us : __schedule (__schedule)

-- 
Marcos Guglielmetti - www.mastermagazine.info

You see things; and you say 'Why?';
But I dream things that never were;
and I say 'Why not?' - George Bernard Shaw

=======================================================================
Videos, charlas, tutoriales: 
http://media.ututo.org:14888/Movies/Musix/