Mailinglist Archive: opensuse-es (614 mails)

< Previous Next >
Re: [opensuse-es] Tiempo Real [Era: lvm o particiones extendidas]
  • From: Rafa Grimán <rafagriman@xxxxxxxxx>
  • Date: Sun, 25 Apr 2010 12:55:35 +0200
  • Message-id: <201004251255.36225.rafagriman@xxxxxxxxx>
Hola :)


On Sunday 25 April 2010 02:42 Carlos E. R. wrote
On 2010-04-24 22:51, Rafa Grimán wrote:
Hola :)


Por cierto, otra cosa: correo, fax, ofimática y similares NO son tiempo
real. Media (broadcast, postproducción, ...) sí es tiempo real, al igual
que es el control de un avión, una central nuclear, ... Yo SÍ te he
puesto ejemplo de uso de HSM en entornos de tiempo real, tu no ;)

En realidad, la tele no es tiempo real, o no necesariamente. El control de
un avión, pues sí, una buena parte. No todo. Pero es que incluso la
lectura del teclado puede ser tiempo real.


Si es un noticiario, sí es tiempo real ;) Y creeme, estar en una TV y ver la
que se lía cuando emiten un noticiario ... eso es más rápido que tiempo real y
me refiero a los trabajadores ;)


El caso es que un programa en tiempo real no significa que tenga que tener
un un tiempo de respuesta de microsegundos. ¡En realidad pueden ser horas!
EL concepto de "tiempo real" lo que significa es simplemente que se
garantiza respuesta en un tiempo determinado o menor de un limite. El
limite pueden ser minutos, segundos, o milisegundos.


Efectivamente, la emisión de un noticiario necesita un tiempo de respuesta por
parte de los trabajadores como por parte del equipamiento informático ;)

Otro ejemplo es un partido de fútbol o de baloncesto. ¿Te imaginas que el
partido NO se transmitiera en tiempo real? Con lo futboleros que son los
españoles (yo no) ... se iba a liar una buena.


Así, para el montaje de una película, te da igual que te venga el vídeo en
una centésima de segundo o en unas cuantas décimas: llegará cuando llegue,
simplemente saldrá retrasado. En cambio, si lo que controlas es la
posición del timón de una aeronave no te puedes permitir que el ordenador
se quede pensando en un bucle sin saber que valor poner. Tiene que
responder _ya_.


No señor. En las TVs no se acepta que un frame venga con "retraso". Otra cosa
es que eso ocurra. Cuando estás montando una TV digital, las pruebas que se
hacen para ver si hay caídas de frames son muy interesantes. Hasta tal punto
que se miden rendimientos en:
- cabina de discos
- switches de fibra
- servidor
- switches Ethernet
- estaciones de trabajo

Y todo simultáneamente. Te lo garantizo porque me ha tocado ;)

Tampoco estás teniendo en cuenta que estés recibiendo una ingesta de
Afganistán y al mismo tiempo estás emitiendo (playout) de la última rueda de
prensa de Zapatero y ...

En el cine es casi peor. Ahora muchas películas se graban y editan en 4K en
las que un frame puede ocupar 50 MBytes y son 24 fps ... 1200 MBytes/s. Si no
garantizas ese rendimiento ... pierdes frames y es inaceptable. Por cierto, no
te hablo de picos de 1200 MBytes/s sino sostenido. Es decir, puedes tener
horas de metraje y tienes que garantizar esos 1200 MBytes/s en todo momento.


Si quieres, puedes pagar para que lo del vídeo responda en tiempo real,
pero te costará una pasta. No basta con que responda rápido, no es eso.
Tienes que garantizar un tiempo de respuesta. Y si está en una cinta, y al
final de la misma... pues no puedes garantizar un tiempo de respuesta en
todos los casos de milisegundos. Responderá rápido, pero no tanto.


Mal, está spensando sólo en películas. Una TV hace más que eso ;)


Es que se confunde "tiempo real" con "respuesta muy rápida". No es lo
mismo.


Ya lo sé. Podía haber puesto el ejemplo de simuladores de vuelo, tanques y
camiones que tenemos, pero son jeemplos menos conocidos ;)

Y te repito, el ejemplo de pelis que has puesto no es tiempo real, lo sé, pero
es que no sólo de pelis vive la TV ;)


Puede ser un sistema de respuesta muy rápida, por ejemplo con una media de
1 mS, con variaciones típicas de hasta 5 mS. Pero basta con que una sóla
vez tarde 1S en responder para que ya no sea "tiempo real". En cambio, si
garantizas que siempre responderá en menos de dos segundos, y eso se
cumple, pues tienes un sistema de tiempo real de dos segundos.

Por ejemplo, un termostato doméstico hecho con un microcontrolador, que
apaga la calefacción cuando la temperatura baja medio grado de la
programada, con diversos periodos de calor o frío según dia de la semana y
hora, que hace sólo una medida de temperatura cada minuto para ahorrar
pilas, es un sistema a tiempo real con respuesta de un minuto o menor.

Incluso en los sistemas de tiempo real verdadero, sólo una parte es tiempo
real. Poquito. Es muy, pero muy caro, de programar.

Ya, te pongo el ejemplo de los simuladores. En un simulador de vuelo (aviones
de combate) necesitas GARANTIZAR el tiempo de respuesta, tiempo real, ...
porque si te falla un frame, el piloto puede reaccionar cuando en la vida real
el misíl no se "para"/"congela". En un simulador NO te puedes permitir que el
misíl se "congele" en el aire o que el simulador responda más tarde a la
instrucción del piloto.

En la TV ocurre algo similar: no te puedes permitir que en la transmisión de
la apertura de las olimpiadas se pierdan frames o se "congele" la imagen.
Tampoco te puedes permitir este tipo de cosas en un Real Madrid - Barça.

Ya, ya sé que pasa, igual que pasa que en una central nuclear (otro ejemplo
que he puesto de tiempo real) haya fallos (tengo un amigo que ha trabajado en
una central nuclear) o que falle en aviones o en trenes o en ... Eso no
siginifca que el sistema no sea tiempo real. Se ha diseñado como tal ... pero
a lo mejor se ha caido un repetidor o se ha caído un disco o un DIMM de
memoria ha fallado, ...

Como siempre, hay fallos: somos Humanos (imperfectos) y vivimos en un entorno
caótico ;)

Rafa

--
"We cannot treat computers as Humans. Computers need love."

Happily using KDE 4.4.1 :)
--
Para dar de baja la suscripción, mande un mensaje a:
opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
opensuse-es+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups