E. Código fuente del benchmark

Universitat Politecnica

de Catalunya

Facultat d’Informatica de Barcelona

Benchmark para PCs con

pocos recursos

Autor:Alexandre Ramırez Gomez

Director:Carlos Alvarez Martınez

Co-director:Xavier Martorell Bofill

13 de junio de 2013

Indice general

1. Introduccion 41.1. Planteamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.2. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2. Diagramas de flujo . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3. Benchmarks globales . . . . . . . . . . . . . . . . . . . . . . . 61.2.4. Benchmarks especıficos . . . . . . . . . . . . . . . . . . . . . . 61.2.5. Colecciones de tests . . . . . . . . . . . . . . . . . . . . . . . . 61.2.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Analisis de requisitos y planificacion 82.1. Marco legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. Modalidades del benchmark . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1. Modalidad clasica . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Modalidad basada en estimacion . . . . . . . . . . . . . . . . 92.2.3. Modalidad basada en la estimacion de una distribucion live . . 92.2.4. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Planificacion temporal . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.1. Coste de software y hardware . . . . . . . . . . . . . . . . . . 142.5.2. Coste espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5.3. Coste de recursos humanos . . . . . . . . . . . . . . . . . . . . 152.5.4. Coste total . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1

3. Especificacion y diseno 183.1. Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2. Version preliminar del benchmark . . . . . . . . . . . . . . . . . . . . 19

3.2.1. Mediciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2. Puntos a mejorar . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3. Version final del benchmark . . . . . . . . . . . . . . . . . . . . . . . 233.4. Modalidad basada en estimacion . . . . . . . . . . . . . . . . . . . . . 243.5. Modalidad basada en la estimacion de una distribucion live . . . . . . 25

3.5.1. ¿Medir o estimar? . . . . . . . . . . . . . . . . . . . . . . . . . 263.5.2. La distribucion live . . . . . . . . . . . . . . . . . . . . . . . . 273.5.3. Estimando en base al hardware . . . . . . . . . . . . . . . . . 28

3.6. Experimentacion con un Pocket PC . . . . . . . . . . . . . . . . . . . 30

4. Implementacion, pruebas y resultados 314.1. Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2. Analisis de las distribuciones . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1. Seleccion de distribuciones candidatas . . . . . . . . . . . . . . 324.2.2. Analisis de funcionalidades . . . . . . . . . . . . . . . . . . . . 35

4.3. Analisis de los PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.1. PCs de TxT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.2. Pruebas de rendimiento preliminares . . . . . . . . . . . . . . 38

4.4. Criba de distribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5. Pruebas de rendimiento en PCs de TxT . . . . . . . . . . . . . . . . . 40

4.5.1. Resultados y reporte de incidencias . . . . . . . . . . . . . . . 404.5.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5.3. Interpretacion de los resultados . . . . . . . . . . . . . . . . . 42

4.6. Realizando estimaciones . . . . . . . . . . . . . . . . . . . . . . . . . 434.7. Comparativa de modalidades del benchmark . . . . . . . . . . . . . . 444.8. Experimentacion con un Pocket PC . . . . . . . . . . . . . . . . . . . 47

5. Conclusiones 495.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.1. Comportamientos anomalos . . . . . . . . . . . . . . . . . . . 505.2.2. Anadir atributos a medir al benchmark . . . . . . . . . . . . . 505.2.3. Actualizar y expandir la lista de distribuciones . . . . . . . . . 515.2.4. Mejorar la estadıstica . . . . . . . . . . . . . . . . . . . . . . . 515.2.5. Probar distintos Pocket PC . . . . . . . . . . . . . . . . . . . 51

2

A. Resultados de la encuesta 53

B. Programas por distribucion 56

C. Funcionalidades por programa 59

D. Funcionalidades por distribucion 63

E. Codigo fuente del benchmark (version 1) 67E.1. run.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67E.2. benchmark.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72E.3. statistics.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

