este articulo no es mio lo saque de aca
Para ver este enlace Registrate o Inicia Sesionpero lo posteo porque me parecio interesante sobre todo para entender un poco la metodologia de los sistemas ope.
Arquitectura de un Sistema Operativo de Propósito GeneralLa memoria física de un computador esta dividida entre el espacio reservado para los usuarios ("user-space") y el espacio reservado para el kernel ("kernel-space"). El kernel multitarea es capaz de manejar múltiples aplicaciones de usuarios que ejecutan en el espacio de usuario haciendo creer a cada uno que dispone de todo el espacio de memoria y de todos los recursos hardware. La comunicación entre los programas en el espacio de usuario y el espacio del kernel se realiza a través de las llamadas al sistema. Estas llamadas típicamente lo que hacen es acceder a recursos físicos compartidos. Todos los accesos a los recursos hardware son controlados por el kernel de modo que los programas de usuario no conozcan los detalles físicos de los dispositivos.
Las funcionalidade
s principales de un sistema operativo de propósito general son:
* Gestión de procesos. Planificación de procesos.
* Gestión de memoria.
* Interactuar con el Hardware.
* Servidor de Ficheros.
* Servidor de Comunicaciones
.
La funcionalidad principal y requerida para un sistema operativo de tiempo real es proveer de un nivel de servicio adecuado a las aplicaciones que requieran una respuesta en un intervalo de tiempo determinado.
La característica principal de un sistema operativo de tiempo real es la respuesta ante eventos internos ó externos, tales como interrupciones hardware externas, interrupciones software internas ó interrupciones de reloj internas, es decir los requerimientos temporales.
Una de las medidas de rendimiento de un Sistema Operativo de Tiempo Real es la latencia, ó tiempo desde que ocurre el evento y éste es tratado. La otra medida es el jitter, ó variaciones en el periodo normal de ocurrencia de eventos periódicos.
Todos los sistemas operativos tienden a tener una baja latencia y un bajo jitter, pero los sistemas operativos de tiempo real requieren que esos valores estén determinados y que no dependan de la carga del sistema.Las funcionalidade
s principales de un sistema operativo de propósito general son:
* Gestión de procesos. Planificación de procesos.
* Gestión de memoria.
* Interactuar con el Hardware.
* Servidor de Ficheros.
* Servidor de Comunicaciones
.
La funcionalidad principal y requerida para un sistema operativo de tiempo real es proveer de un nivel de servicio adecuado a las aplicaciones que requieran una respuesta en un intervalo de tiempo determinado.
La característica principal de un sistema operativo de tiempo real es la respuesta ante eventos internos ó externos, tales como interrupciones hardware externas, interrupciones software internas ó interrupciones de reloj internas, es decir los requerimientos temporales.
Una de las medidas de rendimiento de un Sistema Operativo de Tiempo Real es la latencia, ó tiempo desde que ocurre el evento y éste es tratado. La otra medida es el jitter, ó variaciones en el periodo normal de ocurrencia de eventos periódicos.
Todos los sistemas operativos tienden a tener una baja latencia y un bajo jitter, pero los sistemas operativos de tiempo real requieren que esos valores estén determinados y que no dependan de la carga del sistema.
Clases de tiempo realUn programa ó un sistema operativo es considerado como de tiempo real, si a pesar de las restricciones de tiempo le permiten trabajar y funcionar correctamente.
Se distinguen las siguientes clases:
* Tiempo real estricto (Hard Real Time): Todas las acciones deben ocurrir dentro del plazo especificado.
* Tiempo real flexible (Soft Real Time): Se pueden perder plazos de vez en cuando. El valor de la respuesta decrece con el tiempo.
* Tiempo real firme (Firm Real Time): Se pueden perder plazos ocasionalmente
. Una respuesta tardía no tiene valor.
Características de rendimientoEl criterio fundamental de evaluación del rendimiento de un sistema operativo de tiempo real es la latencia y el periodo del jitter ante un evento. Un evento es cualquier tipo de interrupción, tanto interna, como externa.
*
Latencia en un evento
Un evento puede ser tanto una interrupción hardware como una interrupción software.
La latencia ante una interrupción hardware es el tiempo desde que se produce la interrupción hasta que se ejecuta la primera instrucción de la rutina de tratamiento. Puede haber retrasos debido al acceso al bus.
La latencia ante una interrupción software es el tiempo desde que la señal es generada hasta que la primera instrucción de la tarea es ejecutada. Aquí el valor depende únicamente del acceso a los registros del procesador.
Periodo del Jitter
El periodo del jitter se refiere a las variaciones en el tiempo que experimenta una tarea cuando se ejecuta de manera repetitiva.
Arquitectura de un sistema operativo de tiempo realEl objetivo de un sistema operativo de tiempo real es reducir la latencia y el jitter en las interrupciones, tanto internas como externas, al orden de microsegundos.
Es decir, la parte fundamental para convertir un sistema operativo de propósito general en un sistema operativo de tiempo real es el manejo de las interrupciones
.
El procesamiento de interrupciones en el kernel estándar esta divido en 2 tareas. Una tarea que se encarga de leer los datos del dispositivo físico y escribirlos en un buffer, es lo que se conoce como manejador de interrupciones, y una tarea que se encarga de pasar los datos del buffer a otro para que sean accesible por el kernel. Con este esquema, cuando el manejador esta ejecutando, todas las interrupciones están inhibidas con el siguiente retardo impredecible en el servicio de otras interrupciones que se puedan haber producido y por tanto en los valores de latencia y jitter.
Para conseguir reducir la latencia y el jitter se han desarrollado distintas alternativas que modifican el kernel de linux en este aspecto fundamentalmen
te.
Actualmente hay dos corrientes de diseño:
*
Atención prioritaria en el kernel estándar (Preemptable kernel)
Esta metodología modifica el kernel en profundidad de forma que los procesos de kernel ejecuten con máxima prioridad de forma que puedan interrumpir a procesos de menor prioridad en el acceso a los recursos que necesiten.
Esta metodología implica cambios en los manejadores de interrupciones para que las interrupciones de alta prioridad no sean bloqueadas por el manejador de interrupciones mientras esta manejando otra de menor prioridad.
El resultado de esta metodología es una latencia y un jitter del orden de 1 milisegundo en un Pentium a 100 Mhz.
A partir de la version 2.5.4 del kernel de Linux se incorpora esta metodología.
Como se puede observar en la figura la tarea de tiempo real esta controlada por el planificador del kernel y es una más de las tareas que controla el kernel. Esta tarea hace referencia a los procesos de tiempo real en el espacio de usuario. El planificador sabe que las tareas de tiempo real tiene mayor prioridad que las tareas que no son de tiempo real.
Como se puede comprobar esta metodología es adecuada para aplicaciones de audio y vídeo donde el periodo de interrupciones es del orden de 1 milisegundo, pero inadecuado cuando ya hablamos de menos de 1 milisegundo.
Beneficios y limitaciones de la estrategia de kernel preemptable:
Modificaciones sobre el kernel estándar (Patch)
Existen 4 estrategias de modificación del kernel de Linux para proveer capacidades de tiempo real. Tres de ellas implican añadir un segundo kernel (kernel dual) para manejar las tareas de tiempo real y el cuarto implica modificar directamente el código del kernel para añadir características de tiempo real.
Beneficios y limitaciones de la estrategia de kernel dual:
Micro-kernel
Esta estrategia añade un segundo kernel que en realidad es una capa interfaz entre el hardware y el kernel estándar, lo que se llama tradicionalmen
te HAL (Hardware Abstraction Layer). Esta capa, micro-kernel, controla la ejecución de las tareas de tiempo real y ejecuta el kernel estándar como una tarea en background, es decir, el kernel estándar sólo ejecuta cuando no hay tareas de tiempo real pendientes.
#
Este microkernel intercepta las interrupciones hardware y asegura que las tareas de tiempo real ejecuten con la mayor prioridad posible de forma que la latencia se minimice.
Ejemplo de implementación de esta metodología son RTLinux y RTAI.
#
Nano-kernel
Esta estrategia es similar a la primera, micro-kernel, pero consigue evitar la patente que tiene Yodaiken sobre ésta, de forma que este nano-kernel únicamente captura las interrupciones hardware y permite la ejecución paralela de varios sistemas operativos por encima de él.
En este sentido, esta estrategia no desemboca directamente en un sistema operativo de tiempo real, sino que, simplemente es una capa intermedia entre el hardware y un sistema operativo, que puede ser de tiempo real ó no.
#
Una implementación de esta estrategia es ADEOS. Los desarrolladore
s de este proyecto fueron precisamente los que pusieron el nombre de nano-kernel para diferenciarlo claramente de la estrategia de micro-kernel patentado por Yodaiken.
#
Extensión con un nuevo kernel de acceso a los recursos (Recurso-kernel)
Esta estrategia añade un kernel de forma que éste proporciona una puerta de acceso a los recursos, tales como al sistema de ficheros, al puerto paralelo, etc, tanto para el kernel estándar como a los procesos de usuario.
El recurso kernel no sólo captura las interrupciones sino que proporciona un mecanismo donde los programas de usuario pueden requerir, reservar y garantizarse un porcentaje finito de los recursos como pueden ser de CPU, memoria, etc.
Extensiones POSIX de tiempo real añadidas al kernel
Esta estrategia consiste en modificar directamente el kernel estándar de Linux para añadir librerías que implementan las extensiones de tiempo real de POSIX. El resultado es un kernel conforme al estándar IEEE 1003.1d. No añade un segundo kernel.
Las modificaciones realizadas al kernel consisten en la implementación de relojes, señales, semáforos, memoria compartida, planificador por prioridades, etc según lo especificado en IEEE 1003.1d.
Existen 2 aproximaciones diferentes para esta estrategia:
* KURT (The Kansas University Real Time Linux) que únicamente implementa los relojes conforme al estándar IEEE 1003.1d.
* TimeSys Linux. Añade al "preemptable kernel" un planificador de kernel que proporciona una latencia y un jitter menor de 100µs. El parche con el planificador no proporciona una alta resolución en los relojes, que es necesaria para tareas de tiempo real repetitivas.
Rendimiento de un sistemaSi comparamos por ejemplo el kernel estándar con RTLinux podremos observar claramente como existe gran diferencia tanto en la latencia en las interrupciones como en el jitter, siendo mucho menos para el caso de RTLinux y siempre en el orden de 1 a 10 microsegundos para un Pentium a 100Mhz.
Si comparamos entre si las distintas estrategias de diseño de un sistema operativo de tiempo real podremos observar que las diferencias no son tan amplias si las comparamos con el kernel estándar.
es todo si se pasan por la fuenta abajo del todo hay algunos otros enlazes
saludos
Autor