Hola :) El Jueves, 5 de Octubre de 2006 13:50, Carlos E. R. escribió: [...]
Lo que no se es porqu� los de mythtv no usan una partici�n raw para el buffer circular de recepci�n/visionado.
El usar raw implica "ignorar" las cach�s y los buffers y acceder directamente al dispositivo. Esto para v�deo no es tan bueno porque lo que te interesa es que el streaming se haga desde memoria (m�s r�pido y menos latencia) que desde disco. Adem�s, si dos procesos est�n accediendo a dos sectores diferentes de disco ... el rendimiento (en el caso de raw) caer� vertiginosamente porque el cabezal tiene que bascular mucho :(
Pues curiosamente los de xine creo que usan raw precisamente para evitar el uso de la cache, porque al ser un fichero enorme que se lee una �nica vez no tiene sentido guardarlo en memoria que es m�s util para otros
Siempre y cuando hablemos de un proceso que accede a disco, ¿qué ocurre si son muchos usuarios que acceden a vídeo en tiempo real? Pues que no es sostenible esto. Necesitas cachear todo lo que puedas a memoria porque los cabezales están como locos saltando de un vídeo a otro para satisfacer las peticiones del resto de usuarios y procesos.
ficheros del proceso normal del sistema, que se enlentece globalmente. Creo que en esos casos es m�s eficaz una cach� dedicada al proceso en cuesti�n, o un bufer de lectura grande; es decir, limitar el tama�o de cach� dedicado a ese proceso.
Eso también es interesante, poder gestionar la caché o los buffers en función de tus necesidades. En el kernel, se pueden retocar mediante proc, pero nunca he tenido que hacerlo.
En mis tiempos que me ganaba los garbanzos programando en dos lo not�: la copia de ficheros era muy r�pida si a la funci�n de lectura de un fichero le asignaba un bufer de 64 KiB (lo normal creo que era menos de un k). En el caso de tener un cache de sistema, el fichero es primero leido en un golpe grande (o varios) al cach� del sistema, y de ah� se copia al bufer de lectura, y de ah� una tercera vez a la memoria del programa (las dos ultimas se podr�an juntar, en teor�a). Sin cach� de sistema te ahorras un movimiento de memoria.
Sí, pero si te hacen una segunda petición, el dato está cacheado y se sirve más deprisa :) Un ejemplo, en un cliente nuestro (una televisión) tienen una máquina con 32 GB de RAM ... imagínate cómo cachea el SLES ;) Claro, la segunda vez que se pide el fichero ... la latencia tiende a 0 por lo que el cliente lo recibe en seguida. Eso sí, si abres dos vídeos ... los tienes los dos en memoria y al hacer un free ves que libres hay 5 MB xD
O dicho de otra forma, el programador del proceso conoce el tipo de entrada/salida que va a necesitar y se puede optimizar. El programador de la cach� no: puede orientarla por sectores contiguos de disco, por ficheros completos, por peticiones de procesos, mezclas, algoritmos inteligentes... y todo porque no sabe realmente que es lo que le van a pedir.
Eso es otra historia: hoy en día el desarrollador de aplicaciones se basa ne lo que hacen los desarrolladores del kernel, pero no piden que se implementen determinadas cosas. Por ejemplo, en Linux, el tamaño de bloque máximo son 16 KB (si no recuerdo mal), ¿qué ocurre si mi aplicación funciona mejor leyendo bloques más grandes?
Bueno, en realidad recomendaban JFS, pero prefiero XFS. No iba a dedicarle una partici�n gigante a �l solito, y s�lo para probarlo.
Yo estuve un tiempo probando JFS y no me gust� una cosa: es poco fiable si se compila como m�dulo :( Si quieres que sea fiable y no perder datos ... incl�yelo en el kernel !!
Lo recuerdo, estuvimos hablando de eso aqu� :-)
Y puede dar guerra si a SuSE se le ocurre no ponerlo en el disco de rescate.
Cierto. Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman