Experimentos y Código Fuente para el BASIC Stamp Versión en ...
E. Código fuente del benchmark
-
Upload
trinhduong -
Category
Documents
-
view
229 -
download
0
Transcript of E. Código fuente del benchmark
Universitat Politecnica
de Catalunya
Facultat d’Informatica de Barcelona
Benchmark para PCs con
pocos recursos
Autor:Alexandre Ramırez Gomez
Director:Carlos Alvarez Martınez
Co-director:Xavier Martorell Bofill
13 de junio de 2013
Indice general
1. Introduccion 41.1. Planteamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.2. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2. Diagramas de flujo . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3. Benchmarks globales . . . . . . . . . . . . . . . . . . . . . . . 61.2.4. Benchmarks especıficos . . . . . . . . . . . . . . . . . . . . . . 61.2.5. Colecciones de tests . . . . . . . . . . . . . . . . . . . . . . . . 61.2.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Analisis de requisitos y planificacion 82.1. Marco legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. Modalidades del benchmark . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Modalidad clasica . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Modalidad basada en estimacion . . . . . . . . . . . . . . . . 92.2.3. Modalidad basada en la estimacion de una distribucion live . . 92.2.4. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Planificacion temporal . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1. Coste de software y hardware . . . . . . . . . . . . . . . . . . 142.5.2. Coste espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5.3. Coste de recursos humanos . . . . . . . . . . . . . . . . . . . . 152.5.4. Coste total . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1
3. Especificacion y diseno 183.1. Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2. Version preliminar del benchmark . . . . . . . . . . . . . . . . . . . . 19
3.2.1. Mediciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2. Puntos a mejorar . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Version final del benchmark . . . . . . . . . . . . . . . . . . . . . . . 233.4. Modalidad basada en estimacion . . . . . . . . . . . . . . . . . . . . . 243.5. Modalidad basada en la estimacion de una distribucion live . . . . . . 25
3.5.1. ¿Medir o estimar? . . . . . . . . . . . . . . . . . . . . . . . . . 263.5.2. La distribucion live . . . . . . . . . . . . . . . . . . . . . . . . 273.5.3. Estimando en base al hardware . . . . . . . . . . . . . . . . . 28
3.6. Experimentacion con un Pocket PC . . . . . . . . . . . . . . . . . . . 30
4. Implementacion, pruebas y resultados 314.1. Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2. Analisis de las distribuciones . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1. Seleccion de distribuciones candidatas . . . . . . . . . . . . . . 324.2.2. Analisis de funcionalidades . . . . . . . . . . . . . . . . . . . . 35
4.3. Analisis de los PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.1. PCs de TxT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.2. Pruebas de rendimiento preliminares . . . . . . . . . . . . . . 38
4.4. Criba de distribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5. Pruebas de rendimiento en PCs de TxT . . . . . . . . . . . . . . . . . 40
4.5.1. Resultados y reporte de incidencias . . . . . . . . . . . . . . . 404.5.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5.3. Interpretacion de los resultados . . . . . . . . . . . . . . . . . 42
4.6. Realizando estimaciones . . . . . . . . . . . . . . . . . . . . . . . . . 434.7. Comparativa de modalidades del benchmark . . . . . . . . . . . . . . 444.8. Experimentacion con un Pocket PC . . . . . . . . . . . . . . . . . . . 47
5. Conclusiones 495.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.1. Comportamientos anomalos . . . . . . . . . . . . . . . . . . . 505.2.2. Anadir atributos a medir al benchmark . . . . . . . . . . . . . 505.2.3. Actualizar y expandir la lista de distribuciones . . . . . . . . . 515.2.4. Mejorar la estadıstica . . . . . . . . . . . . . . . . . . . . . . . 515.2.5. Probar distintos Pocket PC . . . . . . . . . . . . . . . . . . . 51
2
A. Resultados de la encuesta 53
B. Programas por distribucion 56
C. Funcionalidades por programa 59
D. Funcionalidades por distribucion 63
E. Codigo fuente del benchmark (version 1) 67E.1. run.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67E.2. benchmark.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72E.3. statistics.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
F. Pruebas de rendimiento en PCs de TxT 81F.1. PC A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81F.2. PC B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82F.3. PC C (Core 2 Duo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
G. Codigo fuente del benchmark (version 2) 84G.1. memory disk discard . . . . . . . . . . . . . . . . . . . . . . . . . . 85G.2. estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
H. Estimaciones en base a la distribucion live 88
I. Ecuaciones para estimar el rendimiento 94I.1. Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94I.2. Slackware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95I.3. Linux Mint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
J. Codigo fuente del benchmark (version 3) 97J.1. run.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97J.2. benchmark.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99J.3. estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
K. Funcionalidades de Raspbian 105
Bibliografıa 109
3
Capıtulo 1
Introduccion
1.1. Planteamiento
1.1.1. Objetivo
El objetivo de este proyecto es disenar e implementar un sistema capaz de de-terminar la distribucion de Linux adecuada para un PC (mas concretamente, un PCcon pocos recursos). Se tendran en cuenta tanto aspectos de funcionalidad como derendimiento. Para esto ultimo sera necesario crear un benchmark que mida el rendi-miento de distintas distribuciones de Linux para poder decidir con que distribucionse aprovecha mejor el escaso potencial de la maquina. Se estudiaran distintas moda-lidades de benchmark con distintos equilibrios entre tiempo de ejecucion y precisionde las mediciones. Luego se analizaran y se compararan entre ellas. Se usaran losPCs de la asociacion Tecnologies per Tothom (de ahora en adelante, TxT) a modode aplicacion real.
1.1.2. Motivacion
La idea surge tras haber participado en una actividad organizada por TxT en laque se instalaba el sistema operativo a ordenadores donados, normalmente con pocosrecursos. El sistema operativo en cuestion era la ultima version de Ubuntu. Se havisto que Ubuntu no es la mejor distribucion para este tipo de sistemas. En cambio,con distribuciones mas ligeras especialmente disenadas para este cometido se puedenobtener buenos resultados.
Creo que los PCs de TxT (y los PCs con pocos recursos en general) podrıantambien beneficiarse de las ventajas que ofrecen estas distribuciones, pero es necesario
4
escoger la mas adecuada con tal de aprovechar al maximo el potencial de la maquina.Para ello es necesario poder calcular de manera cuantitativa el rendimiento de cadadistribucion; es decir, se necesita un benchmark.
Ademas, este benchmark tambien podrıa usarse en sistemas del estilo PocketPC (p. ej., Raspberry Pi), ya que a efectos practicos son PCs con pocos recursos.Actualmente el uso de este tipo de maquinas esta aumentando notablemente, yaque ofrecen una solucion barata y pequena para tareas que no requieran una grancapacidad de computo o unas prestaciones fuera de lo comun. Con este benchmark sepodran comparar este tipo de sistemas con PCs antiguos y ver si realmente suponenuna alternativa viable.
1.2. Estado del arte
1.2.1. Contexto
A la hora de aprovechar un PC con pocos recursos es importante elegir bienque software se instalara con tal de sacar el maximo provecho a nuestro limitadohardware. Actualmente el sistema operativo para los ordenadores de TxT es elegidode manera informal, sin tener en cuenta muchas alternativas y sin una base obje-tiva. Es mi proposito demostrar que esta eleccion afecta de manera considerable alrendimiento del sistema y que se podrıa mejorar haciendola con mas mesura.
La solucion al problema tendra que tener en cuenta tanto aspectos de rendimientocomo de funcionalidad para poder decidir de manera objetiva cual es la mas adecuadapara una determinada maquina.
1.2.2. Diagramas de flujo
Actualmente no existe ningun software que ayude a escoger una distribucion deLinux, mas alla de los tıpicos diagramas de flujo [1]. Si bien estos diagramas tienen laventaja de ser sencillos y no requerir ningun software ni hardware especıfico (porqueno son programas, son diagramas), tienen la desventaja de que su granularidad esmuy gruesa y solo distinguen entre “PC moderno” y “PC antiguo” como mucho,sin tener en cuenta el rendimiento de la maquina. Ademas tampoco tiene en cuentafuncionalidades especıficas, sino que hacen distinciones como “PC de escritorio” o“Servidor”.
5
1.2.3. Benchmarks globales
En la actualidad existen pocos benchmarks para Linux que midan el rendimientode todo el sistema, y los que hay se encuentran desfasados.
Unixbench es probablemente el mas conocido. Aunque fue creado en 1983, haido siendo actualizado y hoy en dıa se sigue usando [3]. El principal defecto de estebenchmark es que mide resultados simulando casos de uso extremos que no coincidencon el perfil de uso que normalmente se le da a un PC.
Otro conocido benchmark es HINT (Hierarchical INTegration) [4]. Se caracte-riza por su buen balance en la ponderacion de los distintos aspectos del sistema.Sin embargo, este benchmark devuelve como resultado un solo valor, que intentaser una medicion de la “calidad” del sistema. Actualmente se desaconseja este com-portamiento y se prefiere que se midan los distintos componentes del sistema porseparado.
1.2.4. Benchmarks especıficos
Existen, por otro lado, benchmarks para medir el rendimiento de un solo aspectoespecıfico del sistema o incluso una tarea concreta. Los benchmarks globales suelenser suites de benchmarks especıficos debidamente ponderados.
Los mas comunes son los benchmarks que miden la potencia de computacion(CPU, FPU y memoria). Estos consisten en hacer calculos que sean CPU-intensivos(como calcular dıgitos de Pi, por ejemplo). Quizas el mas comun de este tipo seanbench [5] (un port a Linux de BYTEmark 2, anteriormente conocido como BYTE’sNative Mode Benchmarks [6]).
No obstante, tambien existen benchmarks dedicados a medir el rendimiento deotras partes del sistema, como IOzone [8] (dedicado a medir el rendimiento de lossistema de ficheros y dispositivos de almacenamiento) o netperf (para medir el ren-dimiento de la conexion de red).
Incluso hay benchmarks dedicados a tareas tan especıficas como medir el rendi-miento de distintos temas y configuraciones de GTK+ (gtkperf [7]).
1.2.5. Colecciones de tests
Finalmente, tambien existen colecciones de tests no relacionados entre sı paraque el usuario elija los tests que desea realizar y pueda crear su propio benchmarkglobal a partir de varios tests especıficos. En este achapterado destaca Phoronix TestSuite [10]. Es una coleccion de tests bastance reciente (creada en 2008) y amplia(contiene mas de 60 tests). Ademas ofrece la posibilidad de compartir resultados
6
a traves del servicio OpenBenchmarking http://www.openbenchmarking.org. Esuna de las plataformas de benchmarking mas usadas, tanto a nivel domestico comoprofesional. Sus mayores crıticas son que el compilador y la configuracion que seusen para compilar los tests pueden afectar a los resultados de los mismos y que lascomparaciones entre sistemas dispares no son del todo fiables.
1.2.6. Conclusiones
Si bien alguno de estos benchmarks podrıa servir para medir el rendimiento delos PCs que se trataran en este TFG, recordemos que el proposito final es elegirun sistema operativo. Ademas del benchmarking convencional, en este trabajo seestudiara la posibilidad de crear un benchmark en una distribucion live que estime elrendimiento de las demas distribuciones sin necesidad de instalarlas realmente todas.Esta es una funcionalidad muy dependiente de la situacion a tratar, por lo cual esalgo que no pueden ofrecer los benchmarks anteriores. Es por esto que es necesariocrear un nuevo benchmark.
7
Capıtulo 2
Analisis de requisitos yplanificacion
2.1. Marco legal
Pese a que los sistemas operativos de la familia Windows son los mas utilizadosen el ambito de la informatica de escritorio, los PCs que trataremos no los podemosdistribuir con estos, ya que Windows se distribuye bajo una licencia de pago [2]que TxT no se puede permitir y que, ademas, prohıbe su redistribucion. Por estosmotivos la distribucion de PCs con sistema operativo Windows queda descartada.
Necesitamos, pues, un sistema operativo gratuito y que nos ofrezca libertad deredistribucion. Con estas caracterısticas, GNU/Linux se presenta como la alternativamas popular. Linux es ampliamente usado en sistemas de escritorio, tanto en elambito personal como en el profesional.
Aunque las condiciones y licencias pueden variar entre distribuciones, la mayorıade ellas se ofrecen de manera gratuita y libre. El grado de libertad es variable,dependiendo de la distribucion, pero la mayorıa cumple con creces los requisitos queTxT impone para poder ser instalado y distribuido con sus PCs.
2.2. Modalidades del benchmark
2.2.1. Modalidad clasica
Un benchmark por si mismo consiste en una coleccion de pruebas que determinanel rendimiento de una maquina (o de algun aspecto en concreto). Mi intencion espoder decir para cada PC que distribucion es mejor, ası que el procedimiento serıa:
8
instalar una distribucion, medir su rendimiento, repetir con el resto de distribucionesy comparar los resultados. Esta serıa la modalidad clasica del benchmark. Comoesto puede llevar mucho tiempo (ademas de resultar tedioso) se contemplaran 2modalidades alternativas.
2.2.2. Modalidad basada en estimacion
La primera consistira en instalar una distribucion y medirla tal y como se hace enla modalidad clasica, pero en lugar de repetir el procedimiento con todas las demasdistribuciones, simplemente se estimara su rendimiento en base a los resultados delas mediciones realizadas en la distribucion instalada. De esta forma nos ahorramostener que instalar y medir todas las distribuciones. No obstante, el precio a pagarpor este ahorro de tiempo es la posible inexactitud de las estimaciones.
2.2.3. Modalidad basada en la estimacion de una distribu-cion live
Para acabar de optimizar el tiempo, se creara una tercera modalidad similara la anterior, pero que basara las estimaciones en mediciones realizadas con unadistribucion live muy liviana creada expresamente para este cometido. Con estamodalidad llevamos al extremo las ventajas y los inconvenientes de la modalidadanterior: el proceso sera mucho mas rapido, ya que no habra que instalar ningunadistribucion, pero los resultados pueden no ser precisos debido a la inexactitud delas estimaciones y a la variabilidad del medio donde se encuentre la distribucion live(CD, DVD, USB...).
2.2.4. Comparativa
Una vez acabadas las tres modalidades, se compararan para ver cual es la mejor.Se tratara de alcanzar un equilibrio entre el tiempo necesario para realizar las pruebasy la precision de los resultados.
2.3. Metodologıa
En primer lugar, necesitamos conocer las necesidades funcionales de los ususariospara poder seleccionar unas distribuciones adecuadas. Para ello se realizara una en-cuesta en la que se consultara a los usuarios sobre que funcionalidades necesitan en
9
un PC. Con los resultados de esta encuesta podremos saber que grado de funcionali-dad alcanzan distintas distribuciones y, por tanto, si son adecuadas para instalarlasen nuestros PCs.
Una vez tengamos la funcionalidad de cada distribucion nos interesa conocer surendimiento. Para esto habra que crear un benchmark. Como ya se ha explicado enel apartado anterior, se implementaran 3 versiones con distintos niveles de equilibrioentre tiempo de ejecucion y precision.
Con los datos de rendimiento obtenidos con el benchmark y los de funcionalidadobtenidos con la encuesta ya estaremos en disposicion de decidir que distribucion esla mas adecuada en cada maquina.
Finalmente, se usara este mismo sistema para medir el rendimiento y las funcio-nalidades de un Pocket PC para comprobar hasta que punto podrıa sustituir un PCde sobremesa.
2.4. Planificacion temporal
Ha habido diferencias en la planificacion con respecto a la inicial. En la previsioninicial, se seleccionaba un conjunto de distribuciones iniciales, se usaban los resul-tados de la encuesta para hacer una criba y luego se creaba el benchmark en sutotalidad. En lugar de eso, tras hacer la encuesta se empezo a crear el benchmarky se hizo una primera version. Con esa primera version del benchmark se evaluo elrendimiento de todas las distribuciones iniciales y, con los resultados de la encuestay los del benchmark se realizo la criba. Esto, por una parte, ofrece mas feedback a lahora de crear el benchmark, ya que se puede probar un prototipo, pero por otra par-te, al tener que hacer mediciones sobre todas las distribuciones iniciales, el trabajose ha alargado una semana. Ademas, las tareas de “Finalizacion del benchmark” y“Definir metodos de estimacion” han tomado mas tiempo del previsto, debido a sucomplejidad, con lo que, a pesar de planificar una holgura al final del trabajo, huboque reducir el tiempo de las tareas finales. La planificacion queda entonces tal queası:
1. Realizar una encuesta: Esta fue la primera tarea del trabajo. Consistio enconfeccionar una encuesta para saber que funcionalidades necesitan los usuariosen varios tipos de programas (p. ej., procesador de textos con compatibilidadcon Microsoft Office 2010) y distribuirla. Su duracion fue de una semana, co-menzando el dıa 18 de Febrero. Los unicos recursos que se usaron fueron miPC personal y la suite de Google Drive para crear la encuesta y recopilar lasrespuestas.
10
2. Seleccionar distribuciones iniciales: Mientras la encuesta esta activa seaprovechara para seleccionar las distribuciones iniciales. Esta tarea duro unasemana: empezo tras distribuir la encuesta y acabo al cerrarse la misma. Paraesta tarea, ademas, se usaron datos de la pagina web DistroWatch (http://www.distrowatch.com).
3. Analizar resultados de la encuesta: Una semana despues de distribuir laencuesta esta se cerro y ya no admite mas respuestas. Entonces se analizaronlos resultados y se usaron para decidir que distribuciones pasarıan la criba masadelante. La duracion de esta tarea fue de 3 dıas y, al igual que la tarea anterior,solo requise de mi PC y Google Drive para llevarla a cabo.
4. Preparar medios de instalacion: Una vez elegidas las distribuciones candi-datas, se crearan y grabaran las imagenes de las distribuciones en CDs y DVDs,ya que los PCs probablemente no dispongan de arranque desde USB. Esta ta-rea tomo apenas 1 dıa. Use mi PC (con grabador de CD y DVD), conexiona Internet para descargar las imagenes y unos CDs y DVDs vırgenes, tantoscomo distribuciones iniciales.
5. Crear primera version del benchmark : Tras ultimar los preparativos pro-cedı a disenar e implementar una primera version del benchmark. Esto im-plico decidir que parametros medir y como hacerlo. Esto llevo 2 semanas.Use un PC propio similar a los menos potentes que hay en TxT para hacerpruebas, los CDs y DVDs de la tarea anterior y, como el benchmark medira laeficiencia de la red, use la conexion a Internet de mi casa.
6. Evaluar el rendimiento de las distribuciones iniciales: Con la primeraversion del benchmark acabada instale cada una de las distribuciones en elmismo PC de la tarea anterior y medı su rendimiento. Debido al alto numerode distribuciones esta tarea llevo toda una semana. Los recursos usados fueronlos mismos que en la tarea anterior.
7. Analizar resultados del benchmark : Una vez obtenidos los resultados derendimiento, pude al fin realizar una criba sobre las distribuciones iniciales.Ademas, con la experiencia obtenida al crear y probar la primera version delbenchmark pude ver que aspectos hay que corregir de cara a la version final.
11
8. Finalizacion del benchmark : Tomando el esbozo de benchmark como basey los resultados de las pruebas como guıa finalizare el benchmakr corrigiendolos errores detectados en las tareas anteriores. Se usaran los mismos recursospara realizar pruebas, aunque esta vez se haran solo sobre las distribucionescandidatas (las que hayan pasado la criba). Esta tarea es una de las claves deltrabajo, y llevo mas tiempo del esperado.
9. Segunda version del benchmark : Crear la segunda modalidad del bench-mark resulto relativamente sencillo, comparado con la modalidad clasica (estatarea tiene una duracion de 10 dıas, frente a los mas de 40 de la creacion delbenchmark clasico). Se implemento de tal manera que se pudo aprovechar elcodigo generado en la tarea anterior.
10. Definir metodos de estimacion: A parte de la creacion del benchmark (ta-reas 5 a 8), el otro gran desafıo del trabajo sera definir como se calcularanlas estimaciones a partir de los valores medidos en la modalidad de benchmarkpor estimacion basado en una distribucion live. Esta tarea llevo poco mas de2 semanas. Dado que es una tarea de diseno de benchmark, los recursos queusare seran los mismos que en la tarea anterior: mi PC personal y mi PC deprueba.
11. Crear distribucion live del benchmark por estimacion: Para poder usarla modalidad de benchmark basada en estimacion tomando como referencia unadistribucion live liviana, primero hay que crear dicha distribucion, con todo elsoftware necesario, y grabarla en un CD. Esta tarea llevo mucho menos delo previsto. En tan solo 1 dıa se pudo completar. Esto fue debido a haberencontrado un programa muy sencillo de usar que se ajustaba perfectamente alas necesidades de la tarea. Los requisitos fueron los mismos que en la tarea 4:mi PC, con grabador de CDs, y un CD virgen.
12. Comparar modalidades del benchmark : Tras implementar las 3 modali-dades del benchmark, se analizaron y se decidio cual se usara en las mediciones.Inicialmente esta tarea iba a ser mas larga, pero debido a las modificacionesen la planificacion tubo que hacerse en solo 2 dıas. Para esta tarea fueronnecesarios los PCs de TxT.
Durante todo el proceso del trabajo se realizara la memoria en paralelo, docu-mentando cada tarea al tiempo que se hace.
Durante la creacion de la primera modalidad del benchmark (tareas 5 a 8), ademasde realizar las mediciones sobre las distribuciones candidatas tambien se realizaronsobre Raspbian (en la Raspberry Pi).
12
2.5. Presupuesto
2.5.1. Coste de software y hardware
En sistemas antiguos como los que se trataran en este trabajo es habitual que elarranque desde USB no este disponible, ası que para no tener que extraer los discosduros y volverlos a instalar, se usara el arranque desde la unidad de CD/DVD. Porello se requeriran CDs y DVDs en los que grabar las imagenes de las distribuciones aevaluar y la distribucion live para el benchmark basado en estimacion. Finalmente sehan seleccionado mas distribuciones de las previstas, ası que el numero de CDs/DVDsnecesarios ha aumentado con respecto a lo inicialmente planeado. Afortunadamenteestos son baratos y el aumento en el precio no es demasiado importante.
Los PCs sobre los que se efectuaran las pruebas seran prestados por TxT, ası queno suponen coste alguno. Para poder trabajar desde casa tambien se haran pruebasen PCs antiguos de los que dispongo, lo cual tampoco supone ningun coste.
Ademas, se necesitara un Raspberry Pi sobre el que efectuar mas pruebas. Final-mente se ha comprado un pack con placa, tarjeta SD y cable de alimentacion.
Todo el software que se use sera libre o, por lo menos, gratuito.Finalmente, tambien necesitare un PC con grabador de CDs y una conexion a
Internet. Ya dispongo de estos recursos, ası que no suponen ningun coste, mas alla delde amortizacion. En el caso de que no los pudiese usar, la facultad ofrece PCs enprestamo y acceso a Internet, tambien de manera gratuita.
Adicionalmente, se ha decidido comprar un medidor de consumo electrico paramedir la potencia que consumen los PCs con las distintas distribuciones.
Teniendo en cuenta la planificacion, los gastos quedarıan tal que ası:
Razon Coste Tiempo deamortizacion
Tiempode uso
Costeimputable
Software 0,00 e 3 anos 4 meses 0,00 ePC personal 1000,00 e 3 anos 4 meses 111,11 ePCs de pruebas 0,00 e 3 anos 4 meses 0,00 eRaspberry Pi 40,00 e 3 anos 4 meses 4,44 e7 CDs 2,00 e 2,00 e3 DVDs 2,00 e 2,00 eMedidor de con-sumo electrico
13,00 e 5 anos 4 meses 0,86 e
Total 120,41 e
14
2.5.2. Coste espacial
Ademas del coste del equipo, tambien hay que contar el coste del mantenimientodel almacen donde se guardan los PCs y donde se realiza el proyecto.
Cuando se realizo la proyeccion inicial todavıa no tenıa acceso al almacen encuestion y, por lo tanto, los costes que estimaron “a ciegas”, sin conocer realmentecomo es el local. Ahora que tengo acceso, puedo aproximar los costes mas fielmentea la realidad.
Razon Coste mensual Tiempode uso
Coste total
Agua 20,00 e/mes 4 meses 80,00 eLuz 50,00 e/mes 4 meses 200,00 eGas 50,00 e/mes 4 meses 200,00 e
Telefono e Internet 50,00 e/mes 4 meses 200,00 eTotal 680,00 e
Sin embargo, hay que tener en cuenta que el almacen no es de uso exclusivo parami proyecto, sino que se realiza trabajo diario en el. Por lo tanto los costes se deberanamortizar entre todo el trabajo que se haga en el. Supongamos que se reparta a partesiguales entre mi proyecto y el resto de trabajo que se realiza allı. Los costes quedanentonces reducidos a la mitad.
Razon Coste mensual Tiempode uso
Coste total
Agua 10,00 e/mes 4 meses 40,00 eLuz 25,00 e/mes 4 meses 100,00 eGas 25,00 e/mes 4 meses 100,00 e
Telefono e Internet 25,00 e/mes 4 meses 100,00 eTotal 340,00 e
2.5.3. Coste de recursos humanos
Por ultimo cabe anadir los costes del personal. Se considera que para la realizacionde este proyecto se requeriran 3 roles. Las siguientes tablas muestran las horas quese requieren de cada rol en cada tarea y su precio.
Estos datos han sufrido cambios respecto a los entregados en el hito intermediodebido a que la duracion de algunas tareas se ha considerado demasiado “hinchada”y a que algunas de las tareas finales se han visto reducidas.
15
Administrador de sistemas experto en atencion al usuario Persona conoce-dora de las necesidades de los usuarios, sus preferencias y sus habitos. Su prin-cipal cometido sera asegurar que las distribuciones que se selecciones sean delagrado de los usuarios y no nieguen funcionalidades basicas a costa del rendi-miento.
Administrador de sistemas experto en performance Responsable de la crea-cion del benchmark. Tiene profundos conocimientos de los parametros que masinfluyen en el rendimiento de un sistema. Es capaz de medirlos de maneraadecuada, aislandolos de otros parametros que pudieran alterar la medicion, einterpretar los resultados dentro de un contexto.
Administrador de sistemas experto en Linux Comprende los fundamentos delos sistemas operativos basados en Linux. Conoce las diferencias entre distintasdistribuciones y el impacto de estas en su funcionamiento y usabilidad. Sutarea consistira en contribuir a la seleccion de distribuciones inicial y crear ladistribucion live.
Tarea A. usuario A. performance A. LinuxRealizar encuesta e inter-pretar resultados
50 h 0 h 0 h
Seleccionar y preparardistribuciones iniciales
20 h 20 h 20 h
Creacion el benchmark 0 h 160 h 0 hPruebas y mediciones 0 h 120 h 0 hDefinir metodos de esti-macion
0 h 100 h 0 h
Comparar modalidadesde benchmark
0 h 10 h 0 h
Crear distribucion live 0 h 0 h 10 hTiempo total 70 h 410 h 30 h
Rol Tiempo Coste por hora Coste totalA. usuario 70 h 20,00 e/h 1400,00 eA. performance 410 h 24,00 e/h 9840,00 eA. Linux 30 h 22,00 e/h 660,00 e
Coste total de personal 11900,00 e
16
2.5.4. Coste total
Una vez detallados todos los costes, podemos ver el coste total que supone elproyecto.
Concepto CosteSoftware y hardware 120,41 eEspacial 340,00 eRecursos humanos 11900,00 eTotal 12360,41 e
17
Capıtulo 3
Especificacion y diseno
3.1. Encuesta
Tras finalizar GEP el primer punto es crear una encuesta que despues se pasara alos usuarios para conocer sus preferencias. En un principio la encuesta iba a ser mastecnica, y el usuario tenıa que elegir directamente el programa que prefiere para cadatipo de tarea. Por ejemplo:
Navegador
Chrome / Chromium
Epiphany
Firefox / Iceweasel
Konqueror
Midori
Opera
No obstante esto se descarto, ya que muy posiblemente los usuarios responderıanque aplicaciones usan y no cuales son las mas adecuadas. Ademas, opciones po-co conocidas quedarıan marginadas, independientemente de las funcionalidades queofreciesen.
Finalmente, la encuesta fue tal que el usuario debıa seleccionar las funcionalida-des que necesita de cada programa, en lugar de elegir los programas directamente.Por ejemplo, para el caso del navegador de Internet se ofrecıan las siguientes funcio-nalidades:
18
Navegador
Bloqueo de pop-ups sin necesidad de complementos
Bloqueo de publicidad sin necesidad de complementos
Control por voz
Gestos de raton
Conversion texto-a-voz (text-to-speech)
Incorpora su propio plugin de Flash
Lector de feeds RSS incorporado (sin necesidad de complementos ni herramien-tas externas)
Gestor de contrasenas (recordar contrasenas, contrasena maestra)
Y el usuario debıa marcar las funcionaliades que vea necesarias mediante un check-box. Al final de la encuesta se ofrecıa un espacio para anadir comentarios. Solo serecibieron 3 comentarios: uno especificaba que preferıa software libre antes que priva-tivo, otro preferıa interfaces sencillas pero customizables y el ultimo era un mensajede animo.
La encuesta completa puede encontrarse en el apendice A (junto con los resulta-dos, que se trataran mas adelante).
3.2. Version preliminar del benchmark
Como las modalidades del benchmark se basan cada una en la anterior, es im-portante que el inicio sea solido. Para asegurarnos de que la primera modalidad debenchmark es consistente, se realizo una version preliminar. Se realizaran pruebascon esta version para detectar posibles errores y poder corregirlos en la version final.
3.2.1. Mediciones
La version preliminar del benchmark consistio en las siguientes mediciones:
Disco El espacio que ocupa una instalacion por defecto de la distribucion en el disco,sin paquetes adicionales. Aunque la mayorıa de discos cumple con creces losrequisitos de todas las distribuciones que se evaluaran, en otros casos en los
19
que se trate con discos de poca capacidad este parametro puede resultar util.Un ejemplo es el caso de la Raspberry Pi, cuyo unico medio de almacenamientoes una tarjeta SD, que puede no ser muy grande.
En todos los casos se usara el formato ext4.
Memoria Cantidad de memoria RAM que consume la distribucion estando en re-poso (entiendase “reposo” como el PC encendido, pero sin realizar trabajo;no como un estado idle o de bajo consumo). Este parametro resulta particu-larmente decisivo en el rendimiento de una distribucion, ya que determina lacantidad de datos que ha de manejar el sistema solo para funcionar.
Incluye la memoria ocupada por buffers y cache. Si bien el sistema puede liberareste espacio para dedicarlo a aplicaciones del usuario, lo “natural” es que elsistema lo tome.
Tiempo de arranque El tiempo que tarda el sistema en arrancar, hasta que esusable. Es uno de los parametros que mas valora el usuario final. Puede verseinfluenciado por otros parametros como el disco y la memoria.
Este parametro se midio leyendo el archivo /etc/uptime.
Para que la medicion se hiciese tan pronto como el sistema acabe de iniciar,se uso la herramienta para configurar la ejecucion de aplicaciones al inicio, quevarıa segun la distribucion.
Tiempo de arranque de un programa lento El tiempo que tarda un programapesado desde el momento en que se manda ejecutar hasta que es usable porel usuario. Los usuarios sin conocimientos profundos de informatica tienden ausar este parametro como medida de rendimiento. Como los usuarios finales po-siblemente no sean informaticos, este es un parametro que resulta convenientevigilar.
Se eligio LibreOffice Writer (version 3.6.6) como ejemplo de “programa lento”,debido a que muy probablemente sea uno de los programas que mas usen losusuarios finales, y se ha medido el tiempo de abrir el programa, esperar hastaque sea usable y cerrarlo (de manera manual). De esta manera se pudo usar laherramienta time para medir el tiempo.
En las distribuciones que no incluıan LibreOffice se instalo desde los reposito-rios. En las que sı lo incluıan se actualizo tambien a traves de los repositoriosoficiales. En todos los casos se instalaron tambien el paquete de ayuda y el deidioma (espanol). En el caso de Puppy Linux se uso el script getLibreOffice,
20
que crea el paquete correspondiente a partir de los paquetes .deb oficiales. Enel caso de Slackware, se crearon los paquetes .tgz a partir de los .deb conla herramienta deb2tgz. En estos dos ultimos casos, hubo que crear soft-linkspara lowriter, ya que no se crean al instalar los paquetes.
Tiempo de apertura de un archivo grande con un programa lento Versionmas sofisticada del parametro anterior. Algunos programas pueden usar tecni-cas para parecer usable cuando en realidad solo lo son parcialmente, de maneraque cargan rapido, pero al interactuar con ellos se ralentizan. Midiendo esteparametro se fuerza al programa a trabajar desde el principio, con lo que dichastecnicas no funcionan.
La metodologıa para medir este parametro es similar a la del parametro ante-rior: se ha elegido LibreOffice, y se incluye el tiempo de cerrar el programa parapoder hacerlo con la herramienta time. Como “archivo grande” se ha genera-do un archivo de texto plano cuyo contenido son 1000000 (un millon) de ‘a’seguidas por un caracter de salto de lınea (‘\n’). En esta ocasion, en lugar desimplemente esperar a que el programa sea usable, se espero a que el recuentode paginas (que LibreOffice Writer muestra en la esquina inferior izquierda)llegase al valor correcto. De esta manera se asegura que el archivo se ha leıdocompletamente.
Velocidad de descarga Para comprobar la eficiencia de la gestion de la red sedescargara un archivo de gran tamano. este es precisamente el principal usoque se le da a la red, de manera que resulta un buen indicador del rendimientode la red.
Se uso un archivo de 500 MB almacenado en un servidor en Internet (comple-tamente ajeno a TxT, a la UPC y a este proyecto).
Tiempo de compilacion de un kernel de Linux en serie La compilacion de unkernel de Linux es una de las pruebas de benchmarking mas usadas. Requierefrecuentes accesos a disco y usa una porcion considerable de la memoria (sufi-ciente para atenuar el efecto de las caches). La prueba simplemente consiste encompilar y comprimir una imagen del kernel de Linux (sin modulos adicionales)y medir el tiempo que tarda.
Para poder comparar los resultados de manera coherente, siempre se compi-lara la misma version del kernel (3.8.4), con las mismas opciones (las opcionespor defecto). No se garantiza que se use la misma version del compilador. Si unadistribucion incluye un compilador desfasado se vera como un aspecto negativoy quedara reflejado en el tiempo de compilacion.
21
Tiempo de compilacion de un kernel de Linux con varios threads Idem alparametro anterior, pero con varios threads trabajando al mismo tiempo. Conesto podemos medir la eficiencia de la gestion de procesos (scheduling) delsistema operativo.
Dado que el numero maximo de procesos que los PCs a tratar pueden ejecutarsimultaneamente es de 2 (hay procesadores con 2 cores y procesadores conHyperthreading) se ha optado por compilar el kernel usando 4 threads, paraforzar el scheduling.
Consumo energetico Consiste en medir la potencia consumida por el sistema es-tando en reposo (entiendase “reposo” como el PC encendido, pero sin realizartrabajo; no como un estado idle o de bajo consumo).
La medicion se hizo con un medidor de consumo electrico (una herramientahardware).
3.2.2. Puntos a mejorar
Durante las pruebas se detectaron los siguientes problemas:
Las mediciones del disco sufren una pequena perturbacion al incluir en el re-sultado el tamano de los archivos del benchmark. Aunque es una perturbacionpequena, es facil evitarla en versiones sucesivas del benchmark.
Las mediciones que involucran LibreOffice requieren la intervencion del usuario(para cerrar el programa en su debido momento).
Las pruebas se realizaron en mi casa y con mi conexion de red. La prueba demedicion de la velocidad de la red podrıa tener que modificarse dependiendode la conexion de red del almacen de TxT (por ejemplo, reemplazar el archivoa descargar por uno mas grande o mas pequeno o cambiar a una localizaciondistinta).
Se ha notado que este atributo no varıa demasiado entre distribuciones, ası queposiblemente se dara la posibilidad de ignorarlo.
El consumo electrico se mide con un hardware que no tiene conexion con el PCy, por lo tanto, el usuario debe tomar nota del valor el mismo.
De todas formas, este atributo tambien varıa muy poco entre distribuciones,ası que tambien se dara la posibilidad de ignorarlo en futuras versiones.
22
Algunas distribuciones necesitaron instalar el software necesario para compilarel kernel de Linux. En las distribuciones basadas en Debian/Ubuntu se ins-talo el paquete build-essential. En Puppy Linux se instalo el paquete devx.En la version final del benchmark se debera informar al usuario.
3.3. Version final del benchmark
La nueva version del benchmark corrige fallos de la version preliminar y se hacreado un script para automatizarlo (el codigo fuente puede verse en el apendice E).Estos son los puntos a destacar de la nueva version del benchmark :
Se resta el tamano de los archivos del benchmark a la medicion del disco.
Se ha creado una funcion bash que usa el comando top para comprobar cuandoLibreOffice ha acabado de trabajar. Con esto, ahora no se medira solo hasta queel recuento de paginas sea correcto, sino hasta que el uso de CPU de LibreOfficesea 0, lo cual puede ser unos segundos despues de que el recuento de paginasalcance el valor adecuado. Ademas, como esta funcion no cierra LibreOfficeWriter satisfactoriamente, se eliminan los archivos temporales de LibreOfficeantes del iniciarlo, para que no pida recuperarlos.
Los PCs de escritorio no acostumbran a ofrecer una interfaz para consultar elconsumo energetico, por lo que esta prueba sigue necesitando la intervenciondel usuario.
Si se va a ejecutar el benchmark en un PC capaz de reportar su propio consumoenergetico (p. ej., un portatil) se podrıa extender el script del benchmark eincorporar esta funcionalidad. Otra posibilidad serıa comprar un medidor deconsumo electrico con conexion al PC (los hay con conexion USB), pero sedecidio no gastar mas en hardware teniendo uno perfectamente funcional.
Si hay alguna dependencia del benchmark sin cumplir se pedira en el momentoque se vaya a usar. Por ejemplo, si LibreOffice no esta instalado, se pedira quese instale tras haber hecho las mediciones de disco y memoria. En el caso deque todas las dependencias esten instaladas no se requerira la intervencion delusuario.
El script es capaz de reiniciar el sistema cuando sea necesario sin la intervenciondel usuario si se usa el parametro adecuado (esto puede requerir permisos).
23
Se pueden ignorar las pruebas de velocidad de la red y de consumo energetico(recordemos que la medicion del consumo se hace de manera manual por partedel usuario).
Como corolario de los tres ultimos puntos, si el sistema cumple las dependen-cias en el momento de ejecutarse, se ignora la prueba de medicion del con-sumo electrico y se manda a ejecutar con privilegios y usando el parametroadecuado para automatizar los reinicios, el benchmark se puede automatizarcompletamente (no requerira en ningun momento la interaccion del usuario).No obstante, hay que tener en cuenta que algunos de los PCs de TxT tienenproblemas al arrancar sin estar conectados a un monitor (esto es importantesi se pretende trabajar con varios PCs a la vez conectados a un multiplexorVGA, como fue mi caso).
Todas las mediciones (excepto la del tiempo de arranque) se haran tras esperar60 segundos despues de que el sistema sea usable, para garantizar que se hainiciado completamente.
3.4. Modalidad basada en estimacion
Una vez que ya se tiene la version final de la primera modalidad del benchmarky unas mediciones fiables de todas las distribuciones candidatas, se puede hacer lasiguiente modalidad del benchmark.
Esta modalidad solo realizara mediciones sobre una de las distribuciones y extra-polara los resultados para determinar el rendimiento de las demas. Se ha decididoque la distribucion de referencia (sobre la que se haran las mediciones) sera Ubuntu,ya que es la que la mayorıa de los PCs de TxT llevan ya instalada.1
El codigo fuente del benchmark se puede reaprovechar casi por completo. El codigoresultante se puede ver en el apendice G. Las mediciones sobre la distribucion seharan exactamente de la misma manera que en la modalidad de benchmark anterior;la diferencia esta en que se estimara el rendimiento de las demas distribuciones,ası que el codigo de la modalidad anterior del benchmark no se modifica, solo seexpande.
1En el momento de disenar esta modalidad de benchmark las distribuciones candidatas eranSlackware (con KDE), Ubuntu, Linux Mint y Puppy Linux.
24
Los parametros mas sencillos de medir son el disco y la memoria, ya que solohay que consultar la cantidad total y la usada. aprovechando esto y, ya que el usode memoria es el gran discriminante, podemos usar estos parametros para realizardescartes tempranos en el caso de que el sistema no disponga de suficiente memoriay/o disco para algunas de las distribuciones. Para ello se distinguira entre 3 casos:
Disco y/o memoria insuficientes para Ubuntu En este caso, se pueden des-cartar al instante Ubuntu y Slackware. Se estimara el consumo de memoria ydisco de Linux Mint. Si las cantidades de memoria y disco son suficientes paracorrer Linux Mint, se elegira como distribucion ganadora. En caso contrario,se elegira Puppy Linux. Sea cual sea la distribucion elegida en este caso, nosera necesario completar el benchmark
Disco y memoria suficientes para Ubuntu, pero no Slackware En este caso,si Ubuntu tiene un buen rendimiento se elegira como distribucion final. En casocontrario, se elegira Linux Mint.
Disco y memoria suficientes para Slackware En este caso habra que elegir en-tre Slackware, Ubuntu y Linux Mint. Si Ubuntu tiene un buen rendimiento,se decidira entre Slackware y Ubuntu. En caso contrario se elegira Linux Mintcomo distribucion ideal.
Para decidir entre 2 distribuciones, el funcionamiento es el mismo que en lamodalidad de benchmark anterior, con la diferencia de que los parametros seranestimados, no medidos.
Debido a que los parametros de velocidad de red y consumo electrico no sondecisivos, se ignoraran. Tambien se ignorara el tiempo de compilacion del kernelde Linux con 4 threads, ya que esto dependera del tipo de procesador (numerode threads, cores, etc.).
3.5. Modalidad basada en la estimacion de una
distribucion live
Aunque con esta segunda version del benchmark reducimos considerablementeel tiempo necesario para averiguar la distribucion ideal, aun tenemos que instalary una distribucion. Ademas existe la posibilidad de que esa distribucion no sea laideal y haya que instalar otra despues. Para ahorrarnos todas estas instalaciones secreo una tercera version del benchmark. Esta version no requerira instalar ningunadistribucion, ya que se ejecutara desde una distribucion live. Tampoco requerira tanto
25
tiempo como las versiones anteriores, ya que la mayorıa de parametros se estimaranen base al hardware del PC en cuestion. Ası, pues, esta version sera la que menostiempo necesite, pero tambien tendra unos resultados potencialmente mas alejadosde la realidad.
3.5.1. ¿Medir o estimar?
Durante la creacion de esta version surgieron dos ideas sobre como deberıa fun-cionar este benchmark. Por un lado, existıa la posibilidad de simplemente ejecutar elbenchmark sobre la distribucion live y, a partir de sus resultados, estimar cuales serıanlos resultados de las demas distribuciones de manera similar a la version anterior delbenchmark. Por el otro, la idea era que desde la distribucion live se consultasen losatributos del hardware del sistema en cuestion y se calculase la distribucion ideal enbase a esos atributos.
Se hicieron pruebas con la primera alternativa. Estas mediciones se realizaronsobre el PC A (Procesador Intel Core 2 Duo, 2 GiB de memoria). Para poder realizarlas pruebas que requieren entorno grafico, se instalo JWM (Joe’s Window Manager)en la distribucion live. Este entorno de escritorio es muy ligero y es el que incluyePuppy Linux por defecto. No se realizo la prueba de ocupacion de disco, porquela distribucion live siempre ocupa el mismo espacio. Tampoco se realizo la pruebade velocidad de red, porque se vio que no era un parametro decisivo (todas lasdistribuciones daban practicamente el mismo resultado).
Paramtero CD USB
Memoria (MiB) 262 242Tiempo de arranque del SO (s) 151,12 24,30
Tiempo de arranque de LibreOffice (s) 21,568 9,819Tiempo de apertura de many_as.txt (s) 141,696 103,413
Tiempo de compilacion en serie (s) 263,273 260,172Tiempo de compilacion en paralelo (s) 143,145 142,294
Consumo energetico (W) 62,0 56,0
El primer problema que encontre fue que para poder conservar los resultados delas mediciones durante los reinicios necesarios serıa necesario un medio de almace-namiento persistente. Es decir, la distribucion live no podrıa ser grabada en un CDo DVD. Esto supone un problema, ya que algunos (pocos) de los PCs de TxT nopueden arrancar desde USB. Ademas, se vio que el medio en el que se grabase ladistribucion (CD, DVD o USB) afectaba a los valores de las mediciones, debido a que
26
la velocidad de lectura de dicho medio no era la misma que la del disco del sistema aevaluar (ademas de que tambien afectaba otros parametros, como el consumo electri-co). Como esta version del benchmark ya extrapola bastante los datos, se decidio queanadir una variable mas a las estimaciones (la velocidad del medio de la distribucionlive) serıa demasiado, ası que se opto por descartar esta alternativa.
3.5.2. La distribucion live
Para esta version del benchmark se ha usado una distribucion live basada en De-bian 6.0.7. Es la misma distribucion con la que se trabajo anteriormente en el trabajo,pero esta vez se usara sin entorno grafico. Con esto conseguimos reducir de maneraconsiderable los recursos necesarios para ejecutarla en tiempos razonables. Ademas,como esta version simplemente toma las propiedades del hardware y realiza calculos(no realiza las mediciones de las versiones anteriores; no se necesitara LibreOffice),no es necesario entorno grafico.
Para crear la distribucion live, en primer lugar se creo una maquina virtual enVirtualBox. Los parametros de la maquina virtual no afectaran al resultado, aunquesı puede afectar al tiempo que se tarde en construir la imagen .iso resultante. Du-rante la instalacion se eligio no instalar el entorno grafico, ya que no sera necesariopara esta tarea y nos permite ahorrar bastante memoria (recordemos que toda ladistribucion sera cargada en memoria). Una vez instalada la distribucion Debian sepersonalizo, instalando los paquetes necesarios para realizar todas las tareas. Esto in-cluyo el paquete build-essential, para compilar, y el paquete nasm, requisito parael programa bandwidth [11] (el cual se instalo desde el codigo fuente proporcionadopor el autor). Finalmente, se realizo una “instantanea” (en ingles, snapshot) usan-do el programa refractasnapshot. Este programa crea por defecto un menu queaparece al arranque y permite elegir entre distintos tipos de arranque (normal, sinentorno grafico, cargar a memoria...). Se edito este menu para que solo estuviese laopcion de cargar a memoria y se redujo el timeout al mınimo (porque realmente noes necesario escoger ninguna opcion, ya que solo hay una). El programa genero unaimagen .iso que contenıa la instantanea de la distribucion tal y como estaba enel momento de la creacion. Finalmente se copio a un USB usando el programa dd.Tambien se podrıa haber grabado en un CD o DVD.
Debido a las limitaciones del programa de entrega de la memoria de este proyecto(el tamano maximo para archivos adicionales es de 100 MB) no se podra entregar laimagen .iso (que tiene un tamano de mas de 200 MB).
27
3.5.3. Estimando en base al hardware
De la misma manera que se hizo en la modalidad anterior de benchmark, leerla capacidad del disco y la memoria y comprobar si es suficiente para cada unade las distribuciones es facil, ya que estos parametros son bastante constantes parauna misma distribucion en varios PCs. Otros parametros no pueden ser medidosdirectamente y tienen que ser estimados en base a pequenas pruebas.
Para poder estimar los valores que no podemos medir, es necesario averiguar deque otros parametros dependen. Para ello se han realizado un estudio estadıstico quepuede encontrarse en el apendice H. En este estudio se observaron variables relativasal disco, la memoria y la CPU, por que son las mas basicas y probablemente las quemas influencia tengan.
Las variables relativas a la CPU son simplemente el tiempo de compilacion deuna aplicacion de referencia con 1 y 4 threads, tal y como se hace en el benchmarkclasico. Al tener que cargar la distribucion live en la memoria, no queda suficientepara compilar el kernel de Linux, ası que se ha optado por una aplicacion maspequena llamada PAPI [12] (la funcionalidad de la aplicacion no nos importa; solosu tiempo de compilacion). Las variables relativas al disco son el ancho de bandade lectura y la latencia. Estas se pueden medir facilmente usando el comando dd;para medir el ancho de banda se leen 1,6 GB y para la latencia, 1 bloque (512 B).Finalmente, las relativas a la memoria son el ancho de banda de lectura de secuencialde archivos de distintos tamanos. Se han distinguido 4 casos: archivos menores de32 kiB, entre 32 y 256 kB, entre 256 kB y 1 MB y superiores a 2 MB. Esta divisionse ha realizado tras ver 4 tramos claramente distintos en pruebas realizadas con elprograma bandwidth (vease la figura 3.1).
28
Figura 3.1: Grafico generado por el programa bandwidth.
29
3.6. Experimentacion con un Pocket PC
Hoy en dıa, cuando se habla de PCs de perfil bajo uno no puede evitar pensaren los llamados Pocket PCs ; PCs diminutos, que caben en la palma de la mano,con los recursos mınimos necesarios para realizar tareas cotidianas como navegar porInternet, consultar el correo o editar un documento. Sus principales ventajas son subajo consumo y su precio, lo cual las hace ideales para, por ejemplo, aulas tecnologicasen paıses subdesarrollados, donde la corriente electrica es escasa y el presupuestomuy ajustado. Actualmente la asociacion TxT dona equipos de sobremesa con pocosrecursos a ONGs con este tipo de finalidades, con lo que resulta interesante comprobarhasta que punto pueden los Pocket PC sustituir los PCs convencionales.
Como parte de este trabajo se experimento con una Raspberry Pi (modelo B). Lafinalidad de estos experimentos fue doble: por un lado, demostrar que el benchmarkpuede funcionar en cualquier dispositivo capaz de correr Linux; y por otro, medir elrendimiento de un Pocket PC y compararlo con el de PCs convencionales de bajorendimiento.
No se trato de comparar las distintas distribuciones disponibles para la RaspberryPi, ya que todavıa son pocas y tienen propositos muy distintos (p. ej., convertir laRaspberry Pi en un media center).
30
Capıtulo 4
Implementacion, pruebas yresultados
4.1. Encuesta
La encuesta se publico en los foros de la facultad y permanecio disponible duranteuna semana. Durante este tiempo se consiguieron 88 respuestas; mas que suficientepara mi proposito.
A la hora de valorar los resultados de la encuesta y asociar un valor a cada opcion,inicialmente se penso en hacer una traduccion directa: asociar a cada funcionalidadel porcentaje de encuestados que la selecciono. Finalmente se opto por normalizar elvalor. Es decir, el valor asignado a una funcionalidad (x) se obtiene con la siguienteformula:
valorx =numero de votosx
Σtodas las funcionalidadesnumero de votos
De esta manera el valor de cada funcionalidad queda ponderado segun su populari-dad: las funcionalidades populares valdran mas que las impopulares.
Los resultados completos de la encuesta se pueden encontrar en el apendice A.Los votos de las opciones de reproduccion de HD-DVD y Blu-Ray Disc se eliminaron,ya que, al no disponer del hardware necesario, estas opciones resultan irrelevantes.
31
Cuadro 4.1: Fragmento de los resultados de la encuesta.
FuncionalidadVotos Votos Valor(abs) ( %) normalizado
Pro
cesa
dor
de
texto
s Compatible con documentos deOffice 2010 (.docx)
77 87,50 % 3,56 %
Compatible con documentos deLibreOffice y OpenOffice (.swx)
47 53,41 % 2,17 %
Posibilidad de anadircomentarios a los documentos
45 51,14 % 2,08 %
Crear graficos y dibujos sinnecesidad de una herramienta
externa54 61,36 % 2,50 %
Integracion con una suiteofimatica completa
18 20,45 % 0,83 %
Version para Mac OS X 14 15,91 % 0,65 %
4.2. Analisis de las distribuciones
4.2.1. Seleccion de distribuciones candidatas
Mientras la encuesta estuvo activa, se seleccionaron las distribuciones candidatascon las que se trabajarıa. A continuacion se detalla que distribuciones se seleccionarony por que motivo.
Bodhi Linux
Version: 2.3.0
Motivo: Esta basada en Ubuntu (que es la distribucion que se usa actual-mente), usa el entorno de escritorio Enlightenment, conocido por ser muyligero. Es muy minimalista y tiene una buena puntuacion en DistroWatch.
32
CrunchBang
Version: 11 (Waldorf)
Motivo: Es una distribucion ligera, basada en Debian (anteriormente basadaen Ubuntu, que es la distribucion que se usa actualmente) y tiene unabuena puntuacion en DistroWatch.
Comentarios: Esta distribucion debe grabarse en un CD de 800 MB comomınimo.
Debian
Version: 6.0.7 (Squeeze)
Motivo: Es una distribucion original (no esta basada en ninguna otra), esmuy conocida y es compatible con paquetes de Ubuntu.
Comentarios: solo se usara el CD1.
Linux Mint
version: 12 (Lisa)
Variante: LXDE
Motivo: Es la distribucion elegida para los PCs mas antiguos de TxT. Se haelegido como referencia.
Comentarios: No es la version mas moderna, pero es la ultima que se puedegrabar en un CD de 700 MB.
Puppy Linux
Version: 5.4.3
Variante: Ubuntu Precise
Motivo: Es una distribucion extremadamente ligera, usa JDM (un entorno deescritorio muy ligero), arranca desde ramdisk y tiene muy buena valoracionen DistroWatch.
Comentarios: Se usara el modo de instalacion Full.
33
Slackware
Version: 14.0
Variante: KDE y XFCE
Motivo: Es una distribucion original de las mas antiguas y muy completa encuanto a funcionalidades. fue sugerida por mis directores.
Comentarios: Esta distribucion debe ser grabada en un DVD como mınimo.Ambas variantes se encuentran en el mismo disco. Se trataran las dosvariantes por separado.
Lubuntu
Version: 12.10
Motivo: Version ligera de Ubuntu, con escritorio LXDE (muy ligero). Tienebuena puntuacion en DistroWatch.
Xubuntu
Version: 12.10
Motivo: Idem a la anterior, pero con escritorio XFCE (tambien muy ligero,auque no tanto como LXDE).
Ubuntu
Version: 12.04
Motivo: Distribucion muy popular. Es una version LTS (Long Term Support).Es la que se usa actualmente en la mayorıa de PCs de TxT. Se ha elegidocomo referencia.
Comentarios: No es la version mas moderna, pero es la ultima que se puedegrabar en un CD de 700 MB.
Todas las instalaciones se hicieron sin acceso a la red y con todas las opcionespor defecto, con las siguientes excepciones:
Se activa la opcion de auto-login siempre que sea posible. Esto es para favorecerla medicion del tiempo de arranque.
En la variante KDE de Slackware no se instala XFCE y viceversa. Esto es parano perturbar la medicion de la ocupacion del disco.
34
En las distribuciones que no proporcionan un particionamiento del disco pordefecto, se instala todo el sistema en una unica particion. Tambien se hace unaparticion swap de tamano igual al doble de la cantidad de memoria del sistema.Siempre se usa ext4.
4.2.2. Analisis de funcionalidades
Una vez elegidas las distribuciones, se calcula su funcionalidad. Para ello, primerose toman de cada distribucion los programas pertenecientes a cada una de las cate-gorıas de la encuesta (vease el apendice B). Con esto ya podemos ver que algunas delas distribuciones no traen programas para algunas de las categorıas. Por ejemplo,Xubuntu no incluye ningun programa para trabajar con hojas de calculo. Estas dis-tribuciones posiblemente se vean perjudicadas en el aspecto de funcionalidad. Solose tuvo en cuenta el software incluido en la instalacion por defecto. El software in-cluido en el disco que no este seleccionado por defecto no se valorara. El software noincluido en el disco pero incluido en los repositorios o instalable a traves de scriptspost-instalacion u otros medios tampoco se valorara. Si algun software incluido en lainstalacion por defecto tiene actualizaciones disponibles a traves de Internet, estasactualizaciones tampoco se tendran en cuenta. Para saber que software incluye cadadistribucion simplemente se instalo cada una de ellas en una maquina virtual.
Despues se mira que funcionalidades tiene cada programa y cuales no (veaseel apendice C). Aquı podemos ver como las distintas alternativas para una mismacategorıa tienen distintos equilibrios entre funcionalidad y rendimiento. Por ejemplo,Abiword es mas ligero que LibreOffice Writer, pero tambien tiene muchas menosfuncionalidades. Mas adelante, cuando se evalue el renimiento, se podra ver masclaramente que distribuciones balancean mejor funcionalidad y rendimiento.
Finalmente, uniendo los programas por distribucion con las funcionalidades porprograma se puede saber que funcionalidades cumple cada distribucion. Esta sera lamedida que se usara como representativa del nivel de funcionalidad de cada distri-bucion. Inicialmente se penso en contar solo las funcionalidades con mas del 50 % devotos, para distinguir las funcionalidades populares de las no populares. Finalmentese opto por un total normalizado, usando el valor normalizado que se calculo con losresultados de la encuesta.
El desglose de los resultados puede encontrarse en apendice D. A continuacion semuestran los totales.
35
La fila “Total (abs)” indica el total de votos para las funcionalidades con mas del50 % de votos.
La fila “Total ( %)” indica el porcentaje de funcionalidades con mas del 50 % devotos que cumple.
La fila “Total normalizado” es una ponderacion teniendo en cuenta todas lasfuncionalidades y su valor normalizado (vease el apendice A).
Leyenda: 1 = Sı; 0 = No; 0,5 = Parcial
FuncionalidadB
odhi
Lin
ux
Cru
nch
Ban
g
Debia
n
Lin
ux
Min
t
Puppy
Lin
ux
Sla
ckw
are
Lubu
ntu
Xubuntu
Ubuntu
KD
E
XF
CE
Tota
l Total mayoritarios(abs)
2,5 12,5 10 19,5 16,5 23 15 19 13 19
Total mayoritarios( %)
8,33 41,67 33,33 65,00 55,00 76,67 50,00 63,33 43,33 63,33
Total normalizado( %)
9,49 43,93 38,77 70,14 60,72 83,49 55,77 65,67 51,04 72,72
Con estos resultados es facil observar que Bodhi Linux no llegara lejos, ya quecumple menos del 10 % de las funcionalidades, muy por debajo del resto de distribu-ciones (esto se debe principalmete a que casi no trae ningun programa por defecto).Por esta razon se decidio descartar Bodhi Linux como distribucion candidata, inclusoantes de medir su rendimiento.
4.3. Analisis de los PCs
4.3.1. PCs de TxT
Con tal de preparar las pruebas, hice una visita al almacen de TxT para ver conque PCs tendrıa que trabajar. En el momento de la inspeccion, la mayorıa de losPCs eran de los siguientes tipos:
36
Modelo A
Procesador: Pentium 4
Frecuencia del procesador: 3,20 GHz
Numero de nucleos: 1
Numero de threads por nucleo: 2 (Hyperthreading)
Memoria: 2 × 512 MB
Disco: 80 GB
Lector de DVD: Sı (DVD-ROM)
Modelo B
Procesador: Pentium D
Frecuencia del procesador: 3,00 GHz
Numero de nucleos: 2
Numero de threads por nucleo: 1
Memoria: 2 × 512 MB
Disco: 160 GB
Lector de DVD: Sı (DVD-RW)
Modelo C
Procesador: Core 2 Duo
Frecuencia del procesador: 3,13 GHz
Numero de nucleos: 2
Numero de threads por nucleo: 1
Memoria: 2 × 1 GB
Disco: 250 GB
Lector de DVD: Sı (DVD-RW)
Nota: La cantidad de memoria y disco puede variar entre PCs del mismo modelo.
37
Aunque habıa PCs de otros tipos (tanto mejores como peores), eran muy pocos yse trataron como outliers.
Estos 3 tipos de PCs eran comunes en gran numero, probablemente debido a quelas donaciones de equipos a TxT se hacen en grandes cantidades. En cambio, losoutliers eran escasos; probablemente eran restos o fueron donados por particulares.
4.3.2. Pruebas de rendimiento preliminares
En un principio, las pruebas se harıan en los PCs antes mencionados, pero la llavedel almacen que me tenıan que dar se extravio y, durante la mayor parte del trabajo,solo pude entrar cuando hubiese alguien dentro, ası que decidı realizar las primeraspruebas en mi casa. Para poder hacer pruebas en casa y no tener que depender deTxT dispuse de un PC de las siguientes caracterısticas:
Modelo A0
Procesador: Pentium 4
Frecuencia del procesador: 3,00 GHz
Numero de nucleos: 1
Numero de threads por nucleo: 2 (Hyperthreading)
Memoria: 512 MB + 1 GB
Disco: 80 GB
Lector de DVD : Sı (DVD-RW)
La intencion es que el PC A0 simule un “suelo” para poder decidir la magnitud delas pruebas; es decir, un PC con los mas bajos recursos (no queremos un benchmarkque tarde demasiado en ejecutarse en un PC lento, ya que la finalidad de este esprecisamente ejecutarlo sobre PCs lentos). En principio se eligio para que fuese unPC con hardware similar al PC A, que es el PC de TxT con los recursos mas bajos.Finalmente, a pesar de que tuviese mas memoria las pruebas de rendimiento indicanque es aun mas lento que el PC A. Esto no supone un problema, ya que al quedarpor debajo del PC A cumple su cometido correctamente.
Con este PC me dispuse a realizar unas pruebas de rendimiento con una versionpreliminar del benchmark para poder disponer de unos datos sobre el rendimientode cada distribucion, aunque fuesen solo aproximados. Los resultados se muestran acontinuacion.
38
Parametro
Cru
nch
Bang
Debia
n
Lin
ux
Min
t
Puppy
Lin
ux
Sla
ckw
are
Lubuntu
Xu
bu
ntu
Ub
untu
KD
E
XF
CE
Ocupacion del disco (GB) 2,3 1,5 2,5 0,72 6,7 5,3 1,8 2,1 2,4Uso de la memoria (MB) 244 165 295 104 628 298 291 390 683Tiempo de arranque (s) 36,94 30,20 20,80 21,21 162,14 35,72 18,73 20,72 20,87Tiempo de arranque de
LibreOffice (s)12,45 10,97 10,01 13,00 18,10 8,31 12,30 10,86 14,32
Tiempo de apertura demany_as.txt
2’ 37” 2’ 15” 2’ 22” 3’ 21” 3’ 22” 3’ 05” 1’ 14” 1’ 11” 3’ 22”
Velocidad de descarga(MB/s)
1,03 1,16 1,13 1,11 1,11 1,13 1,12 1,12 1,00
Tiempo de compilacion delkernel (en serie)
7’ 58” 7’ 07” 7’ 30” 7’ 41” 10’ 32” 8’ 44” 8’ 33” 8’ 27” 9’ 38”
Tiempo de compilacion delkernel (en paralelo)
8’ 56” 5’ 44” 5’ 53” 5’ 56” 10’ 18” 8’ 31” 6’ 12” 6’ 12” 8’ 29”
Consumo energetico (W) 59,0 58,0 59,0 55,5 59,0 59,0 58,5 59,0 58,5
39
4.4. Criba de distribuciones
Una vez obtenidos los datos sobre la funcionalidad y el rendimiento de las dis-tribuciones se puede hacer una criba y escoger solo con las mas prometedoras, paraahorrar trabajo en las pruebas y mediciones que se harıan mas tarde.
Se determino que la distribucion ideal serıa aquella que tenga mas funcionalidadesy supere unos determinados mınimos de rendimiento. Por lo tanto, use la funciona-lidad de las distribuciones para ordenar las distribuciones y los resultados de laspruebas de rendimiento para hacer la criba. Como resultado, las distribuciones De-bian, CrunchBang, Xubuntu y Slackware (variante XFCE) fueron eliminadas por serlas distribuciones con menor funcionalidad. Slackware (variante KDE) se mantuvo apesar de tener malos resultados en las pruebas de rendimiento por ser la distribucioncon mayor funcionalidad.
De ahora en adelante, siempre que se haga referencia a Slackware se referira a lavariante KDE, a menos que se especifique lo contrario.
4.5. Pruebas de rendimiento en PCs de TxT
4.5.1. Resultados y reporte de incidencias
Una vez finalizado el benchmark, seleccionadas las distribuciones y analizadoslos PCs es momento de realizar las mediciones. Los resultados se encuentran en elapendice F.
Durante las pruebas se detectaron las siguientes incidencias:
El PC B era incapaz de arrancar desde algunos de los CDs y DVDs (en par-ticular, Linux Mint, Puppy Linux y Ubuntu). Se soluciono instalando dichasdistribuciones desde USB.
El PC A pide configurar la BIOS y poner el reloj en hora cada vez que seenciende. Posiblemente se deba a que la pila que alimenta la BIOS este gastada.No fue necesario cambiarla; basto con configurar la BIOS y el reloj cada vez quese encendıa (solo la primera vez tras perder la alimentacion); esto no afecto ala medicion del tiempo de arranque.
En la tabla de resultados se puede observar que en algunas distribuciones(Slackware y Puppy Linux) el tiempo de apertura del archivo many_as.txt
con LibreOffice es bastante mayor que en las demas. Esto es debido a que
40
LibreOffice se queda “congelado” durante un tiempo despues de abrirse pe-ro antes de mostrar el archivo. Desconozco la causa, pero es obvio que estopenalizara gravemente a esas distribuciones.
Los tiempos de arranque del PC B son mas altos que los del PC A, a pesar deque este es mas nuevo y dispone de mejor hardware. En cualquier caso, no esel objetivo de este proyecto el descubrir el por que de este fenomeno. Ademas,la diferencia no es demasiado grande como para causar un gran impacto en losresultados, ası que no se le dara mas importancia al asunto.
LibreOffice en Slackware arranca mas rapido en PCs mas viejos. Es un datobastante desconcertante al cual no le encuentro explicacion. De todos modos,Slackware es siempre el mas lento en todos los parametros.
La compilacion del kernel de Linux en Slackware muestra un warning, aunqueesto no afecta a las mediciones del tiempo de compilacion ni a los resultadosdel benchmark.
La conexion de red del almacen de TxT no era la adecuada para llevar a ca-bo las mediciones. La velocidad era muy variable, llegando incluso a mostrardiferencias de cientos de KB/s en una misma distribucion en un mismo PC.Presumiblemente esto se debe a que hay mas gente conectada a la red y hacenun uso intensivo de ella. Para solucionarlo simplemente se usaran los datosobtenidos en las pruebas preliminares (las que se hicieron con el PC A0), yaque tras la experimentacion con Raspberry Pi (mas adelante) se ha visto quela velocidad de red no varıa demasiado de un hardware a otro y, ademas, tam-poco varıan mucho entre distribuciones, con lo que no resultara un parametrodecisivo.
4.5.2. Conclusiones
De las pruebas realizadas con los PCs de TxT se extraen las siguientes conclu-siones:
Disco: Ubuntu, Linux Mint y Lubuntu estan a la par. Slackware ocupa bastantemas y Puppy Linux bastante menos. No varıa mucho entre PCs.
Memoria: Es un poco irregular, pero aun ası es facil de ver el requisito de cadadistribucion. Slackware y Ubuntu son los mas altos, Linux Mint y Lubuntu sonmas razonables y Puppy Linux es diminuto.
41
Tiempo de arranque del SO: Linux Mint arranca bastante mas rapido en el Core2 duo. Lubuntu y Puppy Linux tambien mejoran en este procesador, perola diferencia es pequena. Slackware es siempre muy alto. Basicamente todosexcepto Slackware arrancan en un tiempo aceptable.
Tiempo de arranque de LibreOffice: Muy constante. Ligeramente mejores en elprocesador mas nuevo. La excepcion es Slackware, que va mejor con el proce-sador mas viejo.
Tiempo de apertura de many as.txt con LibreOffice: Aquı es notable una grandiferencia en Slackware y Puppy Linux. Esto es debido a que LibreOffice sequeda bloqueado durante algun tiempo antes de mostrar el archivo. El bloqueodura bastante tiempo (unos 40 segundos) y penaliza gravemente a aquellasdistribuciones que lo sufran. Aunque no se ha comentado antes, esto tambiensucedıa en las pruebas en el PC A0, incluso en distribuciones en las que nose produce ningun bloqueo con los PCs de TxT. No se reporto como un inci-dente debido a que ocurrıa en muchas otras distribuciones y se vio como algo“normal”.
Velocidad de descarga: Tal y como se ha comentado en la seccion anterior, estaprueba no se realizo con exito.
Tiempos de compilacion del kernel de Linux: Se ven fuertemente influencia-dos por el procesador, sobretodo la compilacion en paralelo. Es bastante cons-tante entre distribuciones (excepto Slackware, que es mas lento).
Consumo energetico: Muy influenciado por el procesador (hasta 15 W de diferen-cia). Muy constante entre distribuciones. Puppy consume un par de W menos,pero poca cosa. No es un parametro decisivo.
4.5.3. Interpretacion de los resultados
Con estos resultados se debe escoger una de las distribuciones como la mejor. Sedecidio eliminar Lubuntu, ya que casi no ofrece mejoras con respecto a Linux Mint ytiene casi un 5 % menos de funcionalidad. Ademas, Puppy Linux solo se usara comoultimo recurso, en caso de que el sistema no tuviese suficiente memoria para ningunaotra distribucion.
Para determinar que distribucion es mejor para cada PC se seguira la metodologıasiguiente:
42
Disco y memoria Debera usar como maximo la mitad del total (en el caso deldisco, exceptuando swap).
Tiempos y consumo Sea xi el valor de la distribucion i en el campo x, y x la mediade todas las distribuciones (Slackware, Ubuntu y Linux Mint) en el campo x,se considerara que la distribucion i cumple el requisito si:
xi <= x× 110 %
Se ha anadido un 10 %, porque sino siempre habrıa como mınimo una dis-tribucion que no cumplirıa cada uno de los requisitos, aunque todas tuviesenresultados muy parecidos.
Velocidad de red Idem al anterior, pero cambiando el sentido de la desigualdad,ya que en este campo “mas es mejor”. Por lo tanto, sea ri la velocidad de red dela distribucion i, y r la media de velocidad de red de todas las distribuciones,se considerara que la velocidad de red de la distribucion i es aceptable si:
ri × 110 % >= r
Se ha implementado un script que realiza estos calculos en base a los resultadosde del benchmark. El codigo fuente de este script se encuentra en el apendice E.3.
4.6. Realizando estimaciones
En la modalidad del benchmark que realiza estimaciones sobre Ubuntu, estasson unas estimaciones muy sencillas, ya que teniendo unas mediciones reales comobase se pueden aproximar las mediciones reales de las demas distribuciones de maneramoderadamente sencilla con solo anadir un offset a las mediciones reales (la diferenciamedia entre las distribuciones).
En cuanto a las estimaciones en base a la distribucion live, debido al bajo numerode muestras solo podemos realizar estimaciones en base a 2 variables (+1 variable deoffset). Como algunas de las variables estan correlacionadas con mas de 2 variables,hay que escoger 2 de ellas. Simplemente se escogeran las 2 variables con la correlacionmas significativa.
43
Para calcular en que proporcion afecta cada variable se hara simplemente unsistema de ecuaciones. Por ejemplo, para estimar el tiempo de arranque de Ubuntuse resolverıa el siguiente sistema:
Tiempo de arranquePC A = Ancho de banda del discoPC A × x
+Ancho de banda de la memoria (tramo 4)PC A × y
+z
Tiempo de arranquePC B = Ancho de banda del discoPC B × x
+Ancho de banda de la memoria (tramo 4)PC B × y
+z
Tiempo de arranquePC C = Ancho de banda del discoPC C × x
+Ancho de banda de la memoria (tramo 4)PC C × y
+z
De aquı los valores resultantes son:
x = −0, 19
y = 0, 88
z = 32, 10
De manera que se puede estimar el tiempo de arranque de un PC con la siguienteecuacion:
Tiempo de arranque = Ancho de banda del disco ×−0, 19
+Ancho de banda de la memoria (tramo 4) × 0, 88
+32, 10
Para las demas variables y distribuciones, las ecuaciones resultantes se encuentranen el apendice I:
Para comprobar los resultados, se realizo una regresion lineal multiple [13] con elprograma Minitab [14]. Los resultados coincidieron, con lo que podemos asumir queson correctos.
4.7. Comparativa de modalidades del benchmark
Ahora que se tienen las 3 modalidades del benchmark implementadas, podemoscompararlas para conseguir una proporcion entre tiempo de ejecucion y precision
44
optimas. Como las estimaciones se han hecho en base a los PCs utilizados a lolargo del trabajo, resulta obvio que todas las modalidades del benchmark devolveranlos mismos resultados para estos PCs. Para poder probar de manera efectiva lasdistintas modalidades, se deben ejecutar en un PC totalmente nuevo. A continuacionse detallan las especificaciones de este nuevo PC:
Modelo X
Procesador: AMD Athlon 64 X2
Frecuencia del procesador: 2,00 GHz
Numero de nucleos: 2
Numero de threads por nucleo: 1
Memoria: 1 × 512 + 1 × 256 + 1 × 128 MB
Disco: 80 GB
Lector de DVD: Sı (DVD-ROM)
Los resultados obtenidos por las distintas modalidades de benchmark fueron losque se muestran en la tabla 4.5.
Cuadro 4.5: Resultados de las distintas modalidades del benchmark.PC A PC B PC C PC Xa PC Xb
Benchmark clasico Linux Mint Linux Mint Ubuntu c Linux MintBenchmark Ubuntu Linux Mint Linux Mint Ubuntu Puppy Linux Linux MintBenchmark live Linux Mint Linux Mint Ubuntu Puppy Linux Slackware
aUsando descartes tempranos por memoria y disco.bSin usar descartes tempranos por memoria y disco.cLa modalidad de benchmark clasico no realiza descartes tempranos.
Como podemos ver, en los PCs con los que se ha trabajado todas las modalidadesdan el mismo resultado, como ya se habıa previsto.
Cabe destacar que en los PCs A, B y X se detuvo la ejecucion del benchmark du-rante los descartes por memoria y/o disco, lo que hace pensar que el uso de memoriaes un fuerte discriminante en este tipo de PCs.
Para comprobar la precision de las estimaciones, se han volvio a ejecutar losdistintos benchmark deshabilitando la funcion que realiza los descartes, para ası poderver los rendimientos estimados y compararlos con los reales.
45
Paramtero UbuntuLinuxMint
SlackwareLinuxMint a
Slackwarea
Ubuntub
LinuxMint b
Slackwareb
Disco (GB) 2,38 2,48 6,68 2,47 c 6,81 c 2,38 c 2,47 c 6,68 c
Memoria (MB) 653 451 701 473 c 726 c 680 c 500 c 753 c
Tiempo de arranquedel SO (s)
24,28 27,33 61,94 27,53 75,97 23,19 -50,72 173,41
Tiempo de arranquede LibreOffice (s)
8,934 8,468 12,012 8,340 11,654 4,823 -3,873 -116,047
Tiempo de aperturade many_as.txt (s)
172,682 78,872 130,559 175,112 207,487 82,834 1006,352 -235,406
Tiempo decompilacion en serie
(s)296,913 292,369 334,260 313,123 389,037 211,586 13,142 -71,369
Tiempo decompilacion en
paralelo (s)155,053 153,121 183,267 602,048 497,402 626,916
Cuadro 4.6: Comparacion del rendimiento real de las distribuciones con el rendimiento estimado.
aEstimado en base a Ubuntu.bEstimado en base a la distribucion live.cEstimado por la funcion de descartes tempranos.
46
Como se puede observar, las estimaciones realizadas basadas en Ubuntu son mo-deradamente acertadas. Aunque hay excepciones (p. ej., el tiempo de apertura demany as.txt en Slackware), grosso modo los valores son aceptables y el resultadofinal (la eleccion de la distribucion optima) coincide con el benchmark clasico, con loque esta modalidad de benchmark se puede considerar exitosa.
En cambio, las estimaciones basadas en la distribucion live son claramente erroneas,llegando incluso a retornar tiempos negativos. Esto es debido muy posiblemente albajo numero de muestras del que se dispone. A pesar de esto, la metodologıa pro-puesta es correcta, y se podrıan obtener buenas predicciones si se dispusiera de unmayor numero de muestras.
4.8. Experimentacion con un Pocket PC
El experimento consistio simplemente en ejecutar el benchmark (modalidad clasi-ca) en una Raspberry Pi con sistema operativo Raspbian (que es basicamente unaDebian ARM adaptada a la Raspberry Pi). Se trabajo con 3 versiones de Raspbian:Base, tal cual queda el sistema tras una instalacion por defecto; Mod, tras instalartodos los programas necesarios para maximizar las funcionalidades; y Potencial, igualque Mod, pero incluyendo las licencias para decodificar MPEG-2 y VC-1 (se com-pran por separado). De la version potencial solo se calcularon las funcionalidades,ya que el rendimiento seguramente no variara (solo son un par de codecs) y no sevio necesario comprar las licencias. Los resultados se muestran en la tabla al final deesta seccion.
Si bien los resultados no fueron mejores que los de los PCs de TxT, sı que fueronmejores que los del PC A0 (Procesador Pentium IV, 1,5 GiB de RAM). El principalproblema es el multitasking : LibreOffice Writer funciona de manera decente, pero a laque abrimos el navegador el sistema se vuelve muy lento y resulta tedioso usarlo. Estoprobablemente sea debido a la falta de paralelismo del procesador de la RaspberryPi. Por desgracia, es muy habitual (o incluso necesario) ejecutar varios programas almismo tiempo, por lo que no creo que la Raspberry Pi sea adecuada para sustituirun PC de escritorio en tareas ofimaticas.
Tambien se puede observar que el tiempo de compilacion del kernel de Linux esmuy alto, unas 10 veces mas alto que en los PCs de TxT, de lo cual se deduce queestas maquinas no son adecuadas para cargas de trabajo intensas. No obstante, simiramos el consumo energetico vemos que es aproximadamente 20 veces menor queel de un PC de sobremesa, con lo cual el trabajo realizado por unidad de potenciaes el doble que el de un PC. Es mas, la Raspberry Pi disipa tan poca energıa queni siquiera necesita refrigeracion (no tiene ventiladores ni disipadores, y la caja solo
47
tiene respiracion en la base). Con esto, la Raspberry Pi se convierte en la eleccionperfecta para sistemas que requieran estar encendidas de continuo pero cuya cargade trabajo sea baja, como por ejemplo un servidor domestico o un sustituto de unsistema integrado (embedded).
No obstante, la Raspberry Pi tiene una buena GPU (capaz incluso de reproducirvıdeo de alta resolucion), con lo cual podrıa soportar cargas intensas siempre y cuandosean cargas de GPU, no de CPU. Esto la hace ideal como media center o reproductormultimedia. Tambien se podrıan realizar tareas con alto coste de computo usando laGPU en lugar de la CPU, pero esto probablemente requerira modificar los programaspara que funcionen con la GPU de la Raspberry Pi.
ParamteroBase(Pre)
Base Mod
Disco (GB) 1,5 1,51 2,53Memoria (MB) 112 116 115
Tiempo de arranque del SO (s) 37,81 35,65 52,54Tiempo de arranque de
LibreOffice (s)13,29 16,468 21,945
Tiempo de apertura demany_as.txt (s)
138 145,389 150,274
Velocidad de red (MB/s) 1,13Tiempo de compilacion en serie
(s)2921 2899,735 2864,198
Tiempo de compilacion enparalelo (s)
2934
Consumo energetico (W) 3,5 3,5 3,5
Cuadro 4.7: La columna “Base (Pre)” corresponde a las mediciones realizadas conla version preliminar del benchmark. Las columnas “Base” y “Mod” estan realizadascon la version final del benchmark (primera modalidad), sin prueba de red. Ademas,en estas columnas no se realizo la prueba de medicion de compilacion del kernel con4 threads, ya que se ha visto que, al tener solo 1 CPU y un overhead despreciable,no supone diferencia con respecto a la medicion de compilacion del kernel con 1thread. Las columnas “Base (Pre)” y “Base” corresponden a la distribucion Raspbianpor defecto. La columna “Mod” corresponde a la misma distribucion con paquetesadicionales instalados.
48
Capıtulo 5
Conclusiones
5.1. Conclusiones
En la actividad en la que yo participe (hace mas de 1 ano) se instalaba Ubuntu entodos los PCs, independientemente de sus especificaciones. Actualmente la directivade TxT a la hora de elegir una distribucion es usar Ubuntu si el PC tiene mas de 1GiB de memoria y Lubuntu en caso contrario. Con esta directiva, se elegirıa Lubuntupara los PCs A y B y Ubuntu para el C, aunque he encontrado PCs con Linux Mintinstalado. Segun mi benchmark, la distribucion ideal para cada PC serıa Linux Mintpara el A y el B y Ubuntu para el C. Es obvio que durante el ultimo ano en TxT sehan dado cuenta de la importancia de escoger una distribucion adecuada para cadaPC y han optado por una distribucion mas ligera para los PCs menos potentes. Noobstante, personalmente creo que han dejado un poco de lado la funcionalidad enfavor del rendimiento al escoger Lubuntu frente a Linux Mint. Ademas, la separacionentre ‘mas de un giga’ y ‘un giga o menos’ no es lo suficientemente fina. En unaocasion se encontraron con un PC con 512 MiB de memoria y quisieron instalarleLubuntu, siguiendo su directiva. No obstante, Lubuntu ocupa hasta 480 MiB enreposo, con lo cual el resultado habrıa sido nefasto. Una distribucion como PuppyLinux (∼ 180 MiB) habrıa sido mas acertada.
No obstante cabe destacar que han acertado al escoger la cantidad de memoriacomo parametro discriminante. En las pruebas que he realizado he podido ver queen la mayorıa de los casos la ejecucion del benchmark acababa con los descartesrealizados a raız de la cantidad de memoria.
49
En resumen, la polıtica de TxT en cuanto a que distribucion elegir ha mejoradocon respecto a la actividad que origino mi motivacion para realizar este trabajo,pero aun quedan detalles por pulir. Confıo en que este trabajo ayude a TxT y a sususuarios a conseguir una mejor experiencia.
En cuanto a la Raspberry Pi, su debilidad es la CPU y su fortaleza reside en laGPU. Me parece obvio que los creadores han querido enfocar el aparato mas hacia lareproduccion multimedia que al escritorio. Por suerte, la Raspberry Pi no es el unicoPocket PC del mercado, y hay alternativas que quizas cumplan mejor como sustitutode un PC de sobremesa. Cubieboard [15], por ejemplo, parece ser mas adecuada paraesta tarea: tiene un procesador de 1 GHz (frente a los 700 MHz de la Raspberry Pi),1 GiB de memoria RAM (frente a los 512 MiB de la Raspberry Pi) y soporta masdistribuciones de Linux (Debian, Fedora, Ubuntu, e incluso Android) por un preciomuy similar. El procesador sigue siendo de un solo core y thread. Existen otrasalternativas con procesadores multicore [16], pero tienen un precio mas elevado.
5.2. Trabajo futuro
5.2.1. Comportamientos anomalos
Durante la realizacion de este trabajo me he encontrado con comportamientosque desafıan la logica. Los ejemplos mas claros son el hecho de que Slackware pa-rece funcionar mejor en PCs con menos recursos, a pesar de ser la distribucion quemas recursos usa y que LibreOffice se quede congelado durante un tiempo al ini-ciar en Slackware (la distribucion mas pesada), pero tambien en Puppy Linux (ladistribucion mas ligera) y no en las demas.
Entender el por que de estos fenomenos podrıa ayudar a realizar estimacionesmas precisas y, en general, ayudar en la finalidad de este trabajo, que es seleccionarla distribucion mas acertada para cada PC.
5.2.2. Anadir atributos a medir al benchmark
Siempre cabe la posibilidad de extender el benchmark anadiendo parametros,como podrıan ser el tiempo de abrir una pagina web (para profundizar mas en lagestion de la red) o el framerate medio al reproducir un vıdeo en alta resolucion(para profundizar en el aspecto de computacion grafica). Esto a si vez podrıa llevar ahilar mas fino en el analisis de aplicaciones y funcionalidades. Por ejemplo, teniendoen cuenta el entorno de escritorio y/o el gestor de ventanas explıcitamente.
50
5.2.3. Actualizar y expandir la lista de distribuciones
Durante este trabajo se ha tratado con distribuciones desfasadas, principalmenteporque no estaba seguro de si los PCs de TxT soportarıan el arranque desde DVD.Ahora que he visto que sı lo soportan (la mayorıa, aunque hay outliers que aunleen solo CDs) se podrıa aprovechar para probar con versiones mas actuales de lasdistribuciones escogidas o incluso con distribuciones nuevas que no se hayan tratadoen este trabajo.
5.2.4. Mejorar la estadıstica
Debido a las pocas muestras, la estadıstica en la que se basan las estimacionesde la distribucion live no son muy solidas. Esto podrıa solucionarse tomando masmuestras de mas tipos de PCs (nuevos PCs llegan a TxT continuamente). La distri-bucion live y los scripts ya estan hechos, a modo de prueba de concepto, ahora soloserıa cuestion de ampliar la poblacion de muestras con nuevos PCs.
Ademas, las estimaciones basadas en los resultados de Ubuntu son muy naıve y,aunque funcionan bien en este conjunto de PCs, pueden no ser precisas en PCs conlos que no se haya tratado durante este trabajo.
5.2.5. Probar distintos Pocket PC
Si bien la Raspberry Pi parece no ser la alternativa mas adecuada a un PCde sobremesa, existen otros modelos de Pocket PC mas dirigidos a estas funcionesque podrıa quedar en mejor lugar. Como ya se ha demostrado, el benchmark puedefuncionar perfectamente en dispositivos de este tipo, ası que no serıa difıcil ampliarel trabajo por esta rama.
51
Apendices
52
Apendice A
Resultados de la encuesta
Las columnas “Votos (abs)” y “Votos ( %)” indican el numero de votos que haobtenido la respuesta y el porcentaje de encuestados que la seleccionaron respecti-vamente.
La columna “Valor normalizado” indica la proporcion de votos que correspondena esta respuesta respecto a los votos totales (de todas las respuestas).
Las funcionalidades “soporte para HD-DVD” y “soporte para Blu-Ray” seranignoradas, ya que los PCs con los que se tratara no disponen del hardware necesario.
FuncionalidadVotos Votos Valor(abs) ( %) normalizado
Pro
cesa
dor
de
texto
s Compatible con documentos deOffice 2010 (.docx)
77 87,50 % 3,56 %
Compatible con documentos deLibreOffice y OpenOffice (.swx)
47 53,41 % 2,17 %
Posibilidad de anadircomentarios a los documentos
45 51,14 % 2,08 %
Crear graficos y dibujos sinnecesidad de una herramienta
externa54 61,36 % 2,50 %
Integracion con una suiteofimatica completa
18 20,45 % 0,83 %
Version para Mac OS X 14 15,91 % 0,65 %
53
FuncionalidadVotos Votos Valor(abs) ( %) normalizado
Hoja
de
calc
ulo
Corrector ortografico 36 40,91 % 1,67 %Imprimir seleccion (no toda la
pagina)61 69,32 % 2,82 %
Alto numero de celdas (mas de1000 columnas por pagina, 56000filas por pagina, 256 paginas por
libro)
16 18,18 % 0,74 %
Immobilizar paneles (cabecerassiempre visibles)
46 52,27 % 2,13 %
Importar / exportar tablasLaTeX
21 23,86 % 0,97 %
Loca
li. Interfaz en catalan 45 51,14 % 2,08 %
Soporte para escritura dederecha a izquierda
8 9,09 % 0,37 %
Cli
ente
de
corr
eo Filtro anti-phishing (estafa
cibernetica) sin necesidad decomplementos
52 59,09 % 2,41 %
Lector de feeds RSS sinnecesidad de complementos
10 11,36 % 0,46 %
Vista previa de documentos detexto (pdf, doc, xls, odt, ods)
64 72,73 % 2,96 %
Navegad
or Bloqueo de pop-ups sin
necesidad de complementos73 82,95 % 3,38 %
Bloqueo de publicidad (AdBlock)sin necesidad de complementos
75 85,23 % 3,47 %
Control por voz 9 10,23 % 0,42 %Gestos de raton 11 12,50 % 0,51 %
Conversion texto-a-voz(Text-to-speech)
10 11,36 % 0,46 %
Incorpora su propio plugin Flash 47 53,41 % 2,17 %Lector de feeds RSS incorporadosin necesidad de complementos
ni herramientas externas16 18,18 % 0,74 %
Gestor de contrasenas (recordarcontrasenas, contrasena maestra)
69 78,41 % 3,19 %
54
FuncionalidadVotos Votos Valor(abs) ( %) normalizado
Pro
toco
los
MI
Yahoo! Mail 6 6,82 % 0,28 %Windows Live messenger 22 25,00 % 1,02 %
XMPP (Google talk, Facebookchat)
63 71,59 % 2,92 %
IRC 17 19,32 % 0,79 %Skype 60 68,18 % 2,78 %
MySpaceIM 0 0,00 % 0,00 %
Cliente
MI Emoticonos graficos 51 57,95 % 2,36 %
Emoticonos graficos definidospor el usuario
27 30,68 % 1,25 %
Chat de voz 64 72,73 % 2,96 %Chat de vıdeo 58 65,91 % 2,68 %
Escritura a mano 24 27,27 % 1,11 %Soporte multi-cuenta 54 61,36 % 2,50 %Corrector ortografico 35 39,77 % 1,62 %
Rep
rodu
ctor
de
vıd
eo Soporte para subtıtulos 76 86,36 % 3,52 %
Control de imagen (color,contraste, brillo)
48 54,55 % 2,22 %
Control de sonido (tono) 54 61,36 % 2,50 %Resincronizacion de audio 53 60,23 % 2,45 %
Resincronizacion de subtıtulos 56 63,64 % 2,59 %Soporte para VCD 26 29,55 % 1,20 %
Soporte para SVCD 24 27,27 % 1,11 %Soporte para DVD 62 70,45 % 2,87 %
Soporte para HD-DVD 42 47,73 %Soporte para Blu-Ray 48 54,55 %
Gest
or
de
ar. Miniaturas (Thumbnails) 56 63,64 % 2,59 %
Pestanas 63 71,59 % 2,92 %Doble panel 32 36,36 % 1,48 %
Previsualizaciones 59 67,05 % 2,73 %Navegar por archivos
comprimidos57 64,77 % 2,64 %
Total 88 100,00 % 100,00 %
55
Apendice B
Programas por distribucion
El navegador Iceweasel sera tratado como Firefox, debido a que es practicamenteel mismo (el cambio de nombre es debido a un conflicto de licencias). El mismotratamiento se dara a Icedove / Thunderbird.
Bodhi Linux CrunchBang Debian Linux Mint
Procesador detextos
Ninguno Abiword Ninguno Abiword
Hojas decalculo
Ninguno Gnumeric Ninguno Gnumeric
Cliente decorreo
Ninguno Ninguno Evolution Thunderbird
Navegador Midori IceweaselEpiphany,Iceweasel
Firefox
Cliente de MI Ninguno Ninguno Ninguno PidginReproductor
de vıdeoNinguno VLC Totem
MPlayer,VLC
Gestor dearchivos
EnlightenmentFile Manager
Thunar Nautilus PCManFM
Interfaz encatalan
Parcial Parcial Sı Parcial
Soporte paraescritura dederecha aizquierda
No Sı Sı Sı
56
Puppy LinuxSlackware
KDE XFCE
Procesador detextos
Abiword Calligra Words Ninguno
Hojas decalculo
Gnumeric Calligra Sheets Ninguno
Cliente decorreo
SeaMonkeyKMail,
SeaMonkey,Thunderbird
SeaMonkey,Thunderbird
Navegador SeaMonkeyFirefox,
Konkeror,SeaMonkey
Firefox,SeaMonkey
Cliente de MI Ayttm Kopete, Pidgin Pidgin
Reproductorde vıdeo
MPlayerDragon Player,
KPlayer,MPlayer, xine
MPlayer,xine
Gestor dearchivos
ROX FilerDolphin,Konkeror
Thunar
Interfaz encatalan
Parcial Sı Sı
Soporte paraescritura dederecha aizquierda
No Sı Sı
57
Lubuntu Xubuntu Ubuntu
Procesador detextos
Abiword AbiwordLibreOffice
WriterHojas decalculo
Gnumeric NingunoLibreOffice
CalcCliente de
correoSylpheed Thunderbird Thunderbird
Navegador Chromium Firefox FirefoxCliente de MI Pidgin Pidgin EmpathyReproductor
de vıdeoMPlayer Parole Totem
Gestor dearchivos
PCManFM Thunar Nautilus
Interfaz encatalan
Sı Sı Sı
Soporte paraescritura dederecha aizquierda
Sı Sı Sı
58
Apendice C
Funcionalidades por programa
Cuadro C.1: Procesador de textos
AbiwordCalligraWords
LibreOfficeWriter
Compatible condocumentos .docx
(Office 2010)No Sı Sı
Compatible condocumentos .swx
(LibreOffice,OpenOffice)
No Sı Sı
Posibilidad de anadircomentarios a los
documentosSı Sı Sı
Crear graficos y dibujossin necesidad de unaherramienta externa
No No Sı
Integracion con unasuite ofimatica
completaNo Sı Sı
Version para Mac OS X Sı Sı Sı
59
Cuadro C.2: Hoja de calculosCalligraSheets
GnumericLibreOffice
Calc
Corrector ortografico Sı No SıImprimir seleccion Sı Sı No
Alto numero de celdas No Sı NoInmobilizar paneles No Sı NoImportar / exportar
tablas LaTeXNo Sı Sı
Cuadro C.3: Cliente de correoKMail SeaMonkey Sylpheed Thunderbird
Filtroanti-phishing
Sı No No Sı
Lector de feedsRSS sin necesidadde complementos
No Sı No Sı
Vista previa dedocumentos
No No No No
Cuadro C.4: Navegador
Chro
miu
m
Dillo
Ep
iphany
Fir
efo
x
Konkero
r
Mid
ori
NetS
urf
SeaM
onkey
Bloqueo popups Sı No No Sı Sı No Sı SıBloqueo publicidad No No No Sı Sı Sı Sı Sı
Control por voz No No No Sı No No No NoGestos de raton No No No No Sı Sı No No
Conversion texto-a-voz (Text-to-speech) No No No No No No No NoSu propia version de Flash Sı No No No No No No No
Lector de feeds RSS incorporado No No No Sı Sı No No SıGestor de contrasenas Sı No Sı Sı Sı No No Sı
60
Cuadro C.5: Protocolos MIAyttm Empathy Kopete Pidgin
Yahoo! Mail Sı No Sı SıWindows Live
MessengerSı Sı Sı Sı
XMPP Sı Sı Sı SıIRC Sı Sı Sı Sı
Skype No No No NoMySpace IM No No No Sı
Cuadro C.6: Cliente MIAyttm Empathy Pidgin
Emoticonos graficos Sı Sı SıEmoticonos graficos
definidos por el usuarioSı Sı Sı
Chat de voz No Sı SıChat de vıdeo No Sı Sı
Escritura a mano No No NoSoporte multi-cuenta Sı Sı SıCorrector ortografico Sı Sı Sı
61
Cuadro C.7: Reproductor de vıdeo
Dra
gon
pla
yer
KP
layer
MP
layer
om
xpla
yer
Paro
le
Tote
m
VL
C
XB
MC
Xin
e
Soporte subtıtulos Sı Sı Sı No Sı Sı Sı Sı SıControl de imagen No Sı Sı No No Sı Sı Sı SıControl de sonido No Sı Sı No No No Sı Sı No
Re-sincronizacion de audio No Sı Sı No No No Sı Sı SıRe-sincronizacion de vıdeo No Sı Sı No No No Sı Sı Sı
Soporte para VCD Sı Sı Sı No Sı Sı Sı Sı SıSoporte para SVCD Sı Sı Sı No Sı Sı Sı Sı Sı
Soporte DVD Sı Sı Sı No Sı Sı Sı Sı SıSoporte para HD-DVD No No No No No No No Sı No
Soporte Blu-ray No No No No No No No Sı No
Cuadro C.8: Gestor de archivos
EF
M
Konkero
r
Nauti
lus
PC
man
FM
RO
XF
iler
Thunar
Miniaturas Sı Sı Sı Sı Sı SıPestanas No Sı Sı Sı No No
Doble panel Sı Sı Sı No No NoPrevisualizaciones No Sı Sı No Sı No
Navegar por archivos comprimidos No Sı No No No No
62
Apendice D
Funcionalidades por distribucion
El protocolo de mensajerıa instantanea “MySpace IM” se ha descartado, ya queno recibio ningun voto y resulta irrelevante.
Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” sehan eliminado debido a que los PCs con los que se tratara no disponen del hardwarenecesario.
La fila “Total (abs)” indica el total de votos para las funcionalidades con mas del50 % de votos.
La fila “Total ( %)” indica el porcentaje de funcionalidades con mas del 50 % devotos que cumple.
La fila “Total normalizado” es una ponderacion teniendo en cuenta todas lasfuncionalidades y su valor normalizado (vease el apendice A).
63
Leyenda: 1 = Sı; 0 = No; 0,5 = Parcial
Funcionalidad
Bod
hi
Lin
ux
Cru
nch
Ban
g
Debia
n
Lin
ux
Min
t
Pu
ppy
Lin
ux
Sla
ckw
are
Lubuntu
Xubuntu
Ubuntu
KD
E
XF
CE
Pro
cesa
dor
de
texto
s Compatible condocumentos .docx
0 0 0 0 0 1 0 0 0 1
Compatible condocumentos .swx
0 0 0 0 0 1 0 0 0 1
Posibilidad de anadircomentarios a los
documentos0 1 0 1 1 1 0 1 1 1
Crear graficos ydibujos
0 0 0 0 0 0 0 0 0 1
Integracion con unasuite ofimatica
completa0 0 0 0 0 1 0 0 0 1
Version para Mac OSX
0 1 0 1 1 1 0 1 1 1
Hoja
de
calc
ulo Corrector ortografico 0 0 0 0 0 1 0 0 0 1
Imprimir seleccion 0 1 0 1 1 1 0 1 0 0Alto numero de
celdas0 1 0 1 1 0 0 1 0 0
Immobilizar paneles 0 1 0 1 1 0 0 1 0 0Importar / exportar
tablas LaTeX0 1 0 1 1 0 0 1 0 1
Loca
liza
. Interfaz en catalan 0,5 0,5 1 0,5 0,5 1 1 1 1 1Soporte para
escritura de derecha aizquierda
0 1 1 1 0 1 1 1 1 1
64
Funcionalidad
Bod
hi
Lin
ux
Cru
nch
Ban
g
Deb
ian
Lin
ux
Min
t
Pup
py
Lin
ux
Sla
ckw
are
Lubuntu
Xubuntu
Ubuntu
KD
E
XF
CE
Corr
eo Filtro anti-phishing 0 0 1 1 0 1 1 0 1 1
Lector de feeds RSS 0 0 1 1 1 1 1 0 1 1Vista previa de
documentos de texto0 0 0 0 0 0 0 0 0 0
Navegador Bloqueo de pop-ups 0 1 1 1 1 1 1 1 1 1
Bloqueo de publicidad 1 1 1 1 1 1 1 0 1 1Control por voz 0 1 1 1 0 1 1 0 1 1Gestos de raton 1 0 0 0 0 1 0 0 0 0
Conversiontexto-a-voz
0 0 0 0 0 0 0 0 0 0
Incorpora su propioplugin Flash
0 0 0 0 0 0 0 1 0 0
Lector de feeds RSS 0 1 1 1 1 1 1 0 1 1Gestor de contrasenas 0 1 1 1 1 1 1 1 1 1
Pro
toco
los
MI Yahoo! Mail 0 0 0 1 1 0 0 1 1 0
Windows Livemessenger
0 0 0 1 1 1 1 1 1 1
XMPP (Google talk,Facebook chat)
0 0 0 1 1 1 1 1 1 1
IRC 0 0 0 1 1 1 1 1 1 1Skype 0 0 0 0 0 0 0 0 0 0
Cli
ente
MI Emoticonos graficos 0 0 0 1 1 1 1 1 1 1
Emoticonos graficosdefinidos por el
usuario0 0 0 1 1 1 1 1 1 1
Chat de voz 0 0 0 1 0 1 1 1 1 1Chat de vıdeo 0 0 0 1 0 1 1 1 1 1
Escritura a mano 0 0 0 0 0 0 0 0 0 0Soporte multi-cuenta 0 0 0 1 1 1 1 1 1 1Corrector ortografico 0 0 0 1 1 1 1 1 1 1
65
Funcionalidad
Bod
hi
Lin
ux
Cru
nch
Ban
g
Deb
ian
Lin
ux
Min
t
Pup
py
Lin
ux
Sla
ckw
are
Lubuntu
Xubuntu
Ubuntu
KD
E
XF
CE
Rep
rod
uct
or
de
vıd
eo Soporte para
subtıtulos0 1 1 1 1 1 1 1 1 1
Control de imagen 0 1 1 1 1 1 1 1 0 1Control de sonido
(tono)0 1 0 1 1 1 0 1 0 0
Resincronizacion deaudio
0 1 0 1 1 1 1 1 0 0
Resincronizacion desubtıtulos
0 1 0 1 1 1 1 1 0 0
Soporte para VCD 0 1 1 1 1 1 1 1 1 1Soporte para SVCD 0 1 1 1 1 1 1 1 1 1Soporte para DVD 0 1 1 1 1 1 1 1 1 1
Gest
or
de
ar.
Miniaturas(Thumbnails)
1 1 1 1 1 1 1 1 1 1
Pestanas 0 0 1 1 0 1 0 1 0 1Doble panel 1 0 1 0 0 1 0 0 0 1
Previsualizaciones 0 0 1 0 1 1 0 0 0 1Navegar por archivos
comprimidos0 0 0 0 0 1 0 0 0 0
Tota
l Total mayoritarios(abs)
2,5 12,5 10 19,5 16,5 23 15 19 13 19
Total mayoritarios( %)
8,33 41,67 33,33 65,00 55,00 76,67 50,00 63,33 43,33 63,33
Total normalizado( %)
9,49 43,93 38,77 70,14 60,72 83,49 55,77 65,67 51,04 72,72
66
Apendice E
Codigo fuente del benchmark(version 1)
E.1. run.sh
Este archivo contiene el orden en el que deben medirse los parametros y otrasinstrucciones necesarias (comprobaciones, pausas, reinicios, etc.).
#!/bin/bash
#In order to measure the boot time , this script must be
executed at boot.
cd ~/ benchmark #files must be located here
params=${*:1}
if hash lsb_release 2> /dev/null; then
output_file=‘lsb_release -is‘
else
output_file="unknown"
fi
output_file="results -$output_file.txt"
if [[ $params == *-h* ]]; then
echo "Usage: $0 [PARAMETERS]"
67
echo "Valid parameters:"
echo " -h : Show this message."
echo " -r : Reboot automatically (may require
permissions)."
echo " -n : Do not measure network speed."
echo " -p : Do not measure power consumption (this
measurement requires user input)."
echo " -i : Install dependencies automatically (
uses commands.sh; may require permissions)."
echo "Results will be written to $output_file."
exit 1
fi
[[ $params == *-n* ]] && n=true;
[[ $params == *-p* ]] && p=true;
[[ $params == *-i* ]] && i=true;
function reboot {
if ! [[ $params == *-r* ]]; then
read -p "Ready to reboot (y/n)? " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
/sbin/reboot || echo "Done. Please , reboot the
system now."
fi
exit 1
fi
/sbin/reboot || echo "Done. Please , reboot the system
now."
}
if [ ! -f state ]; then
echo 1 > state
fi
state=‘cat state‘
function save_state {
if [[ "$1" == "" ]]; then
68
state=‘expr $state + 1‘
else
state=$1
fi
echo $state > state
}
function check_install {
if [ $i ]; then
source ./ install_cmd.sh
if [[ "$1" == "/usr/bin/time" ]]; then
install_cmd time
else
install_cmd $1
fi
fi
while ! hash $1 2> /dev/null; do
read -p "Please , install $1 now and press Enter
when finished."
done
}
if [ $state -le 4 ]; then
echo "Phase $state of 4"
echo "------------"
fi
case $state in
1 )
check_install "/usr/bin/time"
echo "There will now be a 60 second pause."
if ! [ $p ]; then
echo "User input will be needed at the end of
the pause." #in order to measure power
consumption
fi
sleep 60
69
./ benchmark.sh MEMORY DISK > $output_file
# memory_disk_discard
check_install bc
if ! [ $p ]; then
./ benchmark.sh POWER >> $output_file
fi
check_install make
check_install gcc
echo "Compiling the Linux kernel. This may take a
while."
./ benchmark.sh KERNEL1 >> $output_file
save_state
reboot
;;
2 )
./ benchmark.sh BOOT >> $output_file
echo "There will now be a 60 second pause."
sleep 60
echo "Compiling the Linux kernel. This may take a
while."
./ benchmark.sh KERNEL4 >> $output_file
check_install libreoffice
#execute libreoffice for the first time , just for
good measure.
lowriter &
sleep 20 && killall soffice.bin
if ! [ $n ]; then
while ! ping -q -c 1 example.org > /dev/null;
do
read -p "Please , connect to the Internet
now and press Enter when finished."
done
echo "Downloading a big file. This may take a
while."
./ benchmark.sh NETWORK >> $output_file
fi
save_state
reboot
70
;;
3)
echo "There will now be a 60 second pause."
sleep 60
./ benchmark.sh LO_STARTUP >> $output_file
save_state
reboot
;;
4)
echo "There will now be a 60 second pause."
sleep 60
echo "Opening a big file. This may take a while."
./ benchmark.sh LO_FILE_STARTUP >> $output_file
echo "Benchmark finished."
save_state
# estimate
# ./ statistics.sh
;;
esac
71
E.2. benchmark.sh
Este archivo contiene el codigo capaz de medir los parametros por separado.
#!/bin/bash
#tests:
#BOOT: boot time
#DISK: disk usage
#MEMORY: memory usage
#NETWORK: network speed
#KERNEL1: time to compile a Linux kernel , using 1 thread
#KERNEL4: time to compila a Linux kernel , using 4 threads
#LO_STARTUP: time to start LibreOffice
#LO_FILE_STARTUP: time to open a (big) file in LibreOffice
tests=${*:1}
cd ~/ benchmark
#configuration
#file to download in the network test
URL="http :// speedtest.wdc01.softlayer.com/downloads/
test500.zip"
#file to use in the lo_file test
perl -e ’print "a"x1000000; print "\n"’ > many_as.txt
LO_FILE="many_as.txt"
#auxiliary functions
function round {
rounded=‘echo "($1+0.5)/1" | bc‘
echo $rounded
}
function lobench {
delay=1
rm -rf /tmp/*.tmp
lowriter ${*:1} >/dev/null 2>&1 &
while [ "$pid" == "" ]; do
pid=‘pidof soffice.bin‘
72
done
iddle="0"
while [ "$iddle" == "0" ]; do
cpu_usage=‘top -bn 2 -p $pid -d $delay | tail -n 2
|grep -v M‘
cpu_usage=‘echo $cpu_usage | cut -f9 -d’ ’ | sed s
/,/./‘
iddle=‘echo "$cpu_usage == 0" | bc‘
done
kill $pid
}
function get_time {
cmd=${*:1}
time=‘{ time $cmd >/dev/null 2>&1 ; } 2>&1 | grep real
| cut -f2 | sed s/h/*3600+/ | sed s/m/*60+/ | sed
s/s// | bc‘
echo $time
}
function compile {
THREADS=$1
if [ "$THREADS" == "" ]; then
THREADS=1
fi
cd $KERNEL_FOLDER > /dev/null
make alldefconfig -j $THREADS > /dev/null
KERNEL_TIME=‘get_time make bzImage -j $THREADS ‘
make distclean -j $THREADS > /dev/null
cd - > /dev/null
echo KERNEL$THREADS $KERNEL_TIME seconds
}
#startup time
#Assuming the script is run at startup. You should remove
any possible delays at startup (grub timeout , login
screens ...).
if [[ $tests == *BOOT* ]]; then
73
BOOT_TIME=‘cat /proc/uptime | awk ’{print $1}’‘
echo BOOT $BOOT_TIME seconds
fi
#memory
if [[ $tests == *MEMORY* ]]; then
MEMORY=‘free -m |sed -n 2p | awk ’{print $3}’‘
echo MEMORY $MEMORY MB
fi
#disk
if [[ $tests == *DISK* ]];then
DISK=‘df | grep rootfs ‘
if [[ "$DISK" != "" ]]; then
#Raspberry Pi
DISK=‘df -m | grep rootfs | awk ’{print $3}’‘
DISK=$(echo "scale=2;${DISK} / 1024" | bc)
else
#DISK=‘df -m | sed -n 2p | awk ’{print $3}’‘
DISK=‘df -m | grep sda | awk ’{print $3}’‘
DISK=‘echo $DISK | sed ’s/ /+/g’ | bc‘
DISK=$(echo "scale=2;(${DISK} - 71) / 1024" | bc)
# 71 MiB is the size of the benchmark files
fi
echo DISK $DISK GB
fi
#network
if [[ $tests == *NETWORK* ]]; then
NETWORK=‘wget -O /dev/null $URL 2>&1 | grep ’\([0-9]\+
[KM]B/s\)’ | cut -f3 ,4 -d ’ ’ | sed ’s/(//’ | sed
’s/)//’ | sed ’s/B\/s//’ | sed ’s/K/*1024/ ’ | sed ’
s/M/*1024*1024/ ’‘
NETWORK=‘echo $NETWORK / 1024 | bc‘
echo NETWORK $NETWORK KB/s
fi
#kernel compilation
74
if [[ $tests == *KERNEL* ]]; then
KERNEL_FILE=‘ls linux-[0-9]*.[0-9]*.[0-9]*.tar.xz‘
KERNEL_FOLDER=‘echo $KERNEL_FILE | sed ’s/.tar.xz//’‘
tar -xf $KERNEL_FILE --xz
fi
#compile using 1 thread
if [[ $tests == *KERNEL1* ]]; then
compile
fi
#compile using 4 threads
if [[ $tests == *KERNEL4* ]]; then
compile 4
fi
if [[ $tests == *KERNEL* ]]; then
rm -rf $KERNEL_FOLDER
fi
#libreoffice
if [[ $tests == *LO_STARTUP* ]]; then
LO_TIME=‘get_time lobench ‘
echo LO_STARTUP $LO_TIME seconds
fi
if [[ $tests == *LO_FILE_STARTUP* ]]; then
LO_FILE_TIME=‘get_time lobench $LO_FILE ‘
echo LO_FILE_STARTUP $LO_FILE_TIME seconds
fi
#power
if [[ $tests == *POWER* ]]; then
echo -n "Please , enter the power consumption of the
system (in Watts): "
while [[ "$power" == "" ]]; do
read power
75
power=‘echo $power | sed s/,/./‘
if ! [[ $power =~ ^[0-9]+([.][0-9]+)?$ ]]; then
echo Please , enter only a number.
power=""
fi
done
echo POWER $power W
fi
76
E.3. statistics.sh
Este script toma los archivos resultantes de correr el benchmark en las distin-tas distribuciones, calcula cuantos requisitos cumple cada distribucion y ordena lasdistribuciones en orden de adecuacion.
#!/bin/bash
x=$0
[[ ${*:1} == *-n* ]] && n=true
[[ ${*:1} == *-p* ]] && p=true
while (( "$#" )); do
if [[ "$1" == "-h" ]]; then
echo "Usage:"
echo " $x [-d TOTAL_DISK] [-m TOTAL_MEMORY] [-n
] [-p]"
echo " $x -h"
echo ""
echo "-d TOTAL_DISK : Specify the size of the disk
(in GiB , not counting swap)."
echo "-m TOTAL_MEMORY : Specify the size of the
memory (in MiB)."
echo "-n : Ignore network speed tests. "
echo "-p : Ignore power consumption tests. "
echo "-h : Show this message."
exit 1
elif [[ "$1" == "-d" ]]; then
shift
total_disk=‘echo $1 | sed s/,/./g‘
if ! [[ $total_disk =~ ^[0-9]+([.][0-9]+)?$ ]];
then
echo "Disk size must be a number."
exit 1
fi
elif [[ "$1" == "-m" ]]; then
shift
total_memory=‘echo $1 | sed s/,/./g‘
77
if ! [[ $total_memory =~ ^[0-9]+([.][0-9]+)?$ ]];
then
echo "Memory size must be a number."
exit 1
fi
fi
shift
done
filenames=(results -*.txt)
n=${#filenames[@]}
for filename in ${filenames[@]}; do
memory+=(‘grep MEMORY $filename | cut -d’ ’ -f2‘)
disk+=(‘grep DISK $filename | cut -d’ ’ -f2‘)
boot_time+=(‘grep BOOT $filename | cut -d’ ’ -f2‘)
lo_startup+=(‘grep LO_STARTUP $filename | cut -d’ ’ -
f2‘)
lo_file_startup+=(‘grep LO_FILE_STARTUP $filename |
cut -d’ ’ -f2‘)
kernel1+=(‘grep KERNEL1 $filename | cut -d’ ’ -f2‘)
kernel4+=(‘grep KERNEL4 $filename | cut -d’ ’ -f2‘)
network+=(‘grep POWER $filename | cut -d’ ’ -f2‘)
if ! [ $n ]; then
network+=(‘grep POWER $filename | cut -d’ ’ -f2‘)
fi
if ! [ $p ]; then
power+=(‘grep POWER $filename | cut -d’ ’ -f2‘)
fi
done
avg_boot_time=‘echo "scale=2; (0 $(printf "+ %s" "${
boot_time[@]}") ) / $n" | bc‘
avg_lo_startup=‘echo "scale=3; (0 $(printf "+ %s" "${
lo_startup[@]}") ) / $n" | bc‘
avg_lo_file_startup=‘echo "scale=3; (0 $(printf "+ %s" "${
lo_file_startup[@]}") ) / $n" | bc‘
78
avg_kernel1=‘echo "scale=3; (0 $(printf "+ %s" "${kernel1[@
]}") ) / $n" | bc‘
avg_kernel4=‘echo "scale=3; (0 $(printf "+ %s" "${kernel4[@
]}") ) / $n" | bc‘
if ! [ $n ]; then
avg_network=‘echo "scale=3; (0 $(printf "+ %s" "${
network[@]}") ) / $n" | bc‘
fi
if ! [ $p ]; then
avg_power=‘echo "scale=1; (0 $(printf "+ %s" "${power[@
]}") ) / $n" | bc‘
fi
[[ "$total_disk" == "" ]] && total_disk=‘df -m | grep sda
| awk ’BEGIN {ORS="+";} {print $2}’‘ && total_disk=‘
echo "scale=2; ($total_disk 0)/1024" | bc‘
[[ "$total_memory" == "" ]] && total_memory=‘free -m | sed
-n 2p | awk ’{print $2}’‘
for (( i=0; i < $n; ++i)); do
filenames[$i]=‘echo ${filenames[$i]} | sed s/results -
// | sed s/.txt//‘
done
results=()
for (( i=0; i < $n; ++i )); do
fails[$i]=‘echo "${disk[$i]} > $total_disk /2" | bc‘
fails[$i]=‘expr ${fails[$i]} + $(echo "${memory[$i]} >
$total_memory /2" | bc)‘
fails[$i]=‘expr ${fails[$i]} + $(echo "${boot_time[$i]
} > $avg_boot_time*1.1" | bc)‘
fails[$i]=‘expr ${fails[$i]} + $(echo "${lo_startup[$i
]} > $avg_lo_startup*1.1" | bc)‘
fails[$i]=‘expr ${fails[$i]} + $(echo "${
lo_file_startup[$i]} > $avg_lo_file_startup*1.1" |
bc)‘
79
fails[$i]=‘expr ${fails[$i]} + $(echo "${kernel1[$i]}
> $avg_kernel1*1.1" | bc)‘
fails[$i]=‘expr ${fails[$i]} + $(echo "${kernel4[$i]}
> $avg_kernel4*1.1" | bc)‘
if ! [ $n ]; then
fails[$i]=‘expr ${fails[$i]} + $(echo "${network[$
i]}*1.1 < $avg_network" | bc)‘
fi
if ! [ $p ]; then
fails[$i]=‘expr ${fails[$i]} + $(echo "${power[$i]
} > $avg_power*1.1" | bc)‘
fi
results+=("${fails[$i]} flaw(s): ${filenames[$i]}")
done
readarray -t sorted < <(for a in "${results[@]}"; do echo
"$a"; done | sort)
for (( i=0; i < $n; ++i )); do
echo ${sorted[$i]}
done
80
Apendice F
Pruebas de rendimiento en PCs deTxT
F.1. PC A
Procesador: Pentium 4 @ 3, 20 GHz (Hyperthreading)
Memoria: 2 × 512 MB
ParamteroLinuxMint
PuppyLinux
Slackware(KDE)
Lubuntu Ubuntu
Disco (GB) 2,48 0,67 6,67 1,84 2,37Memoria (MB) 477 183 684 480 670
Tiempo de arranque del SO(s)
31,99 21,06 74,34 26,86 25,20
Tiempo de arranque deLibreOffice (s)
4,591 7,811 5,700 6,156 5,631
Tiempo de apertura demany_as.txt (s)
74,111 118,034 73,021 74,909 72,019
Tiempo de compilacion enserie (s)
420,378 360,252 528,270 389,047 366,772
Tiempo de compilacion enparalelo (s)
296,251 301,140 350,220 320,031 299,772
Consumo energetico (W) 72,5 73,0 73,0 73,0 73,0
81
F.2. PC B
Procesador: Pentium D @ 3,00 GHz (Dual core)
Memoria: 2 × 512 MB
ParamteroLinuxMint
PuppyLinux
Slackware(KDE)
Lubuntu Ubuntu
Disco (GB) 2,45 0,79 6,68 1,82 2,38Memoria (MB) 448 105 867 370 722
Tiempo de arranque del SO(s)
34,22 29,12 78,65 33,76 27,33
Tiempo de arranque deLibreOffice (s)
5,554 7,492 12,826 5,121 5,313
Tiempo de apertura demany_as.txt (s)
72,186 116,605 116,925 72,321 70,280
Tiempo de compilacion enserie (s)
357,118 358,394 424,427 386,490 362,490
Tiempo de compilacion enparalelo (s)
190,793 191,345 228,274 203,620 190,887
Consumo energetico (W) 66,0 64,0 67,0 65,5 66,0
82
F.3. PC C (Core 2 Duo)
Procesador: Core 2 Duo 3,13 GHz (Dual core)
Memoria: 2 × 1 GB
ParamteroLinuxMint
PuppyLinux
Slackware(KDE)
Lubuntu Ubuntu
Disco (GB) 2,48 0,70 6,68 1,84 2,38Memoria (MB) 575 180 707 480 647
Tiempo de arranque del SO(s)
20,39 24,92 78,93 21,17 24,31
Tiempo de arranque deLibreOffice (s)
5,630 6,076 9,134 5,455 5,002
Tiempo de apertura demany_as.txt (s)
73,113 115,364 126,590 72,735 69,822
Tiempo de compilacion enserie (s)
239,780 243,958 292,331 258,470 239,966
Tiempo de compilacion enparalelo (s)
127,990 133,732 158,848 143,930 133,058
Consumo energetico (W) 57,0 55,5 57,0 57,0 57,0
83
Apendice G
Codigo fuente del benchmark(version 2)
El archivo benchmark.sh es exactamente el mismo (aunque las funciones paramedir la velocidad de red y el consumo electrico no se usaran). Idem con el archivostatistics.sh. El archivo run.sh tambien es igual, con la excepcion de que se des-comentan las funciones memory_discard y estimation. A continuacion se muestrala implementacion de dichas funciones.
84
G.1. memory disk discard
Esta funcion intenta determinar la distribucion ideal en base a la cantidad dememoria y disco usados y las totales disponibles. En caso de que se pueda determinarla distribucion ganadora con solo estos datos, el benchmark no continuara.
function memory_disk_discard {
total_memory=‘free -m | sed -n 2p | awk ’{print $2}’‘
memory_usage=‘grep MEMORY $output_file | cut -d’ ’ -f2
‘
# in MiB , not GiB
total_disk=‘df -m | grep sda | awk ’{print $3}’‘
total_disk=‘echo $total_disk | sed ’s/ /+/g’ | bc‘
disk_usage=‘df -m | grep sda | awk ’{print $4}’‘
disk_usage=‘echo $disk_usage | sed ’s/ /+/g’ | bc‘
if [[ $memory_usage -gt $((total_memory /2)) ]] || [[ $
disk_usage -gt $total_disk ]]; then
if [[ $((memory_usage -180)) -le $((total_memory /2)
) ]] && [[ $((disk_usage+90)) -le $((total_disk
/2)) ]]; then
echo "Due to memory and / or disk limitations ,
the best option is Linux Mint."
else
echo "Due to memory and / or disk limitations ,
the best option is Puppy Linux."
fi
save_state 5
exit 0
fi
}
85
G.2. estimation
Esta funcion decide que distribucion es la ideal una vez se han realizado todaslas mediciones para una de las distribuciones.
function estimation {
MEMORY_USAGE=‘grep MEMORY_USAGE results -ubuntu.txt |
cut -d -f2‘
DISK_USAGE=‘grep DISK_USAGE results -ubuntu.txt | cut -
d -f2‘
BOOT=‘grep BOOT results -ubuntu.txt | cut -d’ ’ -f2‘
DISK_USAGE=‘grep DISK_USAGE results -ubuntu.txt | cut -
d’ ’ -f2‘
MEMORY_USAGE=‘grep MEMORY_USAGE results -ubuntu.txt |
cut -d’ ’ -f2‘
KERNEL1=‘grep KERNEL1 results -ubuntu.txt | cut -d’ ’ -
f2‘
# KERNEL4=‘grep KERNEL4 results -ubuntu.txt | cut -d’ ’ -
f2‘
LO_STARTUP=‘grep LO_STARTUP results -ubuntu.txt | cut -
d’ ’ -f2‘
LO_FILE_STARTUP=‘grep LO_FILE_STARTUP results -ubuntu.
txt | cut -d’ ’ -f2‘
#estimate Slackware ’s performance
echo MEMORY_USAGE $((MEMORY_USAGE + 73)) > results -
slackware.txt
echo DISK_USAGE $((DISK_USAGE + 4403)) >> results -
slackware.txt
BOOT_SLACKWARE=‘echo "scale=2; ${BOOT} + 51.69" | bc‘
echo BOOT $BOOT_SLACKWARE >> results -slackware.txt
echo DISK_USAGE $((DISK_USAGE + 4608)) >> results -
slackware.txt
echo MEMORY_USAGE $((MEMORY_USAGE + 73)) >> results -
slackware.txt
KERNEL1_SLACKWARE=‘echo "scale=2; ${KERNEL1} + 92.124"
| bc‘
echo KERNEL1 $KERNEL1_SLACKWARE >> results -slackware.
txt
86
# KERNEL4_SLACKWARE=‘echo "scale=2; ${KERNEL4} + " | bc‘
# echo KERNEL4 $KERNEL4_SLACKWARE >> results -slackware.
txt
LO_STARTUP_SLACKWARE=‘echo "scale=2; ${LO_STARTUP} +
2.72" | bc‘
echo LO_STARTUP $LO_STARTUP_SLACKWARE >> results -
slackware.txt
LO_FILE_STARTUP_SLACKWARE=‘echo "scale=2; ${
LO_FILE_STARTUP} + 34.805" | bc‘
echo LO_FILE_STARTUP $LO_FILE_STARTUP_SLACKWARE >>
results -slackware.txt
#estimate Linux Mint ’s performance
echo MEMORY_USAGE $((MEMORY_USAGE - 180)) > results -
slackware.txt
echo DISK_USAGE $((DISK_USAGE + 90)) >> results -
slackware.txt
BOOT_MINT=‘echo "scale=2; ${BOOT} + 3.25" | bc‘
echo BOOT $BOOT_MINT >> results -mint.txt
echo DISK_USAGE $((DISK_USAGE + 367)) >> results -mint.
txt
echo MEMORY_USAGE $((MEMORY_USAGE + -180)) >> results -
mint.txt
KERNEL1_MINT=‘echo "scale=2; ${KERNEL1} + 16.21" | bc‘
echo KERNEL1 $KERNEL1_MINT >> results -mint.txt
# KERNEL4_MINT=‘echo "scale=2; ${KERNEL4} + " | bc‘
# echo KERNEL4 $KERNEL4_MINT >> results -mint.txt
echo LO_STARTUP $LO_STARTUP >> results -mint.txt
LO_FILE_STARTUP_MINT=‘echo "scale=2; ${LO_FILE_STARTUP
} + 2.43" | bc‘
echo LO_FILE_STARTUP $LO_FILE_STARTUP_MINT >> results -
mint.txt
}
87
Apendice H
Estimaciones en base a ladistribucion live
Los parametros calculados (columnas) son los siguientes:
r: Coeficiente de correlacion de Pearson. Si r es cercana a 1, indica una fuerte co-rrelacion lineal directa; si es cercana a -1 indica una fuerte correlacion linealinversa; si es cercana a 0, indica que no existe correlacion lineal.
StdErr: Error estandar de r.
Test hipo.: Test de hipotesis de r. Es igual al error estandar de r × t de studentpara el intervalo de confianza del 80 % y n− 2 grados de libertad (= 3,08).
Sign.: Indica si la correlacion entre la variable y el tiempo de arranque es estadısti-camente significativa. Es decir, si r >el test de hipotesis de r.
Las variables observadas son las siguientes:
Tiempo de arranque del SO: Valor medido por el benchmark (Ubuntu).
Tiempo de arranque de LO: Tiempo de arranque de LibreOffice Writer. Valormedido por el benchmark (Ubuntu).
Tiempo de arranque de many as: Tiempo de arranque de LibreOffice Writer abrien-do un archivo grande. Valor medido por el benchmark (Ubuntu).
Ancho de banda del disco: Ancho de banda de lectura del disco.
Latencia: Tiempo que se tarda en leer un byte del disco.
88
Compilacion (1 thread): Tiempo que tarda el sistema en compilar un programade referencia usando solo 1 thread.
Compilacion (4 threads): Tiempo que tarda el sistema en compilar un programade referencia usando 4 threads.
Lectura RAM: tramo 1: Ancho de banda de lectura de la memoria para archivosde tamano menor a 32 kiB.
Lectura RAM: tramo 2: Ancho de banda de lectura de la memoria para archivosde tamano entre 32 kiB y 256 kiB.
Lectura RAM: tramo 3: Ancho de banda de lectura de la memoria para archivosde tamano entre 256 kiB y 1 MiB.
Lectura RAM: tramo 4: Ancho de banda de lectura de la memoria para archivosde tamano mayor a 2 MiB.
89
Cuadro H.1: Correlacion entre el tiempo de arranque del SO y distintas variables.
PC A PC B PC C r StdErrTesthipo.
Sign.
Tiempo de arranque del SO(s)
25,20 27,33 24,31
Ancho de banda del disco(MB/s)
58,1 42,6 62,7 -1,00 0,07 0,22 Sı
Latencia (ms) 16,9465 21,5512 23,6888 -0,08 1,00 3,07 NoCompilacion (1 thread) (s) 141,983 148,85 107,143 0,82 0,57 1,74 NoCompilacion (4 threads) (s) 105,713 79,778 57,85 0,24 0,97 2,99 No
Lectura RAM: tramo 1(GB/s)
46 43 32 0,57 0,82 2,52 No
Lectura RAM: tramo 2(GB/s)
26 24 16 0,58 0,81 2,50 No
Lectura RAM: tramo 3(GB/s)
20 19 16 0,54 0,84 2,59 No
Lectura RAM: tramo 4(GB/s)
5 4 5 -0,96 0,29 0,88 Sı
90
Cuadro H.2: Correlacion entre el tiempo de arranque de LibreOffice Writer y distintas variables.
PC A PC B PC C r StdErrTesthipo.
Sign.
Tiempo de arranque de LO(s)
5,631 5,313 5,002
Ancho de banda del disco(MB/s)
58,1 42,6 62,7 -0,21 0,98 3,01 No
Latencia (ms) 16,9465 21,5512 23,6888 -0,98 0,20 0,62 SıCompilacion (1 thread) (s) 141,983 148,85 107,143 0,77 0,63 1,95 NoCompilacion (4 threads) (s) 105,713 79,778 57,85 1,00 0,04 0,13 Sı
Lectura RAM: tramo 1(GB/s)
46 43 32 0,95 0,32 0,98 No
Lectura RAM: tramo 2(GB/s)
26 24 16 0,94 0,33 1,03 No
Lectura RAM: tramo 3(GB/s)
20 19 16 0,96 0,28 0,87 Sı
Lectura RAM: tramo 4(GB/s)
5 4 5 0,01 1,00 3,08 No
91
Cuadro H.3: Correlacion entre el tiempo de arranque de LibreOffice Writer abriendo un archivo grande ydistintas variables.
PC A PC B PC C r StdErrTesthipo.
Sign.
Tiempo de arranque demany as (s)
72,019 70,280 69,822
Ancho de banda del disco(MB/s)
58,1 42,6 62,7 0,10 0,99 3,06 No
Latencia (ms) 16,9465 21,5512 23,6888 -0,99 0,12 0,36 SıCompilacion (1 thread) (s) 141,983 148,85 107,143 0,54 0,84 2,59 NoCompilacion (4 threads) (s) 105,713 79,778 57,85 0,96 0,27 0,84 Sı
Lectura RAM: tramo 1(GB/s)
46 43 32 0,80 0,60 1,85 No
Lectura RAM: tramo 2(GB/s)
26 24 16 0,79 0,61 1,88 No
Lectura RAM: tramo 3(GB/s)
20 19 16 0,82 0,57 1,75 No
Lectura RAM: tramo 4(GB/s)
5 4 5 0,32 0,95 2,92 No
92
Cuadro H.4: Correlacion entre el tiempo de el tiempo de compilacion del kernel de Linux con un solo thready distintas variables.
PC A PC B PC C r StdErrTesthipo.
Sign.
Tiempo de compilacion (s) 366,200 362,490 239,366Ancho de banda del disco
(MB/s)58,1 42,6 62,7 -0,66 0,75 2,32 No
Latencia (ms) 16,9465 21,5512 23,6888 -0,76 0,65 2,00 NoCompilacion (1 thread) (s) 141,983 148,85 107,143 0,98 0,18 0,55 SıCompilacion (4 threads) (s) 105,713 79,778 57,85 0,85 0,52 1,60 No
Lectura RAM: tramo 1(GB/s)
46 43 32 0,98 0,18 0,55 Sı
Lectura RAM: tramo 2(GB/s)
26 24 16 0,99 0,16 0,50 Sı
Lectura RAM: tramo 3(GB/s)
20 19 16 0,98 0,22 0,66 Sı
Lectura RAM: tramo 4(GB/s)
5 4 5 -0,48 0,88 2,70 No
93
Apendice I
Ecuaciones para estimar elrendimiento
I.1. Ubuntu
Tiempo de arranque = Ancho de banda del disco ×−0, 19
+Ancho de banda de la memoria (tramo 4) × 0, 88
+32, 10
Tiempo de arranque de LibreOffice Writer = Latencia del disco × 0, 02
+Tiempo de compilacion (4 threads) × 0, 02
+3, 48
Tiempo de apertura de un archivo grande = Latencia del disco ×−0, 58
+Tiempo de compilacion (4 threads) ×−0, 04
+85, 52
Tiempo compilacion del kernel (1 thread) = Tiempo de compilacion con 1 thread × 1, 57
+Ancho de banda de la memoria (tramo 2) × 7, 23
+ − 44, 03
Tiempo compilacion del kernel (4 thread2 ) = Tiempo de compilacion con 4 threads × 0, 74
+Latencia del disco ×−19, 50
+552, 35
94
I.2. Slackware
Tiempo de arranque = Ancho de banda del disco × 1
+Ancho de banda de la memoria (tramo 4) ×−0, 77
+115,25
Tiempo de arranque de LibreOffice Writer = Latencia del disco × 5, 56
+Tiempo de compilacion (4 threads) × 0, 71
+ − 163, 73
Tiempo de apertura de un archivo grande = Latencia del disco × 15, 70
+Tiempo de compilacion (4 threads) × 1, 09
+ − 308, 61
Tiempo compilacion del kernel (1 thread) = Tiempo de compilacion con 1 thread ×−4,11
+Ancho de banda de la memoria (tramo 2) × 37, 80
+129, 36
Tiempo compilacion del kernel (4 thread2 ) = Tiempo de compilacion con 4 threads × 1, 29
+Latencia del disco ×−19, 24
+540, 18
I.3. Linux Mint
Tiempo de arranque = Ancho de banda del disco ×−2, 52
+Ancho de banda de la memoria (tramo 4) × 36, 86
+ − 5, 78
Tiempo de arranque de LibreOffice Writer = Latencia del disco × 0, 42
+Tiempo de compilacion (4 threads) × 0, 04
+ − 6, 56
95
Tiempo de apertura de un archivo grande = Latencia del disco ×−1, 46
+Tiempo de compilacion (4 threads) ×−0, 18
+118, 44
Tiempo compilacion del kernel (1 thread) = Tiempo de compilacion con 1 thread ×−1, 97
+Ancho de banda de la memoria (tramo 2) × 24, 87
+53, 54
Tiempo compilacion del kernel (4 thread2 ) = Tiempo de compilacion con 4 threads × 1, 39
+Latencia del disco ×−15, 06
+404, 05
96
Apendice J
Codigo fuente del benchmark(version 3)
El archivo statistics.sh es igual que el de la primera modalidad de benchmark(incluyendo la opcion de la compilacion del kernel con 4 threads), pero sin las opcionesde velocidad de red y consumo electrico.
J.1. run.sh
Este archivo contiene el orden en el que deben medirse los parametros y otrasinstrucciones necesarias (comprobaciones, pausas, reinicios, etc.). Es completamentedisinto al de las modalidades de benchmark anteriores.
#!/bin/bash
cd ~/ benchmark #files must be located here
params=${*:1}
source memory_disk_discard.sh
source estimation.sh
temp_file=temp-results.txt
echo "There will now be a 60 second pause."
#sleep 60
memory_disk_discard
97
[ ! -f memory_bandwidth.txt ] && echo "Measuring memory
bandwidth. This may take a while." && ./ benchmark.sh
MEMORY_BW2 MEMORY_BW4 > $temp_file
echo "Measuring disk bandwidth. This may take a while."
./ benchmark.sh DISK_BW DISK_LAT >> $temp_file
./ benchmark.sh COMPILE1 COMPILE4 >> $temp_file
DISK_BW=‘grep DISK_BW $temp_file | cut -d’ ’ -f2 | sed s
/,/./‘
MEMORY_BW2=‘grep MEMORY_BW2 $temp_file | cut -d’ ’ -f2 |
sed s/,/./‘
MEMORY_BW4=‘grep MEMORY_BW4 $temp_file | cut -d’ ’ -f2 |
sed s/,/./‘
DISK_LAT=‘grep DISK_LAT $temp_file | cut -d’ ’ -f2 | sed s
/,/./‘
COMPILE1=‘grep COMPILE1 $temp_file | cut -d’ ’ -f2 | sed s
/,/./‘
COMPILE4=‘grep COMPILE4 $temp_file | cut -d’ ’ -f2 | sed s
/,/./‘
estimation
./ statistics.sh
98
J.2. benchmark.sh
Este archivo contiene el codigo capaz de medir los parametros por separado. Escompletamente distinto al de las modalidades de benchmark anteriores. Mide losparametros que se usaran para realizar las estimaciones (ancho de banda del disco,la latencia, etc).
#!/bin/bash
#tests:
#DISK_BW: disk bandwidth
#DISK_LAT: disk latency
#MEMORY_BW1: memory bandwidth (1st segment)
#MEMORY_BW2: memory bandwidth (2nd segment)
#MEMORY_BW3: memory bandwidth (3rd segment)
#MEMORY_BW4: memory bandwidth (4th segment)
#COMPILE1: time to compile a program , using 1 thread
#COMPILE4: time to compila a program , using 4 threads
tests=${*:1}
cd ~/ benchmark
MEMORY_BW_FILE=memory_bandwidth.txt
#auxiliary functions
function round {
rounded=‘echo "($1+0.5)/1" | bc‘
echo $rounded
}
function get_time {
cmd=${*:1}
time=‘{ time $cmd >/dev/null 2>&1 ; } 2>&1 | grep real
| cut -f2 | sed s/h/*3600+/ | sed s/m/*60+/ | sed
s/s// | bc‘
echo $time
}
function compile {
99
THREADS=$1
if [ "$THREADS" == "" ]; then
THREADS=1
fi
cd $COMPILE_FOLDER > /dev/null
./ configure > /dev/null
COMPILE_TIME=‘get_time make -j $THREADS ‘
make clean -j $THREADS > /dev/null
cd - > /dev/null
echo COMPILE$THREADS $COMPILE_TIME seconds
}
function drop_caches {
sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"
sudo sh -c "echo 2 > /proc/sys/vm/drop_caches"
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
}
#memory_bw
if [[ $tests == *MEMORY_BW* ]]; then
sudo /home/user/bandwidth -0.32p/bandwidth32 --quick >
$MEMORY_BW_FILE
fi
if [[ $tests == *MEMORY_BW1* ]]; then
MEMORY_BW1=‘grep "Sequential read (128-bit), size = 16
kB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘
MEMORY_BW1=‘echo "scale=2;${MEMORY_BW1} / 1024" | bc‘
echo MEMORY_BW1 $MEMORY_BW1 MB/s
fi
if [[ $tests == *MEMORY_BW2* ]]; then
MEMORY_BW2=‘grep "Sequential read (128-bit), size =
128 kB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘
MEMORY_BW2=‘echo "scale=2;${MEMORY_BW2} / 1024" | bc‘
echo MEMORY_BW2 $MEMORY_BW2 MB/s
fi
if [[ $tests == *MEMORY_BW3* ]]; then
100
MEMORY_BW3=‘grep "Sequential read (128-bit), size =
512 kB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘
MEMORY_BW3=‘echo "scale=2;${MEMORY_BW3} / 1024" | bc‘
echo MEMORY_BW3 $MEMORY_BW3 MB/s
fi
if [[ $tests == *MEMORY_BW4* ]]; then
MEMORY_BW4=‘grep "Sequential read (128-bit), size =
2.5 MB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘
MEMORY_BW4=‘echo "scale=2;${MEMORY_BW4} / 1024" | bc‘
echo MEMORY_BW4 $MEMORY_BW4 MB/s
fi
#disk_bw
if [[ $tests == *DISK_LAT* ]];then
drop_caches
DISK_LAT=‘sudo dd if=/dev/sda1 of=/dev/null count=1 2>
&1 | tail -n1 | cut -d’ ’ -f 6‘
TEMP=‘echo $DISK_LAT | grep e‘
if [[ ! $TEMP ]]; then
echo DISK_LAT 0
else
echo DISK_LAT $DISK_LAT s
fi
fi
if [[ $tests == *DISK_BW* ]];then
drop_caches
DISK_BW_TMP=‘sudo dd if=/dev/sda1 of=/dev/null count=3
M 2>&1 | tail -n1‘
DISK_BW=‘echo $DISK_BW_TMP | cut -d’ ’ -f8‘
DISK_BW_UNIT=‘echo $DISK_BW_TMP | cut -d’ ’ -f9‘
if [ "$DISK_BW_UNIT" == "GB/s" ]; then
DISK_BW=‘echo "scale=2;${DISK_BW} * 1024" | bc‘
fi
echo DISK_BW $DISK_BW MB/s
fi
#compilation
if [[ $tests == *COMPILE* ]]; then
101
COMPILE_FILE=‘ls papi*.tar.gz‘
COMPILE_FOLDER=‘echo $COMPILE_FILE/src | sed ’s/.tar.
gz//’‘
tar -xzf $COMPILE_FILE
fi
#compile using 1 thread
if [[ $tests == *COMPILE1* ]]; then
compile
fi
#compile using 4 threads
if [[ $tests == *COMPILE4* ]]; then
compile 4
fi
if [[ $tests == *COMPILE* ]]; then
COMPILE_FOLDER=‘echo $COMPILE_FILE | sed ’s/.tar.gz//’
‘
rm -rf $COMPILE_FOLDER
fi
102
J.3. estimation
En esta funcion radica la estadıstica que estima el rendimiento de las distribucio-nes.
function estimations {
#estimate Ubuntu ’s performance
BOOT=‘echo "scale=2;${DISK_BW} * -0.19 + ${MEMORY_BW4}
* 0.87 + 32.10" | bc‘
LO_STARTUP=‘echo "scale=2;${DISK_LAT} * 0.02 + ${
COMPILE4} * 0.02 + 3.48" | bc‘
LO_FILE_STARTUP=‘echo "scale=2;${DISK_LAT} * -0.58 + $
{COMPILE4} * -0.04 + 85.52" | bc‘
KERNEL1=‘echo "scale=2;${COMPILE1} * 1.57 + ${
MEMORY_BW2} * 7.23 - 44.03" | bc‘
KERNEL4=‘echo "scale=2;${COMPILE4} * 0.74 + ${DISK_LAT
} * -19.50 + 552.35" | bc‘
echo "BOOT_TIME $BOOT" > results -ubuntu.txt
echo "LO_STARTUP $LO_STARTUP" >> results -ubuntu.txt
echo "LO_FILE_STARTUP $LO_FILE_STARTUP" >> results -
ubuntu.txt
echo "KERNEL1 $KERNEL1" >> results -ubuntu.txt
echo "KERNEL4 $KERNEL4" >> results -ubuntu.txt
#estimate Slackware ’s performance
BOOT_SLACKWARE=‘echo "scale=2;${DISK_BW} + ${
MEMORY_BW4} * -0.77 + 115.25" | bc‘
LO_STARTUP_SLACKWARE=‘echo "scale=2;${DISK_LAT} * 5.56
+ ${COMPILE4} * 0.71 - 163.73" | bc‘
LO_FILE_STARTUP_SLACKWARE=‘echo "scale=2;${DISK_LAT} *
15.70 + ${COMPILE4} * 1.09 - 308.61" | bc‘
KERNEL1_SLACKWARE=‘echo "scale=2;${COMPILE1} * -4.11 +
${MEMORY_BW2} * 37.80 + 129.26" | bc‘
KERNEL4_SLACKWARE=‘echo "scale=2;${COMPILE4} * 1.29 +
${DISK_LAT} * -19.24 + 540.18" | bc‘
echo "BOOT_TIME $BOOT_SLACKWARE" > results -slackware.
txt
103
echo "LO_STARTUP $LO_STARTUP_SLACKWARE" >> results -
slackware.txt
echo "LO_FILE_STARTUP $LO_FILE_STARTUP_SLACKWARE" >>
results -slackware.txt
echo "KERNEL1 $KERNEL1_SLACKWARE" >> results -slackware
.txt
echo "KERNEL4 $KERNEL4_SLACKWARE" >> results -slackware
.txt
#estimate Linux Mint ’s performance
BOOT_MINT=‘echo "scale=2;${DISK_BW} * -2.52 + ${
MEMORY_BW4} * 36.86 - 5.78" | bc‘
LO_STARTUP_MINT=‘echo "scale=2;${DISK_LAT} * 0.42 + ${
COMPILE4} * 0.04 - 6.56" | bc‘
LO_FILE_STARTUP_MINT=‘echo "scale=2;${DISK_LAT} * -
1.46 + ${COMPILE4} * -0.18 + 118.44" | bc‘
KERNEL1_MINT=‘echo "scale=2;${COMPILE1} * -1.97 + ${
MEMORY_BW2} * 24.87 + 53.54" | bc‘
KERNEL4_MINT=‘echo "scale=2;${COMPILE4} * 1.39 + ${
DISK_LAT} * -15.06 + 404.05" | bc‘
echo "BOOT_TIME $BOOT_MINT" > results -mint.txt
echo "LO_STARTUP $LO_STARTUP_MINT" >> results -mint.txt
echo "LO_FILE_STARTUP $LO_FILE_STARTUP_MINT" >>
results -mint.txt
echo "KERNEL1 $KERNEL1_MINT" >> results -mint.txt
echo "KERNEL4 $KERNEL4_MINT" >> results -mint.txt
}
104
Apendice K
Funcionalidades de Raspbian
El protocolo de mensajerıa instantanea “MySpace IM” se ha descartado, ya queno recibio ningun voto y resulta irrelevante.
Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” sehan eliminado debido a que la Raspberry Pi no dispone del hardware necesario.
La fila “Total (abs)” indica el total de votos para las funcionalidades con mas del50 % de votos.
La fila “Total ( %)” indica el porcentaje de funcionalidades con mas del 50 % devotos que cumple.
La fila “Total normalizado” es una ponderacion teniendo en cuenta todas lasfuncionalidades y su valor normalizado (vease el apendice A).
105
Leyenda: 1 = Sı; 0 = No; 0,5 = Parcial
Funcionalidad
Base
Mod
Pote
nci
al
Pro
cesa
dor
de
texto
s Compatible condocumentos .docx
0 1 1
Compatible condocumentos .swx
0 1 1
Posibilidad de anadircomentarios a los
documentos0 1 1
Crear graficos ydibujos
0 1 1
Integracion con unasuite ofimatica
completa0 1 1
Version para Mac OSX
0 1 1
Ho
jade
calc
ulo Corrector ortografico 0 1 1
Imprimir seleccion 0 1 1Alto numero de
celdas0 1 1
Immobilizar paneles 0 1 1Importar / exportar
tablas LaTeX0 1 1
Loca
liza
. Interfaz en catalan 1 1 1Soporte para
escritura de derecha aizquierda
0 1 1
106
Funcionalidad
Base
Mod
Pote
nci
al
Corr
eo Filtro anti-phishing 0 1 1
Lector de feeds RSS 0 1 1Vista previa de
documentos de texto0 0 0
Navegador Bloqueo de pop-ups 0 1 1
Bloqueo de publicidad 1 1 1Control por voz 0 1 1Gestos de raton 1 1 1
Conversiontexto-a-voz
0 0 0
Incorpora su propioplugin Flash
0 1 1
Lector de feeds RSS 0 1 1Gestor de contrasenas 0 1 1
Pro
toco
los
MI Yahoo! Mail 0 1 1
Windows Livemessenger
0 1 1
XMPP (Google talk,Facebook chat)
0 1 1
IRC 0 1 1Skype 0 0 0
Cliente
MI Emoticonos graficos 0 1 1
Emoticonos graficosdefinidos por el
usuario0 1 1
Chat de voz 0 1 1Chat de vıdeo 0 1 1
Escritura a mano 0 0 0Soporte multi-cuenta 0 1 1Corrector ortografico 0 1 1
107
Funcionalidad
Base
Mod
Pote
nci
al
Repro
duct
or
de
vıd
eo Soporte para
subtıtulos0 1 1
Control de imagen 0 1 1Control de sonido
(tono)0 1 1
Resincronizacion deaudio
0 1 1
Resincronizacion desubtıtulos
0 1 1
Soporte para VCD 0 0 1Soporte para SVCD 0 0 1Soporte para DVD 0 0 1
Gest
or
de
ar.
Miniaturas(Thumbnails)
1 1 1
Pestanas 0 1 1Doble panel 1 1 1
Previsualizaciones 0 1 1Navegar por archivos
comprimidos0 0 0
Tota
l Total mayoritarios(abs)
3 24 25
Total mayoritarios( %)
10,00 80,00 83,33
Total normalizado( %)
10,57 84,21 89,62
108
Bibliografıa
[1] Jack Wallen. Linux distribution choice flow chart. http://cdn.ghacks.net/
wp-content/uploads/2010/01/choosing_linux.jpg
[2] Terminos de licencia de Windows 7 Ultimate. https://www.microsoft.com/latam/socios/OEM/Licenciamiento/licencias.aspx
[3] Nicholas Hatt, Axis Sivitz and Benjamin A. Kuperman. “Benchmarking Ope-rating Systems”, 2007.
[4] John L. Gustafson and Quinn O. Snell. HINT: A New Way To Measure Com-puter Performance. Proceedings of the 28th Annual Hawaii International Con-ference on Systems Sciences, IEEE Computer Society Press, 1995.
[5] Uwe F. Mayer. Linux/Unix nbench. http://www.tux.org/~mayer/linux/
bmark.html
[6] BYTE magazine (currently defunct). Snapshot available at http://www.tux.
org/~mayer/linux/byte/bdoc.pdf (thanks to Mayer, Uwe F.)
[7] Kaj Gronholm. GTK+ toolkit on mobile Linux devices. Master thesis.
[8] Don Capps. IOzone Filesystem Benchmark. http://www.iozone.org/, 2008.
[9] R. Jones. “Netperf: A network performance benchmark, version 2.1”, 1995.
[10] Phoronix test suite. http://www.phoronix-test-suite.com/
[11] Zack Smith. Bandwidth: a memory bandwidth benchmark. http://zsmith.co/bandwidth.html
[12] PAPI (Performance Application Programming Interface) http://icl.cs.utk.edu/papi/index.html
109
[13] Renatas Kizys, Angel A. Juan. Modelo de regresion Lineal Multiple http://
www.uoc.edu/in3/emath/docs/T01_Reg_Lineal_Multiple.pdf
[14] Minitab, software estadıstico. http://www.minitab.com/
[15] Cubieboard, a small, high-performance arm box. http://cubieboard.org/
[16] Wandboard, ultra low power complete computer with high performance multi-media capabilities. http://www.wandboard.org/
110