`cnica Universitat Polite de Catalunya

` tica de Barcelona Facultat d’Informa

Benchmark para PCs con pocos recursos

Autor: Alexandre Ram´ırez G´omez

Director: ´ Carlos Alvarez Mart´ınez Co-director: Xavier Martorell Bofill

13 de junio de 2013

´Indice general 1. Introducci´ on 1.1. Planteamiento . . . . . . . . . 1.1.1. Objetivo . . . . . . . . 1.1.2. Motivaci´on . . . . . . 1.2. Estado del arte . . . . . . . . 1.2.1. Contexto . . . . . . . . 1.2.2. Diagramas de flujo . . 1.2.3. Benchmarks globales . 1.2.4. Benchmarks espec´ıficos 1.2.5. Colecciones de tests . . 1.2.6. Conclusiones . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

2. An´ alisis de requisitos y planificaci´ on 2.1. Marco legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Modalidades del benchmark . . . . . . . . . . . . . . . . . . . . . 2.2.1. Modalidad cl´asica . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Modalidad basada en estimaci´on . . . . . . . . . . . . . . 2.2.3. Modalidad basada en la estimaci´on de una distribuci´on live 2.2.4. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Metodolog´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Planificaci´on temporal . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1. Coste de software y hardware . . . . . . . . . . . . . . . . 2.5.2. Coste espacial . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3. Coste de recursos humanos . . . . . . . . . . . . . . . . . . 2.5.4. Coste total . . . . . . . . . . . . . . . . . . . . . . . . . .

1

. . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . .

4 4 4 4 5 5 5 6 6 6 7

. . . . . . . . . . . . .

8 8 8 8 9 9 9 9 10 14 14 15 15 17

3. Especificaci´ on y dise˜ no 3.1. Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Versi´on preliminar del benchmark . . . . . . . . . . . . . . 3.2.1. Mediciones . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. Puntos a mejorar . . . . . . . . . . . . . . . . . . . 3.3. Versi´on final del benchmark . . . . . . . . . . . . . . . . . 3.4. Modalidad basada en estimaci´on . . . . . . . . . . . . . . . 3.5. Modalidad basada en la estimaci´on de una distribuci´on live 3.5.1. ¿Medir o estimar? . . . . . . . . . . . . . . . . . . . 3.5.2. La distribuci´on live . . . . . . . . . . . . . . . . . . 3.5.3. Estimando en base al hardware . . . . . . . . . . . 3.6. Experimentaci´on con un Pocket PC . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

18 18 19 19 22 23 24 25 26 27 28 30

4. Implementaci´ on, pruebas y resultados 4.1. Encuesta . . . . . . . . . . . . . . . . . . . . . 4.2. An´alisis de las distribuciones . . . . . . . . . . 4.2.1. Selecci´on de distribuciones candidatas . 4.2.2. An´alisis de funcionalidades . . . . . . . 4.3. An´alisis de los PCs . . . . . . . . . . . . . . . 4.3.1. PCs de TxT . . . . . . . . . . . . . . . 4.3.2. Pruebas de rendimiento preliminares . 4.4. Criba de distribuciones . . . . . . . . . . . . . 4.5. Pruebas de rendimiento en PCs de TxT . . . . 4.5.1. Resultados y reporte de incidencias . . 4.5.2. Conclusiones . . . . . . . . . . . . . . 4.5.3. Interpretaci´on de los resultados . . . . 4.6. Realizando estimaciones . . . . . . . . . . . . 4.7. Comparativa de modalidades del benchmark . 4.8. Experimentaci´on con un Pocket PC . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

31 31 32 32 35 36 36 38 40 40 40 41 42 43 44 47

. . . . . . .

49 49 50 50 50 51 51 51

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

5. Conclusiones 5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 5.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . 5.2.1. Comportamientos an´omalos . . . . . . . . . . 5.2.2. A˜ nadir atributos a medir al benchmark . . . . 5.2.3. Actualizar y expandir la lista de distribuciones 5.2.4. Mejorar la estad´ıstica . . . . . . . . . . . . . . 5.2.5. Probar distintos Pocket PC . . . . . . . . . .

2

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

A. Resultados de la encuesta

53

B. Programas por distribuci´ on

56

C. Funcionalidades por programa

59

D. Funcionalidades por distribuci´ on

63

E. C´ odigo fuente del benchmark E.1. run.sh . . . . . . . . . . . . E.2. benchmark.sh . . . . . . . . E.3. statistics.sh . . . . . . .

(versi´ on 1) 67 . . . . . . . . . . . . . . . . . . . . . . . 67 . . . . . . . . . . . . . . . . . . . . . . . 72 . . . . . . . . . . . . . . . . . . . . . . . 77