F. Pruebas de rendimiento en PCs de TxT 81F.1. PC A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81F.2. PC B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82F.3. PC C (Core 2 Duo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

G. Codigo fuente del benchmark (version 2) 84G.1. memory disk discard . . . . . . . . . . . . . . . . . . . . . . . . . . 85G.2. estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

H. Estimaciones en base a la distribucion live 88

I. Ecuaciones para estimar el rendimiento 94I.1. Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94I.2. Slackware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95I.3. Linux Mint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

J. Codigo fuente del benchmark (version 3) 97J.1. run.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97J.2. benchmark.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99J.3. estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

K. Funcionalidades de Raspbian 105

Bibliografıa 109

3

Capıtulo 1

Introduccion

1.1. Planteamiento

1.1.1. Objetivo

El objetivo de este proyecto es disenar e implementar un sistema capaz de de-terminar la distribucion de Linux adecuada para un PC (mas concretamente, un PCcon pocos recursos). Se tendran en cuenta tanto aspectos de funcionalidad como derendimiento. Para esto ultimo sera necesario crear un benchmark que mida el rendi-miento de distintas distribuciones de Linux para poder decidir con que distribucionse aprovecha mejor el escaso potencial de la maquina. Se estudiaran distintas moda-lidades de benchmark con distintos equilibrios entre tiempo de ejecucion y precisionde las mediciones. Luego se analizaran y se compararan entre ellas. Se usaran losPCs de la asociacion Tecnologies per Tothom (de ahora en adelante, TxT) a modode aplicacion real.

1.1.2. Motivacion

La idea surge tras haber participado en una actividad organizada por TxT en laque se instalaba el sistema operativo a ordenadores donados, normalmente con pocosrecursos. El sistema operativo en cuestion era la ultima version de Ubuntu. Se havisto que Ubuntu no es la mejor distribucion para este tipo de sistemas. En cambio,con distribuciones mas ligeras especialmente disenadas para este cometido se puedenobtener buenos resultados.

Creo que los PCs de TxT (y los PCs con pocos recursos en general) podrıantambien beneficiarse de las ventajas que ofrecen estas distribuciones, pero es necesario

4

escoger la mas adecuada con tal de aprovechar al maximo el potencial de la maquina.Para ello es necesario poder calcular de manera cuantitativa el rendimiento de cadadistribucion; es decir, se necesita un benchmark.

Ademas, este benchmark tambien podrıa usarse en sistemas del estilo PocketPC (p. ej., Raspberry Pi), ya que a efectos practicos son PCs con pocos recursos.Actualmente el uso de este tipo de maquinas esta aumentando notablemente, yaque ofrecen una solucion barata y pequena para tareas que no requieran una grancapacidad de computo o unas prestaciones fuera de lo comun. Con este benchmark sepodran comparar este tipo de sistemas con PCs antiguos y ver si realmente suponenuna alternativa viable.

1.2. Estado del arte

1.2.1. Contexto

A la hora de aprovechar un PC con pocos recursos es importante elegir bienque software se instalara con tal de sacar el maximo provecho a nuestro limitadohardware. Actualmente el sistema operativo para los ordenadores de TxT es elegidode manera informal, sin tener en cuenta muchas alternativas y sin una base obje-tiva. Es mi proposito demostrar que esta eleccion afecta de manera considerable alrendimiento del sistema y que se podrıa mejorar haciendola con mas mesura.

La solucion al problema tendra que tener en cuenta tanto aspectos de rendimientocomo de funcionalidad para poder decidir de manera objetiva cual es la mas adecuadapara una determinada maquina.

1.2.2. Diagramas de flujo

Actualmente no existe ningun software que ayude a escoger una distribucion deLinux, mas alla de los tıpicos diagramas de flujo [1]. Si bien estos diagramas tienen laventaja de ser sencillos y no requerir ningun software ni hardware especıfico (porqueno son programas, son diagramas), tienen la desventaja de que su granularidad esmuy gruesa y solo distinguen entre “PC moderno” y “PC antiguo” como mucho,sin tener en cuenta el rendimiento de la maquina. Ademas tampoco tiene en cuentafuncionalidades especıficas, sino que hacen distinciones como “PC de escritorio” o“Servidor”.

5

1.2.3. Benchmarks globales

En la actualidad existen pocos benchmarks para Linux que midan el rendimientode todo el sistema, y los que hay se encuentran desfasados.

Unixbench es probablemente el mas conocido. Aunque fue creado en 1983, haido siendo actualizado y hoy en dıa se sigue usando [3]. El principal defecto de estebenchmark es que mide resultados simulando casos de uso extremos que no coincidencon el perfil de uso que normalmente se le da a un PC.

Otro conocido benchmark es HINT (Hierarchical INTegration) [4]. Se caracte-riza por su buen balance en la ponderacion de los distintos aspectos del sistema.Sin embargo, este benchmark devuelve como resultado un solo valor, que intentaser una medicion de la “calidad” del sistema. Actualmente se desaconseja este com-portamiento y se prefiere que se midan los distintos componentes del sistema porseparado.

1.2.4. Benchmarks especıficos

Existen, por otro lado, benchmarks para medir el rendimiento de un solo aspectoespecıfico del sistema o incluso una tarea concreta. Los benchmarks globales suelenser suites de benchmarks especıficos debidamente ponderados.

Los mas comunes son los benchmarks que miden la potencia de computacion(CPU, FPU y memoria). Estos consisten en hacer calculos que sean CPU-intensivos(como calcular dıgitos de Pi, por ejemplo). Quizas el mas comun de este tipo seanbench [5] (un port a Linux de BYTEmark 2, anteriormente conocido como BYTE’sNative Mode Benchmarks [6]).

No obstante, tambien existen benchmarks dedicados a medir el rendimiento deotras partes del sistema, como IOzone [8] (dedicado a medir el rendimiento de lossistema de ficheros y dispositivos de almacenamiento) o netperf (para medir el ren-dimiento de la conexion de red).

Incluso hay benchmarks dedicados a tareas tan especıficas como medir el rendi-miento de distintos temas y configuraciones de GTK+ (gtkperf [7]).

1.2.5. Colecciones de tests

Finalmente, tambien existen colecciones de tests no relacionados entre sı paraque el usuario elija los tests que desea realizar y pueda crear su propio benchmarkglobal a partir de varios tests especıficos. En este achapterado destaca Phoronix TestSuite [10]. Es una coleccion de tests bastance reciente (creada en 2008) y amplia(contiene mas de 60 tests). Ademas ofrece la posibilidad de compartir resultados

6

a traves del servicio OpenBenchmarking http://www.openbenchmarking.org. Esuna de las plataformas de benchmarking mas usadas, tanto a nivel domestico comoprofesional. Sus mayores crıticas son que el compilador y la configuracion que seusen para compilar los tests pueden afectar a los resultados de los mismos y que lascomparaciones entre sistemas dispares no son del todo fiables.

1.2.6. Conclusiones

Si bien alguno de estos benchmarks podrıa servir para medir el rendimiento delos PCs que se trataran en este TFG, recordemos que el proposito final es elegirun sistema operativo. Ademas del benchmarking convencional, en este trabajo seestudiara la posibilidad de crear un benchmark en una distribucion live que estime elrendimiento de las demas distribuciones sin necesidad de instalarlas realmente todas.Esta es una funcionalidad muy dependiente de la situacion a tratar, por lo cual esalgo que no pueden ofrecer los benchmarks anteriores. Es por esto que es necesariocrear un nuevo benchmark.

7

http://www.openbenchmarking.org

Capıtulo 2

Analisis de requisitos yplanificacion

2.1. Marco legal

Pese a que los sistemas operativos de la familia Windows son los mas utilizadosen el ambito de la informatica de escritorio, los PCs que trataremos no los podemosdistribuir con estos, ya que Windows se distribuye bajo una licencia de pago [2]que TxT no se puede permitir y que, ademas, prohıbe su redistribucion. Por estosmotivos la distribucion de PCs con sistema operativo Windows queda descartada.

Necesitamos, pues, un sistema operativo gratuito y que nos ofrezca libertad deredistribucion. Con estas caracterısticas, GNU/Linux se presenta como la alternativamas popular. Linux es ampliamente usado en sistemas de escritorio, tanto en elambito personal como en el profesional.

Aunque las condiciones y licencias pueden variar entre distribuciones, la mayorıade ellas se ofrecen de manera gratuita y libre. El grado de libertad es variable,dependiendo de la distribucion, pero la mayorıa cumple con creces los requisitos queTxT impone para poder ser instalado y distribuido con sus PCs.

2.2. Modalidades del benchmark

2.2.1. Modalidad clasica

Un benchmark por si mismo consiste en una coleccion de pruebas que determinanel rendimiento de una maquina (o de algun aspecto en concreto). Mi intencion espoder decir para cada PC que distribucion es mejor, ası que el procedimiento serıa:

8

instalar una distribucion, medir su rendimiento, repetir con el resto de distribucionesy comparar los resultados. Esta serıa la modalidad clasica del benchmark. Comoesto puede llevar mucho tiempo (ademas de resultar tedioso) se contemplaran 2modalidades alternativas.

2.2.2. Modalidad basada en estimacion

La primera consistira en instalar una distribucion y medirla tal y como se hace enla modalidad clasica, pero en lugar de repetir el procedimiento con todas las demasdistribuciones, simplemente se estimara su rendimiento en base a los resultados delas mediciones realizadas en la distribucion instalada. De esta forma nos ahorramostener que instalar y medir todas las distribuciones. No obstante, el precio a pagarpor este ahorro de tiempo es la posible inexactitud de las estimaciones.

2.2.3. Modalidad basada en la estimacion de una distribu-cion live

Para acabar de optimizar el tiempo, se creara una tercera modalidad similara la anterior, pero que basara las estimaciones en mediciones realizadas con unadistribucion live muy liviana creada expresamente para este cometido. Con estamodalidad llevamos al extremo las ventajas y los inconvenientes de la modalidadanterior: el proceso sera mucho mas rapido, ya que no habra que instalar ningunadistribucion, pero los resultados pueden no ser precisos debido a la inexactitud delas estimaciones y a la variabilidad del medio donde se encuentre la distribucion live(CD, DVD, USB...).

2.2.4. Comparativa

Una vez acabadas las tres modalidades, se compararan para ver cual es la mejor.Se tratara de alcanzar un equilibrio entre el tiempo necesario para realizar las pruebasy la precision de los resultados.

2.3. Metodologıa

En primer lugar, necesitamos conocer las necesidades funcionales de los ususariospara poder seleccionar unas distribuciones adecuadas. Para ello se realizara una en-cuesta en la que se consultara a los usuarios sobre que funcionalidades necesitan en

9

un PC. Con los resultados de esta encuesta podremos saber que grado de funcionali-dad alcanzan distintas distribuciones y, por tanto, si son adecuadas para instalarlasen nuestros PCs.

Una vez tengamos la funcionalidad de cada distribucion nos interesa conocer surendimiento. Para esto habra que crear un benchmark. Como ya se ha explicado enel apartado anterior, se implementaran 3 versiones con distintos niveles de equilibrioentre tiempo de ejecucion y precision.

Con los datos de rendimiento obtenidos con el benchmark y los de funcionalidadobtenidos con la encuesta ya estaremos en disposicion de decidir que distribucion esla mas adecuada en cada maquina.

Finalmente, se usara este mismo sistema para medir el rendimiento y las funcio-nalidades de un Pocket PC para comprobar hasta que punto podrıa sustituir un PCde sobremesa.

2.4. Planificacion temporal

Ha habido diferencias en la planificacion con respecto a la inicial. En la previsioninicial, se seleccionaba un conjunto de distribuciones iniciales, se usaban los resul-tados de la encuesta para hacer una criba y luego se creaba el benchmark en sutotalidad. En lugar de eso, tras hacer la encuesta se empezo a crear el benchmarky se hizo una primera version. Con esa primera version del benchmark se evaluo elrendimiento de todas las distribuciones iniciales y, con los resultados de la encuestay los del benchmark se realizo la criba. Esto, por una parte, ofrece mas feedback a lahora de crear el benchmark, ya que se puede probar un prototipo, pero por otra par-te, al tener que hacer mediciones sobre todas las distribuciones iniciales, el trabajose ha alargado una semana. Ademas, las tareas de “Finalizacion del benchmark” y“Definir metodos de estimacion” han tomado mas tiempo del previsto, debido a sucomplejidad, con lo que, a pesar de planificar una holgura al final del trabajo, huboque reducir el tiempo de las tareas finales. La planificacion queda entonces tal queası:

1. Realizar una encuesta: Esta fue la primera tarea del trabajo. Consistio enconfeccionar una encuesta para saber que funcionalidades necesitan los usuariosen varios tipos de programas (p. ej., procesador de textos con compatibilidadcon Microsoft Office 2010) y distribuirla. Su duracion fue de una semana, co-menzando el dıa 18 de Febrero. Los unicos recursos que se usaron fueron miPC personal y la suite de Google Drive para crear la encuesta y recopilar lasrespuestas.

10

2. Seleccionar distribuciones iniciales: Mientras la encuesta esta activa seaprovechara para seleccionar las distribuciones iniciales. Esta tarea duro unasemana: empezo tras distribuir la encuesta y acabo al cerrarse la misma. Paraesta tarea, ademas, se usaron datos de la pagina web DistroWatch (http://www.distrowatch.com).

3. Analizar resultados de la encuesta: Una semana despues de distribuir laencuesta esta se cerro y ya no admite mas respuestas. Entonces se analizaronlos resultados y se usaron para decidir que distribuciones pasarıan la criba masadelante. La duracion de esta tarea fue de 3 dıas y, al igual que la tarea anterior,solo requise de mi PC y Google Drive para llevarla a cabo.

4. Preparar medios de instalacion: Una vez elegidas las distribuciones candi-datas, se crearan y grabaran las imagenes de las distribuciones en CDs y DVDs,ya que los PCs probablemente no dispongan de arranque desde USB. Esta ta-rea tomo apenas 1 dıa. Use mi PC (con grabador de CD y DVD), conexiona Internet para descargar las imagenes y unos CDs y DVDs vırgenes, tantoscomo distribuciones iniciales.

5. Crear primera version del benchmark : Tras ultimar los preparativos pro-cedı a disenar e implementar una primera version del benchmark. Esto im-plico decidir que parametros medir y como hacerlo. Esto llevo 2 semanas.Use un PC propio similar a los menos potentes que hay en TxT para hacerpruebas, los CDs y DVDs de la tarea anterior y, como el benchmark medira laeficiencia de la red, use la conexion a Internet de mi casa.

6. Evaluar el rendimiento de las distribuciones iniciales: Con la primeraversion del benchmark acabada instale cada una de las distribuciones en elmismo PC de la tarea anterior y medı su rendimiento. Debido al alto numerode distribuciones esta tarea llevo toda una semana. Los recursos usados fueronlos mismos que en la tarea anterior.

7. Analizar resultados del benchmark : Una vez obtenidos los resultados derendimiento, pude al fin realizar una criba sobre las distribuciones iniciales.Ademas, con la experiencia obtenida al crear y probar la primera version delbenchmark pude ver que aspectos hay que corregir de cara a la version final.

11

http://www.distrowatch.com

http://www.distrowatch.com

8. Finalizacion del benchmark : Tomando el esbozo de benchmark como basey los resultados de las pruebas como guıa finalizare el benchmakr corrigiendolos errores detectados en las tareas anteriores. Se usaran los mismos recursospara realizar pruebas, aunque esta vez se haran solo sobre las distribucionescandidatas (las que hayan pasado la criba). Esta tarea es una de las claves deltrabajo, y llevo mas tiempo del esperado.

9. Segunda version del benchmark : Crear la segunda modalidad del bench-mark resulto relativamente sencillo, comparado con la modalidad clasica (estatarea tiene una duracion de 10 dıas, frente a los mas de 40 de la creacion delbenchmark clasico). Se implemento de tal manera que se pudo aprovechar elcodigo generado en la tarea anterior.

10. Definir metodos de estimacion: A parte de la creacion del benchmark (ta-reas 5 a 8), el otro gran desafıo del trabajo sera definir como se calcularanlas estimaciones a partir de los valores medidos en la modalidad de benchmarkpor estimacion basado en una distribucion live. Esta tarea llevo poco mas de2 semanas. Dado que es una tarea de diseno de benchmark, los recursos queusare seran los mismos que en la tarea anterior: mi PC personal y mi PC deprueba.

11. Crear distribucion live del benchmark por estimacion: Para poder usarla modalidad de benchmark basada en estimacion tomando como referencia unadistribucion live liviana, primero hay que crear dicha distribucion, con todo elsoftware necesario, y grabarla en un CD. Esta tarea llevo mucho menos delo previsto. En tan solo 1 dıa se pudo completar. Esto fue debido a haberencontrado un programa muy sencillo de usar que se ajustaba perfectamente alas necesidades de la tarea. Los requisitos fueron los mismos que en la tarea 4:mi PC, con grabador de CDs, y un CD virgen.

12. Comparar modalidades del benchmark : Tras implementar las 3 modali-dades del benchmark, se analizaron y se decidio cual se usara en las mediciones.Inicialmente esta tarea iba a ser mas larga, pero debido a las modificacionesen la planificacion tubo que hacerse en solo 2 dıas. Para esta tarea fueronnecesarios los PCs de TxT.

Durante todo el proceso del trabajo se realizara la memoria en paralelo, docu-mentando cada tarea al tiempo que se hace.

Durante la creacion de la primera modalidad del benchmark (tareas 5 a 8), ademasde realizar las mediciones sobre las distribuciones candidatas tambien se realizaronsobre Raspbian (en la Raspberry Pi).

12

2.5. Presupuesto

2.5.1. Coste de software y hardware

En sistemas antiguos como los que se trataran en este trabajo es habitual que elarranque desde USB no este disponible, ası que para no tener que extraer los discosduros y volverlos a instalar, se usara el arranque desde la unidad de CD/DVD. Porello se requeriran CDs y DVDs en los que grabar las imagenes de las distribuciones aevaluar y la distribucion live para el benchmark basado en estimacion. Finalmente sehan seleccionado mas distribuciones de las previstas, ası que el numero de CDs/DVDsnecesarios ha aumentado con respecto a lo inicialmente planeado. Afortunadamenteestos son baratos y el aumento en el precio no es demasiado importante.

Los PCs sobre los que se efectuaran las pruebas seran prestados por TxT, ası queno suponen coste alguno. Para poder trabajar desde casa tambien se haran pruebasen PCs antiguos de los que dispongo, lo cual tampoco supone ningun coste.

Ademas, se necesitara un Raspberry Pi sobre el que efectuar mas pruebas. Final-mente se ha comprado un pack con placa, tarjeta SD y cable de alimentacion.

Todo el software que se use sera libre o, por lo menos, gratuito.Finalmente, tambien necesitare un PC con grabador de CDs y una conexion a

Internet. Ya dispongo de estos recursos, ası que no suponen ningun coste, mas alla delde amortizacion. En el caso de que no los pudiese usar, la facultad ofrece PCs enprestamo y acceso a Internet, tambien de manera gratuita.

Adicionalmente, se ha decidido comprar un medidor de consumo electrico paramedir la potencia que consumen los PCs con las distintas distribuciones.

Teniendo en cuenta la planificacion, los gastos quedarıan tal que ası:

Razon Coste Tiempo deamortizacion

Tiempode uso

Costeimputable

Software 0,00 e 3 anos 4 meses 0,00 ePC personal 1000,00 e 3 anos 4 meses 111,11 ePCs de pruebas 0,00 e 3 anos 4 meses 0,00 eRaspberry Pi 40,00 e 3 anos 4 meses 4,44 e7 CDs 2,00 e 2,00 e3 DVDs 2,00 e 2,00 eMedidor de con-sumo electrico

13,00 e 5 anos 4 meses 0,86 e

Total 120,41 e

14

2.5.2. Coste espacial

Ademas del coste del equipo, tambien hay que contar el coste del mantenimientodel almacen donde se guardan los PCs y donde se realiza el proyecto.

Cuando se realizo la proyeccion inicial todavıa no tenıa acceso al almacen encuestion y, por lo tanto, los costes que estimaron “a ciegas”, sin conocer realmentecomo es el local. Ahora que tengo acceso, puedo aproximar los costes mas fielmentea la realidad.

Razon Coste mensual Tiempode uso

Coste total

Agua 20,00 e/mes 4 meses 80,00 eLuz 50,00 e/mes 4 meses 200,00 eGas 50,00 e/mes 4 meses 200,00 e

Telefono e Internet 50,00 e/mes 4 meses 200,00 eTotal 680,00 e

Sin embargo, hay que tener en cuenta que el almacen no es de uso exclusivo parami proyecto, sino que se realiza trabajo diario en el. Por lo tanto los costes se deberanamortizar entre todo el trabajo que se haga en el. Supongamos que se reparta a partesiguales entre mi proyecto y el resto de trabajo que se realiza allı. Los costes quedanentonces reducidos a la mitad.

Razon Coste mensual Tiempode uso

Coste total

Agua 10,00 e/mes 4 meses 40,00 eLuz 25,00 e/mes 4 meses 100,00 eGas 25,00 e/mes 4 meses 100,00 e

Telefono e Internet 25,00 e/mes 4 meses 100,00 eTotal 340,00 e

2.5.3. Coste de recursos humanos

Por ultimo cabe anadir los costes del personal. Se considera que para la realizacionde este proyecto se requeriran 3 roles. Las siguientes tablas muestran las horas quese requieren de cada rol en cada tarea y su precio.

Estos datos han sufrido cambios respecto a los entregados en el hito intermediodebido a que la duracion de algunas tareas se ha considerado demasiado “hinchada”y a que algunas de las tareas finales se han visto reducidas.

15

Administrador de sistemas experto en atencion al usuario Persona conoce-dora de las necesidades de los usuarios, sus preferencias y sus habitos. Su prin-cipal cometido sera asegurar que las distribuciones que se selecciones sean delagrado de los usuarios y no nieguen funcionalidades basicas a costa del rendi-miento.

Administrador de sistemas experto en performance Responsable de la crea-cion del benchmark. Tiene profundos conocimientos de los parametros que masinfluyen en el rendimiento de un sistema. Es capaz de medirlos de maneraadecuada, aislandolos de otros parametros que pudieran alterar la medicion, einterpretar los resultados dentro de un contexto.

Administrador de sistemas experto en Linux Comprende los fundamentos delos sistemas operativos basados en Linux. Conoce las diferencias entre distintasdistribuciones y el impacto de estas en su funcionamiento y usabilidad. Sutarea consistira en contribuir a la seleccion de distribuciones inicial y crear ladistribucion live.

Tarea A. usuario A. performance A. LinuxRealizar encuesta e inter-pretar resultados

50 h 0 h 0 h

Seleccionar y preparardistribuciones iniciales

20 h 20 h 20 h

Creacion el benchmark 0 h 160 h 0 hPruebas y mediciones 0 h 120 h 0 hDefinir metodos de esti-macion

0 h 100 h 0 h

Comparar modalidadesde benchmark

0 h 10 h 0 h

Crear distribucion live 0 h 0 h 10 hTiempo total 70 h 410 h 30 h

Rol Tiempo Coste por hora Coste totalA. usuario 70 h 20,00 e/h 1400,00 eA. performance 410 h 24,00 e/h 9840,00 eA. Linux 30 h 22,00 e/h 660,00 e

Coste total de personal 11900,00 e

16

2.5.4. Coste total

Una vez detallados todos los costes, podemos ver el coste total que supone elproyecto.

Concepto CosteSoftware y hardware 120,41 eEspacial 340,00 eRecursos humanos 11900,00 eTotal 12360,41 e

17

Capıtulo 3

Especificacion y diseno

3.1. Encuesta

Tras finalizar GEP el primer punto es crear una encuesta que despues se pasara alos usuarios para conocer sus preferencias. En un principio la encuesta iba a ser mastecnica, y el usuario tenıa que elegir directamente el programa que prefiere para cadatipo de tarea. Por ejemplo:

Navegador

Chrome / Chromium

Epiphany

Firefox / Iceweasel

Konqueror

Midori

Opera

No obstante esto se descarto, ya que muy posiblemente los usuarios responderıanque aplicaciones usan y no cuales son las mas adecuadas. Ademas, opciones po-co conocidas quedarıan marginadas, independientemente de las funcionalidades queofreciesen.

Finalmente, la encuesta fue tal que el usuario debıa seleccionar las funcionalida-des que necesita de cada programa, en lugar de elegir los programas directamente.Por ejemplo, para el caso del navegador de Internet se ofrecıan las siguientes funcio-nalidades:

18

Navegador

Bloqueo de pop-ups sin necesidad de complementos

Bloqueo de publicidad sin necesidad de complementos

Control por voz

Gestos de raton

Conversion texto-a-voz (text-to-speech)

Incorpora su propio plugin de Flash

Lector de feeds RSS incorporado (sin necesidad de complementos ni herramien-tas externas)

Gestor de contrasenas (recordar contrasenas, contrasena maestra)

Y el usuario debıa marcar las funcionaliades que vea necesarias mediante un check-box. Al final de la encuesta se ofrecıa un espacio para anadir comentarios. Solo serecibieron 3 comentarios: uno especificaba que preferıa software libre antes que priva-tivo, otro preferıa interfaces sencillas pero customizables y el ultimo era un mensajede animo.

La encuesta completa puede encontrarse en el apendice A (junto con los resulta-dos, que se trataran mas adelante).

3.2. Version preliminar del benchmark

Como las modalidades del benchmark se basan cada una en la anterior, es im-portante que el inicio sea solido. Para asegurarnos de que la primera modalidad debenchmark es consistente, se realizo una version preliminar. Se realizaran pruebascon esta version para detectar posibles errores y poder corregirlos en la version final.

3.2.1. Mediciones

La version preliminar del benchmark consistio en las siguientes mediciones:

Disco El espacio que ocupa una instalacion por defecto de la distribucion en el disco,sin paquetes adicionales. Aunque la mayorıa de discos cumple con creces losrequisitos de todas las distribuciones que se evaluaran, en otros casos en los

19

que se trate con discos de poca capacidad este parametro puede resultar util.Un ejemplo es el caso de la Raspberry Pi, cuyo unico medio de almacenamientoes una tarjeta SD, que puede no ser muy grande.

En todos los casos se usara el formato ext4.

Memoria Cantidad de memoria RAM que consume la distribucion estando en re-poso (entiendase “reposo” como el PC encendido, pero sin realizar trabajo;no como un estado idle o de bajo consumo). Este parametro resulta particu-larmente decisivo en el rendimiento de una distribucion, ya que determina lacantidad de datos que ha de manejar el sistema solo para funcionar.

Incluye la memoria ocupada por buffers y cache. Si bien el sistema puede liberareste espacio para dedicarlo a aplicaciones del usuario, lo “natural” es que elsistema lo tome.

Tiempo de arranque El tiempo que tarda el sistema en arrancar, hasta que esusable. Es uno de los parametros que mas valora el usuario final. Puede verseinfluenciado por otros parametros como el disco y la memoria.

Este parametro se midio leyendo el archivo /etc/uptime.

Para que la medicion se hiciese tan pronto como el sistema acabe de iniciar,se uso la herramienta para configurar la ejecucion de aplicaciones al inicio, quevarıa segun la distribucion.

Tiempo de arranque de un programa lento El tiempo que tarda un programapesado desde el momento en que se manda ejecutar hasta que es usable porel usuario. Los usuarios sin conocimientos profundos de informatica tienden ausar este parametro como medida de rendimiento. Como los usuarios finales po-siblemente no sean informaticos, este es un parametro que resulta convenientevigilar.

Se eligio LibreOffice Writer (version 3.6.6) como ejemplo de “programa lento”,debido a que muy probablemente sea uno de los programas que mas usen losusuarios finales, y se ha medido el tiempo de abrir el programa, esperar hastaque sea usable y cerrarlo (de manera manual). De esta manera se pudo usar laherramienta time para medir el tiempo.

En las distribuciones que no incluıan LibreOffice se instalo desde los reposito-rios. En las que sı lo incluıan se actualizo tambien a traves de los repositoriosoficiales. En todos los casos se instalaron tambien el paquete de ayuda y el deidioma (espanol). En el caso de Puppy Linux se uso el script getLibreOffice,

20

que crea el paquete correspondiente a partir de los paquetes .deb oficiales. Enel caso de Slackware, se crearon los paquetes .tgz a partir de los .deb conla herramienta deb2tgz. En estos dos ultimos casos, hubo que crear soft-linkspara lowriter, ya que no se crean al instalar los paquetes.

Tiempo de apertura de un archivo grande con un programa lento Versionmas sofisticada del parametro anterior. Algunos programas pueden usar tecni-cas para parecer usable cuando en realidad solo lo son parcialmente, de maneraque cargan rapido, pero al interactuar con ellos se ralentizan. Midiendo esteparametro se fuerza al programa a trabajar desde el principio, con lo que dichastecnicas no funcionan.

La metodologıa para medir este parametro es similar a la del parametro ante-rior: se ha elegido LibreOffice, y se incluye el tiempo de cerrar el programa parapoder hacerlo con la herramienta time. Como “archivo grande” se ha genera-do un archivo de texto plano cuyo contenido son 1000000 (un millon) de ‘a’seguidas por un caracter de salto de lınea (‘\n’). En esta ocasion, en lugar desimplemente esperar a que el programa sea usable, se espero a que el recuentode paginas (que LibreOffice Writer muestra en la esquina inferior izquierda)llegase al valor correcto. De esta manera se asegura que el archivo se ha leıdocompletamente.

Velocidad de descarga Para comprobar la eficiencia de la gestion de la red sedescargara un archivo de gran tamano. este es precisamente el principal usoque se le da a la red, de manera que resulta un buen indicador del rendimientode la red.

Se uso un archivo de 500 MB almacenado en un servidor en Internet (comple-tamente ajeno a TxT, a la UPC y a este proyecto).

Tiempo de compilacion de un kernel de Linux en serie La compilacion de unkernel de Linux es una de las pruebas de benchmarking mas usadas. Requierefrecuentes accesos a disco y usa una porcion considerable de la memoria (sufi-ciente para atenuar el efecto de las caches). La prueba simplemente consiste encompilar y comprimir una imagen del kernel de Linux (sin modulos adicionales)y medir el tiempo que tarda.

Para poder comparar los resultados de manera coherente, siempre se compi-lara la misma version del kernel (3.8.4), con las mismas opciones (las opcionespor defecto). No se garantiza que se use la misma version del compilador. Si unadistribucion incluye un compilador desfasado se vera como un aspecto negativoy quedara reflejado en el tiempo de compilacion.

21

Tiempo de compilacion de un kernel de Linux con varios threads Idem alparametro anterior, pero con varios threads trabajando al mismo tiempo. Conesto podemos medir la eficiencia de la gestion de procesos (scheduling) delsistema operativo.

Dado que el numero maximo de procesos que los PCs a tratar pueden ejecutarsimultaneamente es de 2 (hay procesadores con 2 cores y procesadores conHyperthreading) se ha optado por compilar el kernel usando 4 threads, paraforzar el scheduling.

Consumo energetico Consiste en medir la potencia consumida por el sistema es-tando en reposo (entiendase “reposo” como el PC encendido, pero sin realizartrabajo; no como un estado idle o de bajo consumo).

La medicion se hizo con un medidor de consumo electrico (una herramientahardware).

3.2.2. Puntos a mejorar

Durante las pruebas se detectaron los siguientes problemas:

Las mediciones del disco sufren una pequena perturbacion al incluir en el re-sultado el tamano de los archivos del benchmark. Aunque es una perturbacionpequena, es facil evitarla en versiones sucesivas del benchmark.

Las mediciones que involucran LibreOffice requieren la intervencion del usuario(para cerrar el programa en su debido momento).

Las pruebas se realizaron en mi casa y con mi conexion de red. La prueba demedicion de la velocidad de la red podrıa tener que modificarse dependiendode la conexion de red del almacen de TxT (por ejemplo, reemplazar el archivoa descargar por uno mas grande o mas pequeno o cambiar a una localizaciondistinta).

Se ha notado que este atributo no varıa demasiado entre distribuciones, ası queposiblemente se dara la posibilidad de ignorarlo.

El consumo electrico se mide con un hardware que no tiene conexion con el PCy, por lo tanto, el usuario debe tomar nota del valor el mismo.

De todas formas, este atributo tambien varıa muy poco entre distribuciones,ası que tambien se dara la posibilidad de ignorarlo en futuras versiones.

22

Algunas distribuciones necesitaron instalar el software necesario para compilarel kernel de Linux. En las distribuciones basadas en Debian/Ubuntu se ins-talo el paquete build-essential. En Puppy Linux se instalo el paquete devx.En la version final del benchmark se debera informar al usuario.

3.3. Version final del benchmark

La nueva version del benchmark corrige fallos de la version preliminar y se hacreado un script para automatizarlo (el codigo fuente puede verse en el apendice E).Estos son los puntos a destacar de la nueva version del benchmark :

Se resta el tamano de los archivos del benchmark a la medicion del disco.

Se ha creado una funcion bash que usa el comando top para comprobar cuandoLibreOffice ha acabado de trabajar. Con esto, ahora no se medira solo hasta queel recuento de paginas sea correcto, sino hasta que el uso de CPU de LibreOfficesea 0, lo cual puede ser unos segundos despues de que el recuento de paginasalcance el valor adecuado. Ademas, como esta funcion no cierra LibreOfficeWriter satisfactoriamente, se eliminan los archivos temporales de LibreOfficeantes del iniciarlo, para que no pida recuperarlos.

Los PCs de escritorio no acostumbran a ofrecer una interfaz para consultar elconsumo energetico, por lo que esta prueba sigue necesitando la intervenciondel usuario.

Si se va a ejecutar el benchmark en un PC capaz de reportar su propio consumoenergetico (p. ej., un portatil) se podrıa extender el script del benchmark eincorporar esta funcionalidad. Otra posibilidad serıa comprar un medidor deconsumo electrico con conexion al PC (los hay con conexion USB), pero sedecidio no gastar mas en hardware teniendo uno perfectamente funcional.

Si hay alguna dependencia del benchmark sin cumplir se pedira en el momentoque se vaya a usar. Por ejemplo, si LibreOffice no esta instalado, se pedira quese instale tras haber hecho las mediciones de disco y memoria. En el caso deque todas las dependencias esten instaladas no se requerira la intervencion delusuario.

El script es capaz de reiniciar el sistema cuando sea necesario sin la intervenciondel usuario si se usa el parametro adecuado (esto puede requerir permisos).

23

Se pueden ignorar las pruebas de velocidad de la red y de consumo energetico(recordemos que la medicion del consumo se hace de manera manual por partedel usuario).

Como corolario de los tres ultimos puntos, si el sistema cumple las dependen-cias en el momento de ejecutarse, se ignora la prueba de medicion del con-sumo electrico y se manda a ejecutar con privilegios y usando el parametroadecuado para automatizar los reinicios, el benchmark se puede automatizarcompletamente (no requerira en ningun momento la interaccion del usuario).No obstante, hay que tener en cuenta que algunos de los PCs de TxT tienenproblemas al arrancar sin estar conectados a un monitor (esto es importantesi se pretende trabajar con varios PCs a la vez conectados a un multiplexorVGA, como fue mi caso).

Todas las mediciones (excepto la del tiempo de arranque) se haran tras esperar60 segundos despues de que el sistema sea usable, para garantizar que se hainiciado completamente.

3.4. Modalidad basada en estimacion

Una vez que ya se tiene la version final de la primera modalidad del benchmarky unas mediciones fiables de todas las distribuciones candidatas, se puede hacer lasiguiente modalidad del benchmark.

Esta modalidad solo realizara mediciones sobre una de las distribuciones y extra-polara los resultados para determinar el rendimiento de las demas. Se ha decididoque la distribucion de referencia (sobre la que se haran las mediciones) sera Ubuntu,ya que es la que la mayorıa de los PCs de TxT llevan ya instalada.1

El codigo fuente del benchmark se puede reaprovechar casi por completo. El codigoresultante se puede ver en el apendice G. Las mediciones sobre la distribucion seharan exactamente de la misma manera que en la modalidad de benchmark anterior;la diferencia esta en que se estimara el rendimiento de las demas distribuciones,ası que el codigo de la modalidad anterior del benchmark no se modifica, solo seexpande.

1En el momento de disenar esta modalidad de benchmark las distribuciones candidatas eranSlackware (con KDE), Ubuntu, Linux Mint y Puppy Linux.

24

Los parametros mas sencillos de medir son el disco y la memoria, ya que solohay que consultar la cantidad total y la usada. aprovechando esto y, ya que el usode memoria es el gran discriminante, podemos usar estos parametros para realizardescartes tempranos en el caso de que el sistema no disponga de suficiente memoriay/o disco para algunas de las distribuciones. Para ello se distinguira entre 3 casos:

Disco y/o memoria insuficientes para Ubuntu En este caso, se pueden des-cartar al instante Ubuntu y Slackware. Se estimara el consumo de memoria ydisco de Linux Mint. Si las cantidades de memoria y disco son suficientes paracorrer Linux Mint, se elegira como distribucion ganadora. En caso contrario,se elegira Puppy Linux. Sea cual sea la distribucion elegida en este caso, nosera necesario completar el benchmark

Disco y memoria suficientes para Ubuntu, pero no Slackware En este caso,si Ubuntu tiene un buen rendimiento se elegira como distribucion final. En casocontrario, se elegira Linux Mint.

Disco y memoria suficientes para Slackware En este caso habra que elegir en-tre Slackware, Ubuntu y Linux Mint. Si Ubuntu tiene un buen rendimiento,se decidira entre Slackware y Ubuntu. En caso contrario se elegira Linux Mintcomo distribucion ideal.

Para decidir entre 2 distribuciones, el funcionamiento es el mismo que en lamodalidad de benchmark anterior, con la diferencia de que los parametros seranestimados, no medidos.

Debido a que los parametros de velocidad de red y consumo electrico no sondecisivos, se ignoraran. Tambien se ignorara el tiempo de compilacion del kernelde Linux con 4 threads, ya que esto dependera del tipo de procesador (numerode threads, cores, etc.).

3.5. Modalidad basada en la estimacion de una

distribucion live

Aunque con esta segunda version del benchmark reducimos considerablementeel tiempo necesario para averiguar la distribucion ideal, aun tenemos que instalary una distribucion. Ademas existe la posibilidad de que esa distribucion no sea laideal y haya que instalar otra despues. Para ahorrarnos todas estas instalaciones secreo una tercera version del benchmark. Esta version no requerira instalar ningunadistribucion, ya que se ejecutara desde una distribucion live. Tampoco requerira tanto

25

tiempo como las versiones anteriores, ya que la mayorıa de parametros se estimaranen base al hardware del PC en cuestion. Ası, pues, esta version sera la que menostiempo necesite, pero tambien tendra unos resultados potencialmente mas alejadosde la realidad.

3.5.1. ¿Medir o estimar?

Durante la creacion de esta version surgieron dos ideas sobre como deberıa fun-cionar este benchmark. Por un lado, existıa la posibilidad de simplemente ejecutar elbenchmark sobre la distribucion live y, a partir de sus resultados, estimar cuales serıanlos resultados de las demas distribuciones de manera similar a la version anterior delbenchmark. Por el otro, la idea era que desde la distribucion live se consultasen losatributos del hardware del sistema en cuestion y se calculase la distribucion ideal enbase a esos atributos.

Se hicieron pruebas con la primera alternativa. Estas mediciones se realizaronsobre el PC A (Procesador Intel Core 2 Duo, 2 GiB de memoria). Para poder realizarlas pruebas que requieren entorno grafico, se instalo JWM (Joe’s Window Manager)en la distribucion live. Este entorno de escritorio es muy ligero y es el que incluyePuppy Linux por defecto. No se realizo la prueba de ocupacion de disco, porquela distribucion live siempre ocupa el mismo espacio. Tampoco se realizo la pruebade velocidad de red, porque se vio que no era un parametro decisivo (todas lasdistribuciones daban practicamente el mismo resultado).

Paramtero CD USB

Memoria (MiB) 262 242Tiempo de arranque del SO (s) 151,12 24,30

Tiempo de arranque de LibreOffice (s) 21,568 9,819Tiempo de apertura de many_as.txt (s) 141,696 103,413

Tiempo de compilacion en serie (s) 263,273 260,172Tiempo de compilacion en paralelo (s) 143,145 142,294

Consumo energetico (W) 62,0 56,0

El primer problema que encontre fue que para poder conservar los resultados delas mediciones durante los reinicios necesarios serıa necesario un medio de almace-namiento persistente. Es decir, la distribucion live no podrıa ser grabada en un CDo DVD. Esto supone un problema, ya que algunos (pocos) de los PCs de TxT nopueden arrancar desde USB. Ademas, se vio que el medio en el que se grabase ladistribucion (CD, DVD o USB) afectaba a los valores de las mediciones, debido a que

26

la velocidad de lectura de dicho medio no era la misma que la del disco del sistema aevaluar (ademas de que tambien afectaba otros parametros, como el consumo electri-co). Como esta version del benchmark ya extrapola bastante los datos, se decidio queanadir una variable mas a las estimaciones (la velocidad del medio de la distribucionlive) serıa demasiado, ası que se opto por descartar esta alternativa.

3.5.2. La distribucion live

Para esta version del benchmark se ha usado una distribucion live basada en De-bian 6.0.7. Es la misma distribucion con la que se trabajo anteriormente en el trabajo,pero esta vez se usara sin entorno grafico. Con esto conseguimos reducir de maneraconsiderable los recursos necesarios para ejecutarla en tiempos razonables. Ademas,como esta version simplemente toma las propiedades del hardware y realiza calculos(no realiza las mediciones de las versiones anteriores; no se necesitara LibreOffice),no es necesario entorno grafico.

Para crear la distribucion live, en primer lugar se creo una maquina virtual enVirtualBox. Los parametros de la maquina virtual no afectaran al resultado, aunquesı puede afectar al tiempo que se tarde en construir la imagen .iso resultante. Du-rante la instalacion se eligio no instalar el entorno grafico, ya que no sera necesariopara esta tarea y nos permite ahorrar bastante memoria (recordemos que toda ladistribucion sera cargada en memoria). Una vez instalada la distribucion Debian sepersonalizo, instalando los paquetes necesarios para realizar todas las tareas. Esto in-cluyo el paquete build-essential, para compilar, y el paquete nasm, requisito parael programa bandwidth [11] (el cual se instalo desde el codigo fuente proporcionadopor el autor). Finalmente, se realizo una “instantanea” (en ingles, snapshot) usan-do el programa refractasnapshot. Este programa crea por defecto un menu queaparece al arranque y permite elegir entre distintos tipos de arranque (normal, sinentorno grafico, cargar a memoria...). Se edito este menu para que solo estuviese laopcion de cargar a memoria y se redujo el timeout al mınimo (porque realmente noes necesario escoger ninguna opcion, ya que solo hay una). El programa genero unaimagen .iso que contenıa la instantanea de la distribucion tal y como estaba enel momento de la creacion. Finalmente se copio a un USB usando el programa dd.Tambien se podrıa haber grabado en un CD o DVD.

Debido a las limitaciones del programa de entrega de la memoria de este proyecto(el tamano maximo para archivos adicionales es de 100 MB) no se podra entregar laimagen .iso (que tiene un tamano de mas de 200 MB).

27

3.5.3. Estimando en base al hardware

De la misma manera que se hizo en la modalidad anterior de benchmark, leerla capacidad del disco y la memoria y comprobar si es suficiente para cada unade las distribuciones es facil, ya que estos parametros son bastante constantes parauna misma distribucion en varios PCs. Otros parametros no pueden ser medidosdirectamente y tienen que ser estimados en base a pequenas pruebas.

Para poder estimar los valores que no podemos medir, es necesario averiguar deque otros parametros dependen. Para ello se han realizado un estudio estadıstico quepuede encontrarse en el apendice H. En este estudio se observaron variables relativasal disco, la memoria y la CPU, por que son las mas basicas y probablemente las quemas influencia tengan.

Las variables relativas a la CPU son simplemente el tiempo de compilacion deuna aplicacion de referencia con 1 y 4 threads, tal y como se hace en el benchmarkclasico. Al tener que cargar la distribucion live en la memoria, no queda suficientepara compilar el kernel de Linux, ası que se ha optado por una aplicacion maspequena llamada PAPI [12] (la funcionalidad de la aplicacion no nos importa; solosu tiempo de compilacion). Las variables relativas al disco son el ancho de bandade lectura y la latencia. Estas se pueden medir facilmente usando el comando dd;para medir el ancho de banda se leen 1,6 GB y para la latencia, 1 bloque (512 B).Finalmente, las relativas a la memoria son el ancho de banda de lectura de secuencialde archivos de distintos tamanos. Se han distinguido 4 casos: archivos menores de32 kiB, entre 32 y 256 kB, entre 256 kB y 1 MB y superiores a 2 MB. Esta divisionse ha realizado tras ver 4 tramos claramente distintos en pruebas realizadas con elprograma bandwidth (vease la figura 3.1).

28

Figura 3.1: Grafico generado por el programa bandwidth.

29

3.6. Experimentacion con un Pocket PC

Hoy en dıa, cuando se habla de PCs de perfil bajo uno no puede evitar pensaren los llamados Pocket PCs ; PCs diminutos, que caben en la palma de la mano,con los recursos mınimos necesarios para realizar tareas cotidianas como navegar porInternet, consultar el correo o editar un documento. Sus principales ventajas son subajo consumo y su precio, lo cual las hace ideales para, por ejemplo, aulas tecnologicasen paıses subdesarrollados, donde la corriente electrica es escasa y el presupuestomuy ajustado. Actualmente la asociacion TxT dona equipos de sobremesa con pocosrecursos a ONGs con este tipo de finalidades, con lo que resulta interesante comprobarhasta que punto pueden los Pocket PC sustituir los PCs convencionales.

Como parte de este trabajo se experimento con una Raspberry Pi (modelo B). Lafinalidad de estos experimentos fue doble: por un lado, demostrar que el benchmarkpuede funcionar en cualquier dispositivo capaz de correr Linux; y por otro, medir elrendimiento de un Pocket PC y compararlo con el de PCs convencionales de bajorendimiento.

No se trato de comparar las distintas distribuciones disponibles para la RaspberryPi, ya que todavıa son pocas y tienen propositos muy distintos (p. ej., convertir laRaspberry Pi en un media center).

30

Capıtulo 4

Implementacion, pruebas yresultados

4.1. Encuesta

La encuesta se publico en los foros de la facultad y permanecio disponible duranteuna semana. Durante este tiempo se consiguieron 88 respuestas; mas que suficientepara mi proposito.

A la hora de valorar los resultados de la encuesta y asociar un valor a cada opcion,inicialmente se penso en hacer una traduccion directa: asociar a cada funcionalidadel porcentaje de encuestados que la selecciono. Finalmente se opto por normalizar elvalor. Es decir, el valor asignado a una funcionalidad (x) se obtiene con la siguienteformula:

valorx =numero de votosx

Σtodas las funcionalidadesnumero de votos

De esta manera el valor de cada funcionalidad queda ponderado segun su populari-dad: las funcionalidades populares valdran mas que las impopulares.

Los resultados completos de la encuesta se pueden encontrar en el apendice A.Los votos de las opciones de reproduccion de HD-DVD y Blu-Ray Disc se eliminaron,ya que, al no disponer del hardware necesario, estas opciones resultan irrelevantes.

31

Cuadro 4.1: Fragmento de los resultados de la encuesta.

FuncionalidadVotos Votos Valor(abs) ( %) normalizado

Pro

cesa

dor

de

texto

s Compatible con documentos deOffice 2010 (.docx)

77 87,50 % 3,56 %

Compatible con documentos deLibreOffice y OpenOffice (.swx)

47 53,41 % 2,17 %

Posibilidad de anadircomentarios a los documentos

45 51,14 % 2,08 %

Crear graficos y dibujos sinnecesidad de una herramienta

externa54 61,36 % 2,50 %

Integracion con una suiteofimatica completa

18 20,45 % 0,83 %

Version para Mac OS X 14 15,91 % 0,65 %

4.2. Analisis de las distribuciones

4.2.1. Seleccion de distribuciones candidatas

Mientras la encuesta estuvo activa, se seleccionaron las distribuciones candidatascon las que se trabajarıa. A continuacion se detalla que distribuciones se seleccionarony por que motivo.

Bodhi Linux

Version: 2.3.0

Motivo: Esta basada en Ubuntu (que es la distribucion que se usa actual-mente), usa el entorno de escritorio Enlightenment, conocido por ser muyligero. Es muy minimalista y tiene una buena puntuacion en DistroWatch.

32

http://distrowatch.com/bodhi

CrunchBang

Version: 11 (Waldorf)

Motivo: Es una distribucion ligera, basada en Debian (anteriormente basadaen Ubuntu, que es la distribucion que se usa actualmente) y tiene unabuena puntuacion en DistroWatch.

Comentarios: Esta distribucion debe grabarse en un CD de 800 MB comomınimo.

Debian

Version: 6.0.7 (Squeeze)

Motivo: Es una distribucion original (no esta basada en ninguna otra), esmuy conocida y es compatible con paquetes de Ubuntu.

Comentarios: solo se usara el CD1.

Linux Mint

version: 12 (Lisa)

Variante: LXDE

Motivo: Es la distribucion elegida para los PCs mas antiguos de TxT. Se haelegido como referencia.

Comentarios: No es la version mas moderna, pero es la ultima que se puedegrabar en un CD de 700 MB.

Puppy Linux

Version: 5.4.3

Variante: Ubuntu Precise

Motivo: Es una distribucion extremadamente ligera, usa JDM (un entorno deescritorio muy ligero), arranca desde ramdisk y tiene muy buena valoracionen DistroWatch.

Comentarios: Se usara el modo de instalacion Full.

33

http://distrowatch.com/crunchbang

http://distrowatch.com/puppy

Slackware

Version: 14.0

Variante: KDE y XFCE

Motivo: Es una distribucion original de las mas antiguas y muy completa encuanto a funcionalidades. fue sugerida por mis directores.

Comentarios: Esta distribucion debe ser grabada en un DVD como mınimo.Ambas variantes se encuentran en el mismo disco. Se trataran las dosvariantes por separado.

Lubuntu

Version: 12.10

Motivo: Version ligera de Ubuntu, con escritorio LXDE (muy ligero). Tienebuena puntuacion en DistroWatch.

Xubuntu

Version: 12.10

Motivo: Idem a la anterior, pero con escritorio XFCE (tambien muy ligero,auque no tanto como LXDE).

Ubuntu

Version: 12.04

Motivo: Distribucion muy popular. Es una version LTS (Long Term Support).Es la que se usa actualmente en la mayorıa de PCs de TxT. Se ha elegidocomo referencia.

Comentarios: No es la version mas moderna, pero es la ultima que se puedegrabar en un CD de 700 MB.

Todas las instalaciones se hicieron sin acceso a la red y con todas las opcionespor defecto, con las siguientes excepciones:

Se activa la opcion de auto-login siempre que sea posible. Esto es para favorecerla medicion del tiempo de arranque.

En la variante KDE de Slackware no se instala XFCE y viceversa. Esto es parano perturbar la medicion de la ocupacion del disco.

34

http://distrowatch.com/lubuntu

En las distribuciones que no proporcionan un particionamiento del disco pordefecto, se instala todo el sistema en una unica particion. Tambien se hace unaparticion swap de tamano igual al doble de la cantidad de memoria del sistema.Siempre se usa ext4.

4.2.2. Analisis de funcionalidades

Una vez elegidas las distribuciones, se calcula su funcionalidad. Para ello, primerose toman de cada distribucion los programas pertenecientes a cada una de las cate-gorıas de la encuesta (vease el apendice B). Con esto ya podemos ver que algunas delas distribuciones no traen programas para algunas de las categorıas. Por ejemplo,Xubuntu no incluye ningun programa para trabajar con hojas de calculo. Estas dis-tribuciones posiblemente se vean perjudicadas en el aspecto de funcionalidad. Solose tuvo en cuenta el software incluido en la instalacion por defecto. El software in-cluido en el disco que no este seleccionado por defecto no se valorara. El software noincluido en el disco pero incluido en los repositorios o instalable a traves de scriptspost-instalacion u otros medios tampoco se valorara. Si algun software incluido en lainstalacion por defecto tiene actualizaciones disponibles a traves de Internet, estasactualizaciones tampoco se tendran en cuenta. Para saber que software incluye cadadistribucion simplemente se instalo cada una de ellas en una maquina virtual.

Despues se mira que funcionalidades tiene cada programa y cuales no (veaseel apendice C). Aquı podemos ver como las distintas alternativas para una mismacategorıa tienen distintos equilibrios entre funcionalidad y rendimiento. Por ejemplo,Abiword es mas ligero que LibreOffice Writer, pero tambien tiene muchas menosfuncionalidades. Mas adelante, cuando se evalue el renimiento, se podra ver masclaramente que distribuciones balancean mejor funcionalidad y rendimiento.

Finalmente, uniendo los programas por distribucion con las funcionalidades porprograma se puede saber que funcionalidades cumple cada distribucion. Esta sera lamedida que se usara como representativa del nivel de funcionalidad de cada distri-bucion. Inicialmente se penso en contar solo las funcionalidades con mas del 50 % devotos, para distinguir las funcionalidades populares de las no populares. Finalmentese opto por un total normalizado, usando el valor normalizado que se calculo con losresultados de la encuesta.

El desglose de los resultados puede encontrarse en apendice D. A continuacion semuestran los totales.

35

La fila “Total (abs)” indica el total de votos para las funcionalidades con mas del50 % de votos.

La fila “Total ( %)” indica el porcentaje de funcionalidades con mas del 50 % devotos que cumple.

La fila “Total normalizado” es una ponderacion teniendo en cuenta todas lasfuncionalidades y su valor normalizado (vease el apendice A).

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

FuncionalidadB

odhi

Lin

ux

Cru

nch

Ban

g

Debia

n

Lin

ux

Min

t

Puppy

Lin

ux

Sla

ckw

are

Lubu

ntu

Xubuntu

Ubuntu

KD

E

XF

CE

Tota

l Total mayoritarios(abs)

2,5 12,5 10 19,5 16,5 23 15 19 13 19

Total mayoritarios( %)

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

Total normalizado( %)

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

Con estos resultados es facil observar que Bodhi Linux no llegara lejos, ya quecumple menos del 10 % de las funcionalidades, muy por debajo del resto de distribu-ciones (esto se debe principalmete a que casi no trae ningun programa por defecto).Por esta razon se decidio descartar Bodhi Linux como distribucion candidata, inclusoantes de medir su rendimiento.

4.3. Analisis de los PCs

4.3.1. PCs de TxT

Con tal de preparar las pruebas, hice una visita al almacen de TxT para ver conque PCs tendrıa que trabajar. En el momento de la inspeccion, la mayorıa de losPCs eran de los siguientes tipos:

36

Modelo A

Procesador: Pentium 4

Frecuencia del procesador: 3,20 GHz

Numero de nucleos: 1

Numero de threads por nucleo: 2 (Hyperthreading)

Memoria: 2 × 512 MB

Disco: 80 GB

Lector de DVD: Sı (DVD-ROM)

Modelo B

Procesador: Pentium D



Numero de threads por nucleo: 1


Disco: 160 GB

Lector de DVD: Sı (DVD-RW)

Modelo C

Procesador: Core 2 Duo




Memoria: 2 × 1 GB

Disco: 250 GB

Lector de DVD: Sı (DVD-RW)

Nota: La cantidad de memoria y disco puede variar entre PCs del mismo modelo.

37

Aunque habıa PCs de otros tipos (tanto mejores como peores), eran muy pocos yse trataron como outliers.

Estos 3 tipos de PCs eran comunes en gran numero, probablemente debido a quelas donaciones de equipos a TxT se hacen en grandes cantidades. En cambio, losoutliers eran escasos; probablemente eran restos o fueron donados por particulares.

4.3.2. Pruebas de rendimiento preliminares

En un principio, las pruebas se harıan en los PCs antes mencionados, pero la llavedel almacen que me tenıan que dar se extravio y, durante la mayor parte del trabajo,solo pude entrar cuando hubiese alguien dentro, ası que decidı realizar las primeraspruebas en mi casa. Para poder hacer pruebas en casa y no tener que depender deTxT dispuse de un PC de las siguientes caracterısticas:

Modelo A0

Procesador: Pentium 4



Numero de threads por nucleo: 2 (Hyperthreading)

Memoria: 512 MB + 1 GB

Disco: 80 GB

Lector de DVD : Sı (DVD-RW)

La intencion es que el PC A0 simule un “suelo” para poder decidir la magnitud delas pruebas; es decir, un PC con los mas bajos recursos (no queremos un benchmarkque tarde demasiado en ejecutarse en un PC lento, ya que la finalidad de este esprecisamente ejecutarlo sobre PCs lentos). En principio se eligio para que fuese unPC con hardware similar al PC A, que es el PC de TxT con los recursos mas bajos.Finalmente, a pesar de que tuviese mas memoria las pruebas de rendimiento indicanque es aun mas lento que el PC A. Esto no supone un problema, ya que al quedarpor debajo del PC A cumple su cometido correctamente.

Con este PC me dispuse a realizar unas pruebas de rendimiento con una versionpreliminar del benchmark para poder disponer de unos datos sobre el rendimientode cada distribucion, aunque fuesen solo aproximados. Los resultados se muestran acontinuacion.

38

Parametro

Cru

nch

Bang

Debia

n

Lin

ux

Min

t

Puppy

Lin

ux

Sla

ckw

are

Lubuntu

Xu

bu

ntu

Ub

untu

KD

E

XF

CE

Ocupacion del disco (GB) 2,3 1,5 2,5 0,72 6,7 5,3 1,8 2,1 2,4Uso de la memoria (MB) 244 165 295 104 628 298 291 390 683Tiempo de arranque (s) 36,94 30,20 20,80 21,21 162,14 35,72 18,73 20,72 20,87Tiempo de arranque de

LibreOffice (s)12,45 10,97 10,01 13,00 18,10 8,31 12,30 10,86 14,32

Tiempo de apertura demany_as.txt

2’ 37” 2’ 15” 2’ 22” 3’ 21” 3’ 22” 3’ 05” 1’ 14” 1’ 11” 3’ 22”

Velocidad de descarga(MB/s)

1,03 1,16 1,13 1,11 1,11 1,13 1,12 1,12 1,00

Tiempo de compilacion delkernel (en serie)

7’ 58” 7’ 07” 7’ 30” 7’ 41” 10’ 32” 8’ 44” 8’ 33” 8’ 27” 9’ 38”

Tiempo de compilacion delkernel (en paralelo)

8’ 56” 5’ 44” 5’ 53” 5’ 56” 10’ 18” 8’ 31” 6’ 12” 6’ 12” 8’ 29”

Consumo energetico (W) 59,0 58,0 59,0 55,5 59,0 59,0 58,5 59,0 58,5

39

4.4. Criba de distribuciones

Una vez obtenidos los datos sobre la funcionalidad y el rendimiento de las dis-tribuciones se puede hacer una criba y escoger solo con las mas prometedoras, paraahorrar trabajo en las pruebas y mediciones que se harıan mas tarde.

Se determino que la distribucion ideal serıa aquella que tenga mas funcionalidadesy supere unos determinados mınimos de rendimiento. Por lo tanto, use la funciona-lidad de las distribuciones para ordenar las distribuciones y los resultados de laspruebas de rendimiento para hacer la criba. Como resultado, las distribuciones De-bian, CrunchBang, Xubuntu y Slackware (variante XFCE) fueron eliminadas por serlas distribuciones con menor funcionalidad. Slackware (variante KDE) se mantuvo apesar de tener malos resultados en las pruebas de rendimiento por ser la distribucioncon mayor funcionalidad.

De ahora en adelante, siempre que se haga referencia a Slackware se referira a lavariante KDE, a menos que se especifique lo contrario.

4.5. Pruebas de rendimiento en PCs de TxT

4.5.1. Resultados y reporte de incidencias

Una vez finalizado el benchmark, seleccionadas las distribuciones y analizadoslos PCs es momento de realizar las mediciones. Los resultados se encuentran en elapendice F.

Durante las pruebas se detectaron las siguientes incidencias:

El PC B era incapaz de arrancar desde algunos de los CDs y DVDs (en par-ticular, Linux Mint, Puppy Linux y Ubuntu). Se soluciono instalando dichasdistribuciones desde USB.

El PC A pide configurar la BIOS y poner el reloj en hora cada vez que seenciende. Posiblemente se deba a que la pila que alimenta la BIOS este gastada.No fue necesario cambiarla; basto con configurar la BIOS y el reloj cada vez quese encendıa (solo la primera vez tras perder la alimentacion); esto no afecto ala medicion del tiempo de arranque.

En la tabla de resultados se puede observar que en algunas distribuciones(Slackware y Puppy Linux) el tiempo de apertura del archivo many_as.txt

con LibreOffice es bastante mayor que en las demas. Esto es debido a que

40

LibreOffice se queda “congelado” durante un tiempo despues de abrirse pe-ro antes de mostrar el archivo. Desconozco la causa, pero es obvio que estopenalizara gravemente a esas distribuciones.

Los tiempos de arranque del PC B son mas altos que los del PC A, a pesar deque este es mas nuevo y dispone de mejor hardware. En cualquier caso, no esel objetivo de este proyecto el descubrir el por que de este fenomeno. Ademas,la diferencia no es demasiado grande como para causar un gran impacto en losresultados, ası que no se le dara mas importancia al asunto.

LibreOffice en Slackware arranca mas rapido en PCs mas viejos. Es un datobastante desconcertante al cual no le encuentro explicacion. De todos modos,Slackware es siempre el mas lento en todos los parametros.

La compilacion del kernel de Linux en Slackware muestra un warning, aunqueesto no afecta a las mediciones del tiempo de compilacion ni a los resultadosdel benchmark.

La conexion de red del almacen de TxT no era la adecuada para llevar a ca-bo las mediciones. La velocidad era muy variable, llegando incluso a mostrardiferencias de cientos de KB/s en una misma distribucion en un mismo PC.Presumiblemente esto se debe a que hay mas gente conectada a la red y hacenun uso intensivo de ella. Para solucionarlo simplemente se usaran los datosobtenidos en las pruebas preliminares (las que se hicieron con el PC A0), yaque tras la experimentacion con Raspberry Pi (mas adelante) se ha visto quela velocidad de red no varıa demasiado de un hardware a otro y, ademas, tam-poco varıan mucho entre distribuciones, con lo que no resultara un parametrodecisivo.

4.5.2. Conclusiones

De las pruebas realizadas con los PCs de TxT se extraen las siguientes conclu-siones:

Disco: Ubuntu, Linux Mint y Lubuntu estan a la par. Slackware ocupa bastantemas y Puppy Linux bastante menos. No varıa mucho entre PCs.

Memoria: Es un poco irregular, pero aun ası es facil de ver el requisito de cadadistribucion. Slackware y Ubuntu son los mas altos, Linux Mint y Lubuntu sonmas razonables y Puppy Linux es diminuto.

41

Tiempo de arranque del SO: Linux Mint arranca bastante mas rapido en el Core2 duo. Lubuntu y Puppy Linux tambien mejoran en este procesador, perola diferencia es pequena. Slackware es siempre muy alto. Basicamente todosexcepto Slackware arrancan en un tiempo aceptable.

Tiempo de arranque de LibreOffice: Muy constante. Ligeramente mejores en elprocesador mas nuevo. La excepcion es Slackware, que va mejor con el proce-sador mas viejo.

Tiempo de apertura de many as.txt con LibreOffice: Aquı es notable una grandiferencia en Slackware y Puppy Linux. Esto es debido a que LibreOffice sequeda bloqueado durante algun tiempo antes de mostrar el archivo. El bloqueodura bastante tiempo (unos 40 segundos) y penaliza gravemente a aquellasdistribuciones que lo sufran. Aunque no se ha comentado antes, esto tambiensucedıa en las pruebas en el PC A0, incluso en distribuciones en las que nose produce ningun bloqueo con los PCs de TxT. No se reporto como un inci-dente debido a que ocurrıa en muchas otras distribuciones y se vio como algo“normal”.

Velocidad de descarga: Tal y como se ha comentado en la seccion anterior, estaprueba no se realizo con exito.

Tiempos de compilacion del kernel de Linux: Se ven fuertemente influencia-dos por el procesador, sobretodo la compilacion en paralelo. Es bastante cons-tante entre distribuciones (excepto Slackware, que es mas lento).

Consumo energetico: Muy influenciado por el procesador (hasta 15 W de diferen-cia). Muy constante entre distribuciones. Puppy consume un par de W menos,pero poca cosa. No es un parametro decisivo.

4.5.3. Interpretacion de los resultados

Con estos resultados se debe escoger una de las distribuciones como la mejor. Sedecidio eliminar Lubuntu, ya que casi no ofrece mejoras con respecto a Linux Mint ytiene casi un 5 % menos de funcionalidad. Ademas, Puppy Linux solo se usara comoultimo recurso, en caso de que el sistema no tuviese suficiente memoria para ningunaotra distribucion.

Para determinar que distribucion es mejor para cada PC se seguira la metodologıasiguiente:

42

Disco y memoria Debera usar como maximo la mitad del total (en el caso deldisco, exceptuando swap).

Tiempos y consumo Sea xi el valor de la distribucion i en el campo x, y x la mediade todas las distribuciones (Slackware, Ubuntu y Linux Mint) en el campo x,se considerara que la distribucion i cumple el requisito si:

xi <= x× 110 %

Se ha anadido un 10 %, porque sino siempre habrıa como mınimo una dis-tribucion que no cumplirıa cada uno de los requisitos, aunque todas tuviesenresultados muy parecidos.

Velocidad de red Idem al anterior, pero cambiando el sentido de la desigualdad,ya que en este campo “mas es mejor”. Por lo tanto, sea ri la velocidad de red dela distribucion i, y r la media de velocidad de red de todas las distribuciones,se considerara que la velocidad de red de la distribucion i es aceptable si:

ri × 110 % >= r

Se ha implementado un script que realiza estos calculos en base a los resultadosde del benchmark. El codigo fuente de este script se encuentra en el apendice E.3.

4.6. Realizando estimaciones

En la modalidad del benchmark que realiza estimaciones sobre Ubuntu, estasson unas estimaciones muy sencillas, ya que teniendo unas mediciones reales comobase se pueden aproximar las mediciones reales de las demas distribuciones de maneramoderadamente sencilla con solo anadir un offset a las mediciones reales (la diferenciamedia entre las distribuciones).

En cuanto a las estimaciones en base a la distribucion live, debido al bajo numerode muestras solo podemos realizar estimaciones en base a 2 variables (+1 variable deoffset). Como algunas de las variables estan correlacionadas con mas de 2 variables,hay que escoger 2 de ellas. Simplemente se escogeran las 2 variables con la correlacionmas significativa.

43

Para calcular en que proporcion afecta cada variable se hara simplemente unsistema de ecuaciones. Por ejemplo, para estimar el tiempo de arranque de Ubuntuse resolverıa el siguiente sistema:

Tiempo de arranquePC A = Ancho de banda del discoPC A × x

+Ancho de banda de la memoria (tramo 4)PC A × y

+z

Tiempo de arranquePC B = Ancho de banda del discoPC B × x

+Ancho de banda de la memoria (tramo 4)PC B × y

+z

Tiempo de arranquePC C = Ancho de banda del discoPC C × x

+Ancho de banda de la memoria (tramo 4)PC C × y

+z

De aquı los valores resultantes son:

x = −0, 19

y = 0, 88

z = 32, 10

De manera que se puede estimar el tiempo de arranque de un PC con la siguienteecuacion:

Tiempo de arranque = Ancho de banda del disco ×−0, 19

+Ancho de banda de la memoria (tramo 4) × 0, 88

+32, 10

Para las demas variables y distribuciones, las ecuaciones resultantes se encuentranen el apendice I:

Para comprobar los resultados, se realizo una regresion lineal multiple [13] con elprograma Minitab [14]. Los resultados coincidieron, con lo que podemos asumir queson correctos.

4.7. Comparativa de modalidades del benchmark

Ahora que se tienen las 3 modalidades del benchmark implementadas, podemoscompararlas para conseguir una proporcion entre tiempo de ejecucion y precision

44

optimas. Como las estimaciones se han hecho en base a los PCs utilizados a lolargo del trabajo, resulta obvio que todas las modalidades del benchmark devolveranlos mismos resultados para estos PCs. Para poder probar de manera efectiva lasdistintas modalidades, se deben ejecutar en un PC totalmente nuevo. A continuacionse detallan las especificaciones de este nuevo PC:

Modelo X

Procesador: AMD Athlon 64 X2




Memoria: 1 × 512 + 1 × 256 + 1 × 128 MB

Disco: 80 GB

Lector de DVD: Sı (DVD-ROM)

Los resultados obtenidos por las distintas modalidades de benchmark fueron losque se muestran en la tabla 4.5.

Cuadro 4.5: Resultados de las distintas modalidades del benchmark.PC A PC B PC C PC Xa PC Xb

Benchmark clasico Linux Mint Linux Mint Ubuntu c Linux MintBenchmark Ubuntu Linux Mint Linux Mint Ubuntu Puppy Linux Linux MintBenchmark live Linux Mint Linux Mint Ubuntu Puppy Linux Slackware

aUsando descartes tempranos por memoria y disco.bSin usar descartes tempranos por memoria y disco.cLa modalidad de benchmark clasico no realiza descartes tempranos.

Como podemos ver, en los PCs con los que se ha trabajado todas las modalidadesdan el mismo resultado, como ya se habıa previsto.

Cabe destacar que en los PCs A, B y X se detuvo la ejecucion del benchmark du-rante los descartes por memoria y/o disco, lo que hace pensar que el uso de memoriaes un fuerte discriminante en este tipo de PCs.

Para comprobar la precision de las estimaciones, se han volvio a ejecutar losdistintos benchmark deshabilitando la funcion que realiza los descartes, para ası poderver los rendimientos estimados y compararlos con los reales.

45

Paramtero UbuntuLinuxMint

SlackwareLinuxMint a

Slackwarea

Ubuntub

LinuxMint b

Slackwareb

Disco (GB) 2,38 2,48 6,68 2,47 c 6,81 c 2,38 c 2,47 c 6,68 c

Memoria (MB) 653 451 701 473 c 726 c 680 c 500 c 753 c

Tiempo de arranquedel SO (s)

24,28 27,33 61,94 27,53 75,97 23,19 -50,72 173,41

Tiempo de arranquede LibreOffice (s)

8,934 8,468 12,012 8,340 11,654 4,823 -3,873 -116,047

Tiempo de aperturade many_as.txt (s)

172,682 78,872 130,559 175,112 207,487 82,834 1006,352 -235,406

Tiempo decompilacion en serie

(s)296,913 292,369 334,260 313,123 389,037 211,586 13,142 -71,369

Tiempo decompilacion en

paralelo (s)155,053 153,121 183,267 602,048 497,402 626,916

Cuadro 4.6: Comparacion del rendimiento real de las distribuciones con el rendimiento estimado.

aEstimado en base a Ubuntu.bEstimado en base a la distribucion live.cEstimado por la funcion de descartes tempranos.

46

Como se puede observar, las estimaciones realizadas basadas en Ubuntu son mo-deradamente acertadas. Aunque hay excepciones (p. ej., el tiempo de apertura demany as.txt en Slackware), grosso modo los valores son aceptables y el resultadofinal (la eleccion de la distribucion optima) coincide con el benchmark clasico, con loque esta modalidad de benchmark se puede considerar exitosa.

En cambio, las estimaciones basadas en la distribucion live son claramente erroneas,llegando incluso a retornar tiempos negativos. Esto es debido muy posiblemente albajo numero de muestras del que se dispone. A pesar de esto, la metodologıa pro-puesta es correcta, y se podrıan obtener buenas predicciones si se dispusiera de unmayor numero de muestras.

4.8. Experimentacion con un Pocket PC

El experimento consistio simplemente en ejecutar el benchmark (modalidad clasi-ca) en una Raspberry Pi con sistema operativo Raspbian (que es basicamente unaDebian ARM adaptada a la Raspberry Pi). Se trabajo con 3 versiones de Raspbian:Base, tal cual queda el sistema tras una instalacion por defecto; Mod, tras instalartodos los programas necesarios para maximizar las funcionalidades; y Potencial, igualque Mod, pero incluyendo las licencias para decodificar MPEG-2 y VC-1 (se com-pran por separado). De la version potencial solo se calcularon las funcionalidades,ya que el rendimiento seguramente no variara (solo son un par de codecs) y no sevio necesario comprar las licencias. Los resultados se muestran en la tabla al final deesta seccion.

Si bien los resultados no fueron mejores que los de los PCs de TxT, sı que fueronmejores que los del PC A0 (Procesador Pentium IV, 1,5 GiB de RAM). El principalproblema es el multitasking : LibreOffice Writer funciona de manera decente, pero a laque abrimos el navegador el sistema se vuelve muy lento y resulta tedioso usarlo. Estoprobablemente sea debido a la falta de paralelismo del procesador de la RaspberryPi. Por desgracia, es muy habitual (o incluso necesario) ejecutar varios programas almismo tiempo, por lo que no creo que la Raspberry Pi sea adecuada para sustituirun PC de escritorio en tareas ofimaticas.

Tambien se puede observar que el tiempo de compilacion del kernel de Linux esmuy alto, unas 10 veces mas alto que en los PCs de TxT, de lo cual se deduce queestas maquinas no son adecuadas para cargas de trabajo intensas. No obstante, simiramos el consumo energetico vemos que es aproximadamente 20 veces menor queel de un PC de sobremesa, con lo cual el trabajo realizado por unidad de potenciaes el doble que el de un PC. Es mas, la Raspberry Pi disipa tan poca energıa queni siquiera necesita refrigeracion (no tiene ventiladores ni disipadores, y la caja solo

47

tiene respiracion en la base). Con esto, la Raspberry Pi se convierte en la eleccionperfecta para sistemas que requieran estar encendidas de continuo pero cuya cargade trabajo sea baja, como por ejemplo un servidor domestico o un sustituto de unsistema integrado (embedded).

No obstante, la Raspberry Pi tiene una buena GPU (capaz incluso de reproducirvıdeo de alta resolucion), con lo cual podrıa soportar cargas intensas siempre y cuandosean cargas de GPU, no de CPU. Esto la hace ideal como media center o reproductormultimedia. Tambien se podrıan realizar tareas con alto coste de computo usando laGPU en lugar de la CPU, pero esto probablemente requerira modificar los programaspara que funcionen con la GPU de la Raspberry Pi.

ParamteroBase(Pre)

Base Mod

Disco (GB) 1,5 1,51 2,53Memoria (MB) 112 116 115

Tiempo de arranque del SO (s) 37,81 35,65 52,54Tiempo de arranque de

LibreOffice (s)13,29 16,468 21,945

Tiempo de apertura demany_as.txt (s)

138 145,389 150,274

Velocidad de red (MB/s) 1,13Tiempo de compilacion en serie

(s)2921 2899,735 2864,198

Tiempo de compilacion enparalelo (s)

2934

Consumo energetico (W) 3,5 3,5 3,5

Cuadro 4.7: La columna “Base (Pre)” corresponde a las mediciones realizadas conla version preliminar del benchmark. Las columnas “Base” y “Mod” estan realizadascon la version final del benchmark (primera modalidad), sin prueba de red. Ademas,en estas columnas no se realizo la prueba de medicion de compilacion del kernel con4 threads, ya que se ha visto que, al tener solo 1 CPU y un overhead despreciable,no supone diferencia con respecto a la medicion de compilacion del kernel con 1thread. Las columnas “Base (Pre)” y “Base” corresponden a la distribucion Raspbianpor defecto. La columna “Mod” corresponde a la misma distribucion con paquetesadicionales instalados.

48

Capıtulo 5

Conclusiones

5.1. Conclusiones

En la actividad en la que yo participe (hace mas de 1 ano) se instalaba Ubuntu entodos los PCs, independientemente de sus especificaciones. Actualmente la directivade TxT a la hora de elegir una distribucion es usar Ubuntu si el PC tiene mas de 1GiB de memoria y Lubuntu en caso contrario. Con esta directiva, se elegirıa Lubuntupara los PCs A y B y Ubuntu para el C, aunque he encontrado PCs con Linux Mintinstalado. Segun mi benchmark, la distribucion ideal para cada PC serıa Linux Mintpara el A y el B y Ubuntu para el C. Es obvio que durante el ultimo ano en TxT sehan dado cuenta de la importancia de escoger una distribucion adecuada para cadaPC y han optado por una distribucion mas ligera para los PCs menos potentes. Noobstante, personalmente creo que han dejado un poco de lado la funcionalidad enfavor del rendimiento al escoger Lubuntu frente a Linux Mint. Ademas, la separacionentre ‘mas de un giga’ y ‘un giga o menos’ no es lo suficientemente fina. En unaocasion se encontraron con un PC con 512 MiB de memoria y quisieron instalarleLubuntu, siguiendo su directiva. No obstante, Lubuntu ocupa hasta 480 MiB enreposo, con lo cual el resultado habrıa sido nefasto. Una distribucion como PuppyLinux (∼ 180 MiB) habrıa sido mas acertada.

No obstante cabe destacar que han acertado al escoger la cantidad de memoriacomo parametro discriminante. En las pruebas que he realizado he podido ver queen la mayorıa de los casos la ejecucion del benchmark acababa con los descartesrealizados a raız de la cantidad de memoria.

49

En resumen, la polıtica de TxT en cuanto a que distribucion elegir ha mejoradocon respecto a la actividad que origino mi motivacion para realizar este trabajo,pero aun quedan detalles por pulir. Confıo en que este trabajo ayude a TxT y a sususuarios a conseguir una mejor experiencia.

En cuanto a la Raspberry Pi, su debilidad es la CPU y su fortaleza reside en laGPU. Me parece obvio que los creadores han querido enfocar el aparato mas hacia lareproduccion multimedia que al escritorio. Por suerte, la Raspberry Pi no es el unicoPocket PC del mercado, y hay alternativas que quizas cumplan mejor como sustitutode un PC de sobremesa. Cubieboard [15], por ejemplo, parece ser mas adecuada paraesta tarea: tiene un procesador de 1 GHz (frente a los 700 MHz de la Raspberry Pi),1 GiB de memoria RAM (frente a los 512 MiB de la Raspberry Pi) y soporta masdistribuciones de Linux (Debian, Fedora, Ubuntu, e incluso Android) por un preciomuy similar. El procesador sigue siendo de un solo core y thread. Existen otrasalternativas con procesadores multicore [16], pero tienen un precio mas elevado.

5.2. Trabajo futuro

5.2.1. Comportamientos anomalos

Durante la realizacion de este trabajo me he encontrado con comportamientosque desafıan la logica. Los ejemplos mas claros son el hecho de que Slackware pa-rece funcionar mejor en PCs con menos recursos, a pesar de ser la distribucion quemas recursos usa y que LibreOffice se quede congelado durante un tiempo al ini-ciar en Slackware (la distribucion mas pesada), pero tambien en Puppy Linux (ladistribucion mas ligera) y no en las demas.

Entender el por que de estos fenomenos podrıa ayudar a realizar estimacionesmas precisas y, en general, ayudar en la finalidad de este trabajo, que es seleccionarla distribucion mas acertada para cada PC.

5.2.2. Anadir atributos a medir al benchmark

Siempre cabe la posibilidad de extender el benchmark anadiendo parametros,como podrıan ser el tiempo de abrir una pagina web (para profundizar mas en lagestion de la red) o el framerate medio al reproducir un vıdeo en alta resolucion(para profundizar en el aspecto de computacion grafica). Esto a si vez podrıa llevar ahilar mas fino en el analisis de aplicaciones y funcionalidades. Por ejemplo, teniendoen cuenta el entorno de escritorio y/o el gestor de ventanas explıcitamente.

50

5.2.3. Actualizar y expandir la lista de distribuciones

Durante este trabajo se ha tratado con distribuciones desfasadas, principalmenteporque no estaba seguro de si los PCs de TxT soportarıan el arranque desde DVD.Ahora que he visto que sı lo soportan (la mayorıa, aunque hay outliers que aunleen solo CDs) se podrıa aprovechar para probar con versiones mas actuales de lasdistribuciones escogidas o incluso con distribuciones nuevas que no se hayan tratadoen este trabajo.

5.2.4. Mejorar la estadıstica

Debido a las pocas muestras, la estadıstica en la que se basan las estimacionesde la distribucion live no son muy solidas. Esto podrıa solucionarse tomando masmuestras de mas tipos de PCs (nuevos PCs llegan a TxT continuamente). La distri-bucion live y los scripts ya estan hechos, a modo de prueba de concepto, ahora soloserıa cuestion de ampliar la poblacion de muestras con nuevos PCs.

Ademas, las estimaciones basadas en los resultados de Ubuntu son muy naıve y,aunque funcionan bien en este conjunto de PCs, pueden no ser precisas en PCs conlos que no se haya tratado durante este trabajo.

5.2.5. Probar distintos Pocket PC

Si bien la Raspberry Pi parece no ser la alternativa mas adecuada a un PCde sobremesa, existen otros modelos de Pocket PC mas dirigidos a estas funcionesque podrıa quedar en mejor lugar. Como ya se ha demostrado, el benchmark puedefuncionar perfectamente en dispositivos de este tipo, ası que no serıa difıcil ampliarel trabajo por esta rama.

51

Apendices

52

Apendice A

Resultados de la encuesta

Las columnas “Votos (abs)” y “Votos ( %)” indican el numero de votos que haobtenido la respuesta y el porcentaje de encuestados que la seleccionaron respecti-vamente.

La columna “Valor normalizado” indica la proporcion de votos que correspondena esta respuesta respecto a los votos totales (de todas las respuestas).

Las funcionalidades “soporte para HD-DVD” y “soporte para Blu-Ray” seranignoradas, ya que los PCs con los que se tratara no disponen del hardware necesario.


Pro

cesa

dor

de

texto

s Compatible con documentos deOffice 2010 (.docx)

77 87,50 % 3,56 %

Compatible con documentos deLibreOffice y OpenOffice (.swx)

47 53,41 % 2,17 %

Posibilidad de anadircomentarios a los documentos

45 51,14 % 2,08 %

Crear graficos y dibujos sinnecesidad de una herramienta

externa54 61,36 % 2,50 %

Integracion con una suiteofimatica completa

18 20,45 % 0,83 %

Version para Mac OS X 14 15,91 % 0,65 %

53


Hoja

de

calc

ulo

Corrector ortografico 36 40,91 % 1,67 %Imprimir seleccion (no toda la

pagina)61 69,32 % 2,82 %

Alto numero de celdas (mas de1000 columnas por pagina, 56000filas por pagina, 256 paginas por

libro)

16 18,18 % 0,74 %

Immobilizar paneles (cabecerassiempre visibles)

46 52,27 % 2,13 %

Importar / exportar tablasLaTeX

21 23,86 % 0,97 %

Loca

li. Interfaz en catalan 45 51,14 % 2,08 %

Soporte para escritura dederecha a izquierda

8 9,09 % 0,37 %

Cli

ente

de

corr

eo Filtro anti-phishing (estafa

cibernetica) sin necesidad decomplementos

52 59,09 % 2,41 %

Lector de feeds RSS sinnecesidad de complementos

10 11,36 % 0,46 %

Vista previa de documentos detexto (pdf, doc, xls, odt, ods)

64 72,73 % 2,96 %

Navegad

or Bloqueo de pop-ups sin

necesidad de complementos73 82,95 % 3,38 %

Bloqueo de publicidad (AdBlock)sin necesidad de complementos

75 85,23 % 3,47 %

Control por voz 9 10,23 % 0,42 %Gestos de raton 11 12,50 % 0,51 %

Conversion texto-a-voz(Text-to-speech)

10 11,36 % 0,46 %

Incorpora su propio plugin Flash 47 53,41 % 2,17 %Lector de feeds RSS incorporadosin necesidad de complementos

ni herramientas externas16 18,18 % 0,74 %

Gestor de contrasenas (recordarcontrasenas, contrasena maestra)

69 78,41 % 3,19 %

54


Pro

toco

los

MI

Yahoo! Mail 6 6,82 % 0,28 %Windows Live messenger 22 25,00 % 1,02 %

XMPP (Google talk, Facebookchat)

63 71,59 % 2,92 %

IRC 17 19,32 % 0,79 %Skype 60 68,18 % 2,78 %

MySpaceIM 0 0,00 % 0,00 %

Cliente

MI Emoticonos graficos 51 57,95 % 2,36 %

Emoticonos graficos definidospor el usuario

27 30,68 % 1,25 %

Chat de voz 64 72,73 % 2,96 %Chat de vıdeo 58 65,91 % 2,68 %

Escritura a mano 24 27,27 % 1,11 %Soporte multi-cuenta 54 61,36 % 2,50 %Corrector ortografico 35 39,77 % 1,62 %

Rep

rodu

ctor

de

vıd

eo Soporte para subtıtulos 76 86,36 % 3,52 %

Control de imagen (color,contraste, brillo)

48 54,55 % 2,22 %

Control de sonido (tono) 54 61,36 % 2,50 %Resincronizacion de audio 53 60,23 % 2,45 %

Resincronizacion de subtıtulos 56 63,64 % 2,59 %Soporte para VCD 26 29,55 % 1,20 %

Soporte para SVCD 24 27,27 % 1,11 %Soporte para DVD 62 70,45 % 2,87 %

Soporte para HD-DVD 42 47,73 %Soporte para Blu-Ray 48 54,55 %

Gest

or

de

ar. Miniaturas (Thumbnails) 56 63,64 % 2,59 %

Pestanas 63 71,59 % 2,92 %Doble panel 32 36,36 % 1,48 %

Previsualizaciones 59 67,05 % 2,73 %Navegar por archivos

comprimidos57 64,77 % 2,64 %

Total 88 100,00 % 100,00 %

55

Apendice B

Programas por distribucion

El navegador Iceweasel sera tratado como Firefox, debido a que es practicamenteel mismo (el cambio de nombre es debido a un conflicto de licencias). El mismotratamiento se dara a Icedove / Thunderbird.

Bodhi Linux CrunchBang Debian Linux Mint

Procesador detextos

Ninguno Abiword Ninguno Abiword

Hojas decalculo

Ninguno Gnumeric Ninguno Gnumeric

Cliente decorreo

Ninguno Ninguno Evolution Thunderbird

Navegador Midori IceweaselEpiphany,Iceweasel

Firefox

Cliente de MI Ninguno Ninguno Ninguno PidginReproductor

de vıdeoNinguno VLC Totem

MPlayer,VLC

Gestor dearchivos

EnlightenmentFile Manager

Thunar Nautilus PCManFM

Interfaz encatalan

Parcial Parcial Sı Parcial

Soporte paraescritura dederecha aizquierda

No Sı Sı Sı

56

Puppy LinuxSlackware

KDE XFCE

Procesador detextos

Abiword Calligra Words Ninguno

Hojas decalculo

Gnumeric Calligra Sheets Ninguno

Cliente decorreo

SeaMonkeyKMail,

SeaMonkey,Thunderbird

SeaMonkey,Thunderbird

Navegador SeaMonkeyFirefox,

Konkeror,SeaMonkey

Firefox,SeaMonkey

Cliente de MI Ayttm Kopete, Pidgin Pidgin

Reproductorde vıdeo

MPlayerDragon Player,

KPlayer,MPlayer, xine

MPlayer,xine

Gestor dearchivos

ROX FilerDolphin,Konkeror

Thunar

Interfaz encatalan

Parcial Sı Sı


No Sı Sı

57

Lubuntu Xubuntu Ubuntu

Procesador detextos

Abiword AbiwordLibreOffice

WriterHojas decalculo

Gnumeric NingunoLibreOffice

CalcCliente de

correoSylpheed Thunderbird Thunderbird

Navegador Chromium Firefox FirefoxCliente de MI Pidgin Pidgin EmpathyReproductor

de vıdeoMPlayer Parole Totem

Gestor dearchivos

PCManFM Thunar Nautilus

Interfaz encatalan

Sı Sı Sı


Sı Sı Sı

58

Apendice C

Funcionalidades por programa

Cuadro C.1: Procesador de textos

AbiwordCalligraWords

LibreOfficeWriter

Compatible condocumentos .docx

(Office 2010)No Sı Sı

Compatible condocumentos .swx

(LibreOffice,OpenOffice)

No Sı Sı

Posibilidad de anadircomentarios a los

documentosSı Sı Sı

Crear graficos y dibujossin necesidad de unaherramienta externa

No No Sı

Integracion con unasuite ofimatica

completaNo Sı Sı

Version para Mac OS X Sı Sı Sı

59

Cuadro C.2: Hoja de calculosCalligraSheets

GnumericLibreOffice

Calc

Corrector ortografico Sı No SıImprimir seleccion Sı Sı No

Alto numero de celdas No Sı NoInmobilizar paneles No Sı NoImportar / exportar

tablas LaTeXNo Sı Sı

Cuadro C.3: Cliente de correoKMail SeaMonkey Sylpheed Thunderbird

Filtroanti-phishing

Sı No No Sı

Lector de feedsRSS sin necesidadde complementos

No Sı No Sı

Vista previa dedocumentos

No No No No

Cuadro C.4: Navegador

Chro

miu

m

Dillo

Ep

iphany

Fir

efo

x

Konkero

r

Mid

ori

NetS

urf

SeaM

onkey

Bloqueo popups Sı No No Sı Sı No Sı SıBloqueo publicidad No No No Sı Sı Sı Sı Sı

Control por voz No No No Sı No No No NoGestos de raton No No No No Sı Sı No No

Conversion texto-a-voz (Text-to-speech) No No No No No No No NoSu propia version de Flash Sı No No No No No No No

Lector de feeds RSS incorporado No No No Sı Sı No No SıGestor de contrasenas Sı No Sı Sı Sı No No Sı

60

Cuadro C.5: Protocolos MIAyttm Empathy Kopete Pidgin

Yahoo! Mail Sı No Sı SıWindows Live

MessengerSı Sı Sı Sı

XMPP Sı Sı Sı SıIRC Sı Sı Sı Sı

Skype No No No NoMySpace IM No No No Sı

Cuadro C.6: Cliente MIAyttm Empathy Pidgin

Emoticonos graficos Sı Sı SıEmoticonos graficos

definidos por el usuarioSı Sı Sı

Chat de voz No Sı SıChat de vıdeo No Sı Sı

Escritura a mano No No NoSoporte multi-cuenta Sı Sı SıCorrector ortografico Sı Sı Sı

61

Cuadro C.7: Reproductor de vıdeo

Dra

gon

pla

yer

KP

layer

MP

layer

om

xpla

yer

Paro

le

Tote

m

VL

C

XB

MC

Xin

e

Soporte subtıtulos Sı Sı Sı No Sı Sı Sı Sı SıControl de imagen No Sı Sı No No Sı Sı Sı SıControl de sonido No Sı Sı No No No Sı Sı No

Re-sincronizacion de audio No Sı Sı No No No Sı Sı SıRe-sincronizacion de vıdeo No Sı Sı No No No Sı Sı Sı

Soporte para VCD Sı Sı Sı No Sı Sı Sı Sı SıSoporte para SVCD Sı Sı Sı No Sı Sı Sı Sı Sı

Soporte DVD Sı Sı Sı No Sı Sı Sı Sı SıSoporte para HD-DVD No No No No No No No Sı No

Soporte Blu-ray No No No No No No No Sı No

Cuadro C.8: Gestor de archivos

EF

M

Konkero

r

Nauti

lus

PC

man

FM

RO

XF

iler

Thunar

Miniaturas Sı Sı Sı Sı Sı SıPestanas No Sı Sı Sı No No

Doble panel Sı Sı Sı No No NoPrevisualizaciones No Sı Sı No Sı No

Navegar por archivos comprimidos No Sı No No No No

62

Apendice D

Funcionalidades por distribucion

El protocolo de mensajerıa instantanea “MySpace IM” se ha descartado, ya queno recibio ningun voto y resulta irrelevante.

Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” sehan eliminado debido a que los PCs con los que se tratara no disponen del hardwarenecesario.




63


Funcionalidad

Bod

hi

Lin

ux

Cru

nch

Ban

g

Debia

n

Lin

ux

Min

t

Pu

ppy

Lin

ux

Sla

ckw

are

Lubuntu

Xubuntu

Ubuntu

KD

E

XF

CE

Pro

cesa

dor

de

texto

s Compatible condocumentos .docx

0 0 0 0 0 1 0 0 0 1


0 0 0 0 0 1 0 0 0 1


documentos0 1 0 1 1 1 0 1 1 1

Crear graficos ydibujos

0 0 0 0 0 0 0 0 0 1


completa0 0 0 0 0 1 0 0 0 1

Version para Mac OSX

0 1 0 1 1 1 0 1 1 1

Hoja

de

calc

ulo Corrector ortografico 0 0 0 0 0 1 0 0 0 1

Imprimir seleccion 0 1 0 1 1 1 0 1 0 0Alto numero de

celdas0 1 0 1 1 0 0 1 0 0

Immobilizar paneles 0 1 0 1 1 0 0 1 0 0Importar / exportar

tablas LaTeX0 1 0 1 1 0 0 1 0 1

Loca

liza

. Interfaz en catalan 0,5 0,5 1 0,5 0,5 1 1 1 1 1Soporte para

escritura de derecha aizquierda

0 1 1 1 0 1 1 1 1 1

64

Funcionalidad

Bod

hi

Lin

ux

Cru

nch

Ban

g

Deb

ian

Lin

ux

Min

t

Pup

py

Lin

ux

Sla

ckw

are

Lubuntu

Xubuntu

Ubuntu

KD

E

XF

CE

Corr

eo Filtro anti-phishing 0 0 1 1 0 1 1 0 1 1

Lector de feeds RSS 0 0 1 1 1 1 1 0 1 1Vista previa de

documentos de texto0 0 0 0 0 0 0 0 0 0

Navegador Bloqueo de pop-ups 0 1 1 1 1 1 1 1 1 1

Bloqueo de publicidad 1 1 1 1 1 1 1 0 1 1Control por voz 0 1 1 1 0 1 1 0 1 1Gestos de raton 1 0 0 0 0 1 0 0 0 0

Conversiontexto-a-voz

0 0 0 0 0 0 0 0 0 0

Incorpora su propioplugin Flash

0 0 0 0 0 0 0 1 0 0

Lector de feeds RSS 0 1 1 1 1 1 1 0 1 1Gestor de contrasenas 0 1 1 1 1 1 1 1 1 1

Pro

toco

los

MI Yahoo! Mail 0 0 0 1 1 0 0 1 1 0

Windows Livemessenger

0 0 0 1 1 1 1 1 1 1

XMPP (Google talk,Facebook chat)

0 0 0 1 1 1 1 1 1 1

IRC 0 0 0 1 1 1 1 1 1 1Skype 0 0 0 0 0 0 0 0 0 0

Cli

ente

MI Emoticonos graficos 0 0 0 1 1 1 1 1 1 1

Emoticonos graficosdefinidos por el

usuario0 0 0 1 1 1 1 1 1 1

Chat de voz 0 0 0 1 0 1 1 1 1 1Chat de vıdeo 0 0 0 1 0 1 1 1 1 1

Escritura a mano 0 0 0 0 0 0 0 0 0 0Soporte multi-cuenta 0 0 0 1 1 1 1 1 1 1Corrector ortografico 0 0 0 1 1 1 1 1 1 1

65

Funcionalidad

Bod

hi

Lin

ux

Cru

nch

Ban

g

Deb

ian

Lin

ux

Min

t

Pup

py

Lin

ux

Sla

ckw

are

Lubuntu

Xubuntu

Ubuntu

KD

E

XF

CE

Rep

rod

uct

or

de

vıd

eo Soporte para

subtıtulos0 1 1 1 1 1 1 1 1 1

Control de imagen 0 1 1 1 1 1 1 1 0 1Control de sonido

(tono)0 1 0 1 1 1 0 1 0 0

Resincronizacion deaudio

0 1 0 1 1 1 1 1 0 0

Resincronizacion desubtıtulos

0 1 0 1 1 1 1 1 0 0

Soporte para VCD 0 1 1 1 1 1 1 1 1 1Soporte para SVCD 0 1 1 1 1 1 1 1 1 1Soporte para DVD 0 1 1 1 1 1 1 1 1 1

Gest

or

de

ar.

Miniaturas(Thumbnails)

1 1 1 1 1 1 1 1 1 1

Pestanas 0 0 1 1 0 1 0 1 0 1Doble panel 1 0 1 0 0 1 0 0 0 1

Previsualizaciones 0 0 1 0 1 1 0 0 0 1Navegar por archivos

comprimidos0 0 0 0 0 1 0 0 0 0

Tota


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

Apendice E

Codigo fuente del benchmark(version 1)

E.1. run.sh

Este archivo contiene el orden en el que deben medirse los parametros y otrasinstrucciones necesarias (comprobaciones, pausas, reinicios, etc.).

#!/bin/bash

#In order to measure the boot time , this script must be

executed at boot.

cd ~/ benchmark #files must be located here

params=${*:1}

if hash lsb_release 2> /dev/null; then

output_file=‘lsb_release -is‘

else

output_file="unknown"

fi

output_file="results -$output_file.txt"

if [[ $params == *-h* ]]; then

echo "Usage: $0 [PARAMETERS]"

67

echo "Valid parameters:"

echo " -h : Show this message."

echo " -r : Reboot automatically (may require

permissions)."

echo " -n : Do not measure network speed."

echo " -p : Do not measure power consumption (this

measurement requires user input)."

