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@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org