He estado haciendo algunas pruebas y tus resultados me parecen bastante "poco fiables".
Aquí están los míos:
Tamaño de las ISOs sin comprimir
En Bytes:
683642880 MandrakeLinux-9.2-17-Download-1.i586.iso
731797504 MandrakeLinux-9.2-18-Download-2.i586.iso
728948736 MandrakeLinux-9.2-19-Download-3.i586.iso
Total: 2144389120
En MBytes:
652M MandrakeLinux-9.2-17-Download-1.i586.iso
698M MandrakeLinux-9.2-18-Download-2.i586.iso
696M MandrakeLinux-9.2-19-Download-3.i586.iso
Tamaño de las ISOs comprimidas:
en Bytes:
622589872 MandrakeLinux-9.2-17-Download-1.i586.iso.bz2
719190869 MandrakeLinux-9.2-18-Download-2.i586.iso.bz2
714772893 MandrakeLinux-9.2-19-Download-3.i586.iso.bz2
CD 1:
$ time bzip2 MandrakeLinux-9.2-17-Download-1.i586.iso
11 minutos y 49 segundos, usando el 91% CPU
$ time gzip MandrakeLinux-9.2-17-Download-1.i586.iso
1 minuto 35 segundos, usando el 66% de CPU
CD 2:
$ time bzip2 MandrakeLinux-9.2-18-Download-2.i586.iso
12 minutos y 56 segundos, usando el 92% de CPU
$ time gzip MandrakeLinux-9.2-18-Download-2.i586.iso
1 minuto y 45 segundos, usando el 64% de CPU
CD 3:
$ time bzip2 MandrakeLinux-9.2-19-Download-3.i586.iso
12 minutos y 18 segundos, usando el 94% de CPU
$ time gzip MandrakeLinux-9.2-19-Download-3.i586.iso
1 minuto y 44 segundos, usando el 65% de CPU
Descomprimir:
CD 1:
$ time bunzip2 MandrakeLinux-9.2-17-Download-1.i586.iso.bz2
3 minutos y 3 segundos, usando el 81% de CPU
$ time gunzip MandrakeLinux-9.2-17-Download-1.i586.iso.gz
1 minuto y 1 segundo, usando el 18% de CPU
CD 2:
$ time bunzip2 MandrakeLinux-9.2-18-Download-2.i586.iso.bz2
3 minutos y 22 segundos, usando el 82% de CPU
$ time gunzip MandrakeLinux-9.2-18-Download-2.i586.iso.gz
1 minuto y 3 segundos, usando el 18% de CPU
CD 3:
$ time bunzip2 MandrakeLinux-9.2-19-Download-3.i586.iso.bz2
3 minutos y 18 segundos, usando el 83% de CPU
$ time gunzip MandrakeLinux-9.2-19-Download-3.i586.iso.gz
1 minuto y 05 segundos, usando el 17% de CPU
Datos de referencia:
S.O.: Mandrake 9.2, actualizado
Versión bzip2: bzip2-1.0.2-16mdk
Versión gzip: gzip-1.2.4a-12mdk
Procesador: AMD Athlon 1.8+ (overclockeado, corriendo a 1920 Mhz)
Memoria RAM: 256 MB RAM
HD: IBM DESKSTAR 60 GB IC35L060AVVA07-0 ATA100 7200rpm
Como ves, las diferencias con los datos que tú expones son evidentes. Aún así no son concluyentes, deberían hacerse varias veces y en batería, etc... Pero creo que son bastante representativos.
Es difícil comprimir más los RPMs de Mandrake, porque ya vienen bastante comprimidos. Si no me equivoco el RPM de Mandrake usa precisamente bzip2. Como muestra un botón:
$ du -b libkdecore4-3.1.3-35mdk.i586.rpm
6738341 libkdecore4-3.1.3-35mdk.i586.rpm
$ du -b libkdecore4-3.1.3-35mdk.i586.rpm.bz2
6651674 libkdecore4-3.1.3-35mdk.i586.rpm.bz2
Pues eso, algunos detalles de los que me he dado cuenta luego.
El nivel predeterminado de gzip es 6, y es el que he usado.
El nivel predeterminado de bzip2 es 9, y es el usado.
Cuando hablo del total, simplemente sumo el tamaño total de las imágenes ISO sin comprimir por separado y luego el total de las comprimidas, cada una por separado también. Si primero hiciera un tar de las 3 imágenes ISO y luego se comprimieran el tamaño se reduciría un poco más (teóricamente).
Los resultados parecen ser homogéneos. He probado con una imagen ISO de Debian y el comportamiento es similar, obteniéndose un 5% de reducción al usar gzip.
Respecto a porqué comprime más gzip que bzip2, he de suponer que es porque el contenido de las ISOs ya está comprimido previamente con bzip2. En general al comprimir datos (por ejemplo los fuentes normales de un programa cualquiera, que son texto mayoritariamente) se observa el comportamiento esperado: bzip2 comprime alrededor de un 20% más que gzip. Si alguien fuera tan amable de explicarnos este "comportamiento anómalo"... :)
En realidad me preocupan los tiempos y las cargas de CPU, a eso me refiero cuando hablo de repetirlos, a medir esos parámetros... Sé que el tamaño no va a variar.
Yo es que no soy partidario de comprimir las ISOs en el servidor. Llevo un mirror de algunas distribuciones y la posibilidad de montar las isos para proporcionar acceso tanto a la iso en sí, como al contenido, y sólo ocupar espacio una vez me parece muy atractiva. Con eso en mente tener imágenes comprimidas no es viable.
Si la compresión la realiza el servidor al vuelo, se carga la CPU del servidor, y tampoco me parece viable.
Además otro motivo para no querer isos comprimidas es que al descargar necesitas descomprimir, por lo tanto en algún momento necesitas tener ocupado el doble de espacio en local... Ya no es mucho, tener 650 o 700 megas libres, pero no siempre es posible.
A ver repito:
Las ISOS se comprimen poco porque los RPMs que contiene ya vienen comprimidos... No sé qué tipo de compresiones estaréis haciendo, pero vamos, que evidentemente en esto, como en toda comprobación "científica" los resultados tienen que ser repetibles.
Yo no digo que lo mío sea una verdad absoluta, pero me parecen resultados razonables y homogéneos, y lo que no es razonable es que se comprima en más de un 90% una imagen ISO llena de RPMs con datos binarios ya comprimidos...
Mis datos
(Puntos:5, Informativo)( http://blogdrake.org/ | Última bitácora: Jueves, 23 Septiembre de 2004, 00:26h )
Aquí están los míos:
Como ves, las diferencias con los datos que tú expones son evidentes. Aún así no son concluyentes, deberían hacerse varias veces y en batería, etc... Pero creo que son bastante representativos.
Es difícil comprimir más los RPMs de Mandrake, porque ya vienen bastante comprimidos. Si no me equivoco el RPM de Mandrake usa precisamente bzip2. Como muestra un botón:
Blogdrake [blogdrake.net]
Algunas puntualizaciones
(Puntos:2)( http://blogdrake.org/ | Última bitácora: Jueves, 23 Septiembre de 2004, 00:26h )
- El nivel predeterminado de gzip es 6, y es el que he usado.
- El nivel predeterminado de bzip2 es 9, y es el usado.
- Cuando hablo del total, simplemente sumo el tamaño total de las imágenes ISO sin comprimir por separado y luego el total de las comprimidas, cada una por separado también. Si primero hiciera un tar de las 3 imágenes ISO y luego se comprimieran el tamaño se reduciría un poco más (teóricamente).
- Los resultados parecen ser homogéneos. He probado con una imagen ISO de Debian y el comportamiento es similar, obteniéndose un 5% de reducción al usar gzip.
Respecto a porqué comprime más gzip que bzip2, he de suponer que es porque el contenido de las ISOs ya está comprimido previamente con bzip2. En general al comprimir datos (por ejemplo los fuentes normales de un programa cualquiera, que son texto mayoritariamente) se observa el comportamiento esperado: bzip2 comprime alrededor de un 20% más que gzip. Si alguien fuera tan amable de explicarnos este "comportamiento anómalo"... :)Blogdrake [blogdrake.net]
Me refería a los tiempos :)
(Puntos:2)( http://blogdrake.org/ | Última bitácora: Jueves, 23 Septiembre de 2004, 00:26h )
Yo es que no soy partidario de comprimir las ISOs en el servidor. Llevo un mirror de algunas distribuciones y la posibilidad de montar las isos para proporcionar acceso tanto a la iso en sí, como al contenido, y sólo ocupar espacio una vez me parece muy atractiva. Con eso en mente tener imágenes comprimidas no es viable.
Si la compresión la realiza el servidor al vuelo, se carga la CPU del servidor, y tampoco me parece viable.
Además otro motivo para no querer isos comprimidas es que al descargar necesitas descomprimir, por lo tanto en algún momento necesitas tener ocupado el doble de espacio en local... Ya no es mucho, tener 650 o 700 megas libres, pero no siempre es posible.
Blogdrake [blogdrake.net]
Lo que no es normal es lo otro
(Puntos:2)( http://blogdrake.org/ | Última bitácora: Jueves, 23 Septiembre de 2004, 00:26h )
Yo no digo que lo mío sea una verdad absoluta, pero me parecen resultados razonables y homogéneos, y lo que no es razonable es que se comprima en más de un 90% una imagen ISO llena de RPMs con datos binarios ya comprimidos...
Blogdrake [blogdrake.net]