echo " -i : Install dependencies automatically (

uses commands.sh; may require permissions)."

echo "Results will be written to $output_file."

exit 1

fi

[[ $params == *-n* ]] && n=true;

[[ $params == *-p* ]] && p=true;

[[ $params == *-i* ]] && i=true;

function reboot {

if ! [[ $params == *-r* ]]; then

read -p "Ready to reboot (y/n)? " -n 1 -r

if [[ $REPLY =~ ^[Yy]$ ]]

then

/sbin/reboot || echo "Done. Please , reboot the

system now."

fi

exit 1

fi

/sbin/reboot || echo "Done. Please , reboot the system

now."

}

if [ ! -f state ]; then

echo 1 > state

fi

state=‘cat state‘

function save_state {

if [[ "$1" == "" ]]; then

68

state=‘expr $state + 1‘

else

state=$1

fi

echo $state > state

}

function check_install {

if [ $i ]; then

source ./ install_cmd.sh

if [[ "$1" == "/usr/bin/time" ]]; then

install_cmd time

else

install_cmd $1

fi

fi

while ! hash $1 2> /dev/null; do

read -p "Please , install $1 now and press Enter

when finished."

done

}

if [ $state -le 4 ]; then

echo "Phase $state of 4"

echo "------------"

fi

case $state in

