Proyecto movido a GitHub
Miér 7 Abr 2021 - 19:23 por bittor
Proyecto movido a GitHub:
https://github.com/bittor7x0/VDR-M7x0
Con muchos cambios y correcciones, Más información
También incluye el plugin epgfixer para corregir la EPG usando expresiones regulares y el plugin xmltv2vdr para descargar la EPG de internet
https://github.com/bittor7x0/VDR-M7x0
Con muchos cambios y correcciones, Más información
También incluye el plugin epgfixer para corregir la EPG usando expresiones regulares y el plugin xmltv2vdr para descargar la EPG de internet
Comentarios: 0
Buscar
Mejoras importantes en el JFFS2
4 participantes
Página 1 de 1.
Mejoras importantes en el JFFS2
Por si alguien no lo sabe, el JFFS2 es el sistema de archivos de lectura y escritura usado en el giga, es decir, todo lo que hay bajo /etc.
Hace algún tiempo mejoré (en la versión del SVN) considerablemente el rendimiento de este sistema de archivos usando las funciones CRC32 del último kernel que había en ese momento y como JFFS2 las usa intensivamente su rendimiento mejoró muchísimo, haciendo el arranque 5 segundos más rápido.
Ahora he vuelto a hacer lo mismo, pero añadiendo el soporte para el algoritmo LZO al kernel y al sistema de archivos JFFS2.
LZO es el compresor/descompresor en tiempo real más rápido que existe (sobre todo en lectura y manteniendo un buen ratio de compresión) y consume menos RAM, aunque por contra no comprime tanto como otros.
Aquí está la comparativa de un firmware "normal" (ya lleva la mejora del CRC32) usando zlib con rtime (algoritmo para volver a comprimir los datos ya comprimidos), contra el algoritmo LZO y LZO + rtime, que tiene exactamente los mismos archivos en /rw-flash que es donde se monta nuestro JFFS2.
Tamaño de la imagen del kernel
normal: 635.110 Bytes
lzo: 628.175 Bytes
lzo+rtime: 628.591 Bytes
Primer punto positivo para LZO, porque tenemos un kernel más pequeño y el arranque será ligeramente más rápido (milisegundos) y usará menos memoria.
La diferencia entre LZO y LZO junto al compresor rtime es mínima.
Compresión de los datos
# df -h | grep rw-flash
Size Used Available Use%
normal: 5.8M 768.0K 5.0M 13%
lzo: 5.8M 828.0K 4.9M 14%
lzo+rtime: 5.8M 732.0K 5.0M 12%
Como era de esperar lzo es el que menos compresión ofrece, pero sorprendentemente lzo junto a rtime consiguen la mayor compresión posible.
Estos resultados podrían variar según los datos (plugins, logos, ...) que tengamos en /etc.
Memoria RAM usada
# free (la media de ejecutarlo después de 2 arranques)
total used free shared buffers
normal: 45868 21844 24024 0 3396
lzo: 45888 21248 24640 0 3360
lzo+rtime: 45888 18630 27258 0 3134
El ganador con diferencia vuelve a ser lzo+rtime y podemos ver que curiosamente con LZO tenemos 20 Bytes más de memoria total .
Velocidad de lectura
# io-test -s 2 /rw-flash/test.txt (la media de ejecutarlo 4 veces)
normal: 10,35 MiB/s
lzo: 11,9675 MiB/s
lzo+rtime: 11,945 MiB/s
El aumento de lectura con lzo es bastante considerable y prácticamente igual entre lzo y lzo+rtime (un poco menor porque los datos están más comprimidos).
Velocidad de escritura
# io-test -s 2 /rw-flash/test.txt (la media de ejecutarlo 4 veces)
normal: 44,4075 KiB/s
lzo: 57,6975 KiB/s
lzo+rtime: 58,3675 KiB/s
Aparentemente la ganancia en escritura es muy poca, pero mirando el porcentaje con lzo+rtime es un 31% más rápido (más de la cuarta parte).
Comparando el porcentaje entre lzo+rtime y lzo la ganancia es de un 1,16% ya que tiene que escribir menos datos porque están más comprimidos.
Conclusión
Los números hablan por sí solos y el ganador indiscutible es lzo con rtime.
El que quiera probarlo sólo tiene que compilar la última versión del SVN.
Todos los archivos que estén bajo /etc notarán la mejora, es decir, al leer archivos de configuración al arrancar y escribirlos al apagar, logos de canales, plugins externos, guardar la EPG, etc.
De momento, en el JFFS2 sólo se incluye el directorio "SI", por lo tanto no es necesario hacer un factory reset porque se hará automáticamente y en el primer arranque también se hará una limpieza de todo el JFFS2, por lo que le costará un poco más.
Ya diréis que tal os funciona.
Hace algún tiempo mejoré (en la versión del SVN) considerablemente el rendimiento de este sistema de archivos usando las funciones CRC32 del último kernel que había en ese momento y como JFFS2 las usa intensivamente su rendimiento mejoró muchísimo, haciendo el arranque 5 segundos más rápido.
Ahora he vuelto a hacer lo mismo, pero añadiendo el soporte para el algoritmo LZO al kernel y al sistema de archivos JFFS2.
LZO es el compresor/descompresor en tiempo real más rápido que existe (sobre todo en lectura y manteniendo un buen ratio de compresión) y consume menos RAM, aunque por contra no comprime tanto como otros.
Aquí está la comparativa de un firmware "normal" (ya lleva la mejora del CRC32) usando zlib con rtime (algoritmo para volver a comprimir los datos ya comprimidos), contra el algoritmo LZO y LZO + rtime, que tiene exactamente los mismos archivos en /rw-flash que es donde se monta nuestro JFFS2.
Tamaño de la imagen del kernel
normal: 635.110 Bytes
lzo: 628.175 Bytes
lzo+rtime: 628.591 Bytes
Primer punto positivo para LZO, porque tenemos un kernel más pequeño y el arranque será ligeramente más rápido (milisegundos) y usará menos memoria.
La diferencia entre LZO y LZO junto al compresor rtime es mínima.
Compresión de los datos
# df -h | grep rw-flash
Size Used Available Use%
normal: 5.8M 768.0K 5.0M 13%
lzo: 5.8M 828.0K 4.9M 14%
lzo+rtime: 5.8M 732.0K 5.0M 12%
Como era de esperar lzo es el que menos compresión ofrece, pero sorprendentemente lzo junto a rtime consiguen la mayor compresión posible.
Estos resultados podrían variar según los datos (plugins, logos, ...) que tengamos en /etc.
Memoria RAM usada
# free (la media de ejecutarlo después de 2 arranques)
total used free shared buffers
normal: 45868 21844 24024 0 3396
lzo: 45888 21248 24640 0 3360
lzo+rtime: 45888 18630 27258 0 3134
El ganador con diferencia vuelve a ser lzo+rtime y podemos ver que curiosamente con LZO tenemos 20 Bytes más de memoria total .
Velocidad de lectura
# io-test -s 2 /rw-flash/test.txt (la media de ejecutarlo 4 veces)
normal: 10,35 MiB/s
lzo: 11,9675 MiB/s
lzo+rtime: 11,945 MiB/s
El aumento de lectura con lzo es bastante considerable y prácticamente igual entre lzo y lzo+rtime (un poco menor porque los datos están más comprimidos).
Velocidad de escritura
# io-test -s 2 /rw-flash/test.txt (la media de ejecutarlo 4 veces)
normal: 44,4075 KiB/s
lzo: 57,6975 KiB/s
lzo+rtime: 58,3675 KiB/s
Aparentemente la ganancia en escritura es muy poca, pero mirando el porcentaje con lzo+rtime es un 31% más rápido (más de la cuarta parte).
Comparando el porcentaje entre lzo+rtime y lzo la ganancia es de un 1,16% ya que tiene que escribir menos datos porque están más comprimidos.
Conclusión
Los números hablan por sí solos y el ganador indiscutible es lzo con rtime.
El que quiera probarlo sólo tiene que compilar la última versión del SVN.
Todos los archivos que estén bajo /etc notarán la mejora, es decir, al leer archivos de configuración al arrancar y escribirlos al apagar, logos de canales, plugins externos, guardar la EPG, etc.
De momento, en el JFFS2 sólo se incluye el directorio "SI", por lo tanto no es necesario hacer un factory reset porque se hará automáticamente y en el primer arranque también se hará una limpieza de todo el JFFS2, por lo que le costará un poco más.
Ya diréis que tal os funciona.
Re: Mejoras importantes en el JFFS2
Acabo de compilarlo. A ver si mañana puedo instalar y daré mis impresiones por aqui.
Muchísimas gracias de antemano.
Muchísimas gracias de antemano.
Re: Mejoras importantes en el JFFS2
Lo estoy probando ahora mismo
25 segundos exactos desde apagado total para ver la imagen (muy bien)
Y lo que si que noto es que al entrar en los menús, la epg, etc... es más fluido, como menos "espeso"
Parece mentira como este "cacharro" que tiene una cpu 3 veces más lenta que mi movil, puede dar de si.
25 segundos exactos desde apagado total para ver la imagen (muy bien)
Y lo que si que noto es que al entrar en los menús, la epg, etc... es más fluido, como menos "espeso"
Parece mentira como este "cacharro" que tiene una cpu 3 veces más lenta que mi movil, puede dar de si.
yeahhh- Betatester
- Cantidad de envíos : 2260
Fecha de inscripción : 18/08/2008
Edad : 46
Localización : Barcelona
Re: Mejoras importantes en el JFFS2
En la subversión 825 había que modificar el .config En esta parece que no es necesari ¿es correcta mi deducción?
telete- Cantidad de envíos : 137
Fecha de inscripción : 23/09/2008
Localización : Zaragoza
Re: Mejoras importantes en el JFFS2
Es correcto, primero añadí el soporte para poder generar firmwares con el JFFS2 incluido y por defecto estaba desactivado porque no aportaba ninguna mejora de rendimiento, sólo hacía el "auto-factory reset" al tener el directorio "SI".
Ahora ya está activado para generar una imagen JFFS2 con lzo + rtime por defecto, que es el que más rendimiento da y más comprime.
Ahora ya está activado para generar una imagen JFFS2 con lzo + rtime por defecto, que es el que más rendimiento da y más comprime.
Re: Mejoras importantes en el JFFS2
Lo tengo instalado desde ayer y estoy con yeahhh, el arranque es más rápido desde el apagado total y los menús van mejor (aunque antes tampoco iban nada mal). No he tenido tiempo de probar mucho pero por el momento estupendo trabajo bittor.
Muchísimas gracias.
Muchísimas gracias.
Temas similares
» Mejoras en la comprobación de discos
» Mejoras arranque Mediatomb
» Mejoras a la cola de recortes de grabaciones
» Mejoras en los sistemas de archivos (sistema y disco duro usb)
» Mejoras a activar en kernel para soporte de discos con GPT en lugar de MBR
» Mejoras arranque Mediatomb
» Mejoras a la cola de recortes de grabaciones
» Mejoras en los sistemas de archivos (sistema y disco duro usb)
» Mejoras a activar en kernel para soporte de discos con GPT en lugar de MBR
Página 1 de 1.
Permisos de este foro:
No puedes responder a temas en este foro.