F. Pruebas de rendimiento en PCs de TxT 81 F.1. PC A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 F.2. PC B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 F.3. PC C (Core 2 Duo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 G. C´ odigo fuente del benchmark (versi´ on 2) 84 G.1. memory disk discard . . . . . . . . . . . . . . . . . . . . . . . . . . 85 G.2. estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 H. Estimaciones en base a la distribuci´ on live I. Ecuaciones para estimar el I.1. Ubuntu . . . . . . . . . I.2. Slackware . . . . . . . . I.3. Linux Mint . . . . . . .

88

rendimiento 94 . . . . . . . . . . . . . . . . . . . . . . . . . 94 . . . . . . . . . . . . . . . . . . . . . . . . . 95 . . . . . . . . . . . . . . . . . . . . . . . . . 95

J. C´ odigo fuente del benchmark J.1. run.sh . . . . . . . . . . . . J.2. benchmark.sh . . . . . . . . J.3. estimation . . . . . . . . .

(versi´ on 3) 97 . . . . . . . . . . . . . . . . . . . . . . . 97 . . . . . . . . . . . . . . . . . . . . . . . 99 . . . . . . . . . . . . . . . . . . . . . . . 103

K. Funcionalidades de Raspbian

105

Bibliograf´ıa

109

3

Cap´ıtulo 1 Introducci´ on 1.1. 1.1.1.

Planteamiento Objetivo

El objetivo de este proyecto es dise˜ nar e implementar un sistema capaz de determinar la distribuci´on de Linux adecuada para un PC (m´as concretamente, un PC con pocos recursos). Se tendr´an en cuenta tanto aspectos de funcionalidad como de rendimiento. Para esto u ´ltimo ser´a necesario crear un benchmark que mida el rendimiento de distintas distribuciones de Linux para poder decidir con qu´e distribuci´on se aprovecha mejor el escaso potencial de la m´aquina. Se estudiar´an distintas modalidades de benchmark con distintos equilibrios entre tiempo de ejecuci´on y precisi´on de las mediciones. Luego se analizar´an y se comparar´an entre ellas. Se usar´an los PCs de la asociaci´on Tecnologies per Tothom (de ahora en adelante, TxT) a modo de aplicaci´on real.

1.1.2.

Motivaci´ on

La idea surge tras haber participado en una actividad organizada por TxT en la que se instalaba el sistema operativo a ordenadores donados, normalmente con pocos recursos. El sistema operativo en cuesti´on era la u ´ltima versi´on de Ubuntu. Se ha visto que Ubuntu no es la mejor distribuci´on para este tipo de sistemas. En cambio, con distribuciones m´as ligeras especialmente dise˜ nadas para este cometido se pueden obtener buenos resultados. Creo que los PCs de TxT (y los PCs con pocos recursos en general) podr´ıan tambi´en beneficiarse de las ventajas que ofrecen estas distribuciones, pero es necesario

4

escoger la m´as adecuada con tal de aprovechar al m´aximo el potencial de la m´aquina. Para ello es necesario poder calcular de manera cuantitativa el rendimiento de cada distribuci´on; es decir, se necesita un benchmark. Adem´as, este benchmark tambi´en podr´ıa usarse en sistemas del estilo Pocket PC (p. ej., Raspberry Pi ), ya que a efectos pr´acticos son PCs con pocos recursos. Actualmente el uso de este tipo de m´aquinas est´a aumentando notablemente, ya que ofrecen una soluci´on barata y peque˜ na para tareas que no requieran una gran capacidad de c´omputo o unas prestaciones fuera de lo com´ un. Con este benchmark se podr´an comparar este tipo de sistemas con PCs antiguos y ver si realmente suponen una alternativa viable.

1.2. 1.2.1.

Estado del arte Contexto

A la hora de aprovechar un PC con pocos recursos es importante elegir bien qu´e software se instalar´a con tal de sacar el m´aximo provecho a nuestro limitado hardware. Actualmente el sistema operativo para los ordenadores de TxT es elegido de manera informal, sin tener en cuenta muchas alternativas y sin una base objetiva. Es mi prop´osito demostrar que esta elecci´on afecta de manera considerable al rendimiento del sistema y que se podr´ıa mejorar haci´endola con m´as mesura. La soluci´on al problema tendr´a que tener en cuenta tanto aspectos de rendimiento como de funcionalidad para poder decidir de manera objetiva cu´al es la m´as adecuada para una determinada m´aquina.

1.2.2.

Diagramas de flujo

Actualmente no existe ning´ un software que ayude a escoger una distribuci´on de Linux, m´as all´a de los t´ıpicos diagramas de flujo [1]. Si bien estos diagramas tienen la ventaja de ser sencillos y no requerir ning´ un software ni hardware espec´ıfico (porque no son programas, son diagramas), tienen la desventaja de que su granularidad es muy gruesa y solo distinguen entre “PC moderno” y “PC antiguo” como mucho, sin tener en cuenta el rendimiento de la m´aquina. Adem´as tampoco tiene en cuenta funcionalidades 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 rendimiento de todo el sistema, y los que hay se encuentran desfasados. Unixbench es probablemente el m´as conocido. Aunque fue creado en 1983, ha ido siendo actualizado y hoy en d´ıa se sigue usando [3]. El principal defecto de este benchmark es que mide resultados simulando casos de uso extremos que no coinciden con el perfil de uso que normalmente se le da a un PC. Otro conocido benchmark es HINT (Hierarchical INTegration) [4]. Se caracteriza por su buen balance en la ponderaci´on de los distintos aspectos del sistema. Sin embargo, este benchmark devuelve como resultado un solo valor, que intenta ser una medici´on de la “calidad” del sistema. Actualmente se desaconseja este comportamiento y se prefiere que se midan los distintos componentes del sistema por separado.

1.2.4.

Benchmarks espec´ıficos

Existen, por otro lado, benchmarks para medir el rendimiento de un solo aspecto espec´ıfico del sistema o incluso una tarea concreta. Los benchmarks globales suelen ser suites de benchmarks espec´ıficos debidamente ponderados. Los m´as comunes son los benchmarks que miden la potencia de computaci´on (CPU, FPU y memoria). Estos consisten en hacer c´alculos que sean CPU-intensivos (c´omo calcular d´ıgitos de Pi, por ejemplo). Quiz´as el m´as com´ un de este tipo sea nbench [5] (un port a Linux de BYTEmark 2, anteriormente conocido como BYTE’s Native Mode Benchmarks [6]). No obstante, tambi´en existen benchmarks dedicados a medir el rendimiento de otras partes del sistema, como IOzone [8] (dedicado a medir el rendimiento de los sistema de ficheros y dispositivos de almacenamiento) o netperf (para medir el rendimiento de la conexi´on de red). Incluso hay benchmarks dedicados a tareas tan espec´ıficas como medir el rendimiento de distintos temas y configuraciones de GTK+ (gtkperf [7]).

1.2.5.

Colecciones de tests

Finalmente, tambi´en existen colecciones de tests no relacionados entre s´ı para que el usuario elija los tests que desea realizar y pueda crear su propio benchmark global a partir de varios tests espec´ıficos. En este achapterado destaca Phoronix Test Suite [10]. Es una colecci´on de tests bastance reciente (creada en 2008) y amplia (contiene m´as de 60 tests). Adem´as ofrece la posibilidad de compartir resultados 6

a trav´es del servicio OpenBenchmarking http://www.openbenchmarking.org. Es una de las plataformas de benchmarking m´as usadas, tanto a nivel domestico como profesional. Sus mayores cr´ıticas son que el compilador y la configuraci´on que se usen para compilar los tests pueden afectar a los resultados de los mismos y que las comparaciones 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 de los PCs que se tratar´an en este TFG, recordemos que el prop´osito final es elegir un sistema operativo. Adem´as del benchmarking convencional, en este trabajo se estudiar´a la posibilidad de crear un benchmark en una distribuci´on live que estime el rendimiento de las dem´as distribuciones sin necesidad de instalarlas realmente todas. Esta es una funcionalidad muy dependiente de la situaci´on a tratar, por lo cual es algo que no pueden ofrecer los benchmarks anteriores. Es por esto que es necesario crear un nuevo benchmark.

7

Cap´ıtulo 2 An´ alisis de requisitos y planificaci´ on 2.1.

Marco legal

Pese a que los sistemas operativos de la familia Windows son los m´as utilizados en el ´ambito de la inform´atica de escritorio, los PCs que trataremos no los podemos distribuir con estos, ya que Windows se distribuye bajo una licencia de pago [2] que TxT no se puede permitir y que, adem´as, proh´ıbe su redistribuci´on. Por estos motivos la distribuci´on de PCs con sistema operativo Windows queda descartada. Necesitamos, pues, un sistema operativo gratuito y que nos ofrezca libertad de redistribuci´on. Con estas caracter´ısticas, GNU/Linux se presenta como la alternativa m´as popular. Linux es ampliamente usado en sistemas de escritorio, tanto en el a´mbito personal como en el profesional. Aunque las condiciones y licencias pueden variar entre distribuciones, la mayor´ıa de ellas se ofrecen de manera gratuita y libre. El grado de libertad es variable, dependiendo de la distribuci´on, pero la mayor´ıa cumple con creces los requisitos que TxT impone para poder ser instalado y distribuido con sus PCs.

2.2. 2.2.1.

Modalidades del benchmark Modalidad cl´ asica

Un benchmark por si mismo consiste en una colecci´on de pruebas que determinan el rendimiento de una m´aquina (o de alg´ un aspecto en concreto). Mi intenci´on es poder decir para cada PC qu´e distribuci´on es mejor, as´ı que el procedimiento ser´ıa: 8

instalar una distribuci´on, medir su rendimiento, repetir con el resto de distribuciones y comparar los resultados. Esta ser´ıa la modalidad cl´asica del benchmark. Como esto puede llevar mucho tiempo (adem´as de resultar tedioso) se contemplar´an 2 modalidades alternativas.

2.2.2.

Modalidad basada en estimaci´ on

La primera consistir´a en instalar una distribuci´on y medirla tal y como se hace en la modalidad cl´asica, pero en lugar de repetir el procedimiento con todas las dem´as distribuciones, simplemente se estimar´a su rendimiento en base a los resultados de las mediciones realizadas en la distribuci´on instalada. De esta forma nos ahorramos tener que instalar y medir todas las distribuciones. No obstante, el precio a pagar por este ahorro de tiempo es la posible inexactitud de las estimaciones.

2.2.3.

Modalidad basada en la estimaci´ on de una distribuci´ on live

Para acabar de optimizar el tiempo, se crear´a una tercera modalidad similar a la anterior, pero que basar´a las estimaciones en mediciones realizadas con una distribuci´on live muy liviana creada expresamente para este cometido. Con esta modalidad llevamos al extremo las ventajas y los inconvenientes de la modalidad anterior: el proceso ser´a mucho m´as r´apido, ya que no habr´a que instalar ninguna distribuci´on, pero los resultados pueden no ser precisos debido a la inexactitud de las estimaciones y a la variabilidad del medio donde se encuentre la distribuci´on live (CD, DVD, USB...).

2.2.4.

Comparativa

Una vez acabadas las tres modalidades, se comparar´an para ver cu´al es la mejor. Se tratar´a de alcanzar un equilibrio entre el tiempo necesario para realizar las pruebas y la precisi´on de los resultados.

2.3.

Metodolog´ıa

En primer lugar, necesitamos conocer las necesidades funcionales de los ususarios para poder seleccionar unas distribuciones adecuadas. Para ello se realizar´a una encuesta en la que se consultar´a a los usuarios sobre qu´e funcionalidades necesitan en

9

un PC. Con los resultados de esta encuesta podremos saber qu´e grado de funcionalidad alcanzan distintas distribuciones y, por tanto, si son adecuadas para instalarlas en nuestros PCs. Una vez tengamos la funcionalidad de cada distribuci´on nos interesa conocer su rendimiento. Para esto habr´a que crear un benchmark. Como ya se ha explicado en el apartado anterior, se implementar´an 3 versiones con distintos niveles de equilibrio entre tiempo de ejecuci´on y precisi´on. Con los datos de rendimiento obtenidos con el benchmark y los de funcionalidad obtenidos con la encuesta ya estaremos en disposici´on de decidir qu´e distribuci´on es la m´as adecuada en cada m´aquina. Finalmente, se usar´a este mismo sistema para medir el rendimiento y las funcionalidades de un Pocket PC para comprobar hasta que punto podr´ıa sustituir un PC de sobremesa.

2.4.

Planificaci´ on temporal

Ha habido diferencias en la planificaci´on con respecto a la inicial. En la previsi´on inicial, se seleccionaba un conjunto de distribuciones iniciales, se usaban los resultados de la encuesta para hacer una criba y luego se creaba el benchmark en su totalidad. En lugar de eso, tras hacer la encuesta se empez´o a crear el benchmark y se hizo una primera versi´on. Con esa primera versi´on del benchmark se evalu´o el rendimiento de todas las distribuciones iniciales y, con los resultados de la encuesta y los del benchmark se realiz´o la criba. Esto, por una parte, ofrece m´as feedback a la hora de crear el benchmark, ya que se puede probar un prototipo, pero por otra parte, al tener que hacer mediciones sobre todas las distribuciones iniciales, el trabajo se ha alargado una semana. Adem´as, las tareas de “Finalizaci´on del benchmark ” y “Definir m´etodos de estimaci´on” han tomado m´as tiempo del previsto, debido a su complejidad, con lo que, a pesar de planificar una holgura al final del trabajo, hubo que reducir el tiempo de las tareas finales. La planificaci´on queda entonces tal que as´ı: 1. Realizar una encuesta: Esta fue la primera tarea del trabajo. Consisti´o en confeccionar una encuesta para saber qu´e funcionalidades necesitan los usuarios en varios tipos de programas (p. ej., procesador de textos con compatibilidad con Microsoft Office 2010) y distribuirla. Su duraci´on fue de una semana, comenzando el d´ıa 18 de Febrero. Los u ´nicos recursos que se usaron fueron mi PC personal y la suite de Google Drive para crear la encuesta y recopilar las respuestas. 10

2. Seleccionar distribuciones iniciales: Mientras la encuesta est´a activa se aprovechar´a para seleccionar las distribuciones iniciales. Esta tarea dur´o una semana: empez´o tras distribuir la encuesta y acab´o al cerrarse la misma. Para esta tarea, adem´as, se usaron datos de la p´agina web DistroWatch (http: //www.distrowatch.com). 3. Analizar resultados de la encuesta: Una semana despu´es de distribuir la encuesta esta se cerr´o y ya no admite m´as respuestas. Entonces se analizaron los resultados y se usaron para decidir qu´e distribuciones pasar´ıan la criba m´as adelante. La duraci´on 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 instalaci´ on: Una vez elegidas las distribuciones candidatas, se crear´an y grabar´an las im´agenes de las distribuciones en CDs y DVDs, ya que los PCs probablemente no dispongan de arranque desde USB. Esta tarea tom´o apenas 1 d´ıa. Us´e mi PC (con grabador de CD y DVD), conexi´on a Internet para descargar las im´agenes y unos CDs y DVDs v´ırgenes, tantos como distribuciones iniciales. 5. Crear primera versi´ on del benchmark : Tras ultimar los preparativos proced´ı a dise˜ nar e implementar una primera versi´on del benchmark. Esto implic´o decidir qu´e par´ametros medir y c´omo hacerlo. Esto llev´o 2 semanas. Us´e un PC propio similar a los menos potentes que hay en TxT para hacer pruebas, los CDs y DVDs de la tarea anterior y, como el benchmark medir´a la eficiencia de la red, us´e la conexi´on a Internet de mi casa. 6. Evaluar el rendimiento de las distribuciones iniciales: Con la primera versi´on del benchmark acabada instal´e cada una de las distribuciones en el mismo PC de la tarea anterior y med´ı su rendimiento. Debido al alto n´ umero de distribuciones esta tarea llev´o toda una semana. Los recursos usados fueron los mismos que en la tarea anterior. 7. Analizar resultados del benchmark : Una vez obtenidos los resultados de rendimiento, pude al fin realizar una criba sobre las distribuciones iniciales. Adem´as, con la experiencia obtenida al crear y probar la primera versi´on del benchmark pude ver qu´e aspectos hay que corregir de cara a la versi´on final.

11

8. Finalizaci´ on del benchmark : Tomando el esbozo de benchmark como base y los resultados de las pruebas como gu´ıa finalizar´e el benchmakr corrigiendo los errores detectados en las tareas anteriores. Se usar´an los mismos recursos para realizar pruebas, aunque esta vez se har´an solo sobre las distribuciones candidatas (las que hayan pasado la criba). Esta tarea es una de las claves del trabajo, y llev´o m´as tiempo del esperado. 9. Segunda versi´ on del benchmark : Crear la segunda modalidad del benchmark result´o relativamente sencillo, comparado con la modalidad cl´asica (esta tarea tiene una duraci´on de 10 d´ıas, frente a los m´as de 40 de la creaci´on del benchmark cl´asico). Se implement´o de tal manera que se pudo aprovechar el c´odigo generado en la tarea anterior. 10. Definir m´ etodos de estimaci´ on: A parte de la creaci´on del benchmark (tareas 5 a 8), el otro gran desaf´ıo del trabajo ser´a definir c´omo se calcular´an las estimaciones a partir de los valores medidos en la modalidad de benchmark por estimaci´on basado en una distribuci´on live. Esta tarea llev´o poco m´as de 2 semanas. Dado que es una tarea de dise˜ no de benchmark, los recursos que usar´e ser´an los mismos que en la tarea anterior: mi PC personal y mi PC de prueba. 11. Crear distribuci´ on live del benchmark por estimaci´ on: Para poder usar la modalidad de benchmark basada en estimaci´on tomando como referencia una distribuci´on live liviana, primero hay que crear dicha distribuci´on, con todo el software necesario, y grabarla en un CD. Esta tarea llev´o mucho menos de lo previsto. En tan solo 1 d´ıa se pudo completar. Esto fue debido a haber encontrado un programa muy sencillo de usar que se ajustaba perfectamente a las 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 modalidades del benchmark, se analizaron y se decidi´o cu´al se usar´a en las mediciones. Inicialmente esta tarea iba a ser m´as larga, pero debido a las modificaciones en la planificaci´on tubo que hacerse en solo 2 d´ıas. Para esta tarea fueron necesarios los PCs de TxT. Durante todo el proceso del trabajo se realizar´a la memoria en paralelo, documentando cada tarea al tiempo que se hace. Durante la creaci´on de la primera modalidad del benchmark (tareas 5 a 8), adem´as de realizar las mediciones sobre las distribuciones candidatas tambi´en se realizaron sobre Raspbian (en la Raspberry Pi ). 12

2.5. 2.5.1.

Presupuesto Coste de software y hardware

En sistemas antiguos como los que se tratar´an en este trabajo es habitual que el arranque desde USB no est´e disponible, as´ı que para no tener que extraer los discos duros y volverlos a instalar, se usar´a el arranque desde la unidad de CD/DVD. Por ello se requerir´an CDs y DVDs en los que grabar las im´agenes de las distribuciones a evaluar y la distribuci´on live para el benchmark basado en estimaci´on. Finalmente se han seleccionado m´as distribuciones de las previstas, as´ı que el n´ umero de CDs/DVDs necesarios ha aumentado con respecto a lo inicialmente planeado. Afortunadamente estos son baratos y el aumento en el precio no es demasiado importante. Los PCs sobre los que se efectuar´an las pruebas ser´an prestados por TxT, as´ı que no suponen coste alguno. Para poder trabajar desde casa tambi´en se har´an pruebas en PCs antiguos de los que dispongo, lo cual tampoco supone ning´ un coste. Adem´as, se necesitar´a un Raspberry Pi sobre el que efectuar m´as pruebas. Finalmente se ha comprado un pack con placa, tarjeta SD y cable de alimentaci´on. Todo el software que se use ser´a libre o, por lo menos, gratuito. Finalmente, tambi´en necesitar´e un PC con grabador de CDs y una conexi´on a Internet. Ya dispongo de estos recursos, as´ı que no suponen ning´ un coste, m´as all´a del de amortizaci´on. En el caso de que no los pudiese usar, la facultad ofrece PCs en pr´estamo y acceso a Internet, tambi´en de manera gratuita. Adicionalmente, se ha decidido comprar un medidor de consumo el´ectrico para medir la potencia que consumen los PCs con las distintas distribuciones. Teniendo en cuenta la planificaci´on, los gastos quedar´ıan tal que as´ı: Raz´ on Software PC personal PCs de pruebas Raspberry Pi 7 CDs 3 DVDs Medidor de consumo el´ectrico

Coste 0,00 1000,00 0,00 40,00 2,00 2,00 13,00

e e e e e e e

Tiempo de amortizaci´ on 3 a˜ nos 3 a˜ nos 3 a˜ nos 3 a˜ nos

Tiempo de uso 4 meses 4 meses 4 meses 4 meses

5 a˜ nos

4 meses Total

14

Coste imputable 0,00 e 111,11 e 0,00 e 4,44 e 2,00 e 2,00 e 0,86 e 120,41 e

2.5.2.

Coste espacial

Adem´as del coste del equipo, tambi´en hay que contar el coste del mantenimiento del almac´en donde se guardan los PCs y donde se realiza el proyecto. Cuando se realiz´o la proyecci´on inicial todav´ıa no ten´ıa acceso al almac´en en cuesti´on y, por lo tanto, los costes que estimaron “a ciegas”, sin conocer realmente c´omo es el local. Ahora que tengo acceso, puedo aproximar los costes m´as fielmente a la realidad. Raz´ on Agua Luz Gas Tel´efono e Internet

Coste mensual 20,00 50,00 50,00 50,00

e/mes e/mes e/mes e/mes

Tiempo de uso 4 meses 4 meses 4 meses 4 meses Total

Coste total 80,00 200,00 200,00 200,00 680,00

e e e e e

Sin embargo, hay que tener en cuenta que el almac´en no es de uso exclusivo para mi proyecto, sino que se realiza trabajo diario en ´el. Por lo tanto los costes se deber´an amortizar entre todo el trabajo que se haga en ´el. Supongamos que se reparta a partes iguales entre mi proyecto y el resto de trabajo que se realiza all´ı. Los costes quedan entonces reducidos a la mitad. Raz´ on Agua Luz Gas Tel´efono e Internet

2.5.3.

Coste mensual 10,00 25,00 25,00 25,00

e/mes e/mes e/mes e/mes

Tiempo de uso 4 meses 4 meses 4 meses 4 meses Total

Coste total 40,00 100,00 100,00 100,00 340,00

e e e e e

Coste de recursos humanos

Por u ´ltimo cabe a˜ nadir los costes del personal. Se considera que para la realizaci´on de este proyecto se requerir´an 3 roles. Las siguientes tablas muestran las horas que se requieren de cada rol en cada tarea y su precio. Estos datos han sufrido cambios respecto a los entregados en el hito intermedio debido a que la duraci´on 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 atenci´ on al usuario Persona conocedora de las necesidades de los usuarios, sus preferencias y sus h´abitos. Su principal cometido ser´a asegurar que las distribuciones que se selecciones sean del agrado de los usuarios y no nieguen funcionalidades b´asicas a costa del rendimiento. Administrador de sistemas experto en performance Responsable de la creaci´on del benchmark. Tiene profundos conocimientos de los par´ametros que m´as influyen en el rendimiento de un sistema. Es capaz de medirlos de manera adecuada, aisl´andolos de otros par´ametros que pudieran alterar la medici´on, e interpretar los resultados dentro de un contexto. Administrador de sistemas experto en Linux Comprende los fundamentos de los sistemas operativos basados en Linux. Conoce las diferencias entre distintas distribuciones y el impacto de estas en su funcionamiento y usabilidad. Su tarea consistir´a en contribuir a la selecci´on de distribuciones inicial y crear la distribuci´on live. Tarea Realizar encuesta e interpretar resultados Seleccionar y preparar distribuciones iniciales Creaci´on el benchmark Pruebas y mediciones Definir m´etodos de estimaci´on Comparar modalidades de benchmark Crear distribuci´on live Tiempo total

Rol A. usuario A. performance A. Linux

A. usuario 50 h

A. performance 0h

A. Linux 0h

20 h

20 h

20 h

0h 0h 0h

160 h 120 h 100 h

0h 0h 0h

0h

10 h

0h

0h 70 h

0h 410 h

10 h 30 h

Tiempo Coste por hora 70 h 20,00 e/h 410 h 24,00 e/h 30 h 22,00 e/h Coste total de personal 16

Coste total 1400,00 e 9840,00 e 660,00 e 11900,00 e

2.5.4.

Coste total

Una vez detallados todos los costes, podemos ver el coste total que supone el proyecto. Concepto Software y hardware Espacial Recursos humanos Total

17

Coste 120,41 e 340,00 e 11900,00 e 12360,41 e

Cap´ıtulo 3 Especificaci´ on y dise˜ no 3.1.

Encuesta

Tras finalizar GEP el primer punto es crear una encuesta que despu´es se pasar´a a los usuarios para conocer sus preferencias. En un principio la encuesta iba a ser m´as t´ecnica, y el usuario ten´ıa que elegir directamente el programa que prefiere para cada tipo de tarea. Por ejemplo: Navegador Chrome / Chromium Epiphany Firefox / Iceweasel Konqueror Midori Opera No obstante esto se descart´o, ya que muy posiblemente los usuarios responder´ıan qu´e aplicaciones usan y no cuales son las m´as adecuadas. Adem´as, opciones poco conocidas quedar´ıan marginadas, independientemente de las funcionalidades que ofreciesen. Finalmente, la encuesta fue tal que el usuario deb´ıa seleccionar las funcionalidades 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 funcionalidades: 18

Navegador Bloqueo de pop-ups sin necesidad de complementos Bloqueo de publicidad sin necesidad de complementos Control por voz Gestos de rat´on Conversi´on texto-a-voz (text-to-speech) Incorpora su propio plugin de Flash Lector de feeds RSS incorporado (sin necesidad de complementos ni herramientas externas) Gestor de contrase˜ nas (recordar contrase˜ nas, contrase˜ na maestra) Y el usuario deb´ıa marcar las funcionaliades que vea necesarias mediante un checkbox. Al final de la encuesta se ofrec´ıa un espacio para a˜ nadir comentarios. Solo se recibieron 3 comentarios: uno especificaba que prefer´ıa software libre antes que privativo, otro prefer´ıa interfaces sencillas pero customizables y el u ´ltimo era un mensaje de ´animo. La encuesta completa puede encontrarse en el ap´endice A (junto con los resultados, que se tratar´an m´as adelante).

3.2.

Versi´ on preliminar del benchmark

Como las modalidades del benchmark se basan cada una en la anterior, es importante que el inicio sea s´olido. Para asegurarnos de que la primera modalidad de benchmark es consistente, se realiz´o una versi´on preliminar. Se realizar´an pruebas con esta versi´on para detectar posibles errores y poder corregirlos en la versi´on final.

3.2.1.

Mediciones

La versi´on preliminar del benchmark consisti´o en las siguientes mediciones: Disco El espacio que ocupa una instalaci´on por defecto de la distribuci´on en el disco, sin paquetes adicionales. Aunque la mayor´ıa de discos cumple con creces los requisitos de todas las distribuciones que se evaluar´an, en otros casos en los 19

que se trate con discos de poca capacidad este par´ametro puede resultar u ´til. Un ejemplo es el caso de la Raspberry Pi, cuyo u ´nico medio de almacenamiento es una tarjeta SD, que puede no ser muy grande. En todos los casos se usar´a el formato ext4. Memoria Cantidad de memoria RAM que consume la distribuci´on estando en reposo (enti´endase “reposo” como el PC encendido, pero sin realizar trabajo; no como un estado idle o de bajo consumo). Este par´ametro resulta particularmente decisivo en el rendimiento de una distribuci´on, ya que determina la cantidad de datos que ha de manejar el sistema solo para funcionar. Incluye la memoria ocupada por buffers y cach´e. Si bien el sistema puede liberar este espacio para dedicarlo a aplicaciones del usuario, lo “natural” es que el sistema lo tome. Tiempo de arranque El tiempo que tarda el sistema en arrancar, hasta que es usable. Es uno de los par´ametros que m´as valora el usuario final. Puede verse influenciado por otros par´ametros como el disco y la memoria. Este par´ametro se midi´o leyendo el archivo /etc/uptime. Para que la medici´on se hiciese tan pronto como el sistema acabe de iniciar, se us´o la herramienta para configurar la ejecuci´on de aplicaciones al inicio, que var´ıa seg´ un la distribuci´on. Tiempo de arranque de un programa lento El tiempo que tarda un programa pesado desde el momento en que se manda ejecutar hasta que es usable por el usuario. Los usuarios sin conocimientos profundos de inform´atica tienden a usar este par´ametro como medida de rendimiento. Como los usuarios finales posiblemente no sean inform´aticos, este es un par´ametro que resulta conveniente vigilar. Se eligi´o LibreOffice Writer (versi´on 3.6.6) como ejemplo de “programa lento”, debido a que muy probablemente sea uno de los programas que m´as usen los usuarios finales, y se ha medido el tiempo de abrir el programa, esperar hasta que sea usable y cerrarlo (de manera manual). De esta manera se pudo usar la herramienta time para medir el tiempo. En las distribuciones que no inclu´ıan LibreOffice se instal´o desde los repositorios. En las que s´ı lo inclu´ıan se actualiz´o tambi´en a trav´es de los repositorios oficiales. En todos los casos se instalaron tambi´en el paquete de ayuda y el de idioma (espa˜ nol). En el caso de Puppy Linux se us´o el script getLibreOffice, 20

que crea el paquete correspondiente a partir de los paquetes .deb oficiales. En el caso de Slackware, se crearon los paquetes .tgz a partir de los .deb con la herramienta deb2tgz. En estos dos u ´ltimos casos, hubo que crear soft-links para lowriter, ya que no se crean al instalar los paquetes. Tiempo de apertura de un archivo grande con un programa lento Versi´on m´as sofisticada del par´ametro anterior. Algunos programas pueden usar t´ecnicas para parecer usable cuando en realidad solo lo son parcialmente, de manera que cargan r´apido, pero al interactuar con ellos se ralentizan. Midiendo este par´ametro se fuerza al programa a trabajar desde el principio, con lo que dichas t´ecnicas no funcionan. La metodolog´ıa para medir este par´ametro es similar a la del par´ametro anterior: se ha elegido LibreOffice, y se incluye el tiempo de cerrar el programa para poder hacerlo con la herramienta time. Como “archivo grande” se ha generado un archivo de texto plano cuyo contenido son 1000000 (un mill´on) de ‘a’ seguidas por un car´acter de salto de l´ınea (‘\n’). En esta ocasi´on, en lugar de simplemente esperar a que el programa sea usable, se esper´o a que el recuento de p´aginas (que LibreOffice Writer muestra en la esquina inferior izquierda) llegase al valor correcto. De esta manera se asegura que el archivo se ha le´ıdo completamente. Velocidad de descarga Para comprobar la eficiencia de la gesti´on de la red se descargar´a un archivo de gran tama˜ no. este es precisamente el principal uso que se le da a la red, de manera que resulta un buen indicador del rendimiento de la red. Se us´o un archivo de 500 MB almacenado en un servidor en Internet (completamente ajeno a TxT, a la UPC y a este proyecto). Tiempo de compilaci´ on de un kernel de Linux en serie La compilaci´on de un kernel de Linux es una de las pruebas de benchmarking m´as usadas. Requiere frecuentes accesos a disco y usa una porci´on considerable de la memoria (suficiente para atenuar el efecto de las cach´es). La prueba simplemente consiste en compilar y comprimir una imagen del kernel de Linux (sin m´odulos adicionales) y medir el tiempo que tarda. Para poder comparar los resultados de manera coherente, siempre se compilar´a la misma versi´on del kernel (3.8.4), con las mismas opciones (las opciones por defecto). No se garantiza que se use la misma versi´on del compilador. Si una distribuci´on incluye un compilador desfasado se ver´a como un aspecto negativo y quedar´a reflejado en el tiempo de compilaci´on. 21

Tiempo de compilaci´ on de un kernel de Linux con varios threads ´Idem al par´ametro anterior, pero con varios threads trabajando al mismo tiempo. Con esto podemos medir la eficiencia de la gesti´on de procesos (scheduling) del sistema operativo. Dado que el n´ umero m´aximo de procesos que los PCs a tratar pueden ejecutar simult´aneamente es de 2 (hay procesadores con 2 cores y procesadores con Hyperthreading) se ha optado por compilar el kernel usando 4 threads, para forzar el scheduling. Consumo energ´ etico Consiste en medir la potencia consumida por el sistema estando en reposo (enti´endase “reposo” como el PC encendido, pero sin realizar trabajo; no como un estado idle o de bajo consumo). La medici´on se hizo con un medidor de consumo el´ectrico (una herramienta hardware).

3.2.2.

Puntos a mejorar

Durante las pruebas se detectaron los siguientes problemas: Las mediciones del disco sufren una peque˜ na perturbaci´on al incluir en el resultado el tama˜ no de los archivos del benchmark. Aunque es una perturbaci´on peque˜ na, es f´acil evitarla en versiones sucesivas del benchmark. Las mediciones que involucran LibreOffice requieren la intervenci´on del usuario (para cerrar el programa en su debido momento). Las pruebas se realizaron en mi casa y con mi conexi´on de red. La prueba de medici´on de la velocidad de la red podr´ıa tener que modificarse dependiendo de la conexi´on de red del almac´en de TxT (por ejemplo, reemplazar el archivo a descargar por uno m´as grande o m´as peque˜ no o cambiar a una localizaci´on distinta). Se ha notado que este atributo no var´ıa demasiado entre distribuciones, as´ı que posiblemente se dar´a la posibilidad de ignorarlo. El consumo el´ectrico se mide con un hardware que no tiene conexi´on con el PC y, por lo tanto, el usuario debe tomar nota del valor ´el mismo. De todas formas, este atributo tambi´en var´ıa muy poco entre distribuciones, as´ı que tambi´en se dar´a la posibilidad de ignorarlo en futuras versiones.

22

Algunas distribuciones necesitaron instalar el software necesario para compilar el kernel de Linux. En las distribuciones basadas en Debian/Ubuntu se instal´o el paquete build-essential. En Puppy Linux se instal´o el paquete devx. En la versi´on final del benchmark se deber´a informar al usuario.

3.3.

Versi´ on final del benchmark

La nueva versi´on del benchmark corrige fallos de la versi´on preliminar y se ha creado un script para automatizarlo (el c´odigo fuente puede verse en el ap´endice E). Estos son los puntos a destacar de la nueva versi´on del benchmark : Se resta el tama˜ no de los archivos del benchmark a la medici´on del disco. Se ha creado una funci´on bash que usa el comando top para comprobar cuando LibreOffice ha acabado de trabajar. Con esto, ahora no se medir´a solo hasta que el recuento de p´aginas sea correcto, sino hasta que el uso de CPU de LibreOffice sea 0, lo cual puede ser unos segundos despu´es de que el recuento de p´aginas alcance el valor adecuado. Adem´as, como esta funci´on no cierra LibreOffice Writer satisfactoriamente, se eliminan los archivos temporales de LibreOffice antes del iniciarlo, para que no pida recuperarlos. Los PCs de escritorio no acostumbran a ofrecer una interfaz para consultar el consumo energ´etico, por lo que esta prueba sigue necesitando la intervenci´on del usuario. Si se va a ejecutar el benchmark en un PC capaz de reportar su propio consumo energ´etico (p. ej., un port´atil) se podr´ıa extender el script del benchmark e incorporar esta funcionalidad. Otra posibilidad ser´ıa comprar un medidor de consumo el´ectrico con conexi´on al PC (los hay con conexi´on USB), pero se decidi´o no gastar m´as en hardware teniendo uno perfectamente funcional. Si hay alguna dependencia del benchmark sin cumplir se pedir´a en el momento que se vaya a usar. Por ejemplo, si LibreOffice no est´a instalado, se pedir´a que se instale tras haber hecho las mediciones de disco y memoria. En el caso de que todas las dependencias est´en instaladas no se requerir´a la intervenci´on del usuario. El script es capaz de reiniciar el sistema cuando sea necesario sin la intervenci´on del usuario si se usa el par´ametro adecuado (esto puede requerir permisos).

23

Se pueden ignorar las pruebas de velocidad de la red y de consumo energ´etico (recordemos que la medici´on del consumo se hace de manera manual por parte del usuario). Como corolario de los tres u ´ltimos puntos, si el sistema cumple las dependencias en el momento de ejecutarse, se ignora la prueba de medici´on del consumo el´ectrico y se manda a ejecutar con privilegios y usando el par´ametro adecuado para automatizar los reinicios, el benchmark se puede automatizar completamente (no requerir´a en ning´ un momento la interacci´on del usuario). No obstante, hay que tener en cuenta que algunos de los PCs de TxT tienen problemas al arrancar sin estar conectados a un monitor (esto es importante si se pretende trabajar con varios PCs a la vez conectados a un multiplexor VGA, como fue mi caso). Todas las mediciones (excepto la del tiempo de arranque) se har´an tras esperar 60 segundos despu´es de que el sistema sea usable, para garantizar que se ha iniciado completamente.

3.4.

Modalidad basada en estimaci´ on

Una vez que ya se tiene la versi´on final de la primera modalidad del benchmark y unas mediciones fiables de todas las distribuciones candidatas, se puede hacer la siguiente modalidad del benchmark. Esta modalidad solo realizar´a mediciones sobre una de las distribuciones y extrapolar´a los resultados para determinar el rendimiento de las dem´as. Se ha decidido que la distribuci´on de referencia (sobre la que se har´an las mediciones) ser´a Ubuntu, ya que es la que la mayor´ıa de los PCs de TxT llevan ya instalada.1 El c´odigo fuente del benchmark se puede reaprovechar casi por completo. El c´odigo resultante se puede ver en el ap´endice G. Las mediciones sobre la distribuci´on se har´an exactamente de la misma manera que en la modalidad de benchmark anterior; la diferencia est´a en que se estimar´a el rendimiento de las dem´as distribuciones, as´ı que el c´odigo de la modalidad anterior del benchmark no se modifica, solo se expande. 1

En el momento de dise˜ nar esta modalidad de benchmark las distribuciones candidatas eran Slackware (con KDE), Ubuntu, Linux Mint y Puppy Linux.

24

Los par´ametros m´as sencillos de medir son el disco y la memoria, ya que solo hay que consultar la cantidad total y la usada. aprovechando esto y, ya que el uso de memoria es el gran discriminante, podemos usar estos par´ametros para realizar descartes tempranos en el caso de que el sistema no disponga de suficiente memoria y/o disco para algunas de las distribuciones. Para ello se distinguir´a entre 3 casos: Disco y/o memoria insuficientes para Ubuntu En este caso, se pueden descartar al instante Ubuntu y Slackware. Se estimar´a el consumo de memoria y disco de Linux Mint. Si las cantidades de memoria y disco son suficientes para correr Linux Mint, se elegir´a como distribuci´on ganadora. En caso contrario, se elegir´a Puppy Linux. Sea cual sea la distribuci´on elegida en este caso, no ser´a necesario completar el benchmark Disco y memoria suficientes para Ubuntu, pero no Slackware En este caso, si Ubuntu tiene un buen rendimiento se elegir´a como distribuci´on final. En caso contrario, se elegir´a Linux Mint. Disco y memoria suficientes para Slackware En este caso habr´a que elegir entre Slackware, Ubuntu y Linux Mint. Si Ubuntu tiene un buen rendimiento, se decidir´a entre Slackware y Ubuntu. En caso contrario se elegir´a Linux Mint como distribuci´on ideal. Para decidir entre 2 distribuciones, el funcionamiento es el mismo que en la modalidad de benchmark anterior, con la diferencia de que los par´ametros ser´an estimados, no medidos. Debido a que los par´ametros de velocidad de red y consumo el´ectrico no son decisivos, se ignorar´an. Tambi´en se ignorar´a el tiempo de compilaci´on del kernel de Linux con 4 threads, ya que esto depender´a del tipo de procesador (n´ umero de threads, cores, etc.).

3.5.

Modalidad basada en la estimaci´ on de una distribuci´ on live

Aunque con esta segunda versi´on del benchmark reducimos considerablemente el tiempo necesario para averiguar la distribuci´on ideal, a´ un tenemos que instalar y una distribuci´on. Adem´as existe la posibilidad de que esa distribuci´on no sea la ideal y haya que instalar otra despu´es. Para ahorrarnos todas estas instalaciones se cre´o una tercera versi´on del benchmark. Esta versi´on no requerir´a instalar ninguna distribuci´on, ya que se ejecutar´a desde una distribuci´on live. Tampoco requerir´a tanto 25

tiempo como las versiones anteriores, ya que la mayor´ıa de par´ametros se estimar´an en base al hardware del PC en cuesti´on. As´ı, pues, esta versi´on ser´a la que menos tiempo necesite, pero tambi´en tendr´a unos resultados potencialmente m´as alejados de la realidad.

3.5.1.

¿Medir o estimar?

Durante la creaci´on de esta versi´on surgieron dos ideas sobre c´omo deber´ıa funcionar este benchmark. Por un lado, exist´ıa la posibilidad de simplemente ejecutar el benchmark sobre la distribuci´on live y, a partir de sus resultados, estimar cu´ales ser´ıan los resultados de las dem´as distribuciones de manera similar a la versi´on anterior del benchmark. Por el otro, la idea era que desde la distribuci´on live se consultasen los atributos del hardware del sistema en cuesti´on y se calculase la distribuci´on ideal en base a esos atributos. Se hicieron pruebas con la primera alternativa. Estas mediciones se realizaron sobre el PC A (Procesador Intel Core 2 Duo, 2 GiB de memoria). Para poder realizar las pruebas que requieren entorno gr´afico, se instal´o JWM (Joe’s Window Manager ) en la distribuci´on live. Este entorno de escritorio es muy ligero y es el que incluye Puppy Linux por defecto. No se realiz´o la prueba de ocupaci´on de disco, porque la distribuci´on live siempre ocupa el mismo espacio. Tampoco se realiz´o la prueba de velocidad de red, porque se vi´o que no era un par´ametro decisivo (todas las distribuciones daban pr´acticamente el mismo resultado). Par´ amtero Memoria (MiB) Tiempo de arranque del SO (s) Tiempo de arranque de LibreOffice (s) Tiempo de apertura de many_as.txt (s) Tiempo de compilaci´on en serie (s) Tiempo de compilaci´on en paralelo (s) Consumo energ´etico (W)

CD 262 151,12 21,568 141,696 263,273 143,145 62,0

USB 242 24,30 9,819 103,413 260,172 142,294 56,0

El primer problema que encontr´e fue que para poder conservar los resultados de las mediciones durante los reinicios necesarios ser´ıa necesario un medio de almacenamiento persistente. Es decir, la distribuci´on live no podr´ıa ser grabada en un CD o DVD. Esto supone un problema, ya que algunos (pocos) de los PCs de TxT no pueden arrancar desde USB. Adem´as, se vio que el medio en el que se grabase la distribuci´on (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 a evaluar (adem´as de que tambi´en afectaba otros par´ametros, como el consumo el´ectrico). Como esta versi´on del benchmark ya extrapola bastante los datos, se decidi´o que a˜ nadir una variable m´as a las estimaciones (la velocidad del medio de la distribuci´on live) ser´ıa demasiado, as´ı que se opt´o por descartar esta alternativa.

3.5.2.

La distribuci´ on live

Para esta versi´on del benchmark se ha usado una distribuci´on live basada en Debian 6.0.7. Es la misma distribuci´on con la que se trabaj´o anteriormente en el trabajo, pero esta vez se usar´a sin entorno gr´afico. Con esto conseguimos reducir de manera considerable los recursos necesarios para ejecutarla en tiempos razonables. Adem´as, como esta versi´on simplemente toma las propiedades del hardware y realiza c´alculos (no realiza las mediciones de las versiones anteriores; no se necesitar´a LibreOffice), no es necesario entorno gr´afico. Para crear la distribuci´on live, en primer lugar se cre´o una m´aquina virtual en VirtualBox. Los par´ametros de la m´aquina virtual no afectar´an al resultado, aunque s´ı puede afectar al tiempo que se tarde en construir la imagen .iso resultante. Durante la instalaci´on se eligi´o no instalar el entorno gr´afico, ya que no ser´a necesario para esta tarea y nos permite ahorrar bastante memoria (recordemos que toda la distribuci´on ser´a cargada en memoria). Una vez instalada la distribuci´on Debian se personaliz´o, instalando los paquetes necesarios para realizar todas las tareas. Esto incluy´o el paquete build-essential, para compilar, y el paquete nasm, requisito para el programa bandwidth [11] (el cual se instal´o desde el c´odigo fuente proporcionado por el autor). Finalmente, se realiz´o una “instant´anea” (en ingl´es, snapshot) usando el programa refractasnapshot. Este programa crea por defecto un men´ u que aparece al arranque y permite elegir entre distintos tipos de arranque (normal, sin entorno gr´afico, cargar a memoria...). Se edit´o este men´ u para que s´olo estuviese la opci´on de cargar a memoria y se redujo el timeout al m´ınimo (porque realmente no es necesario escoger ninguna opci´on, ya que solo hay una). El programa gener´o una imagen .iso que conten´ıa la instant´anea de la distribuci´on tal y como estaba en el momento de la creaci´on. Finalmente se copi´o a un USB usando el programa dd. Tambi´en 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 tama˜ no m´aximo para archivos adicionales es de 100 MB) no se podr´a entregar la imagen .iso (que tiene un tama˜ no de m´as 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, leer la capacidad del disco y la memoria y comprobar si es suficiente para cada una de las distribuciones es f´acil, ya que estos par´ametros son bastante constantes para una misma distribuci´on en varios PCs. Otros par´ametros no pueden ser medidos directamente y tienen que ser estimados en base a peque˜ nas pruebas. Para poder estimar los valores que no podemos medir, es necesario averiguar de qu´e otros par´ametros dependen. Para ello se han realizado un estudio estad´ıstico que puede encontrarse en el ap´endice H. En este estudio se observaron variables relativas al disco, la memoria y la CPU, por que son las m´as b´asicas y probablemente las que m´as influencia tengan. Las variables relativas a la CPU son simplemente el tiempo de compilaci´on de una aplicaci´on de referencia con 1 y 4 threads, tal y como se hace en el benchmark cl´asico. Al tener que cargar la distribuci´on live en la memoria, no queda suficiente para compilar el kernel de Linux, as´ı que se ha optado por una aplicaci´on m´as peque˜ na llamada PAPI [12] (la funcionalidad de la aplicaci´on no nos importa; solo su tiempo de compilaci´on). Las variables relativas al disco son el ancho de banda de lectura y la latencia. Estas se pueden medir f´acilmente 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 secuencial de archivos de distintos tama˜ nos. Se han distinguido 4 casos: archivos menores de 32 kiB, entre 32 y 256 kB, entre 256 kB y 1 MB y superiores a 2 MB. Esta divisi´on se ha realizado tras ver 4 tramos claramente distintos en pruebas realizadas con el programa bandwidth (v´ease la figura 3.1).

28

29 Figura 3.1: Gr´afico generado por el programa bandwidth.

3.6.

Experimentaci´ on con un Pocket PC

Hoy en d´ıa, cuando se habla de PCs de perfil bajo uno no puede evitar pensar en 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 por Internet, consultar el correo o editar un documento. Sus principales ventajas son su bajo consumo y su precio, lo cual las hace ideales para, por ejemplo, aulas tecnol´ogicas en pa´ıses subdesarrollados, donde la corriente el´ectrica es escasa y el presupuesto muy ajustado. Actualmente la asociaci´on TxT dona equipos de sobremesa con pocos recursos a ONGs con este tipo de finalidades, con lo que resulta interesante comprobar hasta qu´e punto pueden los Pocket PC sustituir los PCs convencionales. Como parte de este trabajo se experiment´o con una Raspberry Pi (modelo B). La finalidad de estos experimentos fue doble: por un lado, demostrar que el benchmark puede funcionar en cualquier dispositivo capaz de correr Linux; y por otro, medir el rendimiento de un Pocket PC y compararlo con el de PCs convencionales de bajo rendimiento. No se trat´o de comparar las distintas distribuciones disponibles para la Raspberry Pi, ya que todav´ıa son pocas y tienen prop´ositos muy distintos (p. ej., convertir la Raspberry Pi en un media center ).

30

Cap´ıtulo 4 Implementaci´ on, pruebas y resultados 4.1.

Encuesta

La encuesta se public´o en los foros de la facultad y permaneci´o disponible durante una semana. Durante este tiempo se consiguieron 88 respuestas; m´as que suficiente para mi prop´osito. A la hora de valorar los resultados de la encuesta y asociar un valor a cada opci´on, inicialmente se pens´o en hacer una traducci´on directa: asociar a cada funcionalidad el porcentaje de encuestados que la seleccion´o. Finalmente se opt´o por normalizar el valor. Es decir, el valor asignado a una funcionalidad (x) se obtiene con la siguiente f´ormula: n´ umero de votosx valorx = Σtodas las funcionalidades n´ umero de votos De esta manera el valor de cada funcionalidad queda ponderado seg´ un su popularidad: las funcionalidades populares valdran m´as que las impopulares. Los resultados completos de la encuesta se pueden encontrar en el ap´endice A. Los votos de las opciones de reproducci´on 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.

Procesador de textos

Funcionalidad

4.2. 4.2.1.

Compatible con documentos de Office 2010 (.docx) Compatible con documentos de LibreOffice y OpenOffice (.swx) Posibilidad de a˜ nadir comentarios a los documentos Crear gr´aficos y dibujos sin necesidad de una herramienta externa Integraci´on con una suite ofim´atica completa Versi´on para Mac OS X

Votos (abs)

Votos ( %)

Valor normalizado

77

87,50 %

3,56 %

47

53,41 %

2,17 %

45

51,14 %

2,08 %

54

61,36 %

2,50 %

18

20,45 %

0,83 %

14

15,91 %

0,65 %

An´ alisis de las distribuciones Selecci´ on de distribuciones candidatas

Mientras la encuesta estuvo activa, se seleccionaron las distribuciones candidatas con las que se trabajar´ıa. A continuaci´on se detalla qu´e distribuciones se seleccionaron y por qu´e motivo. Bodhi Linux Versi´ on: 2.3.0 Motivo: Est´a basada en Ubuntu (que es la distribuci´on que se usa actualmente), usa el entorno de escritorio Enlightenment, conocido por ser muy ligero. Es muy minimalista y tiene una buena puntuaci´on en DistroWatch.

32

CrunchBang Versi´ on: 11 (Waldorf) Motivo: Es una distribuci´on ligera, basada en Debian (anteriormente basada en Ubuntu, que es la distribuci´on que se usa actualmente) y tiene una buena puntuaci´on en DistroWatch. Comentarios: Esta distribuci´on debe grabarse en un CD de 800 MB como m´ınimo. Debian Versi´ on: 6.0.7 (Squeeze) Motivo: Es una distribuci´on original (no est´a basada en ninguna otra), es muy conocida y es compatible con paquetes de Ubuntu. Comentarios: solo se usar´a el CD1. Linux Mint versi´ on: 12 (Lisa) Variante: LXDE Motivo: Es la distribuci´on elegida para los PCs m´as antiguos de TxT. Se ha elegido como referencia. Comentarios: No es la versi´on m´as moderna, pero es la u ´ltima que se puede grabar en un CD de 700 MB. Puppy Linux Versi´ on: 5.4.3 Variante: Ubuntu Precise Motivo: Es una distribuci´on extremadamente ligera, usa JDM (un entorno de escritorio muy ligero), arranca desde ramdisk y tiene muy buena valoraci´on en DistroWatch. Comentarios: Se usar´a el modo de instalaci´on Full.

33

Slackware Versi´ on: 14.0 Variante: KDE y XFCE Motivo: Es una distribuci´on original de las m´as antiguas y muy completa en cuanto a funcionalidades. fue sugerida por mis directores. Comentarios: Esta distribuci´on debe ser grabada en un DVD como m´ınimo. Ambas variantes se encuentran en el mismo disco. Se tratar´an las dos variantes por separado. Lubuntu Versi´ on: 12.10 Motivo: Versi´on ligera de Ubuntu, con escritorio LXDE (muy ligero). Tiene buena puntuaci´on en DistroWatch. Xubuntu Versi´ on: 12.10 Motivo: ´Idem a la anterior, pero con escritorio XFCE (tambi´en muy ligero, auque no tanto como LXDE). Ubuntu Versi´ on: 12.04 Motivo: Distribuci´on muy popular. Es una versi´on LTS (Long Term Support). Es la que se usa actualmente en la mayor´ıa de PCs de TxT. Se ha elegido como referencia. Comentarios: No es la versi´on m´as moderna, pero es la u ´ltima que se puede grabar en un CD de 700 MB. Todas las instalaciones se hicieron sin acceso a la red y con todas las opciones por defecto, con las siguientes excepciones: Se activa la opci´on de auto-login siempre que sea posible. Esto es para favorecer la medici´on del tiempo de arranque. En la variante KDE de Slackware no se instala XFCE y viceversa. Esto es para no perturbar la medici´on de la ocupaci´on del disco. 34

En las distribuciones que no proporcionan un particionamiento del disco por defecto, se instala todo el sistema en una u ´nica partici´on. Tambi´en se hace una partici´on swap de tama˜ no igual al doble de la cantidad de memoria del sistema. Siempre se usa ext4.

4.2.2.

An´ alisis de funcionalidades

Una vez elegidas las distribuciones, se calcula su funcionalidad. Para ello, primero se toman de cada distribuci´on los programas pertenecientes a cada una de las categor´ıas de la encuesta (v´ease el ap´endice B). Con esto ya podemos ver que algunas de las distribuciones no traen programas para algunas de las categor´ıas. Por ejemplo, Xubuntu no incluye ning´ un programa para trabajar con hojas de c´alculo. Estas distribuciones posiblemente se vean perjudicadas en el aspecto de funcionalidad. Solo se tuvo en cuenta el software incluido en la instalaci´on por defecto. El software incluido en el disco que no est´e seleccionado por defecto no se valorar´a. El software no incluido en el disco pero incluido en los repositorios o instalable a trav´es de scripts post-instalaci´on u otros medios tampoco se valorar´a. Si alg´ un software incluido en la instalaci´on por defecto tiene actualizaciones disponibles a trav´es de Internet, estas actualizaciones tampoco se tendr´an en cuenta. Para saber qu´e software incluye cada distribuci´on simplemente se instal´o cada una de ellas en una m´aquina virtual. Despu´es se mira qu´e funcionalidades tiene cada programa y cuales no (v´ease el ap´endice C). Aqu´ı podemos ver como las distintas alternativas para una misma categor´ıa tienen distintos equilibrios entre funcionalidad y rendimiento. Por ejemplo, Abiword es m´as ligero que LibreOffice Writer, pero tambi´en tiene muchas menos funcionalidades. M´as adelante, cuando se eval´ ue el renimiento, se podr´a ver m´as claramente qu´e distribuciones balancean mejor funcionalidad y rendimiento. Finalmente, uniendo los programas por distribuci´on con las funcionalidades por programa se puede saber qu´e funcionalidades cumple cada distribuci´on. Esta ser´a la medida que se usar´a como representativa del nivel de funcionalidad de cada distribuci´on. Inicialmente se pens´o en contar solo las funcionalidades con m´as del 50 % de votos, para distinguir las funcionalidades populares de las no populares. Finalmente se opt´o por un total normalizado, usando el valor normalizado que se calcul´o con los resultados de la encuesta. El desglose de los resultados puede encontrarse en ap´endice D. A continuaci´on se muestran los totales.

35

CrunchBang

Debian

Linux Mint

Puppy Linux

KDE

XFCE

Lubuntu

Xubuntu

Ubuntu

Total mayoritarios (abs) Total mayoritarios ( %) Total normalizado ( %)

Bodhi Linux

Total

Funcionalidad

Slackware

La fila “Total (abs)” indica el total de votos para las funcionalidades con m´as del 50 % de votos. La fila “Total ( %)” indica el porcentaje de funcionalidades con m´as del 50 % de votos que cumple. La fila “Total normalizado” es una ponderaci´on teniendo en cuenta todas las funcionalidades y su valor normalizado (v´ease el ap´endice A). Leyenda: 1 = S´ı; 0 = No; 0,5 = Parcial

2,5

12,5

10

19,5

16,5

23

15

19

13

19

8,33

41,67 33,33 65,00 55,00 76,67 50,00 63,33 43,33 63,33

9,49

43,93 38,77 70,14 60,72 83,49 55,77 65,67 51,04 72,72

Con estos resultados es f´acil observar que Bodhi Linux no llegar´a lejos, ya que cumple menos del 10 % de las funcionalidades, muy por debajo del resto de distribuciones (esto se debe principalmete a que casi no trae ning´ un programa por defecto). Por esta raz´on se decidi´o descartar Bodhi Linux como distribuci´on candidata, incluso antes de medir su rendimiento.

4.3. 4.3.1.

An´ alisis de los PCs PCs de TxT

Con tal de preparar las pruebas, hice una visita al almac´en de TxT para ver con qu´e PCs tendr´ıa que trabajar. En el momento de la inspecci´on, la mayor´ıa de los PCs eran de los siguientes tipos:

36

Modelo A Procesador: Pentium 4 Frecuencia del procesador: 3,20 GHz N´ umero de n´ ucleos: 1 N´ umero de threads por n´ ucleo: 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 N´ umero de n´ ucleos: 2 N´ umero de threads por n´ ucleo: 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 N´ umero de n´ ucleos: 2 N´ umero de threads por n´ ucleo: 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 y se trataron como outliers. Estos 3 tipos de PCs eran comunes en gran n´ umero, probablemente debido a que las donaciones de equipos a TxT se hacen en grandes cantidades. En cambio, los outliers 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 llave del almac´en que me ten´ıan que dar se extravi´o y, durante la mayor parte del trabajo, solo pude entrar cuando hubiese alguien dentro, as´ı que decid´ı realizar las primeras pruebas en mi casa. Para poder hacer pruebas en casa y no tener que depender de TxT dispuse de un PC de las siguientes caracter´ısticas: Modelo A0 Procesador: Pentium 4 Frecuencia del procesador: 3,00 GHz N´ umero de n´ ucleos: 1 N´ umero de threads por n´ ucleo: 2 (Hyperthreading) Memoria: 512 MB + 1 GB Disco: 80 GB Lector de DVD : S´ı (DVD-RW) La intenci´on es que el PC A0 simule un “suelo” para poder decidir la magnitud de las pruebas; es decir, un PC con los m´as bajos recursos (no queremos un benchmark que tarde demasiado en ejecutarse en un PC lento, ya que la finalidad de este es precisamente ejecutarlo sobre PCs lentos). En principio se eligi´o para que fuese un PC con hardware similar al PC A, que es el PC de TxT con los recursos m´as bajos. Finalmente, a pesar de que tuviese m´as memoria las pruebas de rendimiento indican que es a´ un m´as lento que el PC A. Esto no supone un problema, ya que al quedar por debajo del PC A cumple su cometido correctamente. Con este PC me dispuse a realizar unas pruebas de rendimiento con una versi´on preliminar del benchmark para poder disponer de unos datos sobre el rendimiento de cada distribuci´on, aunque fuesen solo aproximados. Los resultados se muestran a continuaci´on.

38

Linux Mint

Puppy Linux

KDE

XFCE

Lubuntu

Xubuntu

Ubuntu

Slackware

Debian

39

Ocupaci´on del disco (GB) Uso de la memoria (MB) Tiempo de arranque (s) Tiempo de arranque de LibreOffice (s) Tiempo de apertura de many_as.txt Velocidad de descarga (MB/s) Tiempo de compilaci´on del kernel (en serie) Tiempo de compilaci´on del kernel (en paralelo) Consumo energ´etico (W)

CrunchBang

Par´ ametro

2,3 244 36,94

1,5 165 30,20

2,5 295 20,80

0,72 104 21,21

6,7 628 162,14

5,3 298 35,72

1,8 291 18,73

2,1 390 20,72

2,4 683 20,87

12,45

10,97

10,01

13,00

18,10

8,31

12,30

10,86

14,32

2’ 37”

2’ 15”

2’ 22”

3’ 21”

3’ 22”

3’ 05”

1’ 14”

1’ 11”

3’ 22”

1,03

1,16

1,13

1,11

1,11

1,13

1,12

1,12

1,00

7’ 58”

7’ 07”

7’ 30”

7’ 41”

10’ 32”

8’ 44”

8’ 33”

8’ 27”

9’ 38”

8’ 56”

5’ 44”

5’ 53”

5’ 56”

10’ 18”

8’ 31”

6’ 12”

6’ 12”

8’ 29”

59,0

58,0

59,0

55,5

59,0

59,0

58,5

59,0

58,5

4.4.

Criba de distribuciones

Una vez obtenidos los datos sobre la funcionalidad y el rendimiento de las distribuciones se puede hacer una criba y escoger solo con las m´as prometedoras, para ahorrar trabajo en las pruebas y mediciones que se har´ıan m´as tarde. Se determin´o que la distribuci´on ideal ser´ıa aquella que tenga m´as funcionalidades y supere unos determinados m´ınimos de rendimiento. Por lo tanto, us´e la funcionalidad de las distribuciones para ordenar las distribuciones y los resultados de las pruebas de rendimiento para hacer la criba. Como resultado, las distribuciones Debian, CrunchBang, Xubuntu y Slackware (variante XFCE) fueron eliminadas por ser las distribuciones con menor funcionalidad. Slackware (variante KDE) se mantuvo a pesar de tener malos resultados en las pruebas de rendimiento por ser la distribuci´on con mayor funcionalidad. De ahora en adelante, siempre que se haga referencia a Slackware se referir´a a la variante KDE, a menos que se especifique lo contrario.

4.5. 4.5.1.

Pruebas de rendimiento en PCs de TxT Resultados y reporte de incidencias

Una vez finalizado el benchmark, seleccionadas las distribuciones y analizados los PCs es momento de realizar las mediciones. Los resultados se encuentran en el ap´endice F. Durante las pruebas se detectaron las siguientes incidencias: El PC B era incapaz de arrancar desde algunos de los CDs y DVDs (en particular, Linux Mint, Puppy Linux y Ubuntu). Se solucion´o instalando dichas distribuciones desde USB. El PC A pide configurar la BIOS y poner el reloj en hora cada vez que se enciende. Posiblemente se deba a que la pila que alimenta la BIOS est´e gastada. No fue necesario cambiarla; bast´o con configurar la BIOS y el reloj cada vez que se encend´ıa (solo la primera vez tras perder la alimentaci´on); esto no afect´o a la medici´on 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 dem´as. Esto es debido a que

40

LibreOffice se queda “congelado” durante un tiempo despu´es de abrirse pero antes de mostrar el archivo. Desconozco la causa, pero es obvio que esto penalizar´a gravemente a esas distribuciones. Los tiempos de arranque del PC B son m´as altos que los del PC A, a pesar de que este es m´as nuevo y dispone de mejor hardware. En cualquier caso, no es el objetivo de este proyecto el descubrir el por qu´e de este fen´omeno. Adem´as, la diferencia no es demasiado grande como para causar un gran impacto en los resultados, as´ı que no se le dar´a m´as importancia al asunto. LibreOffice en Slackware arranca m´as r´apido en PCs m´as viejos. Es un dato bastante desconcertante al cual no le encuentro explicaci´on. De todos modos, Slackware es siempre el m´as lento en todos los par´ametros. La compilaci´on del kernel de Linux en Slackware muestra un warning, aunque esto no afecta a las mediciones del tiempo de compilaci´on ni a los resultados del benchmark. La conexi´on de red del almac´en de TxT no era la adecuada para llevar a cabo las mediciones. La velocidad era muy variable, llegando incluso a mostrar diferencias de cientos de KB/s en una misma distribuci´on en un mismo PC. Presumiblemente esto se debe a que hay m´as gente conectada a la red y hacen un uso intensivo de ella. Para solucionarlo simplemente se usar´an los datos obtenidos en las pruebas preliminares (las que se hicieron con el PC A0), ya que tras la experimentaci´on con Raspberry Pi (m´as adelante) se ha visto que la velocidad de red no var´ıa demasiado de un hardware a otro y, adem´as, tampoco var´ıan mucho entre distribuciones, con lo que no resultar´a un par´ametro decisivo.

4.5.2.

Conclusiones

De las pruebas realizadas con los PCs de TxT se extraen las siguientes conclusiones: Disco: Ubuntu, Linux Mint y Lubuntu est´an a la par. Slackware ocupa bastante m´as y Puppy Linux bastante menos. No var´ıa mucho entre PCs. Memoria: Es un poco irregular, pero a´ un as´ı es f´acil de ver el requisito de cada distribuci´on. Slackware y Ubuntu son los m´as altos, Linux Mint y Lubuntu son m´as razonables y Puppy Linux es diminuto. 41

Tiempo de arranque del SO: Linux Mint arranca bastante m´as r´apido en el Core 2 duo. Lubuntu y Puppy Linux tambi´en mejoran en este procesador, pero la diferencia es peque˜ na. Slackware es siempre muy alto. B´asicamente todos excepto Slackware arrancan en un tiempo aceptable. Tiempo de arranque de LibreOffice: Muy constante. Ligeramente mejores en el procesador m´as nuevo. La excepci´on es Slackware, que va mejor con el procesador m´as viejo. Tiempo de apertura de many as.txt con LibreOffice: Aqu´ı es notable una gran diferencia en Slackware y Puppy Linux. Esto es debido a que LibreOffice se queda bloqueado durante alg´ un tiempo antes de mostrar el archivo. El bloqueo dura bastante tiempo (unos 40 segundos) y penaliza gravemente a aquellas distribuciones que lo sufran. Aunque no se ha comentado antes, esto tambi´en suced´ıa en las pruebas en el PC A0, incluso en distribuciones en las que no se produce ning´ un bloqueo con los PCs de TxT. No se report´o como un incidente 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 secci´on anterior, esta prueba no se realiz´o con ´exito. Tiempos de compilaci´ on del kernel de Linux: Se ven fuertemente influenciados por el procesador, sobretodo la compilaci´on en paralelo. Es bastante constante entre distribuciones (excepto Slackware, que es m´as lento). Consumo energ´ etico: Muy influenciado por el procesador (hasta 15 W de diferencia). Muy constante entre distribuciones. Puppy consume un par de W menos, pero poca cosa. No es un par´ametro decisivo.

4.5.3.

Interpretaci´ on de los resultados

Con estos resultados se debe escoger una de las distribuciones como la mejor. Se decidi´o eliminar Lubuntu, ya que casi no ofrece mejoras con respecto a Linux Mint y tiene casi un 5 % menos de funcionalidad. Adem´as, Puppy Linux solo se usar´a como u ´ltimo recurso, en caso de que el sistema no tuviese suficiente memoria para ninguna otra distribuci´on. Para determinar qu´e distribuci´on es mejor para cada PC se seguir´a la metodolog´ıa siguiente:

42

Disco y memoria Deber´a usar como m´aximo la mitad del total (en el caso del disco, exceptuando swap). Tiempos y consumo Sea xi el valor de la distribuci´on i en el campo x, y x¯ la media de todas las distribuciones (Slackware, Ubuntu y Linux Mint) en el campo x, se considerar´a que la distribuci´on i cumple el requisito si: xi = r¯ Se ha implementado un script que realiza estos c´alculos en base a los resultados de del benchmark. El c´odigo fuente de este script se encuentra en el ap´endice E.3.

4.6.

Realizando estimaciones

En la modalidad del benchmark que realiza estimaciones sobre Ubuntu, estas son unas estimaciones muy sencillas, ya que teniendo unas mediciones reales como base se pueden aproximar las mediciones reales de las dem´as distribuciones de manera moderadamente sencilla con solo a˜ nadir un offset a las mediciones reales (la diferencia media entre las distribuciones). En cuanto a las estimaciones en base a la distribuci´on live, debido al bajo n´ umero de muestras solo podemos realizar estimaciones en base a 2 variables (+1 variable de offset). Como algunas de las variables est´an correlacionadas con m´as de 2 variables, hay que escoger 2 de ellas. Simplemente se escoger´an las 2 variables con la correlaci´on m´as significativa.

43

Para calcular en qu´e proporci´on afecta cada variable se har´a simplemente un sistema de ecuaciones. Por ejemplo, para estimar el tiempo de arranque de Ubuntu se 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 siguiente ecuaci´on: Tiempo de arranque = Ancho de banda del disco × −0, 19 +Ancho de banda de la memoria (tramo 4) × 0, 88 +32, 10 Para las dem´as variables y distribuciones, las ecuaciones resultantes se encuentran en el ap´endice I: Para comprobar los resultados, se realiz´o una regresi´on lineal m´ ultiple [13] con el programa Minitab [14]. Los resultados coincidieron, con lo que podemos asumir que son correctos.

4.7.

Comparativa de modalidades del benchmark

Ahora que se tienen las 3 modalidades del benchmark implementadas, podemos compararlas para conseguir una proporci´on entre tiempo de ejecuci´on y precisi´on 44

o´ptimas. Como las estimaciones se han hecho en base a los PCs utilizados a lo largo del trabajo, resulta obvio que todas las modalidades del benchmark devolver´an los mismos resultados para estos PCs. Para poder probar de manera efectiva las distintas modalidades, se deben ejecutar en un PC totalmente nuevo. A continuaci´on se detallan las especificaciones de este nuevo PC: Modelo X Procesador: AMD Athlon 64 X2 Frecuencia del procesador: 2,00 GHz N´ umero de n´ ucleos: 2 N´ umero de threads por n´ ucleo: 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 los que 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 c Benchmark cl´asico Linux Mint Linux Mint Ubuntu Linux Mint Benchmark Ubuntu Linux Mint Linux Mint Ubuntu Puppy Linux Linux Mint Benchmark live Linux Mint Linux Mint Ubuntu Puppy Linux Slackware a

Usando descartes tempranos por memoria y disco. Sin usar descartes tempranos por memoria y disco. c La modalidad de benchmark cl´ asico no realiza descartes tempranos. b

Como podemos ver, en los PCs con los que se ha trabajado todas las modalidades dan el mismo resultado, como ya se hab´ıa previsto. Cabe destacar que en los PCs A, B y X se detuvo la ejecuci´on del benchmark durante los descartes por memoria y/o disco, lo que hace pensar que el uso de memoria es un fuerte discriminante en este tipo de PCs. Para comprobar la precisi´on de las estimaciones, se han volvi´o a ejecutar los distintos benchmark deshabilitando la funci´on que realiza los descartes, para as´ı poder ver los rendimientos estimados y compararlos con los reales. 45

46

Par´ amtero

Ubuntu

Disco (GB) Memoria (MB) Tiempo de arranque del SO (s) Tiempo de arranque de LibreOffice (s) Tiempo de apertura de many_as.txt (s) Tiempo de compilaci´on en serie (s) Tiempo de compilaci´on en paralelo (s)

2,38 653

Linux Mint 2,48 451

6,68 701

Linux Mint a 2,47 c 473 c

24,28

27,33

61,94

27,53

75,97

23,19

-50,72

173,41

8,934

8,468

12,012

8,340

11,654

4,823

-3,873

-116,047

172,682

78,872

130,559

175,112

207,487

82,834

1006,352

-235,406

296,913

292,369

334,260

313,123

389,037

211,586

13,142

-71,369

155,053

153,121

183,267

602,048

497,402

626,916

Slackware

Slackware Ubuntu

Slackware

2,38 c 680 c

Linux Mint b 2,47 c 500 c

a

b

6,81 c 726 c

Cuadro 4.6: Comparaci´on del rendimiento real de las distribuciones con el rendimiento estimado. a

Estimado en base a Ubuntu. Estimado en base a la distribuci´on live. c Estimado por la funci´on de descartes tempranos. b

b

6,68 c 753 c

Como se puede observar, las estimaciones realizadas basadas en Ubuntu son moderadamente acertadas. Aunque hay excepciones (p. ej., el tiempo de apertura de many as.txt en Slackware), grosso modo los valores son aceptables y el resultado final (la elecci´on de la distribuci´on o´ptima) coincide con el benchmark cl´asico, con lo que esta modalidad de benchmark se puede considerar exitosa. En cambio, las estimaciones basadas en la distribuci´on live s´on claramente err´oneas, llegando incluso a retornar tiempos negativos. Esto es debido muy posiblemente al bajo n´ umero de muestras del que se dispone. A pesar de esto, la metodolog´ıa propuesta es correcta, y se podr´ıan obtener buenas predicciones si se dispusiera de un mayor n´ umero de muestras.

4.8.

Experimentaci´ on con un Pocket PC

El experimento consisti´o simplemente en ejecutar el benchmark (modalidad cl´asica) en una Raspberry Pi con sistema operativo Raspbian (que es b´asicamente una Debian ARM adaptada a la Raspberry Pi ). Se trabaj´o con 3 versiones de Raspbian: Base, tal cual queda el sistema tras una instalaci´on por defecto; Mod, tras instalar todos los programas necesarios para maximizar las funcionalidades; y Potencial, igual que Mod, pero incluyendo las licencias para decodificar MPEG-2 y VC-1 (se compran por separado). De la versi´on potencial solo se calcularon las funcionalidades, ya que el rendimiento seguramente no variar´a (solo son un par de codecs) y no se vio necesario comprar las licencias. Los resultados se muestran en la tabla al final de esta secci´on. Si bien los resultados no fueron mejores que los de los PCs de TxT, s´ı que fueron mejores que los del PC A0 (Procesador Pentium IV, 1,5 GiB de RAM). El principal problema es el multitasking: LibreOffice Writer funciona de manera decente, pero a la que abrimos el navegador el sistema se vuelve muy lento y resulta tedioso usarlo. Esto probablemente sea debido a la falta de paralelismo del procesador de la Raspberry Pi. Por desgracia, es muy habitual (o incluso necesario) ejecutar varios programas al mismo tiempo, por lo que no creo que la Raspberry Pi sea adecuada para sustituir un PC de escritorio en tareas ofim´aticas. Tambi´en se puede observar que el tiempo de compilaci´on del kernel de Linux es muy alto, unas 10 veces m´as alto que en los PCs de TxT, de lo cual se deduce que estas m´aquinas no son adecuadas para cargas de trabajo intensas. No obstante, si miramos el consumo energ´etico vemos que es aproximadamente 20 veces menor que el de un PC de sobremesa, con lo cual el trabajo realizado por unidad de potencia es el doble que el de un PC. Es m´as, la Raspberry Pi disipa tan poca energ´ıa que ni siquiera necesita refrigeraci´on (no tiene ventiladores ni disipadores, y la caja solo 47

tiene respiraci´on en la base). Con esto, la Raspberry Pi se convierte en la elecci´on perfecta para sistemas que requieran estar encendidas de continuo pero cuya carga de trabajo sea baja, como por ejemplo un servidor domestico o un sustituto de un sistema integrado (embedded ). No obstante, la Raspberry Pi tiene una buena GPU (capaz incluso de reproducir v´ıdeo de alta resoluci´on), con lo cual podr´ıa soportar cargas intensas siempre y cuando sean cargas de GPU, no de CPU. Esto la hace ideal como media center o reproductor multimedia. Tambi´en se podr´ıan realizar tareas con alto coste de c´omputo usando la GPU en lugar de la CPU, pero esto probablemente requerir´a modificar los programas para que funcionen con la GPU de la Raspberry Pi. Par´ amtero Disco (GB) Memoria (MB) Tiempo de arranque del SO (s) Tiempo de arranque de LibreOffice (s) Tiempo de apertura de many_as.txt (s) Velocidad de red (MB/s) Tiempo de compilaci´on en serie (s) Tiempo de compilaci´on en paralelo (s) Consumo energ´etico (W)

Base (Pre) 1,5 112 37,81

Base

Mod

1,51 116 35,65

2,53 115 52,54

13,29

16,468

21,945

138

145,389

150,274

1,13 2921

2899,735 2864,198

2934 3,5

3,5

3,5

Cuadro 4.7: La columna “Base (Pre)” corresponde a las mediciones realizadas con la versi´on preliminar del benchmark. Las columnas “Base” y “Mod” est´an realizadas con la versi´on final del benchmark (primera modalidad), sin prueba de red. Adem´as, en estas columnas no se realiz´o la prueba de medici´on de compilaci´on del kernel con 4 threads, ya que se ha visto que, al tener solo 1 CPU y un overhead despreciable, no supone diferencia con respecto a la medici´on de compilaci´on del kernel con 1 thread. Las columnas “Base (Pre)” y “Base” corresponden a la distribuci´on Raspbian por defecto. La columna “Mod” corresponde a la misma distribuci´on con paquetes adicionales instalados.

48

Cap´ıtulo 5 Conclusiones 5.1.

Conclusiones

En la actividad en la que yo particip´e (hace m´as de 1 a˜ no) se instalaba Ubuntu en todos los PCs, independientemente de sus especificaciones. Actualmente la directiva de TxT a la hora de elegir una distribuci´on es usar Ubuntu si el PC tiene m´as de 1 GiB de memoria y Lubuntu en caso contrario. Con esta directiva, se elegir´ıa Lubuntu para los PCs A y B y Ubuntu para el C, aunque he encontrado PCs con Linux Mint instalado. Seg´ un mi benchmark, la distribuci´on ideal para cada PC ser´ıa Linux Mint para el A y el B y Ubuntu para el C. Es obvio que durante el u ´ltimo a˜ no en TxT se han dado cuenta de la importancia de escoger una distribuci´on adecuada para cada PC y han optado por una distribuci´on m´as ligera para los PCs menos potentes. No obstante, personalmente creo que han dejado un poco de lado la funcionalidad en favor del rendimiento al escoger Lubuntu frente a Linux Mint. Adem´as, la separaci´on entre ‘m´as de un giga’ y ‘un giga o menos’ no es lo suficientemente fina. En una ocasi´on se encontraron con un PC con 512 MiB de memoria y quisieron instalarle Lubuntu, siguiendo su directiva. No obstante, Lubuntu ocupa hasta 480 MiB en reposo, con lo cual el resultado habr´ıa sido nefasto. Una distribuci´on como Puppy Linux (∼ 180 MiB) habr´ıa sido m´as acertada. No obstante cabe destacar que han acertado al escoger la cantidad de memoria como par´ametro discriminante. En las pruebas que he realizado he podido ver que en la mayor´ıa de los casos la ejecuci´on del benchmark acababa con los descartes realizados a ra´ız de la cantidad de memoria.

49

En resumen, la pol´ıtica de TxT en cuanto a qu´e distribuci´on elegir ha mejorado con respecto a la actividad que origin´o mi motivaci´on para realizar este trabajo, pero a´ un quedan detalles por pulir. Conf´ıo en que este trabajo ayude a TxT y a sus usuarios a conseguir una mejor experiencia. En cuanto a la Raspberry Pi, su debilidad es la CPU y su fortaleza reside en la GPU. Me parece obvio que los creadores han querido enfocar el aparato m´as hacia la reproducci´on multimedia que al escritorio. Por suerte, la Raspberry Pi no es el u ´nico Pocket PC del mercado, y hay alternativas que quiz´as cumplan mejor como sustituto de un PC de sobremesa. Cubieboard [15], por ejemplo, parece ser m´as adecuada para esta 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 m´as distribuciones de Linux (Debian, Fedora, Ubuntu, e incluso Android) por un precio muy similar. El procesador sigue siendo de un solo core y thread. Existen otras alternativas con procesadores multicore [16], pero tienen un precio m´as elevado.

5.2. 5.2.1.

Trabajo futuro Comportamientos an´ omalos

Durante la realizaci´on de este trabajo me he encontrado con comportamientos que desaf´ıan la l´ogica. Los ejemplos m´as claros son el hecho de que Slackware parece funcionar mejor en PCs con menos recursos, a pesar de ser la distribuci´on que m´as recursos usa y que LibreOffice se quede congelado durante un tiempo al iniciar en Slackware (la distribuci´on m´as pesada), pero tambi´en en Puppy Linux (la distribuci´on m´as ligera) y no en las dem´as. Entender el por qu´e de estos fen´omenos podr´ıa ayudar a realizar estimaciones m´as precisas y, en general, ayudar en la finalidad de este trabajo, que es seleccionar la distribuci´on m´as acertada para cada PC.

5.2.2.

A˜ nadir atributos a medir al benchmark

Siempre cabe la posibilidad de extender el benchmark a˜ nadiendo par´ametros, como podr´ıan ser el tiempo de abrir una p´agina web (para profundizar m´as en la gesti´on de la red) o el framerate medio al reproducir un v´ıdeo en alta resoluci´on (para profundizar en el aspecto de computaci´on gr´afica). Esto a si vez podr´ıa llevar a hilar m´as fino en el an´alisis de aplicaciones y funcionalidades. Por ejemplo, teniendo en 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, principalmente porque 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 a´ un leen solo CDs) se podr´ıa aprovechar para probar con versiones m´as actuales de las distribuciones escogidas o incluso con distribuciones nuevas que no se hayan tratado en este trabajo.

5.2.4.

Mejorar la estad´ıstica

Debido a las pocas muestras, la estad´ıstica en la que se basan las estimaciones de la distribuci´on live no son muy s´olidas. Esto podr´ıa solucionarse tomando m´as muestras de m´as tipos de PCs (nuevos PCs llegan a TxT continuamente). La distribuci´on live y los scripts ya est´an hechos, a modo de prueba de concepto, ahora solo ser´ıa cuesti´on de ampliar la poblaci´on de muestras con nuevos PCs. Adem´as, 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 con los 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 m´as adecuada a un PC de sobremesa, existen otros modelos de Pocket PC m´as dirigidos a estas funciones que podr´ıa quedar en mejor lugar. Como ya se ha demostrado, el benchmark puede funcionar perfectamente en dispositivos de este tipo, as´ı que no ser´ıa dif´ıcil ampliar el trabajo por esta rama.

51

Ap´ endices

52

Ap´ endice A Resultados de la encuesta Las columnas “Votos (abs)” y “Votos ( %)” indican el n´ umero de votos que ha obtenido la respuesta y el porcentaje de encuestados que la seleccionaron respectivamente. La columna “Valor normalizado” indica la proporci´on de votos que corresponden a esta respuesta respecto a los votos totales (de todas las respuestas). Las funcionalidades “soporte para HD-DVD” y “soporte para Blu-Ray” ser´an ignoradas, ya que los PCs con los que se tratar´a no disponen del hardware necesario.

Procesador de textos

Funcionalidad Compatible con documentos de Office 2010 (.docx) Compatible con documentos de LibreOffice y OpenOffice (.swx) Posibilidad de a˜ nadir comentarios a los documentos Crear gr´aficos y dibujos sin necesidad de una herramienta externa Integraci´on con una suite ofim´atica completa Versi´on para Mac OS X

53

Votos (abs)

Votos ( %)

Valor normalizado

77

87,50 %

3,56 %

47

53,41 %

2,17 %

45

51,14 %

2,08 %

54

61,36 %

2,50 %

18

20,45 %

0,83 %

14

15,91 %

0,65 %

Navegador Cliente de correo Locali.

Hoja de c´ alculo

Funcionalidad Corrector ortogr´afico Imprimir selecci´on (no toda la p´agina) Alto n´ umero de celdas (m´as de 1000 columnas por p´agina, 56000 filas por p´agina, 256 p´aginas por libro) Immobilizar paneles (cabeceras siempre visibles) Importar / exportar tablas LaTeX Interfaz en catal´an Soporte para escritura de derecha a izquierda Filtro anti-phishing (estafa cibern´etica) sin necesidad de complementos Lector de feeds RSS sin necesidad de complementos Vista previa de documentos de texto (pdf, doc, xls, odt, ods) Bloqueo de pop-ups sin necesidad de complementos Bloqueo de publicidad (AdBlock) sin necesidad de complementos Control por voz Gestos de rat´on Conversi´on texto-a-voz (Text-to-speech) Incorpora su propio plugin Flash Lector de feeds RSS incorporado sin necesidad de complementos ni herramientas externas Gestor de contrase˜ nas (recordar contrase˜ nas, contrase˜ na maestra)

54

Votos (abs) 36

Votos ( %) 40,91 %

Valor normalizado 1,67 %

61

69,32 %

2,82 %

16

18,18 %

0,74 %

46

52,27 %

2,13 %

21

23,86 %

0,97 %

45

51,14 %

2,08 %

8

9,09 %

0,37 %

52

59,09 %

2,41 %

10

11,36 %

0,46 %

64

72,73 %

2,96 %

73

82,95 %

3,38 %

75

85,23 %

3,47 %

9 11

10,23 % 12,50 %

0,42 % 0,51 %

10

11,36 %

0,46 %

47

53,41 %

2,17 %

16

18,18 %

0,74 %

69

78,41 %

3,19 %

Gestor de ar.

Reproductor de v´ıdeo

Cliente MI

Protocolos MI

Funcionalidad Yahoo! Mail Windows Live messenger XMPP (Google talk, Facebook chat) IRC Skype MySpaceIM Emoticonos gr´aficos Emoticonos gr´aficos definidos por el usuario Chat de voz Chat de v´ıdeo Escritura a mano Soporte multi-cuenta Corrector ortogr´afico Soporte para subt´ıtulos Control de imagen (color, contraste, brillo) Control de sonido (tono) Resincronizaci´on de audio Resincronizaci´on de subt´ıtulos Soporte para VCD Soporte para SVCD Soporte para DVD Soporte para HD-DVD Soporte para Blu-Ray Miniaturas (Thumbnails) Pesta˜ nas Doble panel Previsualizaciones Navegar por archivos comprimidos Total

55

Votos (abs) 6 22

Votos ( %) 6,82 % 25,00 %

Valor normalizado 0,28 % 1,02 %

63

71,59 %

2,92 %

17 60 0 51

19,32 % 68,18 % 0,00 % 57,95 %

0,79 % 2,78 % 0,00 % 2,36 %

27

30,68 %

1,25 %

64 58 24 54 35 76

72,73 % 65,91 % 27,27 % 61,36 % 39,77 % 86,36 %

2,96 % 2,68 % 1,11 % 2,50 % 1,62 % 3,52 %

48

54,55 %

2,22 %

54 53 56 26 24 62 42 48 56 63 32 59

61,36 % 60,23 % 63,64 % 29,55 % 27,27 % 70,45 % 47,73 % 54,55 % 63,64 % 71,59 % 36,36 % 67,05 %

2,50 % 2,45 % 2,59 % 1,20 % 1,11 % 2,87 %

57

64,77 %

2,64 %

88

100,00 %

100,00 %

2,59 % 2,92 % 1,48 % 2,73 %

Ap´ endice B Programas por distribuci´ on El navegador Iceweasel ser´a tratado como Firefox, debido a que es pr´acticamente el mismo (el cambio de nombre es debido a un conflicto de licencias). El mismo tratamiento se dar´a a Icedove / Thunderbird. Bodhi Linux

CrunchBang

Debian

Linux Mint

Ninguno

Abiword

Ninguno

Abiword

Ninguno

Gnumeric

Ninguno

Gnumeric

Ninguno

Ninguno

Evolution

Thunderbird

Navegador

Midori

Iceweasel

Cliente de MI Reproductor de v´ıdeo Gestor de archivos Interfaz en catal´ an Soporte para escritura de derecha a izquierda

Ninguno

Ninguno

Epiphany, Iceweasel Ninguno

Ninguno

VLC

Totem

Enlightenment File Manager

Thunar

Nautilus

PCManFM

Parcial

Parcial

S´ı

Parcial

No

S´ı

S´ı

S´ı

Procesador de textos Hojas de c´ alculo Cliente de correo

56

Firefox Pidgin MPlayer, VLC

Puppy Linux Procesador de textos Hojas de c´ alculo

Abiword

Calligra Words

Ninguno

Gnumeric

Calligra Sheets

Ninguno

Cliente de correo

SeaMonkey

Navegador

SeaMonkey

Cliente de MI

Ayttm

Reproductor de v´ıdeo

MPlayer

Gestor de archivos Interfaz en catal´ an Soporte para escritura de derecha a izquierda

Slackware KDE XFCE

KMail, SeaMonkey, Thunderbird Firefox, Konkeror, SeaMonkey Kopete, Pidgin Dragon Player, KPlayer, MPlayer, xine Dolphin, Konkeror

ROX Filer

SeaMonkey, Thunderbird Firefox, SeaMonkey Pidgin MPlayer, xine Thunar

Parcial

S´ı

S´ı

No

S´ı

S´ı

57

Procesador de textos Hojas de c´ alculo Cliente de correo Navegador Cliente de MI Reproductor de v´ıdeo Gestor de archivos Interfaz en catal´ an Soporte para escritura de derecha a izquierda

Lubuntu

Xubuntu

Abiword

Abiword

Gnumeric

Ninguno

Sylpheed

Thunderbird

Thunderbird

Chromium Pidgin

Firefox Pidgin

Firefox Empathy

MPlayer

Parole

Totem

PCManFM

Thunar

Nautilus

S´ı

S´ı

S´ı

S´ı

S´ı

S´ı

58

Ubuntu LibreOffice Writer LibreOffice Calc

Ap´ endice C Funcionalidades por programa

Cuadro C.1: Procesador de textos Calligra Abiword Words Compatible con documentos .docx No S´ı (Office 2010) Compatible con documentos .swx No S´ı (LibreOffice, OpenOffice) Posibilidad de a˜ nadir S´ı S´ı comentarios a los documentos Crear gr´ aficos y dibujos sin necesidad de una No No herramienta externa Integraci´ on con una suite ofim´ atica No S´ı completa Versi´ on para Mac OS X S´ı S´ı

59

LibreOffice Writer S´ı

S´ı

S´ı

S´ı

S´ı S´ı

Cuadro C.2: Hoja de c´alculos Calligra Gnumeric Sheets Corrector ortogr´ afico S´ı No Imprimir selecci´ on S´ı S´ı Alto n´ umero de celdas No S´ı Inmobilizar paneles No S´ı Importar / exportar No S´ı tablas LaTeX

LibreOffice Calc S´ı No No No S´ı

Cuadro C.3: Cliente de correo KMail SeaMonkey Sylpheed Thunderbird Filtro anti-phishing Lector de feeds RSS sin necesidad de complementos Vista previa de documentos

S´ı

No

No

S´ı

No

S´ı

No

S´ı

No

No

No

No

60

Dillo

Epiphany

Firefox

Konkeror

Midori

NetSurf

SeaMonkey

Bloqueo popups Bloqueo publicidad Control por voz Gestos de rat´ on Conversi´ on texto-a-voz (Text-to-speech) Su propia versi´ on de Flash Lector de feeds RSS incorporado Gestor de contrase˜ nas

Chromium

Cuadro C.4: Navegador

S´ı No No No No S´ı No S´ı

No No No No No No No No

No No No No No No No S´ı

S´ı S´ı S´ı No No No S´ı S´ı

S´ı S´ı No S´ı No No S´ı S´ı

No S´ı No S´ı No No No No

S´ı S´ı No No No No No No

S´ı S´ı No No No No S´ı S´ı

Yahoo! Mail Windows Live Messenger XMPP IRC Skype MySpace IM

Cuadro C.5: Protocolos MI Ayttm Empathy S´ı No

Kopete S´ı

Pidgin S´ı

S´ı

S´ı

S´ı

S´ı

S´ı S´ı No No

S´ı S´ı No No

S´ı S´ı No No

S´ı S´ı No S´ı

Cuadro C.6: Cliente MI Ayttm Empathy Emoticonos gr´ aficos S´ı S´ı Emoticonos gr´ aficos S´ı S´ı definidos por el usuario Chat de voz No S´ı Chat de v´ıdeo No S´ı Escritura a mano No No Soporte multi-cuenta S´ı S´ı Corrector ortogr´ afico S´ı S´ı

61

Pidgin S´ı S´ı S´ı S´ı No S´ı S´ı

MPlayer

omxplayer

Parole

Totem

VLC

XBMC

S´ı No No No No S´ı S´ı S´ı No No

S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı No No

S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı No No

No No No No No No No No No No

S´ı No No No No S´ı S´ı S´ı No No

S´ı S´ı No No No S´ı S´ı S´ı No No

S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı No No

S´ı S´ı S´ı S´ı S´ı No S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı No S´ı No

62

Konkeror

Nautilus

PCmanFM

ROX Filer

Thunar

Miniaturas Pesta˜ nas Doble panel Previsualizaciones Navegar por archivos comprimidos

EFM

Cuadro C.8: Gestor de archivos

S´ı No S´ı No No

S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı S´ı No

S´ı S´ı No No No

S´ı No No S´ı No

S´ı No No No No

Xine

KPlayer

Soporte subt´ıtulos Control de imagen Control de sonido Re-sincronizaci´ on de audio Re-sincronizaci´ on de v´ıdeo Soporte para VCD Soporte para SVCD Soporte DVD Soporte para HD-DVD Soporte Blu-ray

Dragon player

Cuadro C.7: Reproductor de v´ıdeo

Ap´ endice D Funcionalidades por distribuci´ on El protocolo de mensajer´ıa instant´anea “MySpace IM” se ha descartado, ya que no recibi´o ning´ un voto y resulta irrelevante. Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” se han eliminado debido a que los PCs con los que se tratar´a no disponen del hardware necesario. La fila “Total (abs)” indica el total de votos para las funcionalidades con m´as del 50 % de votos. La fila “Total ( %)” indica el porcentaje de funcionalidades con m´as del 50 % de votos que cumple. La fila “Total normalizado” es una ponderaci´on teniendo en cuenta todas las funcionalidades y su valor normalizado (v´ease el ap´endice A).

63

CrunchBang

Debian

Linux Mint

Puppy Linux

KDE

XFCE

Lubuntu

Xubuntu

Ubuntu

Compatible con documentos .docx Compatible con documentos .swx Posibilidad de a˜ nadir comentarios a los documentos Crear gr´aficos y dibujos Integraci´on con una suite ofim´atica completa Versi´on para Mac OS X Corrector ortogr´afico Imprimir selecci´on Alto n´ umero de celdas Immobilizar paneles Importar / exportar tablas LaTeX Interfaz en catal´an Soporte para escritura de derecha a izquierda

Bodhi Linux

alculo Localiza. Hoja de c´

Procesador de textos

Funcionalidad

Slackware

Leyenda: 1 = S´ı; 0 = No; 0,5 = Parcial

0

0

0

0

0

1

0

0

0

1

0

0

0

0

0

1

0

0

0

1

0

1

0

1

1

1

0

1

1

1

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

0

1

0

1

0

1

1

1

0

1

1

1

0 0

0 1

0 0

0 1

0 1

1 1

0 0

0 1

0 0

1 0

0

1

0

1

1

0

0

1

0

0

0

1

0

1

1

0

0

1

0

0

0

1

0

1

1

0

0

1

0

1

0,5

0,5

1

0,5

0,5

1

1

1

1

1

0

1

1

1

0

1

1

1

1

1

64

Debian

Linux Mint

Puppy Linux

KDE

XFCE

Lubuntu

Xubuntu

Ubuntu

Slackware

CrunchBang

Filtro anti-phishing Lector de feeds RSS Vista previa de documentos de texto Bloqueo de pop-ups Bloqueo de publicidad Control por voz Gestos de rat´on Conversi´on texto-a-voz Incorpora su propio plugin Flash Lector de feeds RSS Gestor de contrase˜ nas Yahoo! Mail Windows Live messenger XMPP (Google talk, Facebook chat) IRC Skype Emoticonos gr´aficos Emoticonos gr´aficos definidos por el usuario Chat de voz Chat de v´ıdeo Escritura a mano Soporte multi-cuenta Corrector ortogr´afico

Bodhi Linux

Cliente MI

Protocolos MI

Navegador

Correo

Funcionalidad

0 0

0 0

1 1

1 1

0 1

1 1

1 1

0 0

1 1

1 1

0

0

0

0

0

0

0

0

0

0

0 1 0 1

1 1 1 0

1 1 1 0

1 1 1 0

1 1 0 0

1 1 1 1

1 1 1 0

1 0 0 0

1 1 1 0

1 1 1 0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

1

0

0

0 0 0

1 1 0

1 1 0

1 1 1

1 1 1

1 1 0

1 1 0

0 1 1

1 1 1

1 1 0

0

0

0

1

1

1

1

1

1

1

0

0

0

1

1

1

1

1

1

1

0 0 0

0 0 0

0 0 0

1 0 1

1 0 1

1 0 1

1 0 1

1 0 1

1 0 1

1 0 1

0

0

0

1

1

1

1

1

1

1

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0

1 1 0 1 1

0 0 0 1 1

1 1 0 1 1

1 1 0 1 1

1 1 0 1 1

1 1 0 1 1

1 1 0 1 1

65

Debian

Linux Mint

Puppy Linux

KDE

XFCE

Lubuntu

Xubuntu

Ubuntu

Slackware

CrunchBang

Soporte para subt´ıtulos Control de imagen Control de sonido (tono) Resincronizaci´on de audio Resincronizaci´on de subt´ıtulos Soporte para VCD Soporte para SVCD Soporte para DVD Miniaturas (Thumbnails) Pesta˜ nas Doble panel Previsualizaciones Navegar por archivos comprimidos Total mayoritarios (abs) Total mayoritarios ( %) Total normalizado ( %)

Bodhi Linux

Total

Gestor de ar.

Reproductor de v´ıdeo

Funcionalidad

0

1

1

1

1

1

1

1

1

1

0

1

1

1

1

1

1

1

0

1

0

1

0

1

1

1

0

1

0

0

0

1

0

1

1

1

1

1

0

0

0

1

0

1

1

1

1

1

0

0

0 0 0

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1 1 1

1

1

1

1

1

1

1

1

1

1

0 1 0

0 0 0

1 1 1

1 0 0

0 0 1

1 1 1

0 0 0

1 0 0

0 0 0

1 1 1

0

0

0

0

0

1

0

0

0

0

2,5

12,5

10

19,5

16,5

23

15

19

13

19

8,33

41,67 33,33 65,00 55,00 76,67 50,00 63,33 43,33 63,33

9,49

43,93 38,77 70,14 60,72 83,49 55,77 65,67 51,04 72,72

66

Ap´ endice E C´ odigo fuente del benchmark (versi´ on 1) E.1.

run.sh

Este archivo contiene el orden en el que deben medirse los par´ametros y otras instrucciones 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 c´odigo capaz de medir los par´ametros 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 2 p | 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 2 p | 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 distintas distribuciones, calcula cu´antos requisitos cumple cada distribuci´on y ordena las distribuciones en orden de adecuaci´on. # !/ 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 2 p | 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 < 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

Ap´ endice H Estimaciones en base a la distribuci´ on live Los par´ametros calculados (columnas) son los siguientes: r: Coeficiente de correlaci´on de Pearson. Si r es cercana a 1, indica una fuerte correlaci´on lineal directa; si es cercana a -1 indica una fuerte correlaci´on lineal inversa; si es cercana a 0, indica que no existe correlaci´on lineal. StdErr: Error est´andar de r. Test hipo.: Test de hip´otesis de r. Es igual al error est´andar de r × t de student para el intervalo de confianza del 80 % y n − 2 grados de libertad (= 3,08). Sign.: Indica si la correlaci´on entre la variable y el tiempo de arranque es estad´ısticamente significativa. Es decir, si r >el test de hip´otesis 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. Valor medido por el benchmark (Ubuntu). Tiempo de arranque de many as: Tiempo de arranque de LibreOffice Writer abriendo 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

Compilaci´ on (1 thread ): Tiempo que tarda el sistema en compilar un programa de referencia usando solo 1 thread. Compilaci´ on (4 threads): Tiempo que tarda el sistema en compilar un programa de referencia usando 4 threads. Lectura RAM: tramo 1: Ancho de banda de lectura de la memoria para archivos de tama˜ no menor a 32 kiB. Lectura RAM: tramo 2: Ancho de banda de lectura de la memoria para archivos de tama˜ no entre 32 kiB y 256 kiB. Lectura RAM: tramo 3: Ancho de banda de lectura de la memoria para archivos de tama˜ no entre 256 kiB y 1 MiB. Lectura RAM: tramo 4: Ancho de banda de lectura de la memoria para archivos de tama˜ no mayor a 2 MiB.

89

90

Cuadro H.1: Correlaci´on entre el tiempo de arranque del SO y distintas variables. Test PC A PC B PC C r StdErr hipo. Tiempo de arranque del SO 25,20 27,33 24,31 (s) Ancho de banda del disco 58,1 42,6 62,7 -1,00 0,07 0,22 (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,08 1,00 3,07 Compilaci´on (1 thread ) (s) 141,983 148,85 107,143 0,82 0,57 1,74 Compilaci´on (4 threads) (s) 105,713 79,778 57,85 0,24 0,97 2,99 Lectura RAM: tramo 1 46 43 32 0,57 0,82 2,52 (GB/s) Lectura RAM: tramo 2 26 24 16 0,58 0,81 2,50 (GB/s) Lectura RAM: tramo 3 20 19 16 0,54 0,84 2,59 (GB/s) Lectura RAM: tramo 4 5 4 5 -0,96 0,29 0,88 (GB/s)

Sign.

S´ı No No No No No No S´ı

91

Cuadro H.2: Correlaci´on entre el tiempo de arranque de LibreOffice Writer y distintas variables. Test PC A PC B PC C r StdErr Sign. hipo. Tiempo de arranque de LO 5,631 5,313 5,002 (s) Ancho de banda del disco 58,1 42,6 62,7 -0,21 0,98 3,01 No (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,98 0,20 0,62 S´ı Compilaci´on (1 thread ) (s) 141,983 148,85 107,143 0,77 0,63 1,95 No Compilaci´on (4 threads) (s) 105,713 79,778 57,85 1,00 0,04 0,13 S´ı Lectura RAM: tramo 1 46 43 32 0,95 0,32 0,98 No (GB/s) Lectura RAM: tramo 2 26 24 16 0,94 0,33 1,03 No (GB/s) Lectura RAM: tramo 3 20 19 16 0,96 0,28 0,87 S´ı (GB/s) Lectura RAM: tramo 4 5 4 5 0,01 1,00 3,08 No (GB/s)

92

Cuadro H.3: Correlaci´on entre el tiempo de arranque de LibreOffice Writer abriendo un archivo grande y distintas variables. Test PC A PC B PC C r StdErr Sign. hipo. Tiempo de arranque de 72,019 70,280 69,822 many as (s) Ancho de banda del disco 58,1 42,6 62,7 0,10 0,99 3,06 No (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,99 0,12 0,36 S´ı Compilaci´on (1 thread ) (s) 141,983 148,85 107,143 0,54 0,84 2,59 No Compilaci´on (4 threads) (s) 105,713 79,778 57,85 0,96 0,27 0,84 S´ı Lectura RAM: tramo 1 46 43 32 0,80 0,60 1,85 No (GB/s) Lectura RAM: tramo 2 26 24 16 0,79 0,61 1,88 No (GB/s) Lectura RAM: tramo 3 20 19 16 0,82 0,57 1,75 No (GB/s) Lectura RAM: tramo 4 5 4 5 0,32 0,95 2,92 No (GB/s)

93

Cuadro H.4: Correlaci´on entre el tiempo de el tiempo de compilaci´on del kernel de Linux con un solo thread y distintas variables. Test PC A PC B PC C r StdErr Sign. hipo. Tiempo de compilaci´on (s) 366,200 362,490 239,366 Ancho de banda del disco 58,1 42,6 62,7 -0,66 0,75 2,32 No (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,76 0,65 2,00 No Compilaci´on (1 thread ) (s) 141,983 148,85 107,143 0,98 0,18 0,55 S´ı Compilaci´on (4 threads) (s) 105,713 79,778 57,85 0,85 0,52 1,60 No Lectura RAM: tramo 1 46 43 32 0,98 0,18 0,55 S´ı (GB/s) Lectura RAM: tramo 2 26 24 16 0,99 0,16 0,50 S´ı (GB/s) Lectura RAM: tramo 3 20 19 16 0,98 0,22 0,66 S´ı (GB/s) Lectura RAM: tramo 4 5 4 5 -0,48 0,88 2,70 No (GB/s)

Ap´ endice I Ecuaciones para estimar el rendimiento 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 compilaci´on (4 threads) × 0, 02 +3, 48 Tiempo de apertura de un archivo grande = Latencia del disco × −0, 58 +Tiempo de compilaci´on (4 threads) × −0, 04 +85, 52 Tiempo compilaci´on del kernel (1 thread ) = Tiempo de compilaci´on con 1 thread × 1, 57 +Ancho de banda de la memoria (tramo 2) × 7, 23 + − 44, 03 Tiempo compilaci´on del kernel (4 thread2 ) = Tiempo de compilaci´on 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 compilaci´on (4 threads) × 0, 71 + − 163, 73 Tiempo de apertura de un archivo grande = Latencia del disco × 15, 70 +Tiempo de compilaci´on (4 threads) × 1, 09 + − 308, 61 Tiempo compilaci´on del kernel (1 thread ) = Tiempo de compilaci´on con 1 thread × −4,11 +Ancho de banda de la memoria (tramo 2) × 37, 80 +129, 36 Tiempo compilaci´on del kernel (4 thread2 ) = Tiempo de compilaci´on 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 compilaci´on (4 threads) × 0, 04 + − 6, 56 95

Tiempo de apertura de un archivo grande = Latencia del disco × −1, 46 +Tiempo de compilaci´on (4 threads) × −0, 18 +118, 44 Tiempo compilaci´on del kernel (1 thread ) = Tiempo de compilaci´on con 1 thread × −1, 97 +Ancho de banda de la memoria (tramo 2) × 24, 87 +53, 54 Tiempo compilaci´on del kernel (4 thread2 ) = Tiempo de compilaci´on con 4 threads × 1, 39 +Latencia del disco × −15, 06 +404, 05

96

Ap´ endice J C´ odigo fuente del benchmark (versi´ on 3) El archivo statistics.sh es igual que el de la primera modalidad de benchmark (incluyendo la opci´on de la compilaci´on del kernel con 4 threads), pero sin las opciones de velocidad de red y consumo el´ectrico.

J.1.

run.sh

Este archivo contiene el orden en el que deben medirse los par´ametros y otras instrucciones necesarias (comprobaciones, pausas, reinicios, etc.). Es completamente disinto 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 ’ ’ / ,/./ ‘ MEMORY_BW2 = ‘ grep MEMORY_BW2 $ temp_file | cut sed s / ,/./ ‘ MEMORY_BW4 = ‘ grep MEMORY_BW4 $ temp_file | cut sed s / ,/./ ‘ DISK_LAT = ‘ grep DISK_LAT $ temp_file | cut -d ’ / ,/./ ‘ COMPILE1 = ‘ grep COMPILE1 $ temp_file | cut -d ’ / ,/./ ‘ COMPILE4 = ‘ grep COMPILE4 $ temp_file | cut -d ’ / ,/./ ‘ estimation ./ statistics . sh

98

- f2 | sed s -d ’ ’ - f2 | -d ’ ’ - f2 | ’ - f2 | sed s ’ - f2 | sed s ’ - f2 | sed s

J.2.

benchmark.sh

Este archivo contiene el c´odigo capaz de medir los par´ametros por separado. Es completamente distinto al de las modalidades de benchmark anteriores. Mide los par´ametros que se usar´an 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 ( 1 st segment ) # MEMORY_BW2 : memory bandwidth ( 2 nd segment ) # MEMORY_BW3 : memory bandwidth ( 3 rd segment ) # MEMORY_BW4 : memory bandwidth ( 4 th 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 sudo sudo sudo }

drop_caches sh -c " echo sh -c " echo sh -c " echo

{ 1 > / proc / sys / vm / drop_caches " 2 > / proc / sys / vm / drop_caches " 3 > / proc / sys / vm / drop_caches "

# memory_bw if [ [ $ tests = = * MEMORY_BW * ] ] ; then sudo / home / user / bandwidth - 0.32 p / 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 funci´on radica la estad´ıstica que estima el rendimiento de las distribuciones. 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

Ap´ endice K Funcionalidades de Raspbian El protocolo de mensajer´ıa instant´anea “MySpace IM” se ha descartado, ya que no recibi´o ning´ un voto y resulta irrelevante. Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” se han 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 m´as del 50 % de votos. La fila “Total ( %)” indica el porcentaje de funcionalidades con m´as del 50 % de votos que cumple. La fila “Total normalizado” es una ponderaci´on teniendo en cuenta todas las funcionalidades y su valor normalizado (v´ease el ap´endice A).

105

106

Potencial

Compatible con documentos .docx Compatible con documentos .swx Posibilidad de a˜ nadir comentarios a los documentos Crear gr´aficos y dibujos Integraci´on con una suite ofim´atica completa Versi´on para Mac OS X Corrector ortogr´afico Imprimir selecci´on Alto n´ umero de celdas Immobilizar paneles Importar / exportar tablas LaTeX Interfaz en catal´an Soporte para escritura de derecha a izquierda

Mod

alculo Localiza. Hoja de c´

Procesador de textos

Funcionalidad

Base

Leyenda: 1 = S´ı; 0 = No; 0,5 = Parcial

0

1

1

0

1

1

0

1

1

0

1

1

0

1

1

0

1

1

0 0

1 1

1 1

0

1

1

0

1

1

0

1

1

1

1

1

0

1

1

107

Mod

Potencial

Filtro anti-phishing Lector de feeds RSS Vista previa de documentos de texto Bloqueo de pop-ups Bloqueo de publicidad Control por voz Gestos de rat´on Conversi´on texto-a-voz Incorpora su propio plugin Flash Lector de feeds RSS Gestor de contrase˜ nas Yahoo! Mail Windows Live messenger XMPP (Google talk, Facebook chat) IRC Skype Emoticonos gr´aficos Emoticonos gr´aficos definidos por el usuario Chat de voz Chat de v´ıdeo Escritura a mano Soporte multi-cuenta Corrector ortogr´afico

Base

Cliente MI

Protocolos MI

Navegador

Correo

Funcionalidad

0 0

1 1

1 1

0

0

0

0 1 0 1

1 1 1 1

1 1 1 1

0

0

0

0

1

1

0 0 0

1 1 1

1 1 1

0

1

1

0

1

1

0 0 0

1 0 1

1 0 1

0

1

1

0 0 0 0 0

1 1 0 1 1

1 1 0 1 1

108

Mod

Potencial

Soporte para subt´ıtulos Control de imagen Control de sonido (tono) Resincronizaci´on de audio Resincronizaci´on de subt´ıtulos Soporte para VCD Soporte para SVCD Soporte para DVD Miniaturas (Thumbnails) Pesta˜ nas Doble panel Previsualizaciones Navegar por archivos comprimidos Total mayoritarios (abs) Total mayoritarios ( %) Total normalizado ( %)

Base

Total

Gestor de ar.

Reproductor de v´ıdeo

Funcionalidad

0

1

1

0

1

1

0

1

1

0

1

1

0

1

1

0 0 0

0 0 0

1 1 1

1

1

1

0 1 0

1 1 1

1 1 1

0

0

0

3

24

25

10,00 80,00 83,33 10,57 84,21 89,62

Bibliograf´ıa [1] Jack Wallen. Linux distribution choice flow chart. http://cdn.ghacks.net/ wp-content/uploads/2010/01/choosing_linux.jpg [2] T´erminos 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 Operating Systems”, 2007. [4] John L. Gustafson and Quinn O. Snell. HINT: A New Way To Measure Computer Performance. Proceedings of the 28th Annual Hawaii International Conference 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 Gr¨onholm. 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, versi´on 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 regresi´on Lineal M´ ultiple 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 multimedia capabilities. http://www.wandboard.org/

110