1 )

check_install "/usr/bin/time"

echo "There will now be a 60 second pause."

if ! [ $p ]; then

echo "User input will be needed at the end of

the pause." #in order to measure power

consumption

fi

sleep 60

69

./ benchmark.sh MEMORY DISK > $output_file

# memory_disk_discard

check_install bc

if ! [ $p ]; then

./ benchmark.sh POWER >> $output_file

fi

check_install make

check_install gcc

echo "Compiling the Linux kernel. This may take a

while."

./ benchmark.sh KERNEL1 >> $output_file

save_state

reboot

;;

2 )

./ benchmark.sh BOOT >> $output_file


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)


sleep 60

./ benchmark.sh LO_STARTUP >> $output_file

save_state

reboot

;;

4)


sleep 60

echo "Opening a big file. This may take a while."

./ benchmark.sh LO_FILE_STARTUP >> $output_file

echo "Benchmark finished."

save_state

# estimate

# ./ statistics.sh

;;

esac

71

E.2. benchmark.sh

Este archivo contiene el codigo capaz de medir los parametros por separado.

#!/bin/bash

#tests:

#BOOT: boot time

#DISK: disk usage

#MEMORY: memory usage

#NETWORK: network speed

#KERNEL1: time to compile a Linux kernel , using 1 thread

#KERNEL4: time to compila a Linux kernel , using 4 threads

#LO_STARTUP: time to start LibreOffice

#LO_FILE_STARTUP: time to open a (big) file in LibreOffice

tests=${*:1}

cd ~/ benchmark

#configuration

#file to download in the network test

URL="http :// speedtest.wdc01.softlayer.com/downloads/

test500.zip"

#file to use in the lo_file test

perl -e ’print "a"x1000000; print "\n"’ > many_as.txt

LO_FILE="many_as.txt"

#auxiliary functions

function round {

rounded=‘echo "($1+0.5)/1" | bc‘

echo $rounded

}

function lobench {

delay=1

rm -rf /tmp/*.tmp

lowriter ${*:1} >/dev/null 2>&1 &

while [ "$pid" == "" ]; do

pid=‘pidof soffice.bin‘

72

done

iddle="0"

while [ "$iddle" == "0" ]; do

cpu_usage=‘top -bn 2 -p $pid -d $delay | tail -n 2

|grep -v M‘

cpu_usage=‘echo $cpu_usage | cut -f9 -d’ ’ | sed s

/,/./‘

iddle=‘echo "$cpu_usage == 0" | bc‘

done

kill $pid

}

function get_time {

cmd=${*:1}

time=‘{ time $cmd >/dev/null 2>&1 ; } 2>&1 | grep real

| cut -f2 | sed s/h/*3600+/ | sed s/m/*60+/ | sed

s/s// | bc‘

echo $time

}

function compile {

THREADS=$1

if [ "$THREADS" == "" ]; then

THREADS=1

fi

cd $KERNEL_FOLDER > /dev/null

make alldefconfig -j $THREADS > /dev/null

KERNEL_TIME=‘get_time make bzImage -j $THREADS ‘

make distclean -j $THREADS > /dev/null

cd - > /dev/null

echo KERNEL$THREADS $KERNEL_TIME seconds

}

#startup time

#Assuming the script is run at startup. You should remove

any possible delays at startup (grub timeout , login

screens ...).

if [[ $tests == *BOOT* ]]; then

73

BOOT_TIME=‘cat /proc/uptime | awk ’{print $1}’‘

echo BOOT $BOOT_TIME seconds

fi

#memory

if [[ $tests == *MEMORY* ]]; then

MEMORY=‘free -m |sed -n 2p | awk ’{print $3}’‘

echo MEMORY $MEMORY MB

fi

#disk

if [[ $tests == *DISK* ]];then

DISK=‘df | grep rootfs ‘

if [[ "$DISK" != "" ]]; then

#Raspberry Pi

DISK=‘df -m | grep rootfs | awk ’{print $3}’‘

DISK=$(echo "scale=2;${DISK} / 1024" | bc)

else

#DISK=‘df -m | sed -n 2p | awk ’{print $3}’‘

DISK=‘df -m | grep sda | awk ’{print $3}’‘

DISK=‘echo $DISK | sed ’s/ /+/g’ | bc‘

DISK=$(echo "scale=2;(${DISK} - 71) / 1024" | bc)

# 71 MiB is the size of the benchmark files

fi

echo DISK $DISK GB

fi

#network

if [[ $tests == *NETWORK* ]]; then

NETWORK=‘wget -O /dev/null $URL 2>&1 | grep ’$[0-9]\+

[KM]B/s$’ | cut -f3 ,4 -d ’ ’ | sed ’s/(//’ | sed

’s/)//’ | sed ’s/B\/s//’ | sed ’s/K/*1024/ ’ | sed ’

s/M/*1024*1024/ ’‘

NETWORK=‘echo $NETWORK / 1024 | bc‘

echo NETWORK $NETWORK KB/s

fi

#kernel compilation

74

if [[ $tests == *KERNEL* ]]; then

KERNEL_FILE=‘ls linux-[0-9]*.[0-9]*.[0-9]*.tar.xz‘

KERNEL_FOLDER=‘echo $KERNEL_FILE | sed ’s/.tar.xz//’‘

tar -xf $KERNEL_FILE --xz

fi

#compile using 1 thread

if [[ $tests == *KERNEL1* ]]; then

compile

fi

#compile using 4 threads

if [[ $tests == *KERNEL4* ]]; then

compile 4

fi

if [[ $tests == *KERNEL* ]]; then

rm -rf $KERNEL_FOLDER

fi

#libreoffice

if [[ $tests == *LO_STARTUP* ]]; then

LO_TIME=‘get_time lobench ‘

echo LO_STARTUP $LO_TIME seconds

fi

if [[ $tests == *LO_FILE_STARTUP* ]]; then

LO_FILE_TIME=‘get_time lobench $LO_FILE ‘

echo LO_FILE_STARTUP $LO_FILE_TIME seconds

fi

#power

if [[ $tests == *POWER* ]]; then

echo -n "Please , enter the power consumption of the

system (in Watts): "

while [[ "$power" == "" ]]; do

read power

75

power=‘echo $power | sed s/,/./‘

if ! [[ $power =~ ^[0-9]+([.][0-9]+)?$ ]]; then

echo Please , enter only a number.

power=""

fi

done

echo POWER $power W

fi

76

E.3. statistics.sh

Este script toma los archivos resultantes de correr el benchmark en las distin-tas distribuciones, calcula cuantos requisitos cumple cada distribucion y ordena lasdistribuciones en orden de adecuacion.

#!/bin/bash

x=$0

[[ ${*:1} == *-n* ]] && n=true

[[ ${*:1} == *-p* ]] && p=true

while (( "$#" )); do

if [[ "$1" == "-h" ]]; then

echo "Usage:"

echo " $x [-d TOTAL_DISK] [-m TOTAL_MEMORY] [-n

] [-p]"

echo " $x -h"

echo ""

echo "-d TOTAL_DISK : Specify the size of the disk

(in GiB , not counting swap)."

echo "-m TOTAL_MEMORY : Specify the size of the

memory (in MiB)."

echo "-n : Ignore network speed tests. "

echo "-p : Ignore power consumption tests. "

echo "-h : Show this message."

exit 1

elif [[ "$1" == "-d" ]]; then

shift

total_disk=‘echo $1 | sed s/,/./g‘

if ! [[ $total_disk =~ ^[0-9]+([.][0-9]+)?$ ]];

then

echo "Disk size must be a number."

exit 1

fi

elif [[ "$1" == "-m" ]]; then

shift

total_memory=‘echo $1 | sed s/,/./g‘

77

if ! [[ $total_memory =~ ^[0-9]+([.][0-9]+)?$ ]];

then

echo "Memory size must be a number."

exit 1

fi

fi

shift

done

filenames=(results -*.txt)

n=${#filenames[@]}

for filename in ${filenames[@]}; do

memory+=(‘grep MEMORY $filename | cut -d’ ’ -f2‘)

disk+=(‘grep DISK $filename | cut -d’ ’ -f2‘)

boot_time+=(‘grep BOOT $filename | cut -d’ ’ -f2‘)

lo_startup+=(‘grep LO_STARTUP $filename | cut -d’ ’ -

f2‘)

lo_file_startup+=(‘grep LO_FILE_STARTUP $filename |

cut -d’ ’ -f2‘)

kernel1+=(‘grep KERNEL1 $filename | cut -d’ ’ -f2‘)

kernel4+=(‘grep KERNEL4 $filename | cut -d’ ’ -f2‘)

network+=(‘grep POWER $filename | cut -d’ ’ -f2‘)

if ! [ $n ]; then

network+=(‘grep POWER $filename | cut -d’ ’ -f2‘)

fi

if ! [ $p ]; then

power+=(‘grep POWER $filename | cut -d’ ’ -f2‘)

fi

done

avg_boot_time=‘echo "scale=2; (0 $(printf "+ %s" "${

boot_time[@]}") ) / $n" | bc‘

avg_lo_startup=‘echo "scale=3; (0 $(printf "+ %s" "${

lo_startup[@]}") ) / $n" | bc‘

avg_lo_file_startup=‘echo "scale=3; (0 $(printf "+ %s" "${

lo_file_startup[@]}") ) / $n" | bc‘

78

avg_kernel1=‘echo "scale=3; (0 $(printf "+ %s" "${kernel1[@

]}") ) / $n" | bc‘

avg_kernel4=‘echo "scale=3; (0 $(printf "+ %s" "${kernel4[@

]}") ) / $n" | bc‘

if ! [ $n ]; then

avg_network=‘echo "scale=3; (0 $(printf "+ %s" "${

network[@]}") ) / $n" | bc‘

fi

if ! [ $p ]; then

avg_power=‘echo "scale=1; (0 $(printf "+ %s" "${power[@

]}") ) / $n" | bc‘

fi

[[ "$total_disk" == "" ]] && total_disk=‘df -m | grep sda

| awk ’BEGIN {ORS="+";} {print $2}’‘ && total_disk=‘

echo "scale=2; ($total_disk 0)/1024" | bc‘

[[ "$total_memory" == "" ]] && total_memory=‘free -m | sed

-n 2p | awk ’{print $2}’‘

for (( i=0; i < $n; ++i)); do

filenames[$i]=‘echo ${filenames[$i]} | sed s/results -

// | sed s/.txt//‘

done

results=()

for (( i=0; i < $n; ++i )); do

fails[$i]=‘echo "${disk[$i]} > $total_disk /2" | bc‘

fails[$i]=‘expr ${fails[$i]} + $(echo "${memory[$i]} >

$total_memory /2" | bc)‘

fails[$i]=‘expr ${fails[$i]} + $(echo "${boot_time[$i]

} > $avg_boot_time*1.1" | bc)‘

fails[$i]=‘expr ${fails[$i]} + $(echo "${lo_startup[$i

]} > $avg_lo_startup*1.1" | bc)‘

fails[$i]=‘expr ${fails[$i]} + $(echo "${

lo_file_startup[$i]} > $avg_lo_file_startup*1.1" |

bc)‘

79

fails[$i]=‘expr ${fails[$i]} + $(echo "${kernel1[$i]}

> $avg_kernel1*1.1" | bc)‘

fails[$i]=‘expr ${fails[$i]} + $(echo "${kernel4[$i]}

> $avg_kernel4*1.1" | bc)‘

if ! [ $n ]; then

fails[$i]=‘expr ${fails[$i]} + $(echo "${network[$

i]}*1.1 < $avg_network" | bc)‘

fi

if ! [ $p ]; then

fails[$i]=‘expr ${fails[$i]} + $(echo "${power[$i]

} > $avg_power*1.1" | bc)‘

fi

results+=("${fails[$i]} flaw(s): ${filenames[$i]}")

done

readarray -t sorted < <(for a in "${results[@]}"; do echo

"$a"; done | sort)

for (( i=0; i < $n; ++i )); do

echo ${sorted[$i]}

done

80

Apendice F

Pruebas de rendimiento en PCs deTxT

F.1. PC A

Procesador: Pentium 4 @ 3, 20 GHz (Hyperthreading)


ParamteroLinuxMint

PuppyLinux

Slackware(KDE)

Lubuntu Ubuntu

Disco (GB) 2,48 0,67 6,67 1,84 2,37Memoria (MB) 477 183 684 480 670

Tiempo de arranque del SO(s)

31,99 21,06 74,34 26,86 25,20

Tiempo de arranque deLibreOffice (s)

4,591 7,811 5,700 6,156 5,631


74,111 118,034 73,021 74,909 72,019

Tiempo de compilacion enserie (s)

420,378 360,252 528,270 389,047 366,772


296,251 301,140 350,220 320,031 299,772

Consumo energetico (W) 72,5 73,0 73,0 73,0 73,0

81

F.2. PC B

Procesador: Pentium D @ 3,00 GHz (Dual core)


ParamteroLinuxMint

PuppyLinux

Slackware(KDE)

Lubuntu Ubuntu



34,22 29,12 78,65 33,76 27,33


5,554 7,492 12,826 5,121 5,313


72,186 116,605 116,925 72,321 70,280


357,118 358,394 424,427 386,490 362,490


190,793 191,345 228,274 203,620 190,887


82

F.3. PC C (Core 2 Duo)

Procesador: Core 2 Duo 3,13 GHz (Dual core)

Memoria: 2 × 1 GB

ParamteroLinuxMint

PuppyLinux

Slackware(KDE)

Lubuntu Ubuntu



20,39 24,92 78,93 21,17 24,31


5,630 6,076 9,134 5,455 5,002


73,113 115,364 126,590 72,735 69,822


239,780 243,958 292,331 258,470 239,966


127,990 133,732 158,848 143,930 133,058


83

Apendice G


El archivo benchmark.sh es exactamente el mismo (aunque las funciones paramedir la velocidad de red y el consumo electrico no se usaran). Idem con el archivostatistics.sh. El archivo run.sh tambien es igual, con la excepcion de que se des-comentan las funciones memory_discard y estimation. A continuacion se muestrala implementacion de dichas funciones.

84

G.1. memory disk discard

Esta funcion intenta determinar la distribucion ideal en base a la cantidad dememoria y disco usados y las totales disponibles. En caso de que se pueda determinarla distribucion ganadora con solo estos datos, el benchmark no continuara.

function memory_disk_discard {

total_memory=‘free -m | sed -n 2p | awk ’{print $2}’‘

memory_usage=‘grep MEMORY $output_file | cut -d’ ’ -f2

‘

# in MiB , not GiB

total_disk=‘df -m | grep sda | awk ’{print $3}’‘

total_disk=‘echo $total_disk | sed ’s/ /+/g’ | bc‘

disk_usage=‘df -m | grep sda | awk ’{print $4}’‘

disk_usage=‘echo $disk_usage | sed ’s/ /+/g’ | bc‘

if [[ $memory_usage -gt $((total_memory /2)) ]] || [[ $

disk_usage -gt $total_disk ]]; then

if [[ $((memory_usage -180)) -le $((total_memory /2)

) ]] && [[ $((disk_usage+90)) -le $((total_disk

/2)) ]]; then

echo "Due to memory and / or disk limitations ,

the best option is Linux Mint."

else

echo "Due to memory and / or disk limitations ,

the best option is Puppy Linux."

fi

save_state 5

exit 0

fi

}

85

G.2. estimation

Esta funcion decide que distribucion es la ideal una vez se han realizado todaslas mediciones para una de las distribuciones.

function estimation {

MEMORY_USAGE=‘grep MEMORY_USAGE results -ubuntu.txt |

cut -d -f2‘

DISK_USAGE=‘grep DISK_USAGE results -ubuntu.txt | cut -

d -f2‘

BOOT=‘grep BOOT results -ubuntu.txt | cut -d’ ’ -f2‘

DISK_USAGE=‘grep DISK_USAGE results -ubuntu.txt | cut -

d’ ’ -f2‘

MEMORY_USAGE=‘grep MEMORY_USAGE results -ubuntu.txt |

cut -d’ ’ -f2‘

KERNEL1=‘grep KERNEL1 results -ubuntu.txt | cut -d’ ’ -

f2‘

# KERNEL4=‘grep KERNEL4 results -ubuntu.txt | cut -d’ ’ -

f2‘

LO_STARTUP=‘grep LO_STARTUP results -ubuntu.txt | cut -

d’ ’ -f2‘

LO_FILE_STARTUP=‘grep LO_FILE_STARTUP results -ubuntu.

txt | cut -d’ ’ -f2‘

#estimate Slackware ’s performance

echo MEMORY_USAGE $((MEMORY_USAGE + 73)) > results -

slackware.txt

echo DISK_USAGE $((DISK_USAGE + 4403)) >> results -

slackware.txt

BOOT_SLACKWARE=‘echo "scale=2; ${BOOT} + 51.69" | bc‘

echo BOOT $BOOT_SLACKWARE >> results -slackware.txt


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


slackware.txt

BOOT_MINT=‘echo "scale=2; ${BOOT} + 3.25" | bc‘

echo BOOT $BOOT_MINT >> results -mint.txt

echo DISK_USAGE $((DISK_USAGE + 367)) >> results -mint.

txt

echo MEMORY_USAGE $((MEMORY_USAGE + -180)) >> results -

mint.txt

KERNEL1_MINT=‘echo "scale=2; ${KERNEL1} + 16.21" | bc‘

echo KERNEL1 $KERNEL1_MINT >> results -mint.txt

# KERNEL4_MINT=‘echo "scale=2; ${KERNEL4} + " | bc‘

# echo KERNEL4 $KERNEL4_MINT >> results -mint.txt

echo LO_STARTUP $LO_STARTUP >> results -mint.txt

LO_FILE_STARTUP_MINT=‘echo "scale=2; ${LO_FILE_STARTUP

} + 2.43" | bc‘

echo LO_FILE_STARTUP $LO_FILE_STARTUP_MINT >> results -

mint.txt

}

87

Apendice H

Estimaciones en base a ladistribucion live

Los parametros calculados (columnas) son los siguientes:

r: Coeficiente de correlacion de Pearson. Si r es cercana a 1, indica una fuerte co-rrelacion lineal directa; si es cercana a -1 indica una fuerte correlacion linealinversa; si es cercana a 0, indica que no existe correlacion lineal.

StdErr: Error estandar de r.

Test hipo.: Test de hipotesis de r. Es igual al error estandar de r × t de studentpara el intervalo de confianza del 80 % y n− 2 grados de libertad (= 3,08).

Sign.: Indica si la correlacion entre la variable y el tiempo de arranque es estadısti-camente significativa. Es decir, si r >el test de hipotesis de r.

Las variables observadas son las siguientes:

Tiempo de arranque del SO: Valor medido por el benchmark (Ubuntu).

Tiempo de arranque de LO: Tiempo de arranque de LibreOffice Writer. Valormedido por el benchmark (Ubuntu).

Tiempo de arranque de many as: Tiempo de arranque de LibreOffice Writer abrien-do un archivo grande. Valor medido por el benchmark (Ubuntu).

Ancho de banda del disco: Ancho de banda de lectura del disco.

Latencia: Tiempo que se tarda en leer un byte del disco.

88

Compilacion (1 thread): Tiempo que tarda el sistema en compilar un programade referencia usando solo 1 thread.

Compilacion (4 threads): Tiempo que tarda el sistema en compilar un programade referencia usando 4 threads.

Lectura RAM: tramo 1: Ancho de banda de lectura de la memoria para archivosde tamano menor a 32 kiB.

Lectura RAM: tramo 2: Ancho de banda de lectura de la memoria para archivosde tamano entre 32 kiB y 256 kiB.

Lectura RAM: tramo 3: Ancho de banda de lectura de la memoria para archivosde tamano entre 256 kiB y 1 MiB.

Lectura RAM: tramo 4: Ancho de banda de lectura de la memoria para archivosde tamano mayor a 2 MiB.

89

Cuadro H.1: Correlacion entre el tiempo de arranque del SO y distintas variables.

PC A PC B PC C r StdErrTesthipo.

Sign.


25,20 27,33 24,31

Ancho de banda del disco(MB/s)

58,1 42,6 62,7 -1,00 0,07 0,22 Sı

Latencia (ms) 16,9465 21,5512 23,6888 -0,08 1,00 3,07 NoCompilacion (1 thread) (s) 141,983 148,85 107,143 0,82 0,57 1,74 NoCompilacion (4 threads) (s) 105,713 79,778 57,85 0,24 0,97 2,99 No

Lectura RAM: tramo 1(GB/s)

46 43 32 0,57 0,82 2,52 No


26 24 16 0,58 0,81 2,50 No


20 19 16 0,54 0,84 2,59 No


5 4 5 -0,96 0,29 0,88 Sı

90

Cuadro H.2: Correlacion entre el tiempo de arranque de LibreOffice Writer y distintas variables.


Sign.

Tiempo de arranque de LO(s)

5,631 5,313 5,002


58,1 42,6 62,7 -0,21 0,98 3,01 No

Latencia (ms) 16,9465 21,5512 23,6888 -0,98 0,20 0,62 SıCompilacion (1 thread) (s) 141,983 148,85 107,143 0,77 0,63 1,95 NoCompilacion (4 threads) (s) 105,713 79,778 57,85 1,00 0,04 0,13 Sı


46 43 32 0,95 0,32 0,98 No


26 24 16 0,94 0,33 1,03 No


20 19 16 0,96 0,28 0,87 Sı


5 4 5 0,01 1,00 3,08 No

91

Cuadro H.3: Correlacion entre el tiempo de arranque de LibreOffice Writer abriendo un archivo grande ydistintas variables.


Sign.

Tiempo de arranque demany as (s)

72,019 70,280 69,822


58,1 42,6 62,7 0,10 0,99 3,06 No

Latencia (ms) 16,9465 21,5512 23,6888 -0,99 0,12 0,36 SıCompilacion (1 thread) (s) 141,983 148,85 107,143 0,54 0,84 2,59 NoCompilacion (4 threads) (s) 105,713 79,778 57,85 0,96 0,27 0,84 Sı


46 43 32 0,80 0,60 1,85 No


26 24 16 0,79 0,61 1,88 No


20 19 16 0,82 0,57 1,75 No


5 4 5 0,32 0,95 2,92 No

92

Cuadro H.4: Correlacion entre el tiempo de el tiempo de compilacion del kernel de Linux con un solo thready distintas variables.


Sign.

Tiempo de compilacion (s) 366,200 362,490 239,366Ancho de banda del disco

(MB/s)58,1 42,6 62,7 -0,66 0,75 2,32 No

Latencia (ms) 16,9465 21,5512 23,6888 -0,76 0,65 2,00 NoCompilacion (1 thread) (s) 141,983 148,85 107,143 0,98 0,18 0,55 SıCompilacion (4 threads) (s) 105,713 79,778 57,85 0,85 0,52 1,60 No


46 43 32 0,98 0,18 0,55 Sı


26 24 16 0,99 0,16 0,50 Sı


20 19 16 0,98 0,22 0,66 Sı


5 4 5 -0,48 0,88 2,70 No

93

Apendice I

Ecuaciones para estimar elrendimiento

I.1. Ubuntu



+32, 10

Tiempo de arranque de LibreOffice Writer = Latencia del disco × 0, 02

+Tiempo de compilacion (4 threads) × 0, 02

+3, 48

Tiempo de apertura de un archivo grande = Latencia del disco ×−0, 58

+Tiempo de compilacion (4 threads) ×−0, 04

+85, 52

Tiempo compilacion del kernel (1 thread) = Tiempo de compilacion con 1 thread × 1, 57


+ − 44, 03

Tiempo compilacion del kernel (4 thread2 ) = Tiempo de compilacion con 4 threads × 0, 74

+Latencia del disco ×−19, 50

+552, 35

94

I.2. Slackware

Tiempo de arranque = Ancho de banda del disco × 1

+Ancho de banda de la memoria (tramo 4) ×−0, 77

+115,25



+ − 163, 73

Tiempo de apertura de un archivo grande = Latencia del disco × 15, 70


+ − 308, 61

Tiempo compilacion del kernel (1 thread) = Tiempo de compilacion con 1 thread ×−4,11


+129, 36



+540, 18

I.3. Linux Mint



+ − 5, 78



+ − 6, 56

95

Tiempo de apertura de un archivo grande = Latencia del disco ×−1, 46

+Tiempo de compilacion (4 threads) ×−0, 18

+118, 44

Tiempo compilacion del kernel (1 thread) = Tiempo de compilacion con 1 thread ×−1, 97


+53, 54



+404, 05

96

Apendice J


El archivo statistics.sh es igual que el de la primera modalidad de benchmark(incluyendo la opcion de la compilacion del kernel con 4 threads), pero sin las opcionesde velocidad de red y consumo electrico.

J.1. run.sh

Este archivo contiene el orden en el que deben medirse los parametros y otrasinstrucciones necesarias (comprobaciones, pausas, reinicios, etc.). Es completamentedisinto al de las modalidades de benchmark anteriores.

#!/bin/bash

cd ~/ benchmark #files must be located here

params=${*:1}

source memory_disk_discard.sh

source estimation.sh

temp_file=temp-results.txt


#sleep 60

memory_disk_discard

97

[ ! -f memory_bandwidth.txt ] && echo "Measuring memory

bandwidth. This may take a while." && ./ benchmark.sh

MEMORY_BW2 MEMORY_BW4 > $temp_file

echo "Measuring disk bandwidth. This may take a while."

./ benchmark.sh DISK_BW DISK_LAT >> $temp_file

./ benchmark.sh COMPILE1 COMPILE4 >> $temp_file

DISK_BW=‘grep DISK_BW $temp_file | cut -d’ ’ -f2 | sed s

/,/./‘

MEMORY_BW2=‘grep MEMORY_BW2 $temp_file | cut -d’ ’ -f2 |

sed s/,/./‘

MEMORY_BW4=‘grep MEMORY_BW4 $temp_file | cut -d’ ’ -f2 |

sed s/,/./‘

DISK_LAT=‘grep DISK_LAT $temp_file | cut -d’ ’ -f2 | sed s

/,/./‘

COMPILE1=‘grep COMPILE1 $temp_file | cut -d’ ’ -f2 | sed s

/,/./‘

COMPILE4=‘grep COMPILE4 $temp_file | cut -d’ ’ -f2 | sed s

/,/./‘

estimation

./ statistics.sh

98

J.2. benchmark.sh

Este archivo contiene el codigo capaz de medir los parametros por separado. Escompletamente distinto al de las modalidades de benchmark anteriores. Mide losparametros que se usaran para realizar las estimaciones (ancho de banda del disco,la latencia, etc).

#!/bin/bash

#tests:

#DISK_BW: disk bandwidth

#DISK_LAT: disk latency

#MEMORY_BW1: memory bandwidth (1st segment)

#MEMORY_BW2: memory bandwidth (2nd segment)

#MEMORY_BW3: memory bandwidth (3rd segment)

#MEMORY_BW4: memory bandwidth (4th segment)

#COMPILE1: time to compile a program , using 1 thread

#COMPILE4: time to compila a program , using 4 threads

tests=${*:1}

cd ~/ benchmark

MEMORY_BW_FILE=memory_bandwidth.txt

#auxiliary functions

function round {

rounded=‘echo "($1+0.5)/1" | bc‘

echo $rounded

}

function get_time {

cmd=${*:1}

time=‘{ time $cmd >/dev/null 2>&1 ; } 2>&1 | grep real

| cut -f2 | sed s/h/*3600+/ | sed s/m/*60+/ | sed

s/s// | bc‘

echo $time

}

function compile {

99

THREADS=$1

if [ "$THREADS" == "" ]; then

THREADS=1

fi

cd $COMPILE_FOLDER > /dev/null

./ configure > /dev/null

COMPILE_TIME=‘get_time make -j $THREADS ‘

make clean -j $THREADS > /dev/null

cd - > /dev/null

echo COMPILE$THREADS $COMPILE_TIME seconds

}

function drop_caches {

sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"



}

#memory_bw

if [[ $tests == *MEMORY_BW* ]]; then

sudo /home/user/bandwidth -0.32p/bandwidth32 --quick >

$MEMORY_BW_FILE

fi

if [[ $tests == *MEMORY_BW1* ]]; then

MEMORY_BW1=‘grep "Sequential read (128-bit), size = 16

kB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘

MEMORY_BW1=‘echo "scale=2;${MEMORY_BW1} / 1024" | bc‘

echo MEMORY_BW1 $MEMORY_BW1 MB/s

fi


MEMORY_BW2=‘grep "Sequential read (128-bit), size =

128 kB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘



fi


100


512 kB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘



fi



2.5 MB" $MEMORY_BW_FILE | cut -d’ ’ -f11‘



fi

#disk_bw

if [[ $tests == *DISK_LAT* ]];then

drop_caches

DISK_LAT=‘sudo dd if=/dev/sda1 of=/dev/null count=1 2>

&1 | tail -n1 | cut -d’ ’ -f 6‘

TEMP=‘echo $DISK_LAT | grep e‘

if [[ ! $TEMP ]]; then

echo DISK_LAT 0

else

echo DISK_LAT $DISK_LAT s

fi

fi

if [[ $tests == *DISK_BW* ]];then

drop_caches

DISK_BW_TMP=‘sudo dd if=/dev/sda1 of=/dev/null count=3

M 2>&1 | tail -n1‘

DISK_BW=‘echo $DISK_BW_TMP | cut -d’ ’ -f8‘

DISK_BW_UNIT=‘echo $DISK_BW_TMP | cut -d’ ’ -f9‘

if [ "$DISK_BW_UNIT" == "GB/s" ]; then

DISK_BW=‘echo "scale=2;${DISK_BW} * 1024" | bc‘

fi

echo DISK_BW $DISK_BW MB/s

fi

#compilation

if [[ $tests == *COMPILE* ]]; then

101

COMPILE_FILE=‘ls papi*.tar.gz‘

COMPILE_FOLDER=‘echo $COMPILE_FILE/src | sed ’s/.tar.

gz//’‘

tar -xzf $COMPILE_FILE

fi

#compile using 1 thread

if [[ $tests == *COMPILE1* ]]; then

compile

fi

#compile using 4 threads

if [[ $tests == *COMPILE4* ]]; then

compile 4

fi

if [[ $tests == *COMPILE* ]]; then

COMPILE_FOLDER=‘echo $COMPILE_FILE | sed ’s/.tar.gz//’

‘

rm -rf $COMPILE_FOLDER

fi

102

J.3. estimation

En esta funcion radica la estadıstica que estima el rendimiento de las distribucio-nes.

function estimations {

#estimate Ubuntu ’s performance

BOOT=‘echo "scale=2;${DISK_BW} * -0.19 + ${MEMORY_BW4}

* 0.87 + 32.10" | bc‘

LO_STARTUP=‘echo "scale=2;${DISK_LAT} * 0.02 + ${

COMPILE4} * 0.02 + 3.48" | bc‘

LO_FILE_STARTUP=‘echo "scale=2;${DISK_LAT} * -0.58 + $

{COMPILE4} * -0.04 + 85.52" | bc‘

KERNEL1=‘echo "scale=2;${COMPILE1} * 1.57 + ${

MEMORY_BW2} * 7.23 - 44.03" | bc‘

KERNEL4=‘echo "scale=2;${COMPILE4} * 0.74 + ${DISK_LAT

} * -19.50 + 552.35" | bc‘

echo "BOOT_TIME $BOOT" > results -ubuntu.txt

echo "LO_STARTUP $LO_STARTUP" >> results -ubuntu.txt

echo "LO_FILE_STARTUP $LO_FILE_STARTUP" >> results -

ubuntu.txt

echo "KERNEL1 $KERNEL1" >> results -ubuntu.txt

echo "KERNEL4 $KERNEL4" >> results -ubuntu.txt

#estimate Slackware ’s performance

BOOT_SLACKWARE=‘echo "scale=2;${DISK_BW} + ${

MEMORY_BW4} * -0.77 + 115.25" | bc‘

LO_STARTUP_SLACKWARE=‘echo "scale=2;${DISK_LAT} * 5.56

+ ${COMPILE4} * 0.71 - 163.73" | bc‘

LO_FILE_STARTUP_SLACKWARE=‘echo "scale=2;${DISK_LAT} *

15.70 + ${COMPILE4} * 1.09 - 308.61" | bc‘

KERNEL1_SLACKWARE=‘echo "scale=2;${COMPILE1} * -4.11 +

${MEMORY_BW2} * 37.80 + 129.26" | bc‘

KERNEL4_SLACKWARE=‘echo "scale=2;${COMPILE4} * 1.29 +

${DISK_LAT} * -19.24 + 540.18" | bc‘

echo "BOOT_TIME $BOOT_SLACKWARE" > results -slackware.

txt

103

echo "LO_STARTUP $LO_STARTUP_SLACKWARE" >> results -

slackware.txt

echo "LO_FILE_STARTUP $LO_FILE_STARTUP_SLACKWARE" >>

results -slackware.txt

echo "KERNEL1 $KERNEL1_SLACKWARE" >> results -slackware

.txt

echo "KERNEL4 $KERNEL4_SLACKWARE" >> results -slackware

.txt

#estimate Linux Mint ’s performance

BOOT_MINT=‘echo "scale=2;${DISK_BW} * -2.52 + ${

MEMORY_BW4} * 36.86 - 5.78" | bc‘

LO_STARTUP_MINT=‘echo "scale=2;${DISK_LAT} * 0.42 + ${

COMPILE4} * 0.04 - 6.56" | bc‘

LO_FILE_STARTUP_MINT=‘echo "scale=2;${DISK_LAT} * -

1.46 + ${COMPILE4} * -0.18 + 118.44" | bc‘

KERNEL1_MINT=‘echo "scale=2;${COMPILE1} * -1.97 + ${

MEMORY_BW2} * 24.87 + 53.54" | bc‘

KERNEL4_MINT=‘echo "scale=2;${COMPILE4} * 1.39 + ${

DISK_LAT} * -15.06 + 404.05" | bc‘

echo "BOOT_TIME $BOOT_MINT" > results -mint.txt

echo "LO_STARTUP $LO_STARTUP_MINT" >> results -mint.txt

echo "LO_FILE_STARTUP $LO_FILE_STARTUP_MINT" >>

results -mint.txt

echo "KERNEL1 $KERNEL1_MINT" >> results -mint.txt

echo "KERNEL4 $KERNEL4_MINT" >> results -mint.txt

}

104

Apendice K

Funcionalidades de Raspbian

El protocolo de mensajerıa instantanea “MySpace IM” se ha descartado, ya queno recibio ningun voto y resulta irrelevante.

Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” sehan eliminado debido a que la Raspberry Pi no dispone del hardware necesario.




105


Funcionalidad

Base

Mod

Pote

nci

al

Pro

cesa

dor

de

texto

s Compatible condocumentos .docx

0 1 1


0 1 1


documentos0 1 1

Crear graficos ydibujos

0 1 1


completa0 1 1

Version para Mac OSX

0 1 1

Ho

jade

calc

ulo Corrector ortografico 0 1 1

Imprimir seleccion 0 1 1Alto numero de

celdas0 1 1

Immobilizar paneles 0 1 1Importar / exportar

tablas LaTeX0 1 1

Loca

liza

. Interfaz en catalan 1 1 1Soporte para

escritura de derecha aizquierda

0 1 1

106

Funcionalidad

Base

Mod

Pote

nci

al

Corr

eo Filtro anti-phishing 0 1 1

Lector de feeds RSS 0 1 1Vista previa de

documentos de texto0 0 0

Navegador Bloqueo de pop-ups 0 1 1

Bloqueo de publicidad 1 1 1Control por voz 0 1 1Gestos de raton 1 1 1

Conversiontexto-a-voz

0 0 0

Incorpora su propioplugin Flash

0 1 1

Lector de feeds RSS 0 1 1Gestor de contrasenas 0 1 1

Pro

toco

los

MI Yahoo! Mail 0 1 1

Windows Livemessenger

0 1 1

XMPP (Google talk,Facebook chat)

0 1 1

IRC 0 1 1Skype 0 0 0

Cliente

MI Emoticonos graficos 0 1 1

Emoticonos graficosdefinidos por el

usuario0 1 1

Chat de voz 0 1 1Chat de vıdeo 0 1 1

Escritura a mano 0 0 0Soporte multi-cuenta 0 1 1Corrector ortografico 0 1 1

107

Funcionalidad

Base

Mod

Pote

nci

al

Repro

duct

or

de

vıd

eo Soporte para

subtıtulos0 1 1

Control de imagen 0 1 1Control de sonido

(tono)0 1 1

Resincronizacion deaudio

0 1 1

Resincronizacion desubtıtulos

0 1 1

Soporte para VCD 0 0 1Soporte para SVCD 0 0 1Soporte para DVD 0 0 1

Gest

or

de

ar.

Miniaturas(Thumbnails)

1 1 1

Pestanas 0 1 1Doble panel 1 1 1

Previsualizaciones 0 1 1Navegar por archivos

comprimidos0 0 0

Tota


3 24 25


10,00 80,00 83,33


10,57 84,21 89,62

108

Bibliografıa

[1] Jack Wallen. Linux distribution choice flow chart. http://cdn.ghacks.net/

wp-content/uploads/2010/01/choosing_linux.jpg

[2] Terminos de licencia de Windows 7 Ultimate. https://www.microsoft.com/latam/socios/OEM/Licenciamiento/licencias.aspx

[3] Nicholas Hatt, Axis Sivitz and Benjamin A. Kuperman. “Benchmarking Ope-rating Systems”, 2007.

[4] John L. Gustafson and Quinn O. Snell. HINT: A New Way To Measure Com-puter Performance. Proceedings of the 28th Annual Hawaii International Con-ference on Systems Sciences, IEEE Computer Society Press, 1995.

[5] Uwe F. Mayer. Linux/Unix nbench. http://www.tux.org/~mayer/linux/

bmark.html

[6] BYTE magazine (currently defunct). Snapshot available at http://www.tux.

org/~mayer/linux/byte/bdoc.pdf (thanks to Mayer, Uwe F.)

[7] Kaj Gronholm. GTK+ toolkit on mobile Linux devices. Master thesis.

[8] Don Capps. IOzone Filesystem Benchmark. http://www.iozone.org/, 2008.

[9] R. Jones. “Netperf: A network performance benchmark, version 2.1”, 1995.

[10] Phoronix test suite. http://www.phoronix-test-suite.com/

[11] Zack Smith. Bandwidth: a memory bandwidth benchmark. http://zsmith.co/bandwidth.html

[12] PAPI (Performance Application Programming Interface) http://icl.cs.utk.edu/papi/index.html

109

http://cdn.ghacks.net/wp-content/uploads/2010/01/choosing_linux.jpg

http://cdn.ghacks.net/wp-content/uploads/2010/01/choosing_linux.jpg

https://www.microsoft.com/latam/socios/OEM/Licenciamiento/licencias.aspx

https://www.microsoft.com/latam/socios/OEM/Licenciamiento/licencias.aspx

http://www.tux.org/~mayer/linux/bmark.html

http://www.tux.org/~mayer/linux/bmark.html

http://www.tux.org/~mayer/linux/byte/bdoc.pdf

http://www.tux.org/~mayer/linux/byte/bdoc.pdf

http://www.iozone.org/

http://www.phoronix-test-suite.com/

http://zsmith.co/bandwidth.html

http://zsmith.co/bandwidth.html

http://icl.cs.utk.edu/papi/index.html

http://icl.cs.utk.edu/papi/index.html

[13] Renatas Kizys, Angel A. Juan. Modelo de regresion Lineal Multiple http://

www.uoc.edu/in3/emath/docs/T01_Reg_Lineal_Multiple.pdf

[14] Minitab, software estadıstico. http://www.minitab.com/

[15] Cubieboard, a small, high-performance arm box. http://cubieboard.org/

[16] Wandboard, ultra low power complete computer with high performance multi-media capabilities. http://www.wandboard.org/

110

http://www.uoc.edu/in3/emath/docs/T01_Reg_Lineal_Multiple.pdf

http://www.uoc.edu/in3/emath/docs/T01_Reg_Lineal_Multiple.pdf

http://www.minitab.com/

http://cubieboard.org/

http://www.wandboard.org/

E. Código fuente del benchmark

Documents

Transcript of E. Código fuente del benchmark