Download - Karma Linux

PROYECTO FIN DE CARRERA

INGENIERIA TECNICA EN INFORMATICA DE SISTEMAS

Karma Linux 2008

Distribucion de Linux para la Evaluacion de Rendimiento enSistemas Computacionales Modernos

AutorFernando Garcıa Aranda

DirectoresEzequiel Herruzo Gomez

Jose Ignacio Benavides Benıtez

ESCUELA POLITECNICA SUPERIOR

UNIVERSIDAD DE CORDOBA

Junio - 2008

D. Ezequiel Herruzo Gomez, Profesor Colaborador de Primer Niveldel Area de Arquitectura y Tecnologıa de Computadores del Departamentode Arquitectura de Computadores, Electronica y Tecnologıa Electronica dela Universidad de Cordoba.

D. Jose Ignacio Benavides Benıtez, Catedratico de EscuelasUniversitarias del Area de Arquitectura y Tecnologıa de Computadores delDepartamento de Arquitectura de Computadores, Electronica y TecnologıaElectronica de la Universidad de Cordoba.

Informan:

Que el proyecto de fin de carrera de Ingenierıa Tecnica en Informaticade Sistemas titulado ((Distribucion de Linux para la Evaluacion deRendimiento en Sistemas Computacionales Modernos)) ha sidorealizado bajo su direccion por Fernando Garcıa Aranda en la EscuelaPolitecnica Superior de la Universidad de Cordoba, reuniendo, a su juicio,las condiciones exigidas a este tipo de trabajos.

Y para que conste, firman el presente informe en Cordoba a 10 de juliode 2008.

Los directores:

D. Ezequiel Herruzo Gomez D. J. Ignacio Benavides Benıtez

Copyright c© 2008 Fernando Garcıa, Ezequiel Herruzo, J. Ignacio Benavides

Se otorga permiso para copiar, distribuir y/o modificar este docu-mento bajo los terminos de la Licencia de Documentacion Libre de GNU,Version 1.2 o cualquier otra version posterior publicada por la Free SoftwareFoundation; sin Secciones Invariantes ni Textos de Cubierta Delanterani Textos de Cubierta Trasera. Una copia de la licencia esta incluida enla seccion titulada “GNU Free Documentation License” del Apendice deLicencias.

Karma Linux 2008

Distribucion de Linux para la Evaluacion de Rendimiento enSistemas Computacionales Modernos

AutorFernando Garcıa Aranda

DirectoresEzequiel Herruzo Gomez

Jose Ignacio Benavides Benıtez

Indice general

1. Introduccion 11.1. Eventos del Procesador . . . . . . . . . . . . . . . . . . . . . 2

1.1.1. Perfctr y Performance API . . . . . . . . . . . . . . . 31.1.2. Ruidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Sistemas Operativos en Tiempo Real . . . . . . . . . . . . . . 41.2.1. Planificacion de tareas . . . . . . . . . . . . . . . . . . 41.2.2. Manejo de Interrupciones . . . . . . . . . . . . . . . . 51.2.3. Comunicacion y Sincronizacion . . . . . . . . . . . . . 61.2.4. Gestion de la memoria . . . . . . . . . . . . . . . . . . 6

2. Definicion del Problema 92.1. Identificacion del Problema Real . . . . . . . . . . . . . . . . 92.2. Identificacion del Problema Tecnico . . . . . . . . . . . . . . 10

2.2.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 102.2.2. Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3. Vida Esperada . . . . . . . . . . . . . . . . . . . . . . 122.2.4. Ciclo de Mantenimiento . . . . . . . . . . . . . . . . . 122.2.5. Competencia . . . . . . . . . . . . . . . . . . . . . . . 132.2.6. Aspecto Externo . . . . . . . . . . . . . . . . . . . . . 132.2.7. Estandarizacion . . . . . . . . . . . . . . . . . . . . . . 132.2.8. Calidad y Fiabilidad . . . . . . . . . . . . . . . . . . . 142.2.9. Programa de Tareas . . . . . . . . . . . . . . . . . . . 142.2.10. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.11. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1. Adaptacion de Karma a Procesadores Multinucleo . . 162.3.2. Mejora de la Usabilidad . . . . . . . . . . . . . . . . . 162.3.3. Autonomıa de la Plataforma . . . . . . . . . . . . . . 17

2.4. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.1. Antecedentes a Lperfex y Glperfex . . . . . . . . . . . 182.4.2. Antecedentes de Planificadores en Tiempo Real . . . . 192.4.3. Antecedentes de la Distribucion . . . . . . . . . . . . . 192.4.4. Antecedentes a Sistemas de Benchmarking . . . . . . . 19

iii

iv INDICE GENERAL

2.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.1. Factores Dato . . . . . . . . . . . . . . . . . . . . . . . 212.5.2. Factores Estrategicos . . . . . . . . . . . . . . . . . . . 21

2.6. Recursos para el Desarrollo . . . . . . . . . . . . . . . . . . . 232.6.1. Recursos Humanos . . . . . . . . . . . . . . . . . . . . 232.6.2. Recursos Hardware . . . . . . . . . . . . . . . . . . . . 242.6.3. Recursos Software . . . . . . . . . . . . . . . . . . . . 24

2.7. Recursos para la Ejecucion . . . . . . . . . . . . . . . . . . . 252.7.1. Recursos Humanos . . . . . . . . . . . . . . . . . . . . 262.7.2. Recursos Hardware . . . . . . . . . . . . . . . . . . . . 262.7.3. Recursos Software . . . . . . . . . . . . . . . . . . . . 26

3. Analisis del Sistema 273.1. Identificacion de Requisitos . . . . . . . . . . . . . . . . . . . 273.2. Modelado Estatico . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . 293.2.2. Analisis de Clases del Sistema . . . . . . . . . . . . . . 32

3.3. Modelado Dinamico . . . . . . . . . . . . . . . . . . . . . . . 343.3.1. Diagramas de Secuencia . . . . . . . . . . . . . . . . . 34

3.4. Descripcion de la Informacion . . . . . . . . . . . . . . . . . . 383.4.1. El Formato CSV . . . . . . . . . . . . . . . . . . . . . 393.4.2. Nuestro Uso de CSV . . . . . . . . . . . . . . . . . . . 40

3.5. Requisitos de la Interfaz . . . . . . . . . . . . . . . . . . . . . 413.6. Descripcion y Especificaciones del Resto del Sistema . . . . . 43

3.6.1. Planificacion de Procesos . . . . . . . . . . . . . . . . 433.6.2. Descripcion de Componentes . . . . . . . . . . . . . . 453.6.3. Requisitos Funcionales . . . . . . . . . . . . . . . . . . 543.6.4. Requisitos No Funcionales . . . . . . . . . . . . . . . . 56

4. Diseno del Sistema 594.1. Diseno del Entorno de Ejecucion . . . . . . . . . . . . . . . . 59

4.1.1. Compilacion y Preparacion del Kernel . . . . . . . . . 604.1.2. Creacion del Entorno en Tiempo Real . . . . . . . . . 614.1.3. Creacion del Entorno de Medicion de Eventos . . . . . 624.1.4. Integracion del Sistema de Medicion en el kernel de

Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.2. Diseno de la Aplicacion . . . . . . . . . . . . . . . . . . . . . 63

4.2.1. Clase MainFrame . . . . . . . . . . . . . . . . . . . . . 634.2.2. Clase Configuration . . . . . . . . . . . . . . . . . . . 644.2.3. Clase Counters . . . . . . . . . . . . . . . . . . . . . . 654.2.4. Clase CheckListCtrl . . . . . . . . . . . . . . . . . . . 664.2.5. Clase Results . . . . . . . . . . . . . . . . . . . . . . . 664.2.6. Clase ResultsPanel . . . . . . . . . . . . . . . . . . . . 674.2.7. Clase IOInterface . . . . . . . . . . . . . . . . . . . . . 68

INDICE GENERAL v

4.3. Diseno de la Interfaz . . . . . . . . . . . . . . . . . . . . . . . 694.3.1. Generar Medicion . . . . . . . . . . . . . . . . . . . . 694.3.2. Cargar Resultado . . . . . . . . . . . . . . . . . . . . . 72

4.4. Diseno del Sistema Autonomo . . . . . . . . . . . . . . . . . . 734.4.1. Instalacion de Live Helper . . . . . . . . . . . . . . . . 744.4.2. Configuracion del Live CD Basico . . . . . . . . . . . 744.4.3. Anadiendo Funcionalidades al Live CD Basico . . . . 754.4.4. El entorno chroot . . . . . . . . . . . . . . . . . . . . . 774.4.5. Cerrando el Live CD . . . . . . . . . . . . . . . . . . . 78

5. Pruebas 795.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2. Pruebas de Unidad . . . . . . . . . . . . . . . . . . . . . . . . 80

5.2.1. Pruebas de Casos de Uso . . . . . . . . . . . . . . . . 805.2.2. Pruebas de Escenarios de la Aplicacion . . . . . . . . 82

5.3. Pruebas de la Aplicacion . . . . . . . . . . . . . . . . . . . . . 845.3.1. Procedimiento Seguido . . . . . . . . . . . . . . . . . . 845.3.2. Ejecucion de los Casos de Prueba de la Aplicacion . . 85

5.4. Pruebas de Rendimiento de la Aplicacion . . . . . . . . . . . 875.4.1. Pruebas No Exclusivas Sin Ruido . . . . . . . . . . . . 885.4.2. Pruebas No Exclusivas Con Ruido . . . . . . . . . . . 895.4.3. Pruebas Bajo el Entorno Exclusivo . . . . . . . . . . . 89

6. Conclusiones y Futuras Mejoras 936.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.1.1. Conclusiones personales . . . . . . . . . . . . . . . . . 946.2. Futuras mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Bibliografıa 97

A. Manual de Usuario 101A.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

A.1.1. Requisitos del Sistema Completo . . . . . . . . . . . . 102A.1.2. Requisitos de Glperfex . . . . . . . . . . . . . . . . . . 102

A.2. Instalacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103A.2.1. Instalacion de Karma Linux 2008 . . . . . . . . . . . . 103A.2.2. Instalacion de la Aplicacion . . . . . . . . . . . . . . . 105

A.3. Uso de la Aplicacion . . . . . . . . . . . . . . . . . . . . . . . 106A.3.1. Abrir Glperfex . . . . . . . . . . . . . . . . . . . . . . 106A.3.2. Generar Medicion con Planificador Estandar . . . . . 106A.3.3. Generar Medicion Exclusiva . . . . . . . . . . . . . . . 110A.3.4. Guardar Resultados de una Medicion . . . . . . . . . 111A.3.5. Guardar Grafica de una Medicion . . . . . . . . . . . . 111A.3.6. Cargar una Medicion Previa . . . . . . . . . . . . . . . 112

vi INDICE GENERAL

A.4. Ayuda y Licencia . . . . . . . . . . . . . . . . . . . . . . . . . 113

B. Manual de Codigo 115B.1. Referencia de la Clase glperfex::MainFrame . . . . . . . . . . 116

B.1.1. Descripcion detallada . . . . . . . . . . . . . . . . . . 117B.1.2. Documentacion de las funciones miembro . . . . . . . 117

B.2. Referencia de la Clase configuracion::Configuration . . . . . . 124B.2.1. Descripcion detallada . . . . . . . . . . . . . . . . . . 125B.2.2. Documentacion de las funciones miembro . . . . . . . 125

B.3. Referencia de la Clase contadores::Counters . . . . . . . . . . 130B.3.1. Descripcion detallada . . . . . . . . . . . . . . . . . . 131B.3.2. Documentacion de las funciones miembro . . . . . . . 132

B.4. Referencia de la Clase contadores::CheckListCtrl . . . . . . . 135B.4.1. Descripcion detallada . . . . . . . . . . . . . . . . . . 136B.4.2. Documentacion de las funciones miembro . . . . . . . 137

B.5. Referencia de la Clase resultados::Results . . . . . . . . . . . 137B.5.1. Descripcion detallada . . . . . . . . . . . . . . . . . . 138B.5.2. Documentacion de las funciones miembro . . . . . . . 139

B.6. Referencia de la Clase resultados::ResultsPanel . . . . . . . . 144B.6.1. Descripcion detallada . . . . . . . . . . . . . . . . . . 144B.6.2. Documentacion de las funciones miembro . . . . . . . 145

B.7. Referencia de la Clase io::IOInterface . . . . . . . . . . . . . . 149B.7.1. Descripcion detallada . . . . . . . . . . . . . . . . . . 150B.7.2. Documentacion de las funciones miembro . . . . . . . 150

C. Licencias 161C.1. GNU General Public License . . . . . . . . . . . . . . . . . . 163C.2. GNU Free Documentation License . . . . . . . . . . . . . . . 178

Indice de figuras

3.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . 293.2. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . 323.3. Diagrama de Secuencia: Generar Medicion . . . . . . . . . . . 353.4. Diagrama de Secuencia: Cargar Medicion . . . . . . . . . . . 383.5. Ejemplo de Fichero CSV: Una medicion . . . . . . . . . . . . 413.6. Ejemplo de Fichero CSV: Tres mediciones . . . . . . . . . . . 423.7. Cuantos de tiempo en el planificador de Linux . . . . . . . . . 443.8. Estructura de Componentes de Karma GNU/Linux . . . . . . 453.9. Posicionamiento de ADEOS en el sistema operativo . . . . . 463.10. Composicion RTAI y Linux . . . . . . . . . . . . . . . . . . . 483.11. Arquitectura del sistema PAPI . . . . . . . . . . . . . . . . . 53

4.1. Glperfex: ventana principal . . . . . . . . . . . . . . . . . . . 704.2. Glperfex: pestana de contadores . . . . . . . . . . . . . . . . . 714.3. Glperfex: pestana de resultados con siete ejecuciones . . . . . 724.4. Glperfex: pestana de resultados con una ejecucion . . . . . . 734.5. Glperfex: opciones del menu archivo . . . . . . . . . . . . . . 744.6. Glperfex: abriendo una prueba . . . . . . . . . . . . . . . . . 754.7. Glperfex: resultados cargados de un fichero CSV . . . . . . . 76

A.1. Manual de Usuario: abrir glperfex . . . . . . . . . . . . . . . . 106A.2. Manual de Usuario: Medicion con Planificador Estandar . . . 107A.3. Manual de Usuario: Medicion con Planificador Estandar . . . 108A.4. Manual de Usuario: Medicion con Planificador Estandar 1 . . 111A.5. Manual de Usuario: Resultados con Planificador Estandar 2 . 112A.6. Manual de Usuario: Ejecucion en Modo Exclusivo . . . . . . . 113A.7. Manual de Usuario: Menu Archivo . . . . . . . . . . . . . . . 114

vii

Indice de cuadros

3.1. Plantilla para la Definicion de Casos de Uso . . . . . . . . . . 303.2. Ejemplo de Fichero CSV resultado de una medicion . . . . . 403.3. Ejemplo de Fichero CSV resultado de tres mediciones . . . . 40

4.1. Configuracion del Entorno en Tiempo Real . . . . . . . . . . 614.2. Configuracion de perfctr dentro del kernel de Linux . . . . . . 624.3. Configuracion previa del kernel del Live CD . . . . . . . . . . 76

5.1. Resultados de las mediciones estandar sin ruido . . . . . . . . 885.2. Resultados obtenidos para las pruebas estandar con ruido . . 905.3. Resultados de las mediciones bajo entorno exclusivo . . . . . 91

A.1. Manual de Usuario: caracterısticas validas de un ejecutable . 107

ix

Capıtulo 1

Introduccion

En ciertas ocasiones, la ejecucion de programas se ve condicionada porla necesidad de una respuesta instantanea. Un ejemplo de ello puede encon-trarse en programas que supervisan la dinamica de un sistema fısico, comoel control de inyeccion de combustible de un motor, que debe realizar lamezcla en un intervalo de tiempo determinado. A este tipo de computacionse le denomina computacion en tiempo real.

Karma Linux es una distribucion de GNU/Linux en tiempo real disenadapara la medicion de eventos de procesador. En nuestro caso, las exigenciasde tiempo real vienen dadas por la necesidad de ejecutar programas en unprocesador de manera que la medicion de su ejecucion se vea condicionadapor la menor cantidad posible de ruido, es decir, que el proceso lanzadopueda ejecutarse de forma exclusiva sobre el procesador, obteniendo ası elmayor rendimiento.

En los ultimos anos, los objetivos en el diseno de procesadores ha cam-biado radicalmente. La busqueda de la maxima frecuencia, del mayor rendi-miento para un solo procesador se ha visto desbordada por el viejo conceptode la computacion paralela, estamos en la era de los multicore.

La primera version de Karma Linux fue desarrollada en septiembrede 2006 como proyecto fin de carrera del alumno de Ingenierıa Tecnicaen Informatica de Sistemas Pedro Navajas Modelo [1] bajo la direccionde Ezequiel Herruzo Gomez, profesor del Departamento de Arquitecturade Computadores, Electronica y Tecnologıa Electronica. Esta primeraversion estaba disenada para la ejecucion en sistemas monoprocesadorde la arquitectura x86, lo que implicaba que los programas ejecutadosen Karma no pudieran aprovechar la capacidad de todas las tecnologıasemergentes en paralelizacion de carga de procesador. Ejemplos de estastecnologıas podemos encontrar en HyperThreading de Intel (que simula dos

1

2 1.1. Eventos del Procesador

procesadores logicos dentro de un unico procesador fısico, lo que supone unamejora en el uso del procesador de un 30 % [3]) implementado en algunosmodelos de Pentium IV o en los casi ultimos procesadores de Intel, los DualCore y Core 2 Duo. Por este motivo surgio la motivacion de realizar unanueva version de Karma, que pudiese lograr ejecuciones optimas en estosultimos procesadores, haciendo hincapie tambien en un diseno intuitivo de laaplicacion, de manera que pudiera ser utilizada facilmente con fines docentes.

A continuacion vamos a realizar un enfoque de los conceptos necesariospara abordar la tarea. En el primer parrafo se definıa a Karma Linux comouna distribucion en tiempo real para la medicion de eventos de procesa-dor. Por ello, en la introduccion al proyecto es necesario definir estos dosconceptos que confluyen e introducir ası al lector de lleno en la tematicadel mismo, de manera que la lectura de los subsiguientes capıtulos sea lomas sencilla posible. En primer lugar haremos un enfoque sobre los even-tos del procesador, para mostrar como se miden estos eventos a traves decontadores hardware que proporcionan los procesadores, y en segundo lugarrealizaremos una introduccion a los sistemas operativos en tiempo real y losconceptos fundamentales para la comprension de los mismos.

1.1. Eventos del Procesador

Los eventos del procesador son todas las operaciones atomicas produci-das dentro del mismo. Nos referimos con atomicas a las operaciones que aldividirse pierden su condicion. Por ejemplo, una instruccion de procesadores divisible, pero cada una de sus divisiones no forman una instruccion.

Dichos eventos estan asociados a uno o varios recursos hardware (de-pendiendo de la arquitectura y modelo de procesador) y nos serviran paraobtener informacion acerca de la ejecucion de procesos y su rendimiento.

Los contadores de monitorizacion de rendimiento (Performance Monito-ring Counters o PMC) son contadores hardware incluıdos en la mayorıa deprocesadores existentes en el mercado. Estos contadores registran un grannumero de eventos relacionados con el rendimiento de una aplicacion duran-te la ejecucion, por ejemplo, el numero de instrucciones ejecutadas, fallos decache o cualquier evento propio de la familia del procesador. El objetivo delos PMCs es identificar problemas de rendimiento a bajo nivel, de maneraque sea posible solucionar futuros problemas en la puesta en marcha de pro-yectos sensibles a la optimizacion del uso del dispositivo sobre el que seranejecutados.

Introduccion 3

1.1.1. Perfctr y Performance API

Linux Performance-Monitoring Counters Driver (Perfctr) es una biblio-teca desarrollada por Mikael Pettersson, profesor del Departamento de Tec-nologıas de la Informacion de la Universidad de Uppsala, que modifica elkernel de Linux para permitir el acceso a los contadores hardware de lamaquina. El acceso a estos contadores se realiza a traves de un conjunto dePMCs virtuales accesibles desde el dispositivo /dev/perfctr, de esta ma-nera cada proceso pueda obtener, a traves de una llamada al sistema, losresutados de la medicion de su ejecucion.

La Performance Application Programming Interface (PAPI) es un pro-yecto desarrollado por el Departamento de Ingenierıa Electrica y Cienciasde la Computacion de la Universidad de Tennessee que trata de especificaruna interfaz de programacion estandar para el acceso a los contadores hard-ware del procesador a traves del driver perfctr. Provee dos interfaces, una dealto nivel y facil uso, y otra completamente programable a bajo nivel paranecesidades mas especıficas.

PAPI presenta una gran portabilidad, un codigo escrito usando PAPIdebe medir los mismos eventos en distintas plataforma sin la necesidad derealizar ningun cambio. Por otro lado para el acceso a contadores especıficosde una maquina simplemente habra que utilizar la interfaz de bajo nivelanteriormente mencionada.

1.1.2. Ruidos

La mayorıa de sistemas operativos modernos de proposito general com-parten una caracterıstica fundamental, permiten la planificacion multitarea.Esto supone la necesidad de ejecucion de procesos sobre uno o varios proce-sadores al mismo tiempo, por lo que el sistema operativo necesita crear unaconcurrencia virtual entre dichos procesos, de forma que puedan convivir enel mismo entorno de forma transparente al usuario.

El procedimiento que se sigue para conseguir el objetivo de la multitarease basa en la asignacion de prioridades a los diferentes procesos, segun lacual el planificador del sistema crea una cola en la que de cada proceso activose ejecutara un cuanto1 de determinado tamano (influido por la prioridadel proceso). Para evitar atascos en la ejecucion de tareas, el planificadorcontempla mecanismos de reemplazo, segun los cuales un proceso de mayorprioridad puede reemplazar la ejecucion de uno de menor prioridad.

De acuerdo con las caracterısticas del planificador del kernel de Linux,1Tiempo que el proceso puede ejecutarse sin ser reemplazado.

4 1.2. Sistemas Operativos en Tiempo Real

si un proceso requiere 20000 ms de tiempo de procesador para llevar a cabosu ejecucion completa, dependiendo del uso y de la prioridad, el planificadorlo dividira en cuantos de aproximadamente 100 ms y lo trasladara a la colajunto al resto de procesos activos.

Cuando entre en competicion un proceso de mayor prioridad, es pro-bable que este reemplace a nuestro proceso aunque estuviera activo en esemomento de acuerdo con la capacidad de reemplazo del planificador.

Esta caracterıstica de los sistemas operativos de proposito general difi-culta enormemente la capacidad de medir el tiempo que tarda el procesoen ejecutarse. Dependiendo de la carga del sistema, nuestro proceso, que re-querıa 20000 ms, puede llegar a durar hasta mas de 100000 ms, consumiendoun mayor numero de ciclos, provocando mas fallos en memoria cache, etc.Esta intrusion de codigo de otros procesos es el concepto que de ahora enadelante llamaremos ruido, ya que provoca interferencias en la medicion deeventos imposibles de predecir.

1.2. Sistemas Operativos en Tiempo Real

Para comprender la diferencia en la ejecucion exclusiva de Karma Li-nux con las ejecuciones estandar de Linux debemos diferenciar los SistemasOperativos en tiempo real de los Sistemas Operativos convencionales. Unamanera muy intuitiva de hacer esto es describir las caracterısticas de im-portancia que debe cumplir un Sistema Operativo y comentar las diferentesmaneras de enfocarlas de los RTOS2 y los Sistemas Operativos de PropositoGeneral. Estas caracterısticas principales son: planificacion de tareas, ma-nejo de interrupciones, sincronizacion y comunicacion y la gestion de lamemoria.

1.2.1. Planificacion de tareas

La planificacion de tareas o hilos es el principal problema de un sistemaoperativo. Mientras el sistema esta en funcionamiento deben crearse y eli-minarse tareas, estas pueden cambiar su nivel de prioridad, necesidades dememoria, etc. En un sistema en tiempo real, estas tareas son mas peligrosasque en un sistema operativo de proposito general: si se crea una tarea entiempo real, debe obtener la memoria que requiera reservar sin demoras.Dicha memoria debera ser almacenada de manera que no se produzcan re-

2Real Time Operating Systems, Sistemas Operativos en Tiempo Real

Introduccion 5

trasos debidos a swapping3, por lo que los datos deberıan ser almacenadosen memoria principal. Ademas, cambiar la prioridad en la ejecucion de unproceso influirıa al comportamiento de toda la ejecucion del sistema, y eldeterminismo del mismo, que es una caracterıstica de gran importancia enun Sistema Operativo en Tiempo Real. Por ello la planificacion de tareas esuno de los principales rompecabezas en los RTOS.

Normalmente, sobre un sistema multitarea, existen multiples tareas acti-vas al mismo tiempo, y el sistema operativo es responsable de suministrar demanera compartida los recursos disponibles, es decir, tiempo de CPU, me-moria, etc. A la decision del sistema operativo sobre la manera de compartirlos procesadores se le denomina planificacion.

Para la planificacion existen una serie de algoritmos, valorados en funcionde su eficiencia y simpleza, su optimalidad. En los Sistemas Operativos enTiempo Real se tiende a utilizar algoritmos de planificacion simples, ya quese necesita un tiempo de computacion pequeno y determinıstico, debemosapostar por soluciones que se consuman la menor cantidad de memoria.

En los Sistemas Operativos de proposito general, la polıtica de planifi-cacion difiere en gran medida, se tienen en cuenta los mismos principios, sinembargo en estos sistemas se pretende obtener un rendimiento optimo envalores medios, mientras que en los RTOS se requiere un comportamientodeterminista.

1.2.2. Manejo de Interrupciones

Un sistema operativo debe ser capaz, ademas de capaz de planificartareas de acuerdo con un algoritmo determinista, de proporcionar acceso adispositivos perifericos como motores, sensores, contadores de tiempo, discosexternos, etc. Esto requiere una atencion del sistema operativo de maneraasıncrona, cuando el proceso en ejecucion requiere esos servicios, el sistemaoperativo debe comprobar que esta listo para complacer los requerimientos,estas llamadas al sistema se denominan interrupciones. Existen dos tipos deinterrupciones:

Interrupciones de hardware El periferico pone un bit en un canal par-ticular, que comunica al procesador en el cual se ejecuta el sistemaoperativo que necesita ser servido. Como resultado de esto, el proce-

3Se denomina swapping al modo de interrelacionar la memoria principal (que contieneel programa en ejecucion, proceso inmediato y resultados intermedios) con la secunda-ria, ampliando ası la capacidad de la memoria principal basandose en la capacidad delalmacenamiento secundario.

6 1.2. Sistemas Operativos en Tiempo Real

sador almacena el estado actual y salta a la direccion en su espacio dememoria que ha sido conectada a la inicializacion de la interrupcion.

Interrupciones de software Muchos procesadores disponen de instruc-ciones equivalentes a las interrupciones de hardware generadas porsoftware. El resultado tambien hace que se salte a una direccion dememoria especificada previamente.

El sistema operativo no se involucra en principio en la ejecucion de elcodigo que genera la interrupcion del hardware, de esto se encarga el proce-sador sin que se vea interferido por ningun software. Sin embargo, el sistemaoperativo tiene influencia, primero, en la conexion de la direccion de memo-ria con cada lınea de interrupcion y segundo en los momentos posteriores ala interrupcion. En los Sistemas Operativos en Tiempo Real, logicamente, sedebe proceder a un manejo de las interrupciones de manera que se garanticeque las tareas son servidas de manera determinista.

1.2.3. Comunicacion y Sincronizacion

La tercera responsabilidad de un sistema operativo es conocida como co-municacion entre procesos (Inter-Process Communication o IPC). La IPCcomprende una extensa cantidad de primitivas de programacion que el sis-tema operativo ofrece para la necesidad de intercambio de informacion conotras tareas y/o la sincronizacion en sus acciones. En los RTOS, debe obte-nerse una comunicacion y sincronizacion de manera determinista.

Hay que recordar que la comunicacion y sincronizacion con otras tareasno se limita simplemente a aquellas que son ejecutadas en la misma maqui-na, sino que pueden aplicase tambien a la necesidad de comunicacion entreperifericos o dispositivos en red.

1.2.4. Gestion de la memoria

La cuarta responsabilidad de un sistema operativo es la gestion de me-moria.

Los diferentes procesos en el sistema requieren una parte de la memoriadisponible. En ocasiones, esta memoria debe estar almacenada en unadireccion especıfica. Por lo tanto, el trabajo del sistema operativo es dar acada proceso la memoria que necesita, memory allocation, realizar el mapeode memoria real en los diferentes rangos de direcciones usadas por las tareasque requieren la memoria, memory mapping, y realizar la accion apropiada

Introduccion 7

cuando una tarea utiliza memoria que no ha sido reservada4. A esto se lellama tambien proteccion de memoria, que en ocasiones suele solucionarsesimplemente matando el proceso que ha pedido el acceso no autorizado.

Una vez introducidos los conceptos necesarios para comprender los di-ferentes conceptos en los que se basa la definicion, diseno y solucion delproyecto, podemos comenzar el proceso de desarrollo del mismo.

El estudio de dichos conceptos en las diferentes asignaturas que compo-nen el plan de estudios de la titulacion de Ingeniero Tecnico en Informaticade Sistemas no cumple con los requisitos adecuados para la comprension delmismo. Por ello, hemos considerado necesaria una introduccion profunda enla materia, de manera que el alumno, o cualquier lector interesado en re-tomar el proyecto o simplemente estudiarlo, pueda inmiscuirse en el mismodesde el comienzo, con una curva de aprendizaje pronunciada al inicio peromas suave a medida que se avanza en la lectura.

4Causas comunes de esto son punteros no conectados, o utilizacion de valores fuera deun array reservado.

Capıtulo 2

Definicion del Problema

2.1. Identificacion del Problema Real

La informacion acerca del rendimiento es crucial en el desarrollo de cual-quier proyecto software. Los recursos informaticos reales no son infinitos,y este problema se convierte en excesivamente crıtico si estamos tratandocon sistemas empotrados y en definitiva toda clase de sistemas en tiemporeal, donde la optimizacion de codigo debe enfocarse hacia el objetivo deuna ejecucion rapida que realice el menor numero de ciclos de procesadorposible.

Para obtener toda esa informacion en la ejecucion de un programa, sonnecesarias herramientas de deteccion que nos proporcionen una interfaz conlas capacidades de medicion que ofrece el procesador sobre datos como ciclosde ejecucion, accesos o fallos de cache.

El proceso de medicion de cualquier magnitud debe entranar la maximaexactitud posible. En el caso que nos ocupa, la medicion de eventos deprocesador viene marcada por la condicion de “convivencia” de procesos enun sistema operativo enfocado a la ejecucion concurrente de programas. Estaejecucion en convivencia, puede provocar mediciones con un exceso evidentede ruido que nos lleve a conclusiones erroneas a la hora de enfocar el disenode nuestro programa si consideramos estas mediciones como propias de uncontexto determinista1.

Ademas de controlar la fiabilidad de la medicion, a la hora de la realiza-cion de pruebas es necesario mantener el enfoque de portabilidad del sistema,es decir, debemos ofrecer la capacidad de ejecutar las pruebas en el mayor

1Un contexto determinista en este caso se trata de aquel entorno donde se obtiene elmismo resultado bajo unas condiciones iniciales similares.

9

10 2.2. Identificacion del Problema Tecnico

numero de entornos posible. De esta manera, el diseno de nuestro sistema depruebas no puede cenirse a dispositivos monoprocesador, sino que debemosdar un paso adelante y permitir la entrada de la tecnologıa emergente deprocesadores multinucleo2, permitiendo aislar ejecuciones determinısticas enmas de un nucleo o procesador.

Por ultimo, el proceso de medicion debe ser transparente al usuario, y aser posible, lo mas intuitivo posible. Esto hace necesario un entorno dondeno sea necesario recompilar el codigo para lanzar ejecuciones, donde todoslos elementos para la medicion esten ya disponibles, sin necesidad de instalarsoftware adicional, y donde la facilidad de uso mediante una interfaz sencillalleven a la persona encargada de realizar las pruebas al objetivo inicial deoptimizacion del programa en un entorno fiable y, a pesar de no tratarse deuna expresion de nuestro gusto, amigable.

2.2. Identificacion del Problema Tecnico

A continuacion se presentan los aspectos tecnicos relevantes a la hora dellevar a cabo la identificacion del problema tecnico haciendo uso de la tecnicade Especificaciones del Diseno del Producto (Product Design Specification oPDS), que nos permite realizar un analisis de los principales condicionantestecnicos respondiendo a los siguientes apartados.

2.2.1. Funcionamiento

El proyecto consta de cuatro apartados fundamentales definidos a con-tinuacion:

lperfex Es la aplicacion encargada de realizar mediciones de procesador decualquier tarea.

lperfex dispone de una interfaz grafica llamada glperfex que incrementalas posibilidades de esa interfaz permitiendo extraer y guardar datosy graficas de dichas ejecuciones.

El funcionamiento de lperfex no es intrusivo, ya que realiza un procesovırico (intercepta el inicio del proceso, colocando codigo al inicio y alfin con el objetivo de preparar y recoger los resultados de ejecucion delprograma).

2En la redaccion del manual tecnico se utilizaran indistintamente los conceptos demultinucleo, su equivalente en ingles multicore y multiprocesador para referirnos a laejecucion de procesos del sistema operativo en maquinas con mas de un procesador, yasea real o virtual.

Definicion del Problema 11

Dicho programa puede, por lo tanto, haber sido escrito en C, Fortran ocualquier lenguaje que permita generar un fichero ejecutable que cum-pla con los estandares comentados en el apartado 2.2.7, dependiendola medicion simplemente de la existencia de un binario a ejecutar, faci-litando ası el proceso al usuario, que no debera recompilar el programapara realizar las pruebas.

RTAI Como se describio en la identificacion del problema real, debe existirun elemento que permita la ejecucion del proceso a medir de formaindependiente al planificador del kernel de Linux.

Para realizar estas mediciones sera necesaria la utilizacion de unaherramienta que se coloque por encima del propio nucleo, eludiendoası los cambios de contexto provocados por las interrupciones software,el reemplazo en la cola de planificacion, etc.

La herramienta que permite esta capacidad es el proyecto RTAI, queofrece a nuestro sistema la capacidad de realizar operaciones en tiemporeal.

PAPI Este es el elemento en el que se basa lperfex para acceder a loscontadores hardware que el usuario desee medir.

Haciendo uso del driver perfctr, PAPI permite al programador me-diante una biblioteca sencilla y portable realizar mediciones de esoscontadores.

Live CD La aplicacion lperfex necesita un entorno de ejecucion que dispon-ga de unas caracterısticas especiales. Necesita acceso a los contadoreshardware que ofrece el procesador para obtener las estadısticas soli-citadas de cada ejecucion ası como las caracterısticas de tiempo realque comentabamos en la descripcion de RTAI. Para ello es necesariala instalacion de parches al kernel de Linux y carga de varios modu-los ası como la instalacion de varias bibliotecas. Para evitar la tediosaoperacion de instalar todos los componentes en un sistema, la opcionmas sencilla es presentar todo el sistema empaquetado en un Live CDcon herramientas basicas como un entorno grafico, navegador web, he-rramientas de oficina, desarrollo, etc.

2.2.2. Entorno

Como se adelanto a la hora de definir el funcionamiento, el entorno deejecucion de nuestro sistema se forma en un Live CD.

Un Live CD forma un sistema operativo ejecutado al arrancar la maqui-na sin realizar ninguna instalacion en el disco duro. Contiene una imagen


comprimida del sistema, en este caso con todas las caracterısticas requeri-das. Una vez arrancado, descomprime el sistema de ficheros del CDROM(squashfs) y comienza el arranque. Una de las caracterısticas de los Live CDes que adaptan la configuracion del sistema a la maquina sobre la que seestan ejecutando. De esta manera, se detectaran los dispositivos de los quedispone la misma y los configurara correctamente para el trabajo a realizar.

Una vez cargada la configuracion y arrancado el sistema, nos encontrare-mos con el entorno tal y como fue disenado para su uso. El kernel del sistemaoperativo, convenientemente parcheado, habra cargado los modulos necesa-rios tanto para la ejecucion exclusiva de tareas cuando esta sea requerida,como para acceder correctamente a los contadores hardware.

La principal novedad de Karma Linux 2008, ademas de la posibilidadde aislar en los procesadores deseados la carga del programa a ejecutar esla incorporacion de la interfaz grafica glperfex para realizar las mediciones.De esta manera, ademas de facilitar el trabajo con nuevas opciones para elusuario, se pretende que la aplicacion pueda ser utilizada de forma sencillacon fines docentes, donde los alumnos no se tendran que enfrentar al impe-dimento de no tener un alto conocimiento de interaccion con la terminal delsistema (modo de interaccion original de lperfex ). Por ello, con estas facili-dades, el entorno de ejecucion de la aplicacion se hace plenamente accesiblesin necesidad de configuracion ni grandes conocimientos previos.

No obstante, Karma sigue ofreciendo la capacidad de utilizar lperfex sinnecesidad de interfaz grafica, mediante la interaccion estandar por consolade getopts.

2.2.3. Vida Esperada

La capacidad de adaptacion a la medicion de ejecucion, y a las carac-terısticas de cualquier sistema (siempre teniendo en cuenta la arquitecturax86 para la que ha sido disenada la distribucion) mediante la deteccion dedispositivos, hace que el proyecto pueda seguir cubriendo las necesidadespara las que se disena a lo largo del tiempo.

2.2.4. Ciclo de Mantenimiento

Karma esta compuesto de una serie de herramientas libres, cuyo desarro-llo se lleva a cabo por una comunidad muy activa. Si se examinan artıculosprovistos tanto en la pagina web de RTAI [6] o en la de PAPI [7] existen unagran cantidad de proyectos afectados por el desarrollo de dichas bibliotecas,


que cada dıa amplıan su soporte a nuevas arquitecturas o familias de proce-sadores. Este hecho hace que el futuro mantenimiento de Karma amplıe loshorizontes para los que ha sido disenado de manera que se cubran nuevosprocesadores y se adapte a la medicion real en todo tipo de entornos. Eldiseno modular del sistema, hace posible la actualizacion sencilla de com-ponentes, de manera que el proyecto no sera difıcil de retomar en futurasversiones.

2.2.5. Competencia

La competencia a la aplicacion, tal y como se describira en el apartado2.4 es escasa, existen escasos antecedentes que se puedan ajustar a las ca-racterısticas requeridas a la hora de concebir el proyecto y en caso de existirson obsoletos.

2.2.6. Aspecto Externo

Como se ha comentado a lo largo del apartado 2.2, el aspecto externosera el Live CD desde el que se ejecutara la aplicacion de medicion. Esteenglobara la aplicacion lperfex y sus dependencias, incluyendo las bibliotecasencargadas de interceptar tareas y anadir codigo al principio y final de lastareas interceptadas.

La interfaz grafica lperfex sera disenada usando el binding3 de la bibliote-ca grafica wxWidgets para el lenguaje de programacion Python, wxPython.Esta biblioteca se caracteriza por ser multiplataforma, por lo que su usojunto a Python permite el desarrollo rapido de aplicaciones graficas multi-plataforma.

Puesto que esta se trata no se trata de una aplicacion de ambito comer-cial, las caracterısticas de presentacion y distribucion del soporte del sistemano se tendran en cuenta.

2.2.7. Estandarizacion

El desarrollo de un proyecto software libre requiere un enfasis en la estan-darizacion del sistema, de manera que los potenciales desarrolladores puedanrealizar futuros cambios y modificaciones de forma que se fomente la mejoradel proyecto.

3En el campo de la programacion, un binding es una adaptacion de una bibliotecapara ser usada en un lenguaje de programacion distinto de aquel en el que ha sido escrita.


La distribucion sigue las indicaciones de la Linux Standard Base(LSB), con la salvedad del uso, implıcito en distribuciones de tipoDebian, de empaquetado deb en lugar de rpm [8]. Esta excepcion sepodrıa salvar utilizando el programa alien en el empaquetado. Se pue-den consultar crıticas sobre esta normativa en [9] y [10].

Las mediciones solo seran admitidas para ficheros ejecutables que siganel formato de enlazado ELF4.

Ademas para el uso de lperfex por terminal se utilizara el estandardefinido por la GNU Libc getopts ademas de utilizar las herramientasde edicion de proyectos autotools.

A la hora de desarrollar la interfaz grafica, el enfoque se dirige a Pythonen su version 2.4, para guardar compatibilidades, mientras que porcon respecto a wxPython se utilizaran caracterısticas de la version de2.8 debido a las numerosas mejoras que presenta frente a versionesanteriores.

2.2.8. Calidad y Fiabilidad

La calidad y fiabilidad del producto final seran evaluadas comprobandola mejora del sistema mediante tests realizados en caracterısticas norma-les de uso y los tests realizados aislando los procesos en los procesadoresespecificados en la prueba. Midiendo tambien la diferencia entre entornoscon ruido y entornos sin ruido que demuestren la calidad y precision de lasolucion final.

2.2.9. Programa de Tareas

A diferencia de la primera version de Karma, el proyecto fin de carreraparte de una solucion dada y pretende una mejora de la misma. De estamanera, que la carga de investigacion del mismo se ha visto reducida sensi-blemente. Tambien debemos tener en cuenta que al tratarse de un proyectofin de carrera, en principio, y adaptandonos al caso que nos ocupa, no esnecesario un calculo de costes o plazos de ejecucion.

4El formato ELF (Executable and Linkable Format) es un formato de archivo paraejecutables, codigo objeto, librerıas compartidas y volcados de memoria. Fue desarrolladopor el Unix System Laboratory (USL) como parte de la ABI. En principio fue desarrolladopara plataformas de 32 bits, a pesar de que hoy en dıa se usa en gran variedad de sis-temas. Es el formato ejecutable usado mayoritariamente en los sistemas tipo Unix comoGNU/Linux, BSD, Solaris, IRIX. Existen otros formatos soportados en algunos de estossistemas como COFF o a.out, pero ELF es sin duda el mas usado.


Las fases de desarrollo del proyecto seran:

Fase de Preparacion Durante esta fase se reunira la informacion necesa-ria para abordar la realizacion del proyecto.

Estudio de Karma Linux original en su conjunto desgranando loscomponentes.

Estudio de la herramienta lperfex.

Estudio de RTAI.

Fase de Especificacion de Requisitos Durante esta etapa ha de reali-zarse una descripcion del comportamiento del sistema y los objetosindividuales que forman parte del mismo, analizando las condicionesque debe reunir el sistema final.

Fase de Implementacion Como resultado de la fase de especificacion derequisitos se implementara la solucion final con los cambios y adicionesnecesarias a Karma Linux.

Fase de Pruebas Se analizaran las mejoras realizadas con las condicionesiniciales planteadas respecto a la version original de Karma Linux, demanera que en caso de ser positiva se construya una nueva version deKarma Linux en un Live CD.

Fase de Documentacion Se reuniran los documentos generados en fasesanteriores para la redaccion de los documentos pertinentes.

2.2.10. Pruebas

En la fase final del proyecto, como hemos visto en el apartado anterior, sesometera al sistema a un conjunto de pruebas para comparar los resultadosprevios y poder extraer conclusiones de las mejoras.

Ademas de las pruebas propias de la mejora de la aplicacion, seran ne-cesarias pruebas de caja blanca durante la codificacion de las codificacionesy modificaciones de codigo.

2.2.11. Seguridad

La seguridad del sistema esta basada en la seguridad propia de los siste-mas tipo Unix. La cuenta de usuario del Live CD tiene una contrasena queimpide el acceso al mismo desde fuera del ordenador. Es decir, el usuario

16 2.3. Objetivos

debera tener acceso fısico al mismo, o acceder por red conociendo el usuarioy contrasena con protocolos como SSH.

Por otro lado la aplicacion es software libre bajo licencia GNU GPLversion 3, esto quiere decir, que todo el codigo y la aplicacion estara dis-ponible para el desarrollo de cualquier desarrollador que desee mejorarlo omodificarlo. Por ello no existira ningun metodo de proteccion anticopia.

2.3. Objetivos

Una vez identificado el problema real y tecnico se exponen los objetivosa alcanzar con el desarrollo del proyecto. Como hemos adelantado, KarmaLinux 2008 se plantea como una actualizacion de Karma Linux que suplalas carencias del mismo en materia de usabilidad y se adapte a los nuevosprocesadores multinucleo.

2.3.1. Adaptacion de Karma a Procesadores Multinucleo

Como se menciono en la introduccion, la implantacion del procesadoresmultinucleo en el mercado es una realidad a dıa de hoy. El enfoque mono-procesador de Karma Linux hace que la distribucion no pueda aprovecharni examinar las capacidades de estos nuevos sistemas.

Por ello el primer objetivo a cumplir por el proyecto es habilitar la he-rramienta lperfex para la medicion de ejecuciones exclusivas en multipro-cesador, de manera que el programa detecte el numero de procesadores dela maquina y permita elegir en que procesador o procesadores realizar lamedicion.

2.3.2. Mejora de la Usabilidad

Una de las posibles areas de aplicacion de Karma Linux es la docencia.La medicion de eventos de procesador al ejecutar un programa nos permiteobservar la mejora de esa ejecucion en distintos procesadores y programas,siendo informacion util para la comprension de materias relacionadas conSistemas Operativos y Arquitectura de Computadores.

lperfex es, como hemos comentado anteriormente, una aplicacion acce-sible solo a traves de terminal mediante la interfaz de uso getopts. Estodificulta la interaccion con el mismo para un usuario inexperto ademas de


limitar la informacion expuesta al no poder anadir, por ejemplo, graficaspara ilustrar la ejecucion.

Por ello, otro de los objetivos del proyecto es dotar a lperfex de una in-terfaz sencilla capaz de mostrar los resultados correctamente, anadir graficasal mismo y ofrecer la capacidad de almacenar los resultados para posterioresvisualizaciones y comparaciones de forma compatible con programas talescomo hojas de calculo, etc. A partir de ahora nos referiremos a esta interfazcomo glperfex.

2.3.3. Autonomıa de la Plataforma

El objetivo de garantizar la autonomıa de la plataforma hereda del plan-teamiento de Karma Linux original. Debido a la necesidad de un entornoespecial en el que el planificador permita un mayor control sobre el procesa-dor y la cola de procesos, de manera que podamos garantizar la ausencia deruidos externos en la ejecucion del programa a medir, sera necesario crearuna plataforma donde la aplicacion y el entorno puedan existir de formaautonoma, proveyendo al usuario todas las herramientas necesarias para eldesarrollo de su tarea. Esto conlleva:

La construccion de un sistema comprimido en una imagen grabable aun CDROM con todas las bibliotecas, modulos y parches necesariospara la ejecucion de nuestro entorno.

Autodeteccion de hardware durante el arranque de la imagen del siste-ma, de manera que se generen los ficheros de configuracion necesariospara la ejecucion del mismo en cualquier maquina de la arquitecturax86 y x86 64.

Construccion de paquetes adicionales para mejorar la usabilidad delsistema, esto significa incluir navegadores web, hojas de calculo, com-piladores y un entorno grafico.

2.4. Antecedentes

A continuacion se presentan los antecedentes al proyecto a realizar, di-vidimos estos antecedentes en cuatro apartados. En primer lugar aquellasaplicaciones o interfaces de programacion para evaluar el funcionamiento deprogramas accediendo a contadores hardware, en segundo lugar los sistemasoperativos o modificaciones que permitan la ejecucion de modo exclusivode procesos, en tercer lugar analizaremos el antecedente de la distribucion y

18 2.4. Antecedentes

punto de partida principal del proyecto, Karma Linux, y por ultimo comenta-remos algunas soluciones posibles para realizar tests destinados a comprobarlas mejoras que ofrece nuestro sistema.

2.4.1. Antecedentes a Lperfex y Glperfex

ContEven Proyecto Fin de Carrera de Antonio Espinar Ruiz para el anali-sis de rendimiento de procesadores de tipo Pentium y AMD desarrolla-do en el Area de Arquitectura de Computadores del Departamento deArquitectura de Computadores, Electronica y Tecnologıa Electronicade la Universidad de Cordoba en 2003. El inconveniente fundamen-tal que no hace aplicable el proyecto como solucion es que este solomuestra informacion generica del procesador sin aprovechar la infor-macion que nos proporcionan los contadores hardware del procesador.Este programa funciona en la plataforma Windows, lo que traicionanuestro objetivo moral de aportar una solucion utilizando unicamentesoftware libre a la hora de enfocar el proyecto.

Perfex Herramienta para la realizacion de tests en sistemas con procesadorR10K y sistema operativo IRIX de Silicon Graphics a traves de loscontadores de eventos proporcionados por dichos procesadores. Por ellose trata de una aplicacion imposible de adaptar a sistemas distintospara los que esta concebido.

SpeedShop Es un conjunto de herramientas para la ejecucion de prue-bas de rendimiento en programas ejecutables y examinar los resul-tados de dichas pruebas. Proporciona no solo las estadısticas tıpi-cas de programas de analisis de rendimiento de procesador como usodel procesador, estado de la pila o registro de excepciones, sino queademas, incorpora experimentos que que permiten analizar directa-mente el rendimiento de la memoria cache, fallos de acceso a memoriacache de datos e instrucciones, fallos de acceso a TLB5, controles comofork, exec, sproc, etc. Sin embargo al igual que Perfex, SpeedShopsolo puede ser utilizado en sistemas IRIX.

Papiex Sistema similar a la herramienta Perfex para entornos x86. Estaaplicacion se distribuye junto a PAPI y es util para el estudio de laintercepcion de procesos. Sin embargo no serıa solucion a nuestrosobjetivos al no permitir una ejecucion exclusiva del proceso sobre elprocesador, ademas de ser una herramienta poco actualizada [1].

5Translation Lookaside Buffer (TLB) es un bufer o cache en una Unidad de Procesa-miento Central (CPU), que contiene partes de la tabla de paginacion, es decir, relacionesentre direcciones virtuales y reales.


Intel Vtune Analiza el rendimiento de programas para Windows y Linux.Esta disenado para desarrollar software mas eficiente y rapido en sis-temas mono y multiprocesador. Ademas, analiza aplicaciones sin ne-cesidad de recompilacion o enlazado [11]. Sin embargo, VTune esta di-senado exclusivamente para procesadores Intel, y el coste de su licenciaes elevado.

2.4.2. Antecedentes de Planificadores en Tiempo Real

RTLinux Es un sistema operativo en tiempo real utilizado en proyectos demedicina o aeronautica [12]. Su vertiente de codigo abierto ha caıdoen desuso [13] y la version comercial es descartada por su caracterprivativo por las mismas razones que argumentabamos al hablar deContEven.

RTAI Es un sistema de tiempo real que utiliza una capa de abstraccionllamada ADEOS y soporta arquitecturas como x86, PowerPC, ARM yMIPS [14]. El proyecto RTAI es software libre y se utilizo para para laplanificacion de procesos de modo exclusivo en Karma Linux, nuestroantecedente principal.

2.4.3. Antecedentes de la Distribucion

Karma Linux Es una distribucion de Linux en tiempo real para la me-dicion de eventos [1]. Karma Linux esta enfocado como adelantamosen la introduccion en el uso del modo exclusivo de ejecucion sobre ununico procesador para los eventos que la requieran. La limitacion fun-damental de Karma Linux radica en este hecho, que impide un funcio-namiento optimo en sistemas multiprocesador. Ademas, la aplicacionutilizada para la medicion de contadores hardware carece de interfazde usuario mas alla de la terminal. Con la realizacion de este proyectopretendemos solventar estas dos limitaciones de Karma Linux.

2.4.4. Antecedentes a Sistemas de Benchmarking

El benchmark es una tecnica utilizada para medir el rendimiento de unsistema o componente de un sistema, frecuentemente en comparacion conel cual se refiere especıficamente a la accion de ejecutar un benchmark. Lapalabra benchmark es un anglicismo traducible al castellano como compa-rativa. Si bien tambien puede encontrarse esta palabra haciendo referenciaal significado original en la lengua anglosajona, es en el campo informatico

20 2.4. Antecedentes

donde su uso esta mas ampliamente extendido. Mas formalmente puede en-tenderse que un benchmark es el resultado de la ejecucion de un programainformatico o un conjunto de programas en una maquina, con el objetivo deestimar el rendimiento de un elemento concreto, o la totalidad de la misma,y poder comparar los resultados con maquinas similares [15].

Los benchmarks analizados fueron:

Standard Performance Evaluation Corporation (SPEC) Es un con-sorcio sin fines de lucro que incluye a vendedores de computadoras,integradores de sistemas, universidades, grupos de investigacion, pu-blicadores y consultores de todo el mundo. Son los responsables delconjunto de tests SPEC CPU2000, un benchmark creado con el fin deproveer una medida de rendimiento que pueda ser usado para com-parar cargas de trabajo intensivas de computo en distintos sistemas.Se divide en dos suites principales, la CINT2000, orientada a la medi-cion de computacion sobre enteros, y la CFP2000, para punto flotante.SPEC CPU2000 incluye algoritmos de teorıa de juegos e InteligenciaArtificial, recorrido de arboles, compiladores e interpretes, compresionde datos, bases de datos, prediccion del clima, dinamica de fluidos, fısi-ca, quımica y procesamiento de imagenes, con lo que se puede probarun amplio espectro de algoritmia con dichos tests [16]. Los benchmarksSPEC fueron los elegidos para la realizacion de un artıculo sobre Kar-ma Linux presentado en el Congreso CEDI en 2005 [17].

NAS BenchMark Coleccion de benchmark creados por la NASA. El pro-grama NAS nacio como un gran esfuerzo por parte del centro de inves-tigaciones de la NASA para avanzar en el estudio de la computacionaerodinamica. NAS presenta la ventaja de que al ser desarrollados conla computacion paralela en mente, son genericos y no favorecen nin-guna maquina de forma especıfica. Ademas, a pesar de que la mayorıade tests son de ejecucion paralela (usando MPI), tambien existe unarama que incluye los principales tests NAS en modo serial. El bench-mark NAS posee tres algoritmos principales, Lower-Upper SymmetricGauss-Seidel (LUS), Scalar Penta-diagonal (SP) y Block Tri-diagonal(BT). Los test NAS cargan principalmente al procesador, teniendoescasa o nula presencia de entrada/salida [18].

Perfect Bencharmak Es una prueba orientada a superordenadores y pro-ceso en paralelo. Consta de 13 programas en FORTRAN, que incluyenaplicaciones de ingenierıa y cientıficas, representando a cuatro areasde estudio reales: mecanica de fluidos, fısica y quımica, diseno de inge-nierıa y procesado de senal. Los resultados, expresados en millones deoperaciones en coma flotante por segundo (MFLOPS), son calculadoscomo la media geometrica de los resultados de este juego de tests [21].


2.5. Restricciones

A continuacion se expondran las restricciones o factores limitativos exis-tentes en el ambito del diseno y que condicionan la eleccion de las diferentesalternativas.

2.5.1. Factores Dato

En el desarrollo del proyecto se consideraran los siguientes factores dato:

El resultado final ha de se transparente al usuario, esto implica que elusuario no tendra que realizar una configuracion previa del sistema yque la aplicacion a probar no requerira ser recompilada. Por lo tantolas mediciones se realizaran sobre codigo compilado sin que el codigo deC, Fortran o cualquier lenguaje deba ser tratado de manera especial,siempre que haya sido compilado de acuerdo con el estandar ELF.

El sistema ha de ser multiplataforma, satisfaciendo ası el objetivo decrear un sistema autonomo e independiente de la plataforma dondese desee ejecutar (aunque no de la arquitectura). Ademas debera sercapaz de aprovechar las tecnologıas multiprocesador.

Se hara uso de la aplicacion lperfex y las bibliotecas RTAI y PAPIadoptando la solucion escogida en Karma Linux original para imple-mentar la medicion no intrusiva de eventos. Esto implica que las fun-cionalidades a extender (no hablamos de proporcionar una interfazgrafica al programa, sino del funcionamiento interno del sistema demedicion) deberan programarse en C y deberan cumplir con la licen-cia vırica GNU GPL v2 [19] de lperfex. Esto significa, que nuestraaplicacion ampliada, de acuerdo con la licencia GNU GPL, podra li-cenciarse como GPL v2 o superior, contando esta eleccion como unfactor estrategico.

Uso de GNU/Linux, por motivos analogos al punto anterior, ya queeste proyecto se plantea como una ampliacion de Karma Linux, tododebera enfocarse desde y para este sistema operativo.

2.5.2. Factores Estrategicos

Tambien se consideraran los siguientes factores estrategicos:

22 2.5. Restricciones

Enfoque del trabajo hacia la arquitectura x86, arquitectura de mayoruso y mayor facilidad de acceso a la hora de realizar el proyecto. Sepodrıa realizar una version de arquitectura x86 64, sin embargo estoimpedirıa su aplicacion en la mayorıa de monoprocesadores comunes yen los Intel Core Duo (ordenadores a dıa de hoy utilizados en las aulasde informatica de la Universidad de Cordoba).

Uso de la licencia GNU GPL v3. Como se adelanto en el tercer puntode los factores dato, lperfex, aplicacion que nos permitira realizar lasmediciones de forma no intrusiva, ya sea usando un planificador entiempo real o el planificador clasico del kernel de Linux, esta licenciadasegun la GNU GPL v2. Esta forma de licenciar el producto da laposibilidad de escoger en las modificaciones la licencia GNU GPL v2o una licencia superior. En este caso se escogera la licencia GNU GPLv3 persiguiendo los objetivos de la misma en defensa del software libre[20]:

• Resolver formas en que a pesar de todo alguien podıa quitar li-bertades a los usuarios.

• Como un caso especial de lo anterior: Prohibir el uso de softwa-re cubierto por licencias de sistemas disenados para sustraer laslibertades de los usuarios del mismo (como las tecnologıas cono-cidas como DRM6).

• Resolver ambiguedades y aumentar su compatibilidad con otraslicencias.

• Facilitar su adaptacion a otros paıses.

• Incluir clausulas que defiendan a la comunidad de software libredel uso indebido de patentes de software.

Realizacion de una interfaz grafica para la aplicacion lperfex de mo-do que se facilite la usabilidad del programa y que se proporcionenuna serie de funcionalidades extra. Esto responde al interes de difun-dir la aplicacion entre personas sin un gran conocimiento del manejode comandos bajo Unix. Desafortunadamente esto es comun no soloentre alumnos de informatica sino tambien entre profesionales de lainformatica.

6Digital Rights Management (DRM) es un conjunto de tecnologıas orientadas a ejercerrestricciones sobre los usuarios de un sistema forzando de esta manera los derechos digitalespermitidos por comision de los poseedores de esos derechos de autor e independientementede la voluntad del usuario/consumidor del mismo. Generalmente estos dispositivos soninstalados como condicion previa a la distribucion de software no libre, obras musicales,libros electronicos o cualquier tipo de archivo sujeto a derechos de autor. En algunoscasos, las restricciones aplicadas se extienden mas alla de los archivos que debıan proteger,agregando restricciones sobre el uso de otros documentos o aplicaciones presentes en lamaquina.


Uso de Python para la realizacion de la interfaz grafica. Este factorestrategico se debe a la versatilidad del lenguaje, debida a la grancantidad de bibliotecas que contiene, no solo para la realizacion deinterfaces graficas sino para manejo de cualquier tipo de dato, accesosal sistema, etc.

Python nos ofrece una sencillez a la hora de programar que favore-cera tanto la rapidez del desarrollo de la interfaz, como la interaccioncon lperfex, gracias a la facilidad para operar con entradas y salidasde programas (stdin, stdout, stderr) o la posibilidad de realizarllamadas a funciones de C a traves de bindings.

Con respecto a las pruebas de benchmarking se descartan los test Per-fect Benchrmark debido a que su antiguedad (los test son anterioresa 1985), hace que alguno de estos tests no sean compatibles con loscompiladores modernos de Fortran. A pesar de su frecuente uso en elpasado, dichos test apenas se mencionan en documentos a partir delano 2000 [1].

Los test escogidos para la realizacion del proyecto son los test NAS,cuyas caracterısticas resumimos en el apartado 2.4.4. Por ejemplo seusara un algoritmo para buscar la solucion de diferencias finitas a ecua-ciones de Navier-Stokes, que consisten en un conjunto de ecuaciones nolineales en derivadas parciales que describen el movimiento de un flui-do. Los demas tests tratan de resolver el mismo problema empleandodiversos metodos matematicos [18].

La complejidad de calculo de los tests hace que provoquen una grancarga de procesamiento del sistema y una baja carga de entrada/salida,mejorando el metodo de medicion de la mejora obtenida. Esta es larazon del descarte de los test SPEC como metodo de valoracion, yaque, a pesar de los buenos resultados obtenidos en experiencias previas,tienen una excesiva cantidad de entrada/salida.

2.6. Recursos para el Desarrollo

A continuacion se comentaran los recursos necesarios para el desarrollodel proyecto. Estos recursos vendran diferenciados en funcion de su condi-cion, es decir, recursos humanos, hardware y software.

2.6.1. Recursos Humanos

Los recursos humanos a la hora de desarrollar el proyecto son:

24 2.6. Recursos para el Desarrollo

Recursos humanos internos:

Directores Prof. D. Ezequiel Herruzo Gomez y Prof. Dr. Jose Igna-cio Benavides Benıtez, directores, asesoradores y supervisores deldesarrollo del proyecto.

Autor Fernando Garcıa Aranda. Encargado del analisis y soluciondel problema, tecnicas de mejora, testeo y documentacion de lamisma.

Recursos humanos externos:

Pedro Navajas Modelo Autor de Karma Linux.

Lista de correo de RTAI Fundamental a la hora de examinar lospuntos a modificar del programa para permitir la seleccion deprocesadores del multiprocesador que se desean utilizar en la eje-cucion exclusiva del programa.

Lista de correo de PAPI Necesaria a la hora de conseguir que lasolucion final se adapte a la medicion de eventos en el maximonumero de procesadores (modelos) posibles.

2.6.2. Recursos Hardware

Los recursos hardware a la hora de realizar el proyecto seran:

Ordenador PC con procesador Intel Core 2 Duo (T7200), 2GHz, 4MBde memoria cache, 1GB de memoria RAM y 120GB de disco duro.Sera el utilizado para trabajar con multiprocesador, en este caso mul-ticore.

Ordenador PC con procesador AMD Athlon XP 2.6Ghz, 512KB dememoria cache, 512MB de memoria RAM y 120GB de disco duro.Utilizado para trabajar en monoprocesador.

2.6.3. Recursos Software

Los recursos software seran:

Debian GNU/Linux: distribucion de GNU/Linux bajo la que se reali-zara el desarrollo de la solucion y que servira de base para la imple-mentacion final de la misma (Live CD).


Interprete de Python 2.4: para la ejecucion de la interfaz grafica deusuario.

Biblioteca WxPython 2.8: binding de la biblioteca grafica wxWidgets(escrita en C++) para el lenguaje de programacion Python. Necesariapara la implementacion de la interfaz grafica de usuario.

Live-helper: conjunto de paquetes para la creacion de Live CDs bajoDebian testing y unstable.

Autotools: Herramientas para la creacion de proyectos de softwarelibre que permite la generacion automatica de Makefiles adaptadosa cada sistema, generacion y mantenimiento de traducciones, analisisde dependencias, etc.

Coleccion de Compiladores de GNU (GCC): Compiladores de C y For-tran empleados para compilar y enlazar el codigo fuente del medidorde eventos y las pruebas de testeo.

Kernel de Linux: fuentes originales del kernel (vanilla sources) dondeaplicaremos los parches necesarios, version 2.6.22.15.

Editores de textos Vim y Gedit, para la codificacion del proyecto y ladocumentacion del mismo.

Kile: IDE7 de LATEX.

DIA: programa para la realizacion de diagramas, procedimientos ygraficos de todo tipo necesarios para la documentacion del proyecto.

Doxygen: generador de documentacion multilenguaje para el manualde codigo.

Evince: programa para la visualizacion de documentos pdf y ps.

Navegador web Iceweasel y cliente de correo Icedove (basados en lasherramientas de Mozila Firefox y Thunderbird respectivamente, in-cluidos en Debian GNU/Linux).

2.7. Recursos para la Ejecucion

A continuacion se comentaran los recursos necesarios para la ejecuciondel proyecto.

7Integrated Development Environment, Entorno de Desarrollo Integrado.

26 2.7. Recursos para la Ejecucion

2.7.1. Recursos Humanos

Cualquier persona puede insertar el Live CD en su maquina e iniciar elsistema con las herramientas necesarias para realizar las mediciones. EsteCD configurara el sistema y preparara todo lo necesario para que el usuariopueda realizar la labor sin necesidad de configurar nada.

2.7.2. Recursos Hardware

Cualquier ordenador con arquitectura x86 o x86 64 y lector de DVD essuficiente para realizar las mediciones.

2.7.3. Recursos Software

No es necesario ningun recurso software, ya que el Live CD provee todoslos recursos necesarios para crear un entorno de ejecucion idoneo.

Capıtulo 3

Analisis del Sistema

Si en capıtulo anterior se ofrecio una vision global del problema a resol-ver, describiendo ası la aplicacion a desarrollar, ahora es el momento de laespecificacion tecnica de los requisitos de la aplicacion.

Para describir la aplicacion glperfex, interfaz sencilla a lperfex utilizare-mos el Lenguaje Unificado de Modelado (UML) a traves de diagramas decasos de uso y clases, para el modelado estatico, y diagramas secuencia, parael modelado dinamico. Por otro lado estableceremos los requisitos y espe-cificaciones del resto de los elementos que componen el sistema, ademas dedescribir como se alamacenara la informacion manejada.

3.1. Identificacion de Requisitos

El proyecto trata de realizar un entorno sencillo y determinista de me-dicion de eventos de procesador sobre programas ejecutables.

A continuacion se presenta una lista general de requisitos del sistema,dada por los objetivos que enumeramos durante la etapa de definicion delproblema.

Mejorar la precision de las mediciones Esta propuesta requiere prue-bas en diversos entornos para solventar los aspectos del problema, porlo que es difıcil estimar la duracion de la misma.

Usar un entorno en tiempo real bajo Linux Ofrece las ventajas de unplanificador en tiempo real junto a la posibilidad de uso de un sistemaoperativo libre, que asegure una mayor configurabilidad del mismo yun mayor aprendizaje de los aspectos internos del mismo.

27

28 3.2. Modelado Estatico

Uso de herramientas libres La idea es aprovechar y contribuir en el tra-bajo de una comunidad incalculable de desarrolladores de software quenos brindan la oportunidad de utilizar, mejorar y modificar excelentesproductos integrandolos ası en nuestro sistema. Por ello es fundamen-tal la publicacion de las modificaciones que realicemos para que puedanser aprovechadas por el resto de la sociedad ya que esta filosofıa es sinduda un paso adelante y una gran contribucion al avance tecnologico.

Interfaz grafica sencilla para la realizacion de las medicionesImplica el diseno de una interfaz grafica simple, completa e intuitivaque permita al usuario poco experimentado aprovechar las funcionali-dades de la aplicacion, de manera que pueda utilizare para multitudde ambitos de aplicacion.

Adaptacion a Multiprocesador Hace necesario el estudio y aplicacionde una solucion para la distribucion del proceso a ejecutar en modoexclusivo por el planificador en tiempo real.

Obtencion de Informacion sobre la maquina en tiempo de ejecucionExiste informacion vital para lograr una muestra valida de acuerdocon las caracterısticas del modelo de procesador sobre el que se ejecutala aplicacion. Por ello el sistema debe ser capaz de obtener datostan importantes como el numero de procesadores y los contadoreshardware con los que cuenta la maquina.

Entorno propio sin necesidad de configuracion Como consecuenciadel punto anterior se debe de contar con un entorno configurado ade-cuadamente para realizar las mediciones sin que el usuario realice ins-talaciones extra y que detecte los elementos y configure el equipo deacuerdo con sus caracterısticas.

3.2. Modelado Estatico

Mediante el modelado estatico se pretende establecer de un modo for-mal el comportamiento del sistema a traves de uso del Lenguaje Unificadode Modelado (UML). Para ello examinaremos tanto los casos de uso de laaplicacion, a traves de sus diagramas de casos de uso, como las clases invo-lucradas y sus relaciones, a traves su diagrama de clases.

La vision que realizaremos se basara exclusivamente en la interfaz gl-perfex (describiremos la relacion de esta interfaz con lperfex en el modeladodinamico), ya que las especificaciones y requisitos del resto del sistema serandescritos en el apartado 3.6.

Analisis del Sistema 29

3.2.1. Casos de Uso

3.2.1.1. Identificacion de los Actores

El unico actor implicado es el usuario final. Esto se debe al cumplimientode la premisa de funcionamiento autonomo del sistema, de manera que noexista la necesidad de implicar a ningun administrador que realice configu-raciones o mantenimiento del mismo. Podemos catalogar a los usuarios entrelos siguientes tipos:

Investigadores y Desarrolladores Utilizan la aplicacion para realizarbenchmarkings midiendo ası la optimizacion de un algoritmo (obser-vando las mejoras a realizar o los exitos de las mismas) evaluando paraello todos los eventos que la arquitectura permite medir.

Docentes y Alumnos Pueden necesitar la aplicacion para la demostra-cion y validacion de teorıas a traves de una serie de pruebas de lasmismas. Tambien puede utilizarse la aplicacion para la comprensiondel funcionamiento interno de un procesador (en este caso debera li-mitarse a procesadores de las arquitecturas x86 y x86 64 ).

3.2.1.2. Diagrama de Casos de Uso

En la Figura 3.1 podemos observar los casos de uso de nuestro sistema.

Figura 3.1: Diagrama de Casos de Uso


3.2.1.3. Especificacion de los Casos de Uso

A continuacion especificaremos de modo formal cada uno de los casosque se han identificado a la hora de realizar el diagrama. Dado que UML nopropone ningun modelo de plantilla para definir los casos de uso, establece-remos una plantilla basica para especificar cada caso en el proceso.

UC#id: Nombre del Caso de Uso Descripcion breve del caso de los ob-jetivos del caso de uso.

1. Actores: Actores que intervienen en el caso de uso.

2. Precondiciones: Conjunto de condiciones que deben cumplirsepara que el caso de uso se realice de forma correcta.

3. Flujo Principal: Secuencia de pasos necesarios que se debenseguir para la correcta realizacion del caso de uso.

4. Postcondiciones: Conjunto de condiciones que se cumplencuando se ejecutan los pasos del flujo principal.

5. Flujo alternativo: Opciones del flujo alternativo en caso de noejecutarse el flujo principal.

Cuadro 3.1: Plantilla para la Definicion de Casos de Uso

Una vez definida la plantilla a emplear para el detallado de los casos deuso podemos realizar el proceso con los casos identificados.

UC1: Generar Medicion El usuario desea realizar una medicion sobreuna serie de contadores hardware de un programa ejecutable.

1. Actores: Usuario

2. Precondiciones: No existen precondiciones porque contamoscon un sistema autonomo que ha detectado los elementos de lamaquina y que contiene todo lo necesario para realizar la medi-cion.

3. Flujo Principal: Para realizar la medicion de forma correcta elusuario debera actuar de acuerdo con los pasos que se siguen enel caso de uso UC5 (Punto de Inclusion).

4. Postcondiciones: Se generan una serie de estadısticas que refle-jan los valores de medicion que se pidieron en la configuracion dela misma.

5. Flujo alternativo: Existen dos flujos alternativos que puedenoperar con los datos obtenidos a partir de la medicion generada.


Se podran guardar los resultados de la medicion (Punto deExtension: Guardar Resultados). En este caso el usuario sim-plemente tendra que dar la ruta donde desea almacenar elfichero y se generara el mismo.Se podra guardar la grafica de la medicion en caso de ha-ber sido generada (Punto de Extension: Guardar Grafica).El usuario indicara la ruta y el tipo de imagen (formato aelegir entre una serie de formatos soportados) que desee ge-nerar para su posterior visualizacion.

UC2: Cargar Medicion El usuario dispone de datos extraıdos de medi-ciones anteriores y desea cargarlos en la aplicacion para examinarlos.

1. Actores: Usuario

2. Precondiciones: Existe la precondicion de disponer de unos re-sultados guardados en el formato apropiado.

3. Flujo Principal: El usuario selecciona el fichero de resultadosdeseados.

4. Postcondiciones: Se publican las estadısticas que reflejan losvalores de medicion guardados en el fichero.

5. Flujo alternativo: -

UC3: Configurar Medicion El usuario necesita configurar la medicion arealizar para poder generar los resultados deseados, por lo tanto setrata de un caso de inclusion.

1. Actores: Usuario

2. Precondiciones: -

3. Flujo Principal: El usuario debe seleccionar medicion normaldentro de las opciones de configuracion. Tambien establecera elnumero de ejecuciones que se realizaran en las pruebas, el bina-rio a ejecutar (programa que se desea probar en el sistema) yseleccionara los eventos hardware que desea medir.

4. Postcondiciones: Una vez realizada la configuracion, se puedeobtener la medicion y enviar la consulta (haciendo una analogıaa las bases de datos) a lperfex para que realice la medicion.

5. Flujo alternativo: El sistema permite realizar otro tipo de me-dicion aparte de la estandar y es la medicion exclusiva (Punto deExtension: Medicion Exclusiva) que se describe en el UC4.

UC4: Medicion Exclusiva El usuario puede desear una medicion distintade la estandar o normal, de acuerdo con el requisito de inclusion deun planificador en tiempo real.


1. Actores: Usuario

2. Precondiciones: -

3. Flujo Principal: El usuario debe seleccionar medicion exclusi-va dentro de las opciones de configuracion. Como caracterısticafundamental de la medicion exclusiva es que permite seleccionarel procesador o procesadores donde se desea lanzar la aplicaciona probar. Mas alla de eso se realizaran la configuracion de ele-mentos comunes, numero de ejecuciones que se realizaran en laspruebas...

4. Postcondiciones: Igual que las establecidas en el caso base deconfiguracion de la medicion, lperfex se encargara de realizar lamedicion exclusiva.

5. Flujo alternativo: -

3.2.2. Analisis de Clases del Sistema

En esta etapa del modelado estatico se determinaran las clases que apa-receran en el sistema. Se trata de una descripcion breve sin llegar a ungrado de explicacion que se obtendra en etapas siguientes del desarrollo delproyecto.

3.2.2.1. Diagrama de Clases

En la Figura 3.2 podemos observar el diagrama de clases de glperfex,donde identificamos las siete clases distintas que lo componen.

Figura 3.2: Diagrama de Clases


3.2.2.2. Descripcion de las Clases

A continuacion describimos la clases indicadas en el diagrama:

MainFrame Es la clase encargada de mostrar la ventana principal de glper-fex. Dentro de ella se encuentra el notebook que albergara los panelesque se describiran a continuacion y se dirigen las operaciones de ge-neracion de mediciones, ademas de dar la opcion de almacenar dichosresultados, su grafica, en caso de haberse generado, y cargar resultadosde mediciones anteriores. Tambien albergara las acciones para abrir laayuda.

Configuration Esta clase alberga el panel encargado de la configuracionde la ejecucion del programa. Esta situada por encima de la clase deentrada y salida, y requiere de ella para tener acceso y contacto con elprograma lperfex. Dentro de ella se realiza la configuracion del numerode ejecuciones, numero de procesadores a elegir, y se elige entre el casobase de prueba (medicion estandar) o el caso de medicion exclusiva.

Counters Clase correspondiente al panel encargado de la configuracion delos contadores elegidos para la medicion, utiliza la clase de entrada ysalida, situandose por encima de esta en nivel de abstraccion de formaque obtiene los contadores propios del sistema que proporciona lperfex.Gestionara como como vemos a continuacion la clase CheckListCtrlpara mostrar y operar con los contadores.

CheckListCtrl Clase correspondiente simplemente al panel donde se es-cribiran y seleccionaran los contadores hardware de la maquina bajoel mando de la clase Counters.

Results De la misma manera que las dos clases anteriores, esta clase corres-ponde a un panel, en este caso al encargado de mostrar los resultadosde las estadısticas ası como la grafica de los mismos (siempre se mos-trara en caso de existir mas de dos resultados de una prueba, unagrafica con un unico punto no tendrıa sentido), para mostrar los resul-tados se hara uso de la clase ResultsPanel. Para recoger los resultadostras la ejecucion se comportara en interaccion de manera analoga a lasclases anteriores con la clase IOInterface.

ResultsPanel Es una clase utilizada por Results simplemente como panelde muestra de resultados.

IOInterface Clase encargada de interaccionar con el programa lperfex, laidea inicial es que se comporte como una capa a parte, de manera quesea cual sea la forma elegida de interaccionar con lperfex, el resto de

34 3.3. Modelado Dinamico

comunicacion con las clases no se vea modificada. Al ser una capa deabstraccion menor, y por propia usabilidad, las clases Configuration,Counters y Results heredaran de ella.

3.3. Modelado Dinamico

En esta fase de la especificacion se procedera a describir como interactuanentre sı los objetos presentes en la aplicacion, modificando el estado de estea lo largo del tiempo. Para ello, siguiendo el modelo de UML, se emplearandiagramas de secuencia. Esto nos servira para realizar la fase de diseno dedatos.

3.3.1. Diagramas de Secuencia

Los diagramas de secuencia describen la colaboracion entre los objetosque componen el sistema. Se tratan de una serie de diagramas de interaccionque detallan las operaciones que se llevan a cabo, que mensajes son enviadosy cuando. El tiempo comienza en el eje y del sistema de coordenadas car-tesiano, de forma que los eventos que ocurran en las partes inferiores seranlos que hayan ocurrido con mayor tiempo transcurrido. De forma analogaobjetos se situaran conforme a su orden de participacion en el eje x.

Estableceremos un diagrama de secuencia para los casos fundamentalesde uso. Sin embargo, y por la simpleza y mınima variacion que suponen, taly como describiremos posteriormente, resumiremos los casos de uso en dosunicos diagramas de secuencia.

3.3.1.1. Generar Medicion

El caso de uso Generar Medicion (UC1), Figura 3.1, es el principal denuestra aplicacion. El usuario pide al programa (aplicando una serie de confi-guraciones) que muestre por pantalla los resultados deseados. Existıan tam-bien dos posibilidades anadidas a este caso, la posibilidad de guardar losresultados de la ejecucion en un fichero, y la posibilidad de guardar unagrafica con los resultados en caso de que esta hubiera sido generada (en casode haber existido mas de una ejecucion, para visualizar graficamente comoesta se ajustaba a la media).

La Figura 3.3 presenta el diagrama de secuencia del caso de uso GenerarMedicion, anadiendo al final del mismo la operacion Guardar Resultadoscomo muestra completa de las posibilidades que el programa si atacamos su


funcionalidad por este sentido. Podrıamos haber anadido tambien al final (ala altura de Guardar Resultados, la posibilidad de Guardar la grafica) sinembargo se trata de un proceso analogo y no se considera necesario redundaren la explicacion.

Figura 3.3: Diagrama de Secuencia: Generar Medicion

A continuacion realizaremos una descripcion paso a paso del diagrama:

1. El usuario, que tiene a su disposicion la interfaz grafica (GUI) glperfexabierta se encuentra con la opcion de configurar la ejecucion. Estecaso de uso tenıa, como vimos en la seccion 3.2.1.3, un caso especial

36 3.3. Modelado Dinamico

de ejecucion exclusiva, hemos determinado no obstante que tendranque aparecer todas las opciones en el mismo espacio en la ventana,adelantandonos de este modo un poco a la especificacion de la interfaz,por lo que no sera necesaria la descripcion, o especificacion de unacomunicacion extra para las comunicaciones del usuario a la GUI.

2. El usuario necesita ahora elegir los contadores para completar la con-figuracion de la ejecucion, por ello pide a la interfaz que muestre loscontadores disponibles por el sistema. En este caso podrıamos haberespecificado el proceso que realiza la GUI a traves de la Interfaz deI/O para obtener esos datos de lperfex, sin embargo este proceso serealiza al iniciar la ejecucion de glperfex y no con la intervencion delusuario, por lo que se situarıa al principio. No obstante, se trata proce-so analogo al de obtencion de resultados, y, por supuesto, sera tomadoen cuenta a la hora de codificar.

3. Una vez la interfaz detecta la peticion de muestra del panel de conta-dores, la GUI muestra al usuario los contadores obtenidos (generadotal y como se comento en el punto 2).

4. El usuario realiza la seleccion deseada entre los contadores que le mues-tra la GUI.

5. Una vez se han reunido los datos necesarios para generar una medicion,el usuario puede pedir a la aplicacion que se genere la medicion de suprograma.

6. La GUI recopila internamente los datos que el usuario ha dado comoentrada.

7. La GUI envıa la informacion recopilada para la ejecucion y mediciona la Interfaz de Entrada/Salida.

8. La Interfaz de Entrada/Salida se encarga de reunir la informacion enuna consulta valida para lperfex, siguiendo las especificaciones de lamisma.

9. La Interfaz de I/O ejecuta lperfex con las caracterısticas requeridas.

10. lperfex realiza las mediciones correspondientes.

11. Una vez realizadas las mediciones, lperfex da sus resultados y la Inter-faz de I/O los recoge.

12. La Interfaz de I/O da formato a los resultados obtenidos de la ejecucionde lperfex.

13. Una vez reunidos los datos de la ejecucion y guardados en las estruc-turas requeridas por la GUI para manejarlos se mandan a la misma.


14. La GUI rellena los paneles de resultados (y la grafica en caso de sernecesario hacerlo) de acuerdo con los datos recibidos en las estructurascorrectas.

15. El usuario puede disfrutar ahora de los resultados de la ejecucion or-denada.

En este caso el usuario podrıa contentarse con la ejecucion dada, peroexiste una posibilidad mas detallada en el diagrama que podrıa realizar(en realidad tal y como comentamos en la introduccion a la descripcionson dos analogas), la opcion de guardar los resultados, puntos 16, 17,18, 19, 20 y 21.

16. El usuario pide a la GUI guardar los resultados.

17. La GUI necesita el nombre del fichero donde se desea guardar y suruta para transmitirlo, por ello lo solicita al usuario.

18. El usuario especifica a la GUI el nombre del fichero a ejecutar.

19. La GUI ejecuta la opcion de guardar resultados de la Interfaz de I/O,que comunicara con el sistema para realizar la operacion.

20. La Interfaz de I/O envıa la confirmacion de escritura del fichero.

21. La GUI notifica al usuario la confirmacion de escritura.

3.3.1.2. Cargar Medicion

El caso de uso Cargar Medicion nos da la oportunidad de mostrar losresultados almacenados tras alguna medicion por pantalla. De esta maneraen la Figura 3.4 se muestra el diagrama de secuencia correspondiente al casode uso.

A continuacion realizaremos una descripcion paso a paso del diagrama:

1. El usuario selecciona la opcion de cargar medicion en la interfaz grafica(GUI).

2. La GUI pide al usuario el nombre y la ruta del fichero que desea cargar.

3. El usuario escribe el nombre del fichero y la ruta en la GUI.

4. La GUI da la instruccion a la Interfaz de Entrada/Salida para abrir elfichero deseado.

38 3.4. Descripcion de la Informacion

Figura 3.4: Diagrama de Secuencia: Cargar Medicion

5. La Interfaz de I/O obtiene el fichero a traves de una llamada al sistemay una vez abierto, almacena los datos en las estructuras requeridas porla GUI para el manejo de los datos.

6. La Interfaz de I/O envıa los datos formateados a GUI.

7. La GUI rellena con los datos correspondientes los paneles de resulta-dos.

8. La GUI muestra los resultados una vez rellenos los paneles (con graficaen caso de haberse generado).

3.4. Descripcion de la Informacion

Antes de realizar un enfoque a la especificacion de la interfaz y a la des-cripcion del resto de componentes del sistema es importante tener en cuentala informacion manipulada por la aplicacion. En concreto nos centraremosen la descripcion de la informacion almacenada y manipulada en los casosde uso Cargar Medicion y en el caso especial al generar medicion, GuardarResultados.

Una de las necesidades que ya hemos comentado en los objetivos y enla especificacion de requisitos de nuestro sistema es la de guardar los datos


de las mediciones. Si estamos inmersos en un proceso de evaluacion delfuncionamiento de una aplicacion, sera capital comparar los resultados delas diferentes mediciones que vayamos obteniendo.

La manera mas util de almacenar estos resultados serıa hacerlo en un for-mato entendible por programas de oficina como hojas de calculo, de formaque no solo pudieran ser visualizados en nuestro sistema, sino que pudie-ran ser manipulados externamente y tratados con una gran facilidad. Otraposibilidad serıa almacenar los resultados en una base de datos. Sin embar-go, incurrirıamos en el supuesto que acabamos de negar, los resultados soloserıan accesibles a traves de nuestro programa o mediante consultas SQL,lo que dificultarıa en gran manera el acceso y manipulacion posterior de losmismos.

Con estas premisas, y tras una breve investigacion se ha escogido laopcion de guardar las estadısticas en un formato especial llamado comma-separated values (CSV).

3.4.1. El Formato CSV

Los ficheros CSV son un tipo de documento sencillo para representardatos en forma de tabla. En ellas las columnas se separan por comas (o puntoy coma, dependiendo del estilo que escogido para la separacion decimal) ylas filas por saltos de lınea. Los campos que contengan una coma, un saltode lınea o una comilla doble deben ser encerrados entre comillas dobles.

El formato CSV es muy sencillo y no indica un juego de caracteres con-creto, ni como van situados los bytes, ni el formato para el salto de lınea.Estos puntos deben indicarse muchas veces al abrir el fichero, por ejemplo,con una hoja de calculo [22].

La principal ventaja de CSV, ademas de la especificacion sencilla1 y so-portada por multitud de lenguajes de programacion, es que las principalesherramientas de hojas de calculo del mercado son capaces de leer y operarcon dicho formato (OpenOffice.org Calc y Excel de Microsoft Office entreellas). De esta manera el usuario de nuestra aplicacion podra tratar los resul-tados en hojas de calculo facilitando la labor de documentacion y evaluacionde las pruebas.

1Probablemente no exista ninguna especificacion mas sencilla que la de CSV. No obs-tante, hay que matizar que no existe una especificacion formal para los ficheros CSV. Lasunicas directrices fueron dadas en el documento RFC 4180 [23] que describe un formatocomun y establece el tipo MIME “text/csv”, registrado por la Internet Assigned NumbersAuthority (IANA). Otra especificacion importante es la provista por el estandar FieldedText [24] que cubre en un apartado el formato CSV. Se pueden encontrar mas referenciasa la especificacion en [25] y [26].

40 3.4. Descripcion de la Informacion

Contador,Resultado,Tiempo,Tiempo Sys

NOMBRECONTADOR0,RESULTADO,TIEMPO,TIEMPOSYSNOMBRECONTADOR1,RESULTADO,TIEMPO,TIEMPOSYSNOMBRECONTADOR2,RESULTADO,TIEMPO,TIEMPOSYSNOMBRECONTADOR3,RESULTADO,TIEMPO,TIEMPOSYS.....

Cuadro 3.2: Ejemplo de Fichero CSV resultado de una medicion

Contador,Resultado medio,Desviacion,Tiempo,Tiempo Sys,N. Ejecuciones

NOMBRECONTADOR0,RESULTADOMEDIO,DESVIACION,T,T_SYS,3N. Ejecucion,Resultado1, Valor12, Valor23, Valor3

NOMBRECONTADOR1,RESULTADOMEDIO,DESVIACION,T,T_SYS,3N. Ejecucion,Resultado1, Valor12, Valor23, Valor3....

Cuadro 3.3: Ejemplo de Fichero CSV resultado de tres mediciones

3.4.2. Nuestro Uso de CSV

Tal y como hemos visto en la descripcion de CSV el formato almacenalos datos en columnas separadas por comas y filas establecidas como saltosde lınea. De esta manera, el objetivo es escribir en el fichero la informaciontabulada que aparecera en los paneles de resultados que comentabamos enlos diagramas de secuencia.

Establecemos dos modelos de registro de datos, la clasificacion viene dadapor el numero de ejecuciones que ha ordenado el usuario de cada contador.

El Cuadro 3.2 muestra el modelo fichero en caso de prueba de una unicamedicion de varios contadores, mientras que el Cuadro 3.3 muestra el ficheroen caso de tres ejecuciones de varios contadores.

La presentacion de estos dos ficheros CSV en OpenOffice.org Calc resul-tara tal y como podemos observar en las Figuras 3.5 y 3.6 facil de tratar por


el usuario final y asegurara que el Caso de Uso de almacenaje de los datossea totalmente funcional una vez escrito el fichero.

Figura 3.5: Ejemplo de Fichero CSV: Una medicion

3.5. Requisitos de la Interfaz

Una vez conocidas las restricciones propuestas a la interfaz, ası comolos casos de uso principales, es hora de dar la primera aproximacion a lasnormas que debera obtener la interfaz final.

Nuestro sistema de medicion tiene dos interfaces fundamentales,

La interfaz proporcionada por Karma Linux original, es decir, uso delperfex mediante la interaccion con a traves del estandar getopts conla terminal y el programa documentada en [1].

La interfaz de Karma Linux 2008, glperfex, en modo grafico con elobjetivo de cumplir su funcion de manera sencilla y agil para el usuario.

En este apartado describiremos la segunda interfaz al tratarse de la pro-pia de nuestro proyecto, y de una de los objetivos fundamentales de KarmaLinux 2008. Las normas o requisitos de glperfex son los siguientes:

42 3.5. Requisitos de la Interfaz

Figura 3.6: Ejemplo de Fichero CSV: Tres mediciones

La interfaz debe permitir la configuracion de la clase de ejecucion(estandar o exclusiva), un numero de ejecuciones dado por el usuario,ası como el numero de procesadores donde se ejecutara la aplicacionen caso de producirse una medicion exclusiva.

Debe permitir la carga de uno o mas eventos de procesador para sumedicion, por lo que estos eventos deberan estar disponibles con unadescripcion de los mismos de manera que el usuario pueda configurarlosde forma correcta.

La interfaz debera publicar los resultados de una forma entendiblepara el usuario.

En caso de producirse la medicion de un evento en mas de una ocasion,se debera generar una grafica con los resultados sobre un eje cartesianode manera que se pueda ver la variacion con respecto de la media delos mismos.

Debera ofrecer la posibilidad de guardar los resultados generados enun fichero, ası como la grafica en caso de haber sido generada.

Debera ofrecer la posibilidad de cargar resultados generados en medi-ciones anteriores en el sistema.

En caso de necesitarla el usuario podra consultar una opcion de ayudadonde aclarar las mismas.


La interfaz debera emitir mensajes de error cuando falten datos porintroducir y/o estos datos sean erroneos de la forma mas sencilla po-sible.

3.6. Descripcion y Especificaciones del Resto delSistema

En las secciones anteriores hemos realizado el analisis de la aplicacionglperfex que con el uso conjunto de lperfex utilizaremos para realizar lasmediciones y obtener los resultados de las mismas tanto de forma exclusivacomo mediante el uso del planificador estandar del kernel de Linux.

Una vez definidas las especificaciones de la aplicacion debemos extendereste analisis al contexto en el que se encuentra la aplicacion, por lo queen esta seccion nos encargaremos de analizar todos los objetos del dominioası como sus requisitos funcionales y no funcionales.

3.6.1. Planificacion de Procesos

Los sistemas operativos multitarea se dividen en dos tipos, los sistemasoperativos multitarea cooperativa y los de multitarea de reemplazo [2].

Multitarea Cooperativa En estos sistemas un proceso no deja de ejecu-tarse hasta que el mismo ası lo decida, el acto de suspension voluntariade la ejecucion es llamado yielding o cesion. Debido a esto, el proce-sador no puede tomar decisiones globales sobre que proceso ejecutar,los procesos pueden monopolizar el procesador durante un periodo detiempo muy largo y se corre el riesgo de que dichos procesos no cedanjamas uso del procesador. Uno de los escasos ejemplos de sistemas ope-rativos multitarea cooperativa es el MacOS 9 y versiones anteriores.

Multitarea de Reemplazo Al contrario que en los sistemas multitareacooperativa aquı es el planificador el que decide cuando un procesodebe cesar su ejecucion y cuando un proceso debe continuarla. El actode suspender una tarea en ejecucion es llamado preempt o reemplazo.El tiempo que un proceso ejecuta antes de su reemplazo es determina-do con anterioridad, aunque puede variar en caso de imprevistos. Esteperiodo de ejecucion antes de su reemplazo es llamado cuanto y varıapara cada sistema operativo y cada tarea. Unix posee multitarea dereemplazo desde el comienzo y por tanto Linux tambien, al igual quela mayorıa de sistemas operativos modernos. En Linux el cuanto de

44 3.6. Descripcion y Especificaciones del Resto del Sistema

tiempo de ejecucion es calculado dinamicamente permitiendo al plani-ficador tomar decisiones globales sobre el sistema. Esta naturaleza dereemplazo y division en cuantos, previene que un proceso monopolicela CPU.

Como hemos podido ver, en Linux, una tarea no obtiene el control ab-soluto de la CPU de ninguna forma. En la rama 2.6 del kernel se han des-activado las llamadas sti() y cli(), restringiendo el acceso a la activaciony desactivacion de interrupciones, lo que obliga al programador a usar otrastecnicas para la sincronizacion de drivers. Esta restriccion, que deja todo elcontrol de los procesos al sistema operativo, tiene el objetivo de asegurarun sistema fiable con una mayor transparencia y mejor interaccion con elusuario final.

Un ejemplo de ello podemos encontrarlo en la forma de tratar los cuan-tos de tiempo en el planificador del kernel de Linux. Tal y como podemosobservar en la Figura 3.7, el planificador asigna un cuanto de tiempo quevarıa desde los 10 milisegundos hasta los 200 dependiendo de la prioridadde la tarea y de la interactividad que requiera, es decir, a mayor interactivi-dad, mayor sera el cuanto de tiempo, ya que es preferible que el usuario nopermanezca a la espera eternamente.

Figura 3.7: Cuantos de tiempo en el planificador de Linux

Estas decisiones tomadas para mejorar la capacidad de interaccion delsistema operativo son a su vez el principal problema a la hora de realizarlas mediciones. Nuestra tarea es reemplazada por otra, pero sin embargo loscontadores siguen midiendo de tal forma que incluso creando una serie decontadores virtuales que midan solo una tarea desactivandose al ser reem-plazada, los contadores medirıan el cambio de contexto, la llamada al nuevoproceso y en cada cuanto que vuelva a ocupar nuestro proceso el procesador,los contadores medirıan de nuevo su cambio de contexto, y lo que es masimportante, el proceso cometerıa errores forzados en la memoria cache, quese traducirıan en una cantidad variable de ciclos de procesador adicional,mas accesos a cache tanto de nivel 1 como de nivel 2, etc.


3.6.2. Descripcion de Componentes

Una vez descrito el contexto bajo el que se coloca la aplicacion es elmomento de describir los principales objetos que intervendran en nuestroentorno. Dado que glperfex es una interfaz para lperfex nos referiremos apartir de este punto a los objetos que intervienen en las mediciones realizadaspor lperfex.

En la Figura 3.8 podemos observar para introducirnos en el complejosistema de dependencias que necesita lperfex para realizar su cometido, unavez visualizada la estructura introduciremos cada componente para poderespecificar sin problemas los requisitos de los diferentes subsistemas.

Figura 3.8: Estructura de Componentes de Karma GNU/Linux

3.6.2.1. Glibc

Es la biblioteca estandar de C en su sexta version para practicamentetodo programa compilado en entornos Unix. Glibc divide los procesos en


una serie de llamadas al sistema divididas en funciones y estructuras entrelas que se encuentra una funcion que se ejecuta en el contexto del proce-so como inicializacion del mismo, donde se pueden colocar constructores yotros elementos, y otra que se ejecutara al final del proceso pero dentro desu contexto, es decir, antes de que el proceso definitivamente muera. Graciasa esto, Glibc permite sustituir esas funciones para que un proceso determi-nado crea que lo que debe ejecutar es codigo que la aplicacion inserto en sucontexto para inicializar los contadores, ya que si los contadores son inicia-lizados fuera del contexto de una aplicacion, mediran fuera de ella.

3.6.2.2. RTAI

RTAI es una implementacion de Linux para tiempo real basada en RTLi-nux [30]. Anade un pequeno kernel de tiempo real bajo el kernel estandarde Linux y trata al kernel de Linux como una tarea con la menor prioridad.RTAI ademas proporciona una amplia seleccion de mecanismos de comuni-cacion entre procesos y otros servicios de tiempo real.

La Real-Time Application Interface actua como dominio de ADEOS. Co-mo vimos con anterioridad, ADEOS se coloca un nivel por encima del kerneldel sistema operativo e intercepta sus interrupciones y llamadas a sistemacon la finalidad de poder tomar decisiones sin ningun tipo de restriccion.

Figura 3.9: Posicionamiento de ADEOS en el sistema operativo

Arquitectura[28] RTAI trata el kernel estandar de Linux como una tareade tiempo real con la menor prioridad, lo que hace posible que se eje-cute cuando no haya ninguna tarea con mayor prioridad ejecutandose.


Las operaciones basicas de las tareas de tiempo real son implemen-tadas como modulos del kernel. RTAI maneja las interrupciones deperifericos y son atendidas por el kernel de Linux despues de las posi-bles acciones de tiempo real que hayan podido ser lanzadas por efectode la interrupcion.

La Figura 3.10 muestra la arquitectura basica de RTAI. Las interrup-ciones se originan en el procesador y en los perifericos. Las originadasen el procesador (principalmente senales de error como division porcero), son manejadas por el kernel estandar, pero las interrupcionesde los perifericos (como los relojes) son manejadas por RTAI InterruptDispatcher. RTAI envıa las interrupciones a los manejadores del ker-nel estandar de Linux cuando no hay tareas de tiempo real activas.Las instrucciones de activar/desactivar las interrupciones del kernelestandar son reemplazadas por macros que se enlazan con las instruc-ciones de RTAI. Cuando las interrupciones estan desactivadas en elkernel estandar, RTAI encola las interrupciones para ser repartidasdespues de que el kernel estandar haya activado las interrupciones denuevo.

Adicionalmente, se puede ver en la Figura 3.10 el mecanismo de co-municacion entre procesos (IPC), que esta implementado de forma se-parado por Linux y por RTAI. Tambien existe un planificador distintopara Linux y para RTAI.

HAL - Hardware Abstraction Layer[29]Los desarrolladores de RTAI introducen el concepto de Real TimeHardware Abstraction Layer (RTHAL) que es usado para inter-ceptar las interrupciones hardware y procesarlas despues. RTHALes una estructura instalada en el kernel de Linux que reune lospunteros a los datos internos del hardware relacionados en el ker-nel y las funciones necesarias por RTAI para operar. El objetivode RTHAL es minimizar el numero de cambios necesarios sobre elcodigo del kernel y por tanto mejorar el mantenimiento de RTAIy del codigo del kernel de Linux. Con RTHAL, las diferentes ope-raciones (ej. manejar interrupciones) son mas faciles de cambiaro modificar sin tener que interferir con la implementacion de Li-nux. Por ejemplo, la estructura de RTHAL contiene la tabla demanejadores de interrupcion, la cual es un lista de las funcionesque son llamadas para manejar las diferentes interrupciones. Elcambio consiste unicamente en modificar unas 20 lıneas del codigodel kernel de Linux y anadir unas 50 nuevas lıneas.Cuando RTHAL es instalado en Linux, las funciones y las estruc-turas de datos relacionadas con la interaccion con el hardwareson reemplazada por punteros a la estructura de RTHAL.


Figura 3.10: Composicion RTAI y Linux

PlanificacionLa unidad de planificacion de RTAI es la tarea. Siempre hay almenos una tarea, llamada kernel de Linux, que ejecuta como latarea de menor prioridad. Cuando las tareas de tiempo real sonanadidas, el planificador da entonces mayor prioridad a estas so-bre la tarea del kernel de Linux. El planificador proporciona servi-cios tales como suspend, resume, yield, make periodic o wait until,que son usadas en varios sistemas operativos de tiempo real.El planificador es implementado como un modulo del kernel dedi-cado lo que facilita la implementacion de planificadores alterna-tivos si es necesario. Actualmente hay tres tipos de planificadoresdependiendo del tipo de maquina:

• Uniprocesador (UP).• Multiprocesador simetrico (SMP). Esta disenado para

maquinas SMP y proporciona un interfaz para las aplica-ciones de forma que es posible seleccionar el procesador oprocesadores que deben ejecutar una tarea. Si el usuario noespecifica un procesador para la tarea, SMP selecciona el pro-cesador en funcion de la carga de trabajo.

• Multi-Uniprocesador (MUP). Puede ser usado con ambos,pero al contrario que SMP, a las tareas se les debe especificar


el procesador que deben usar. Viendolo por el lado positivo,el planificador MUP permite unos mecanismo de tiempo masflexibles para las tareas que los planificadores SMP o UP.

Caracterısticas Con el objetivo de hacer el desarrollo de aplicaciones masfaciles y flexibles posibles, los desarrolladores de RTAI han introduci-do diferentes mecanismos para la comunicacion entre procesos (IPC),entre las tareas de tiempo real y los procesos en el espacio de usua-rios. Como anadido al mecanismo IPC, RTAI proporciona servicios demanejo de memoria y threads compatibles con POSIX.

Comunicacion entre procesos (IPC - Inter-process comu-nication)RTAI proporciona una variedad de mecanismos para la comu-nicacion entre procesos. Aunque los sistemas Unix proporcionanmecanismos similares a IPC para los procesos en el espacio deusuario, RTAI necesita proporcionar una implementacion propiapara que las tareas de tiempo real puedan usar este mecanismoy no usen el estandar del kernel de Linux. Los diferentes meca-nismo de IPC estan incluidos como modulos de kernel, lo quefacilita la carga cuando son necesarios. Como ventaja adicional eluso de modulos para los servicios, IPC facilita el mantenimientoy la expansion.El antiguo mecanismo basico de comunicacion de RTAI eran losFIFOs. FIFO es un asıncrono y no bloqueante canal de comuni-cacion entre los procesos de Linux y las tareas de tiempo real.RTAI puede lanzar senales cuando hay eventos en el FIFO (es-critura de nuevos datos). Los procesos en el espacio de usuariopueden entonces crear un manejador para la senal por los me-canismos estandar de Unix. Sin embargo, este mecanismo no esnecesario para los procesos de usuario que quieran leer o escribirdel FIFO. Adicionalmente, puede haber multiples lectores y es-critores en el FIFO. Ademas, los identificadores FIFO pueden serdinamicamente localizados con un nombre simbolico.Los semaforos es otra herramienta basica de sincronizacion entreprocesos usada en los sistemas operativos. RTAI proporciona unAPI para usar semaforos, aunque cada semaforo esta tecnicamen-te asociado a un FIFO, por tanto cada semaforo usa una entradaglobal del FIFO. Como anadido al servicio basico de semaforos,un semaforo puede estar asociado con un reloj, el cual puede serusado para despertar un proceso encolado en un semaforo, inclusocuando el semaforo aun esta cerrado.La comparticion de memoria proporciona una alternativa a IPCy al paradigma FIFO cuando un modelo de comunicacion dife-


rente es requerido. La memoria compartida es un bloque comunde memoria que puede ser leıdo o escrito por un proceso y unatarea en el sistema. Como los diferentes procesos pueden operarde forma asıncrona en la region de memoria, es necesario un di-seno para asegurar que los datos no sean sobreescritos de formaintencionada.Finalmente, el metodo mas flexible de IPC quizas sean los mailbo-xes. Cualquier numero de procesos pueden enviar y recibir men-saje de y desde un mailbox. Un mailbox almacena mensajes hastaun lımite que se defina, y contrario a los FIFOs, mailbox preservalos mensajes que estan en el lımite. Puede haber un numero arbi-trario de mailboxes activos en el sistema simultaneamente. RTAItambien facilita la comunicacion entre procesos mediante RPC.Gestion de memoriaEn las primeras versiones de RTAI la memoria tenıa que ser asig-nada estaticamente y no era posible la asignacion en tiempo real.Sin embargo en las actuales versiones se incluye un modulo gestorde memoria que permite la asignacion dinamica de memoria porparte de las tareas de tiempo real usando un interfaz basado enuna biblioteca estandar de C.RTAI preasigna trozos de memoria antes de la ejecucion de tiem-po real. Cuando la tarea de tiempo real llama a la funcionrt_malloc(), la respuesta que obtiene es el trozo preasignado.Antes de que el espacio se agote, RTAI reserva nuevos trozos dememoria (preasigna) para futuras llamadas. De manera similarocurre con la funcion rt_free(), en este caso, se libera la memo-ria preasignada a la espera de futuras reservas. Cuando la sumade memoria liberada es mayor que un valor para una marca, seordena su liberacion.Threads POSIXRTAI tiene modulos que proporcionan la implementacion de th-reads de acuerdo al estandar POSIX 1003.1c. Usando las opera-ciones especificadas en el estandar, el usuario puede manejar demanera similar a como lo hace con los threads POSIX convencio-nales, excepto en cuanto a los conceptos de joining y detaching.Los threads de un mismo proceso comparten el espacio de memo-ria, por tanto es facil el intercambio de informacion entre ellos, sinembargo, el uso de areas de memoria compartida son necesariaspara la sincronizacion. Tambien se proporcionan los mecanismosde mutex y de variables de condicion.LXRT: User-space Interface to RTAILXRT es una API para RTAI que hace posible el desarrollo deaplicaciones de tiempo real en el espacio de usuario sin tener que


crear modulos para el kernel. Esto es util en primer lugar porqueel espacio de memoria destinado al kernel no esta protegido deaccesos invalidos, lo que puede provocar la corrupcion de datos yel mal funcionamiento del kernel de Linux. En segundo lugar, si elkernel es actualizado, los modulos necesitan ser recompilados loque puede provocar que sean incompatibles con la nueva version.

Mientras se desarrolla una aplicacion de tiempo real en el espaciode usuario el programador puede usar las herramientas estandarde depuracion hasta que ya no contienen errores, pero en estecaso se trata de procesos de tiempo real flexibles (soft). Ademas,los servicios proporcionados por las llamadas al sistema de Li-nux estan disponibles para las tareas. La ventaja de esto es quecuando la aplicacion este libre de errores puede convertirse a unmodulo en el espacio del kernel, por lo que ya tendremos unatarea de tiempo real estricto. Sin embargo, al hacer esto, las lla-madas al sistema utilizadas no sirven y deberan ser cambiadaspor las proporcionadas por RTAI.

El cambio de la aplicacion de procesos del espacio de usuario atareas de tiempo real es facil porque LXRT proporciona una APIsimetrica para la comunicacion entre procesos y otros servicios deRTAI, lo que significa que la misma API puede ser usada por lastareas de tiempo real y por los procesos del espacio de usuario. Lamisma API de LXRT puede ser tambien usada cuando 2 procesosdel espacio de usuario o 2 tareas de tiempo real se comunicanentre si, esto implica que varios relojes y mensajes del sistemaproporcionados por LXRT puedan ser usados incluso cuando laaplicacion no requiera tiempo real.

LXRT permite a las aplicaciones el intercambio dinamico entretiempo real flexible y estricto mediante el uso de una simple lla-mada en el espacio de usuario. Cuando una aplicacion esta en elmodo de tiempo real flexible, usa el planificador de Linux, perorequiere el uso de la polıtica de planificacion FIFO. Sin embar-go la planificacion de procesos FIFO puede provocar la perdidade ranuras de tiempo por varias razones, por ejemplo, porque seesta ejecutando un manejador de interrupciones o el planificadorde tareas de RTAI.

Con el objetivo de facilitar el paso a tiempo real estricto, LXRTcrea un agente en el espacio del kernel para cada proceso del es-pacio de usuario con requerimientos de tiempo real. Cuando elproceso entra en modo de tiempo real estricto, el agente desac-tiva las interrupciones, y mueve al proceso fuera del planificadorde Linux y lo anade a la cola del planificador de RTAI. Ahora elproceso no es interrumpido por las interrupciones de otro proceso


de Linux. Para poder realizar este cambio el proceso debe asegu-rar que la memoria usada por el proceso este en la memoria RAMy debe desactivar la paginacion usando la funcion mlockall().Esta llamada no debe ser usada en modo tiempo real estricto.Aunque los desarrolladores de RTAI ven bien el desarrollo deaplicaciones de tiempo real estricto usando LXRT, el tiempo derespuesta no es tan bueno como la ejecucion de las tareas comomodulos del kernel.

3.6.2.3. PAPI

PAPI consiste en un conjunto de bibliotecas de funciones que nos per-miten realizar pruebas de rendimiento de hardware con codigo creado pornosotros mismos. Usando estas bibliotecas podremos crear benchmarks, me-dir FLOPS, MIPS, etc, en el procesador. Estas bibliotecas constan de 40funciones de bajo nivel y 6 funciones de alto nivel. Estas ultimas estan cons-truidas usando las primeras para facilitar los test del hardware, tanto enFortran como en C. Con todas estas funciones se nos proporciona acceso alos contadores hardware de nuestro procesador y con ellos se pueden medirocurrencias de diferentes eventos para obtener las medidas de rendimientoque deseemos.

PAPI nos da soporte para contadores hardware en Windows NT (y su-cesores) y Linux, incluyendo este ultimo soporte para varias arquitecturasde procesador.

Arquitectura PAPI surgio con la idea principal de hacer frente a la cre-ciente aparicion de diversos sistemas de medicion exclusivos de cadaarquitectura, hecho que complica la comparacion entre las mismas alno existir un entorno comun de evaluacion de rendimiento.

Por este motivo, PAPI se divide en una capa independiente de lamaquina sobre la que se ejecuta y una capa dependiente del hardware(Figura 3.11).

La capa inferior consta de una extension al sistema operativo quelo aprovecha para acceder al hardware de medicion de eventos de lamaquina, por lo que variara para cada hardware y para cada sistemaoperativo.

La capa superior esta formada por varios componentes opcionales, quedependeran del hardware de la maquina, como el control de desborda-miento (overflow), el multiplexado y las interrupciones del temporiza-dor ya que no estan disponibles en todas las maquinas. En esta capase situan las dos divisiones de la API, la de bajo nivel y las funciones


Figura 3.11: Arquitectura del sistema PAPI

de alto nivel que son usadas para las herramientas de medicion, gra-cias a lo cual se consiguen herramientas que, al igual que PAPI, seranindependientes de la plataforma.

3.6.2.4. Live CD

Para terminar el recorrido al contexto del sistema el ultimo punto amencionar es el entorno donde encontraremos el sistema. Como menciona-mos en apartados anteriores, la complicacion que entrana la configuraciondel sistema, con la necesidad de aplicar parches y configurar el kernel deLinux de una manera especial, ası como la instalacion de bibliotecas com-plementarias apartan al usuario medio de nuestra aplicacion. Por ello, se haescogido la integracion del sistema en un Live CD, basado en la distribucionde GNU/Linux Debian.

Esta distribucion basada en Debian contara con todo el entorno realizadopara la realizacion de las pruebas, ası como con herramientas de compilacion


y depuracion, edicion de textos y un entorno grafico.

En Debian la realizacion de Live CDs (actualmente en la rama testingy unstable) se basa en un paquete de aplicaciones llamado live-helper [27].Una vez instalado live-helper contamos con una serie de herramientas sen-cillas para realizar el proceso creacion del Live CD, existiendo incluso unaherramienta grafica de configuracion denominada live-magic.

3.6.3. Requisitos Funcionales

Una vez contextualizado el sistema, podemos establecer los requisitosfuncionales de los diferentes componentes.

3.6.3.1. Performance API

El componente de medicion de eventos trae una serie de requisitos fun-cionales a satisfacer, la mayorıa de ellos ligados unicamente a los contadoreshardware.

La Performance API debe emplearse teniendo en cuenta que de los datosdisponibles en las distintas maquinas, algunos forman una base comun quedebera estar accesible desde todas ellas, estos son:

Unidades Enteras Numero de instrucciones enteras ejecutadas y numerode instrucciones por segundo.

Unidades de Punto Flotante Instrucciones de punto flotante por segun-do e instrucciones de multiplicacion o division en punto flotante.

Unidad de Prediccion de saltos, aciertos y fallos en la prediccionConsulta de la informacion sobre los saltos que utiliza.

Memoria Cache Numero de aciertos, fallos y acceso a la misma en losdistintos niveles, tanto refiriendonos a toda la cache como solo a la dedatos o solo a la de instrucciones (si en el procesador se encuentranseparadas).

Eventos Generales Acerca de distintas ocurrencias de la maquina, talescomo tiempos de ejecucion de un codigo, cantidad de ciclos empleados,frecuencia real del procesador o interrupciones hardware.

Ademas de medir las ocurrencias de estos eventos o los tiempos, tambienresulta interesante de cara a la comprension de la arquitectura del procesa-dor, o del compilador para dicho procesador, inferir medidas a partir de las


obtenidas directamente mediante el conteo de eventos, como por ejemplo latasa de reuso de lınea de cache, etc.

En general se habla de dos tipos de eventos, unos cuentan ocurrencias ylos otros cuentan duracion. Los primeros se cuentan cada vez que ocurre elevento que se contabiliza (lo que se traduce en un incremento del contadorcorrespondiente). Para los de duracion el contador muestra el numero totalde ciclos en los que la condicion es cierta.

Esta monitorizacion tambien debe estar disponible y se puede realizargracias a unos registros internos que la CPU incorpora y que pueden serinicializados, modificados y consultados.

3.6.3.2. RTAI

Como comentamos en el apartado 3.6.1, el planificador estandar del ker-nel de Linux no satisface nuestros requisitos. Necesitamos un componenteen el proyecto que se encargue de reemplazar el planificador no deseado poruno que nos permita aislar un proceso en el procesador que determinemos.

El sistema escogido debe cumplir con una serie de requisitos por lo tanto:

Debe poder ignorar las interrupciones del sistema operativo cuandose desee, de esta forma eliminaremos este foco de intromision en lasmediciones.

Debe estar situado por encima del sistema operativo con el fin depoder planificar incumpliendo las normas del planificador del kernelde Linux.

Debe permitir la monopolizacion de las CPUs seleccionadas por partede un proceso, sin que ningun otro pueda reemplazarle ni ocupar alguncuanto de tiempo mientras el proceso crıtico este en ejecucion.

Cuando no se realice ninguna tarea especıfica, el sistema debe permitirque sea el planificador de Linux el que se encargue de los procesos, esdecir, no queremos un entorno exclusivo cuando se vaya a ejecutar unproceso no crıtico.

3.6.3.3. Live CD

Para que el entorno obtenido finalmente sea funcional y se ajuste a lasnecesidades del proyecto ha de satisfacer las siguientes necesidades:


Configuracion automatica Configuracion de la red, configuracion graficay configuracion del resto del sistema y perifericos.

Acceso a la Red Una vez detectada la configuracion hardware de red, elsistema debera intentar configurar el acceso a red de forma automaticay en caso de no conseguirse se debera pedir al usuario los datos de laconexion para establecer el acceso a internet.

Permitir el acceso al Sistema desde fuera de la Red De manera queno sea necesaria la presencia fısica para la realizacion de las mismas, elsistema debera hacer de servidor para cualquiera que conozca la clavedel mismo pueda acceder para realizar cualquier accion que podrıarealizar en la maquina de forma presencial.

Software de Oficina Incluyendo todo el software necesario para generardocumentos de texto y datos estadısticos. Tambien se deben incluirclientes de correo y navegadores web.

Herramientas de Desarrollo Depuradores, compiladores para manejarlos programas que deseamos tratar y optimizar su rendimiento pro-gresivamente.

Entorno Grafico Para alejar al usuario inexperto de complicaciones e in-cluir los paquetes comentados en el punto anterior.

Posibilidad de Instalacion De manera que el usuario pueda instalar elsistema en su ordenador de modo nativo.

3.6.4. Requisitos No Funcionales

A parte de los requisitos anteriormente indicados, la solucion adoptadatiene varios requisitos adicionales de caracter general, los mas notables sonlos siguientes:

Reusabilidad, el sistema puede ampliarse y es necesario que cada unade las partes que lo compone este perfectamente definido y modulari-zado para permitir que en caso de ampliacion encaje adecuadamentecon el resto del sistema. Cada modulo ademas ha de tener en cuen-ta este punto y permitir la creacion del sistema sin un determinadomodulo para permitir el desarrollo independiente de los mismos.

Sistema multiplataforma, punto que como se comento anteriormente sesatisface con la creacion de un sistema autonomo, ya que si no necesitauna plataforma ya que esta incluida en la solucion, no hay necesidadde multiplataforma.


Adaptabilidad a nuevos entornos y formas de funcionamiento. Estose debera cumplir ofreciendo el codigo fuente junto a la solucion paraque todo aquel que necesite adaptar el sistema a sus necesidades puedarealizar la adaptacion con un coste mınimo y sin necesidad de reali-zar ingenierıa inversa. Tanto el entorno como la aplicacion deberancumplir este requisito, puesto que ambas partes pueden necesitar deadaptaciones previas en distintos campos.

Escasos requisitos hardware para el funcionamiento, ya que se pre-tende una solucion capaz de medir eventos en cualquier plataformacon arquitectura PC, se debe usar software que no requiera una granvelocidad de procesador, o una buena tarjeta grafica para el entornografico que acompana a la distribucion etc.

Capıtulo 4

Diseno del Sistema

A lo largo de los capıtulos anteriores se ha realizado una descripcion delas caracterısticas, restricciones y requisitos que debe cumplir el proyecto.Mientras que la fase de analisis trata recopilar todas las especificacionesnecesarias para lograr la solucion del problema independientemente de laforma de llegar a la misma, durante el diseno se tomaran las decisionespertinentes acerca de la forma en la que se resolvera el problema.

El diseno del sistema se dividira en cuatro partes:

El entorno que necesita la aplicacion para ejecutarse. Es decir: confi-guracion del kernel y entornos tanto de tiempo real como de medicionde eventos.

La aplicacion en sı. Seccion en la que indicaremos el plantamiento ydesarrollo de glperfex.

El diseno de la interfaz de la aplicacion.

El sistema final en el que se incorporara la aplicacion, es decir el en-torno necesario de herramientas basicas en la maquina donde se ana-lizara el rendimiento.

4.1. Diseno del Entorno de Ejecucion

El entorno de ejecucion debe contemplar tres apartados fundamenta-les: un kernel compilado y preparado con los parches necesarios de RTAIy perfctr, el entorno en tiempo real (RTAI+ADEOS), y el entorno para lamedicion de eventos (perfctr+PAPI).

59

60 4.1. Diseno del Entorno de Ejecucion

4.1.1. Compilacion y Preparacion del Kernel

El entorno de ejecucion dispondra de un kernel de Linux con todas lasmodificaciones necesarias para la interaccion con el entorno de tiempo realy de medicion de eventos.

El primer paso para la preparacion del kernel sera la descarga de unacopia sin modificaciones previas. Las distribuciones de GNU/Linux suelenincluir parches de serie en el kernel para mejorar la integracion e inter-accion con los componentes que incluyen. Sin embargo, algunos de estosparches provocan problemas de rendimiento y funcionamiento de RTAI.Por ello, descargaremos un kernel vanilla (en el argot de Gentoo Linux)de http://www.kernel.org, en este caso el kernel 2.6.22.15.

Una vez descargado el kernel pertinente deberemos construir el parcheque incluya las modificaciones necesarias para ambos entornos. El procesorecomendado para realizar el parche es el siguiente:

1. Se realizan tres copias del kernel linux-2.6.22.15 original en unacarpeta.

2. Una vez realizadas las tres copias del kernel aplicamos de for-ma independiente el parche HAL (modificacion de ADEOS) deRTAI a linux-2.6.22.15-rtai y el parche de perfctr-2.6 paralinux-2.6.22.15-papi.

3. Una vez realizada la aplicacion de los parches procederemos a unacomparacion de tres vıas de los directorios. Una manera sencilla derealizar la comparacion es mediante la aplicacion grafica Meld. El mo-tivo de no aplicar los dos parches consecutivamente sobre el kernel esque existen modificaciones comunes a varias lıneas de codigo con dis-tintas implementaciones, y por ello es necesaria una evaluacion lıneaa lınea de los cambios, decidiendo la solucion no-conflictiva.

4. Una vez realizado el proceso obtendremos un kernel parcheado conlas caracterısticas necesarias para que los dos entornos funcionen demanera correcta.

Lo correcto, una vez tengamos el kernel, sera extraer un par-che de las modificaciones a traves del comando diff y gene-rar tres paquetes precompilados deb1, uno para la imagen delkernel (linux-image-2.6.22.15-karma.deb), otro para las cabeceras

1Deberemos de tener en cuenta la configuracion que comentaremos posteriormente deperfctr. En la version original de Karma Linux (basada en Gentoo) se realizo un ebuild.

Diseno del Sistema 61

(linux-headers-2.6.22.15-karma.deb) y un ultimo paquete con las fuen-tes (linux-source-2.6.22.15-karma.deb).

4.1.2. Creacion del Entorno en Tiempo Real

RTAI necesita para su ejecucion y correcto funcionamiento el sistemaADEOS, tal y como se comento en la descripcion de la fase de analisis.La instalacion de este sistema requiere una recompilacion del kernel de Li-nux con parche especıfico que coloca el sistema ADEOS por encima de el,permitiendo su posterior utilizacion por parte de RTAI.

4.1.2.1. Configuracion de RTAI

Para la compilacion de RTAI, ademas de la aplicacion del parche deADEOS, es necesaria la configuracion del propio sistema a crear. La confi-guracion de RTAI sigue un sistema analogo al del kernel de Linux. Es decir,antes de realizar el proceso de compilacion (make, make install) proce-deremos a crear un Makefile de acuerdo con los objetivos de configuraciondeseados. Para obtener este Makefile teclearemos make menuconfig, siguien-do las siguientes indicaciones del Cuadro 4.1 en el dialogo que aparecera acontinuacion.

General --->(/usr/realtime) Installation directory(/usr/src/linux) Linux source treeRTAI Documentation --->[*] Build DocBook XML documentation (HTML/PDF)[*] Let the DocBook XML tools use network

Base system --->[*] Kernel/User space scheduler without RTAI own kernel tasks[*] Kernel/User space scheduler with RTAI own kernel tasks

Cuadro 4.1: Configuracion del Entorno en Tiempo Real

Las primeras opciones establecidas, dentro del apartado General indi-can los directorios de instalacion del sistema y del arbol del kernel a utilizar.Dentro de este apartado modificaremos la RTAI Documentation seleccio-nando la construccion de la documentacion en HTML y PDF para permitirusar la red a las herramientas de DocBook (el sistema de generacion dedocumentacion empleado por RTAI).

Las opciones seleccionadas dentro de Base System forman parte del pro-pio sistema a generar, su significado es el siguiente:

62 4.1. Diseno del Entorno de Ejecucion

Kernel/User space scheduler without RTAI own kernel taskEspecifica que el planificador soporte hard real time para todos losobjetos planificables de Linux (procesos, hilos y kthreads2).

Kernel/User space scheduler with RTAI own kernel task Indicaque no deseamos solamente hard real time para objetos del sistema,sino tambien para las tareas de RTAI. Esta opcion hace tambien quela llamada a creacion de procesos de RTAI cree un propio proceso deRTAI en modo kernel, por lo que se reduce notablemente el tiempode ejecucion eliminando los cambios de contexto.

4.1.3. Creacion del Entorno de Medicion de Eventos

El entorno PAPI necesita, al igual que RTAI, unas funcionalidades queno estan incluidas por defecto en el kernel de Linux por lo que es necesarioaplicar una serie de modificaciones al mismo en forma de parche.

4.1.4. Integracion del Sistema de Medicion en el kernel deLinux

La configuracion (configuracion make menuconfig del kernel de Linux)necesaria para el sistema de medicion de eventos escogido (perfctr) se mues-tra en el cuadro 4.2.

Processor type and features --->Performance-monitoring counters support --->

<*> Performance monitoring counters support[ ] Additional internal consistency checks[ ] Init-time hardware tests[*] Virtual performance counters support[*] Global performance counters support

Cuadro 4.2: Configuracion de perfctr dentro del kernel de Linux

La justificacion de las selecciones es la siguiente:

2Un kthread es un hilo creado bajo modo kernel para realizar algunas tareas de fondo.A pesar de que habitan en modo kernel y jamas son enviados a modo usuario, los kthreadsson tratados como procesos normales y pueden ser reemplazados de la cola de planificacioncomo cualquier otro proceso. Solo son creados durante el inicio o por otro kthread


Additional internal consistency checks Esta opcion no sera necesaria,ya que se utiliza para labores de depuracion.

Init-time hardware test Permite al driver realizar tests del hardwareadicionales durante la inicializacion de modo que se puedan realizaralgunas comprobaciones, algo util cuando el procesador sobre el quese van a realizar las pruebas principales no es conocido o estandar.En la mayorıa de los casos esto no es ası por lo que esta opcion no esnecesaria.

Virtual performance counters support Crea contadores virtuales apartir de los contadores hardware encargados de medir cada proce-so, esto evita ruidos y aumenta la efectividad de las mediciones.

Global performance counters support Permite que se lean y controlentodas las mediciones realizadas en todos los procesadores.

Una vez establecida la configuracion necesaria del kernel de Linux seseguira la instalacion tıpica que proporcionan las herramientas de autocon-figuracion de GNU.

4.2. Diseno de la Aplicacion

En este apartado se describen las clases que son necesarias para la aplica-cion y que se desean implementar. Las clases han sido extraıdas de la propiadefinicion del problema, de los diagramas de casos de uso y de los diagramasde secuencia.

Cada una de estas clases que seran descritas incluyen: una breve des-cripcion de la funcionalidad de la clase, los diferentes atributos que formanla clase y los metodos que la componen. De estas clases solo se detallaranaquellos atributos y metodos que se consideran mas importantes.

4.2.1. Clase MainFrame

Clase que contiene el marco principal de la aplicacion grafica, dentrode el se activaran las pestanas donde se configuran las diferentes opcionesdel programa expresadas en pestanas. Es decir, la pestana de Configuracion,clase Configuration, la pestana de Contadores, clase Counters y la pestanade Resultados, clase Results.

64 4.2. Diseno de la Aplicacion

4.2.1.1. Metodos

init Constructor de la clase.

GetAndSendSelections Recoge las selecciones que se han realizado ycomprueba si se puede proceder a aplicar la medicion.

OnOpen Abre los resultados que estan almacenados en un fichero dado porel usuario.

OnSave Guarda los resultados de la ejecucion en caso de haber sido gene-rados estos.

OnSaveDraw Guarda la grafica despues de comprobar si esta ha sido ge-nerada.

OnAbout Construye la ventana de About, donde podremos consultar losautores de la aplicacion ası como su licencia completa.

OnExit Cierra la ventana.

4.2.1.2. Atributos Publicos

config Instancia de la clase Configuration.

counters Instancia de la clase Counters.

stats Instancia de la clase Results.

nb NoteBook con los paneles de configuracion, contadores y resultados ensus pestanas.

4.2.2. Clase Configuration

Desde esta clase se muestran las opciones de Configuracion de la ejecu-cion de lperfex. Es decir, sintetiza de modo grafico las opciones lperfex -x,lperfex -s y lperfex -s -x de la interfaz de comandos. Ademas de sinte-tizar las operaciones de configuracion, une a la cadena el fichero ejecutable(debe ser un binario enlazado con la libc) a medir.

Subiendo en abstraccion, esta clase se trata de un Panel en la ventanaprincipal (MainFrame) de glperfex.


4.2.2.1. Metodos

init Constructor de la clase MainFrame.

OpenFile Abre un dialogo para cargar un fichero, en este caso el ejecutablede la medicion.

OnOpen Habilita las checkboxes que senalan la posibildad de escoger elprocesador, o procesadores, donde ejecutaremos el proceso a medir enfuncion de si hemos elegido el modo normal (0), que deshabilita todos,o uno distinto de cero, que habilita la seleccion de procesador.

GetCommand Trata el Comando que sera enviado.


io Instancia de la clase IOInterface.

executionMode Define el modo de ejecucion (normal o exclusiva).

cpusnum Registra las CPUs donde se desea ejecutar el programa.

executable Guardara el nombre del fichero ejecutable.

4.2.3. Clase Counters

Desde esta clase se muestran los contadores que pueden ser medidos enla Ejecucion. Una vez el usuario ha observado dichos contadores podra selec-cionar aquellos que desee medir. Se trata de un Panel en la ventana principal(MainFrame) de glperfex.

4.2.3.1. Metodos

init Constructor de la Clase.

OnSelect Controla la seleccion de los distintos contadores al realizarse lamisma.

OnSelectAll Al activarse, selecciona todos los contadores de la lista.

OnSelectNone Borra todos los contadores de la lista, se activa al pulsarel boton correspondiente.

GetSelectedCountersList Obtiene los elementos seleccionados de la lista.




selectedCountersList Lista de Contadores seleccionados, que se actualizacon la seleccion del usuario.

4.2.4. Clase CheckListCtrl

Esta clase construye una Lista de Control con Checkboxes, la utilizare-mos para que el usuario seleccione los contadores.

4.2.4.1. Metodos


4.2.5. Clase Results

Esta clase controla la interfaz de Resultados, dentro de ella encontra-mos un notebook con pestanas eliminables donde se registran los resultadosgenerados desde la clase de interfaz de entrada y salida.

4.2.5.1. Metodos


SetResults Inserta los resultados de las ejecuciones en sus listas corres-pondientes, de forma que cada nuevo resultado aparece en una nuevapestana del notebook.

RemoveTab Borra un elemento dado de la lista de Pestanas.

SetList Inicia los diccionarios.

Load Carga en el diccionario de resultados los valores del fichero a abrir.

Get Extrae los valores de la ejecucion de la pestana actual para escribirlosen un fichero.

GetDraw Guarda en el fichero que se indica la grafica obtenida, en casode haber sido generada.




nb Notebook con pestanas de paneles de resultados de obtenidos y/o carga-dos.

listOfTabs Lista con las pestanas de los paneles de resultados obtenidos,de modo que se puedan controlar aquellos que se encuentran abiertosen cada momento.

commandDict Diccionario con los comandos a ejecutar.

dictionaryOfResults Diccionario con los resultados obtenidos y que sepublicaran en los paneles de resultados.

4.2.6. Clase ResultsPanel

La clase ResultsPanel se ocupa de manejar las pestanas que se carganen la clase Results.

4.2.6.1. Metodos


DecideStructure Este metodo construye los resultados que figuraran enla pestana de cada resultado, la construccion dependera del numerode filas que tenga, es decir, si la ejecucion se realizo una sola vez, solotendra que ofrecer resultados individuales, en caso contrario mostra-mos la grafica y las ejecuciones medias.

OnSelect Es llamado al activar el evento de seleccion de un resultado mediode la lista de resultados medios. Tiene el objetivo de imprimir en lalista de resultados individuales dichos resultados y dibujar la grafica.


isDrawn Comprueba si se ha dibujado la grafica de resultados (la variablese utiliza para comprobaciones a la hora de guardar la grafica).

dictionaryOfResults Diccionario con los resultados obtenidos y que pu-blicara en el panel.

rows Indica el numero de filas que tendra el panel de resultados individuales(una fila significara que solo hubo una ejecucion y no hace falta fabricarun panel con resultados individuales).


4.2.7. Clase IOInterface

Esta clase hace de interfaz entre glperfex y lperfex, de manera que el restode clases puedan despreocuparse de los aspectos mas complicados como leerficheros, escribir en ellos o comunicarse con la entrada y salida de lperfex.

4.2.7.1. Metodos


GetDictionary Devuelve el diccionario de contadores de la maquina.

AddItemToSelectionList Anade un ıtem a la lista de seleccion.

RemoveItemFromSelectionList Borra un ıtem de la lista de seleccion.

CleanSelectionList Borra toda la lista de seleccion.

GetSelectionList Devuelve la lista de seleccion.

GetResults Devuelve los resultados obtenidos al ejecutar un comando delperfex, es quiza el metodo mas importante de glperfex, ya que es juntoal metodo que obtiene la lista de eventos el que ofrece la interaccioncon lperfex.

DividePath Obtiene el directorio y lo une al nombre del fichero tras com-probar que se aloja en un directorio valido en la variable PATH delsistema.

CheckExecutableFile Comprueba si el fichero introducido se trata de unfichero ejecutable valido a traves de la salida del comando file, es decir,si se trata de un fichero ELF de 32 bits enlazado dinamicamente.

ReadCSV Lee un fichero .csv dado por parametros, tal y como estable-cimos en la definicion del mismo en el apartado 3.4.2, y devuelve undiccionario de resultados tal y como si se hubiera realizado una medi-cion normal.

WriteCSV Escribe un fichero .csv con los resultados recibidos.

SaveDraw Guarda un fichero utilizando el metodo SaveFile del objetocliente.



selectionList Lista de seleccion.

dictofCounters Diccionario de contadores de la maquina (incluye el nom-bre del contador y la descripcion del mismo).

command Comando a ejecutar.

4.3. Diseno de la Interfaz

En esta seccion se presentan, a partir de los requisitos que impusimos enla fase de analisis de la interfaz, seccion 3.5, los disenos de las ventanas denuestra aplicacion mediante una serie de capturas de pantalla.

4.3.1. Generar Medicion

Cuando describıamos los casos de uso, hablabamos de dos casos princi-pales de uso, el caso que nos llevaba a generar una medicion, configurandouna serie de parametros, y el caso en el que cargabamos los resultados desdeun fichero. En este caso nos ocupamos del primero.

4.3.1.1. Configuracion

Tal y como podemos observar en la Figura 4.1, la primera vista del pro-grama nos muestra una ventana con tres pestanas, correspondientes a cadauno de los tres paneles necesarios para configurar y recoger los resultadosde las mediciones.

En la primera pestana que se muestra podemos escoger los distintosparametros de configuracion de la ejecucion. Es decir:

Modo de Ejecucion Nos permitira seleccionar entre la ejecucion estandar(normal), que usa el planificador del kernel de Linux para ejecutar latarea, o la ejecucion en modo exclusivo, que inicia una tarea en tiemporeal.

CPUs activas En caso de seleccionar el modo exclusivo es posible escogerel procesador donde se lanzara la tarea. Por defecto, si no se seleccionanada se ejecutara en el primer procesador de la maquina (en este casoCPU0). En caso de seleccionar ambos procesadores RTAI decide el

70 4.3. Diseno de la Interfaz

Figura 4.1: Glperfex: ventana principal

procesador donde aislar la tarea dependiendo de la carga de tareas deRTAI que existan en ese momento activas. El numero de procesadoresse detecta a traves de una llamada al sistema en tiempo de ejecucion.

Numero de Ejecuciones Con esta configuracion indicamos el numero demediciones que queremos realizar de los eventos que luego selecciona-remos en la pestana de Contadores, en este caso es posible realizarentre 1 y 20 ejecuciones.

Binario a Ejecutar En este dialogo se introduce el ejecutable del progra-ma sobre el que deseamos realizar las mediciones. Podemos buscargraficamente la ruta a traves del boton etiquetado con “...” o es-cribirla directamente. Si nuestro ejecutable esta en un directorio delPATH, tambien se permite escribir el nombre del archivo sin ruta.Por ejemplo, para realizar una medida del comando ls, no hara faltaespecificar /bin/ls.

4.3.1.2. Contadores

Una vez establecidos los parametros de configuracion de la ejecucion, enla segunda pestana, la pestana de Contadores, Figura 4.2, se procedera a


la seleccion de los contadores requeridos para la ejecucion. Estos contadoresson obtenidos en tiempo de ejecucion, a traves de lperfex sobre la maquinasobre la ejecutamos y se nos permite elegir todos los contadores requeridos,ya que internamente, se mediran de forma independiente3.

Figura 4.2: Glperfex: pestana de contadores

4.3.1.3. Resultados

Con los datos incluıdos en la pestana de configuracion, y en la de con-tadores podemos realizar la medicion. Como hemos comentado ya, tanto enla fase de analisis como en la de diseno, la presentacion de los resultadosdepende del numero ejecuciones que hayamos indicado en la configuracion.

Como podemos observar en la Figura 4.3, al ordenar mas de una ejecu-cion, se generara una grafica y se indicaran tambien los resultados indivi-duales de la misma, y en caso contrario, Figura 4.4, se mostrara un unicoresultado individual de los contadores seleccionados.

Los diferentes resultados de las ejecuciones se muestran como hemospodido ver en diferentes pestanas etiquetadas segun su orden de ejecucion.

3Dependiendo de la arquitectura, normalmente no se permite la medicion de mas dedos eventos al mismo tiempo

72 4.3. Diseno de la Interfaz

Figura 4.3: Glperfex: pestana de resultados con siete ejecuciones

Estas pestanas nos permiten mantener a mano resultados de ejecucionesanteriores y comparar los mismos de manera sencilla.

El resto de operaciones que podemos realizar en el caso de uso podemosobservarlas en la Figura 4.5, donde vemos el menu Archivo desplegado, conlas opciones de Guardar Resultados y Guardar Grafica.

4.3.2. Cargar Resultado

El caso de uso Cargar Resultado esta contemplado en la interfaz tal ycomo fue descrito en la fase de analisis. Como podemos observar en la Figura4.5, al seleccionar Archivo en la barra de menu, se despliegan una serie deopciones. Al pulsar en la opcion abrir, Figura 4.6, se nos pregunta el nombredel fichero CSV deseado. Una vez seleccionado, este se cargara en la pestanade resultados, tal y como se muestra en la Figura 4.7.


Figura 4.4: Glperfex: pestana de resultados con una ejecucion

4.4. Diseno del Sistema Autonomo

La ultima parte del diseno de nuestro sistema trata de establecer lasherramientas finales necesarias del sistema autonomo, es decir, todo aquelloque requerira el Live CD en el que se presenta la solucion final para sufuncionamiento y uso.

Como comentamos en el apartado 3.6.2.4, el conjunto de herramientasprovistas en las distribuciones Debian testing y unstable para la realizacionde un Live CD se denomina live-helper. El proceso a seguir para la realiza-cion del Live CD requiere unas opciones de configuracion iniciales, dondedejaremos prefijadas algunas de las caracterısticas del sistema, y una confi-guracion mas amplia, donde en un entorno chroot4, dejar establecidas todaslas necesidades finales del mismo.

4chroot es una llamada al sistema en Unix que permite configurar un directorio co-mo raız del sistema de ficheros para un proceso y sus hijos. En otras palabras, permiteconfigurar el sistema de forma tal que se puedan lanzar procesos confinados dentro de undeterminado directorio. Para ellos, dicho directorio sera el “/” (la raız). Cualquier ficheroo directorio que este fuera del chroot les quedara inaccesible.

74 4.4. Diseno del Sistema Autonomo

Figura 4.5: Glperfex: opciones del menu archivo

4.4.1. Instalacion de Live Helper

El primer paso para construir el sistema sera la instalacion del conjuntode herramientas que provee live-helper, para ello tecleamos:

# apt-get install live-helper live-initramfs live-magic \> live-initscripts user-setup

Si observamos los paquetes instalados, aparece live-magic una sencillaaplicacion grafica, que, utilizada a modo de wizard5 permite realizar rapida-mente un Live CD ampliamente configurable. Sin embargo, para la puestaen marcha de nuestro sistema, utilizaremos otro tipo de herramientas.

4.4.2. Configuracion del Live CD Basico

Una vez contamos con las herramientas necesarias, procedemos al disenodel sistema autonomo propiamente dicho. Para ello, utilizando el coman-do lh_config, estableceremos unas primeras configuraciones sobre datos

5Con wizard nos referimos a un asistente de configuracion sencillo y paso a paso.


Figura 4.6: Glperfex: abriendo una prueba

genericos del Live CD. Para ello crearemos una carpeta donde se guardarantodos los ficheros generados en las fases de construccion y dentro de el te-clearemos lo siguiente:

# lh_config -a i386 --sections "main contrib" -p gnome

Esto nos crea las indicaciones sencillas para un Live CD de la arquitec-tura x86, con repositorios de Debian main y contrib y el entorno graficognome. Si quisieramos terminar simplemente con el sistema indicado te-clearıamos lh_build y se construirıa la imagen del CD, sin embargo, eneste caso deberemos cumplir mas indicaciones.

4.4.3. Anadiendo Funcionalidades al Live CD Basico

La manera mas sencilla de anadir funcionalidades a nuestro CD basicosera construir un entorno chroot y dentro de el instalar programas tal y


Figura 4.7: Glperfex: resultados cargados de un fichero CSV

como si estuvieramos en un sistema normal. Antes de eso deberemos esta-blecer nuestro “sabor” del kernel dentro de la configuracion. Por ello en elfichero config/chroot modificaremos los parametros LH_LINUX_FLAVOURSy LH_LINUX_PACKAGES con los valores del Cuadro 4.3.

LH_LINUX_FLAVOURS="2.6.22.15-karma"

LH_LINUX_PACKAGES="linux-image linux-headers linux-sourceaufs-modules squashfs-modules rtai-dev rtai-modules"

Cuadro 4.3: Configuracion previa del kernel del Live CD

Lo que queremos indicar es que usaremos un kernel distinto al que in-cluye Debian por defecto, y que instale los siguientes paquetes extra, que sedenominaran utilizando el sufijo -2.6.22.15-karma. A Estos paquetes sonnecesarios para la configuracion de nuestro kernel, ademas de los ya nombra-dos linux-image-2.6.22.15-karma, linux-headers-2.6.22.15-karma ylinux-source-2.6.22.15-karma, se anaden los construidos con la compi-lacion de RTAI, que incluyen modulos para este kernel, y los modulos parael mismo kernel de los sistemas de ficheros aufs y squashfs necesarios para


cargar el sistema en el arranque del Live CD.

Los paquetes mencionados deberan copiarse al directorioconfig/chroot_local-packages.

4.4.4. El entorno chroot

Una vez realizadas algunas de las configuraciones basicas necesarias, es-tamos en condiciones de configurar el entorno chroot. Para construirlo de-beremos ejecutar:

# lh_bootstrap && \> lh_chroot && \> lh_chroot_hosts install && \> lh_chroot_resolv install && \> lh_chroot_proc install && \> chroot chroot

Tras esta serie de instrucciones tendremos un entorno a construir, quefinalmente sera el que disfrutaremos durante la ejecucion del Live CD. Lalista de operaciones a realizar serıa mas o menos la siguiente:

1. Configuracion de las Locales.

2. Instalacion de compiladores, bibliotecas y herramientas necesarias parala compilacion y configuracion de las fuentes. Entre estas herramientaspodemos encontrar: gcc, gfortran y g77, gdb y su interfaz ddd, make,autoconf, autogen...

3. Instalacion de wxPython en su version 2.8. Para ello in-cluiremos los repositorios de wxPython de Ubuntu Gutsy,deb http://apt.wxwidgets.org/ gutsy-wx main en el fiche-ro de fuentes /etc/apt/source.list. Los paquetes a instalarseran: python-wxgtk2.8, python-wxtools, python-wxaddons ywx2.8-i18n.

4. Instalacion de PAPI, con sus librerıas, compilando las fuentes.

5. Instalacion de lperfex, compilando las fuentes y glperfex, a traves de sufichero deb.

6. Instalacion de programas de oficina y edicion de textos, tales comotodo el paquete de openoffice.org y el IDE kile, para la edicion deLATEX, y el editor fundamental vim.


7. Instalacion de herramientas de comunicacion, es decir, clientes de men-sajerıa como pidgin, paquetes de acceso remoto ssh y clientes de IRCcomo xchat.

4.4.5. Cerrando el Live CD

Una vez realizada la configuracion del entorno chroot solo quedara laconstruccion del sistema en una imagen capaz de generar un CDROM. Porlo tanto, para terminar el proceso, simplemente tecleamos:

# lh_chroot_hosts remove && \> lh_chroot_resolv remove && \> lh_chroot_proc remove && \> lh_binary

Tras este proceso, si miramos el directorio que creamos al inicio, descubri-remos un fichero llamado binary.iso, que sera la solucion final al problemaque plantea el proyecto.

Capıtulo 5

Pruebas

5.1. Introduccion

A lo largo del siguiente capıtulo se mostraran y comentaran los resultadosde las pruebas realizadas sobre la aplicacion principal y la integracion de lamisma en el sistema.

Las pruebas que realizaremos tienen una doble finalidad:

Pretenden poner de manifiesto posibles errores o incongruencias de laaplicacion con el objetivo de corregirlas antes de su puesta en funcio-namiento.

Pretenden demostrar que la aplicacion cumple con los requerimientosdetallados en la fase de analisis.

Las pruebas que realizaremos sobre la aplicacion seran:

Pruebas de Unidad Engloba las siguientes pruebas:

Pruebas de Casos de Uso Equivalen a las pruebas de caja negra.En ellas se observa el comportamiento de la aplicacion desde elpunto de vista del resultado, a partir de una entrada para cadauno de los casos de uso especificados en la seccion 3.2.1.

Pruebas de Escenarios de la Aplicacion Equivalentes a las prue-bas de caja blanca, donde se analiza la secuencia interna de accio-nes para ejecutar cada grupo especıfico de datos de entrada parala aplicacion.

79

80 5.2. Pruebas de Unidad

Pruebas de la Aplicacion Se realizaran varias pruebas de la aplicacionde forma global.

Pruebas de Rendimiento Se compraran diferentes ejecuciones en la me-dicion de eventos para ver el exito de la implantacion de la solucionde la ejecucion exclusiva.

5.2. Pruebas de Unidad

Las pruebas de unidad tratan de comprobar que el sistema desarrolladocumple de forma correcta las especificaciones para las que fue definido.

De este modo se verificara que toda la funcionalidad de la aplicacionproporciona la salida esperada y que existen los distintos conjuntos de datosde entrada que hacen que se ejecuten todos los caminos posibles. Estastecnicas se denominan pruebas de casos de uso y pruebas de escenarios,respectivamente.

5.2.1. Pruebas de Casos de Uso

En esta seccion se realizaran pruebas para cada uno de los casos de usodescritos en el la seccion 3.2.1.

Para la realizacion de los mismos sera necesario desarrollar una serie decasos de prueba que especifiquen las pruebas para cada caso. Un caso deprueba de este tipo incluye la verificacion del resultado de la interaccionentre actores y aplicacion, y de la secuencia a seguir de acuerdo con lasacciones especificadas en el mismo.

Por lo tanto, esta prueba consiste en una aplicacion de la caja negra,es decir, una prueba del comportamiento de la misma observable desde elexterior.

A continuacion se describen los diferentes casos de prueba descritos paralos dos casos de uso de la aplicacion y para extensiones de casos de uso.

5.2.1.1. Caso de Prueba: Generar Medicion

Entrada La aplicacion recibira los datos necesarios para la ejecucion, esdecir, el tipo de medicion estandar, en el caso de uso normal, el nume-ro de ejecuciones que se desean realizar, el nombre y, en caso de ser

Pruebas 81

necesaria, la ruta del binario a ejecutar (que debera ser un fichero bi-nario compilado de 32 bits). Ademas habra que anadir una lista decontadores de los indicados en la lista que se adjunta al usuario.

Salida La salida correcta sera la enumeracion de los resultados de los datospedidos en una nueva pestana de resultados. Estos llevaran una graficaen caso de haberse ordenado mas de una ejecucion.

Condiciones Haber introducido un binario valido y seleccionado uno o mascontadores.

Como caso especial de esta medicion tenemos la medicion exclusiva, eneste caso, el caso de prueba serıa:

Entrada La aplicacion recibira los datos necesarios para la ejecucion, esdecir, el tipo de medicion exclusiva, las CPUs donde se desea intentarlanzar el proceso en tiempo real, el numero de ejecuciones que se deseanrealizar, el nombre y, en caso de ser necesaria, la ruta del binarioa ejecutar (que debera ser un fichero binario compilado de 32 bits).Ademas habra que anadir una lista de contadores de los indicados enla lista que se adjunta al usuario.

Salida La salida correcta sera la enumeracion de los resultados de los datospedidos en una nueva pestana de resultados. Estos llevaran una graficaen caso de haberse ordenado mas de una ejecucion.

Condiciones Haber introducido un binario valido, y seleccionado uno omas contadores, ademas de la CPU donde lanzar la aplicacion.

5.2.1.2. Caso de Prueba: Guardar Medicion

Entrada Debe introducirse el nombre del fichero y la ruta que se deseaguardar en el dialogo de gnome que se abre para guardar el fichero.

Salida Aparecera en el directorio que hemos escogido un fichero con losresultados.

Condiciones Debera haberse seleccionado un resultado en la pestana deresultados, o tenerlo activo.

5.2.1.3. Caso de Prueba: Guardar Grafica

Entrada Debe introducirse el nombre del fichero y la ruta que se deseaguardar en el dialogo de gnome que se abre para guardar el fichero. El

82 5.2. Pruebas de Unidad

tipo de fichero sera uno de los que soporta la biblioteca de las graficas,estos se indicaran en la ventana.

Salida Aparecera en el directorio que hemos escogido un fichero con lagrafica.

Condiciones Debera haberse seleccionado un resultado en la pestana deresultados que contenga una grafica.

5.2.1.4. Caso de Prueba: Cargar Medicion

Entrada Debe introducirse el nombre del fichero y la ruta que se deseacargar en el dialogo de gnome que se abre para cargar el fichero.

Salida Apareceran los resultados cargados en una nueva pestana de la pes-tana de resultados.

Condiciones Debera haberse seleccionado un fichero valido.

5.2.2. Pruebas de Escenarios de la Aplicacion

Para la realizacion de estos casos es necesaria la implementacion de unaserie de casos de prueba. Un caso de prueba de este tipo puede incluir laverificacion de la interaccion entre los componentes que implementan loscasos de uso. Estos casos especificaran una prueba de aplicacion de cajablanca.

Los casos de prueba realizados son los siguientes:


El cuarto caso se trata de una opcion solo compatible con la medicionexclusiva.

1. DescripcionEl usuario no introduce el nombre del binario a ejecutar.Acciones EsperadasEl sistema informa de la ausencia de datos.

2. DescripcionEl usuario introduce un fichero no valido en el campo del binario aejecutar.Acciones Esperadas

Pruebas 83

El sistema informa de la incompatibilidad del fichero con el formatorequerido.

3. DescripcionEl usuario no selecciona ningun contador en la pestana de contadores.Acciones EsperadasEl sistema informa de la ausencia de contadores.

4. DescripcionEl usuario no selecciona ninguna CPU donde ejecutarse.Acciones EsperadasEl sistema presupone que se ha seleccionado la CPU0.


1. DescripcionEl usuario no introduce el nombre del fichero a guardar.Acciones EsperadasEl sistema informa de la ausencia de datos.

2. DescripcionNo se ha realizado ninguna medicion.Acciones EsperadasEl sistema informa de la ausencia de mediciones a guardar.


1. DescripcionEl usuario no introduce el nombre de la grafica a guardar.Acciones EsperadasEl sistema informa de la ausencia de datos.

2. DescripcionEl usuario intenta guardar sin haberse generado una grafica.Acciones EsperadasEl sistema informa de la ausencia de grafica a guardar.


1. DescripcionEl usuario no introduce el nombre de la medicion a cargar.Acciones EsperadasEl sistema no hace nada.

84 5.3. Pruebas de la Aplicacion

2. DescripcionEl usuario intenta cargar un fichero no valido.Acciones EsperadasEl sistema no hace nada.

5.3. Pruebas de la Aplicacion

En este apartado se describiran los resultados obtenidos en la realizacionde los casos y procedimientos de prueba disenados en el apartado anterior,probando ası los casos de uso mas importantes.

5.3.1. Procedimiento Seguido

A continuacion se especifica el procedimiento seguido para probar losdistintos casos de prueba de la aplicacion:

1. El usuario ejecuta la aplicacion.

2. El usuario intenta realizar una medicion sin ejecutar ningun binarioen el campo indicado.

3. El usuario introduce un fichero no valido como binario para las medi-ciones de eventos.

4. El usuario no selecciona ningun contador en la pestana de contadores.

5. El usuario no selecciona ninguna CPU en la seleccion de CPUs de lamedicion exclusiva.

6. El usuario intenta guardar un fichero sin introducir su nombre.

7. El usuario intenta guardar un fichero sin haberse realizado una medi-cion.

8. El usuario no introduce el nombre de la grafica a almacenar.

9. El usuario intenta guardar una grafica sin haber sido generado esta.

10. El usuario no introduce el nombre de una medicion a cargar.

11. El usuario intenta cargar un fichero no valido como medicion.

Pruebas 85

5.3.2. Ejecucion de los Casos de Prueba de la Aplicacion

Por ultimo, y una vez planeados, descritos y realizados los casos de prue-ba, podemos examinar el comportamiento observado en la aplicacion. Laevaluacion se compone de la descripcion del error que se produce, el resul-tado de la prueba y el estado del sistema al concluir la misma.


El cuarto caso se trata de una opcion solo compatible con la medicionexclusiva.

1. DescripcionEl usuario no introduce el nombre del binario a ejecutar.ResultadoCompletado.EstadoEstable.

2. DescripcionEl usuario introduce un fichero no valido en el campo del binario aejecutar.ResultadoCompletado.EstadoEstable.

3. DescripcionEl usuario no selecciona ningun contador en la pestana de contadores.ResultadoCompletado.EstadoEstable.

4. DescripcionEl usuario no selecciona ninguna CPU donde ejecutarse.ResultadoCompletado.EstadoEstable.

86 5.3. Pruebas de la Aplicacion


1. DescripcionEl usuario no introduce el nombre del fichero a guardar.ResultadoCompletado.EstadoEstable.

2. DescripcionNo se ha realizado ninguna medicion.ResultadoCompletado.EstadoEstable.


1. DescripcionEl usuario no introduce el nombre de la grafica a guardar.ResultadoCompletado.EstadoEstable.

2. DescripcionEl usuario intenta guardar sin haberse generado una grafica.ResultadoCompletado.EstadoEstable.


1. DescripcionEl usuario no introduce el nombre de la medicion a cargar.ResultadoCompletado.EstadoEstable.

2. DescripcionEl usuario intenta cargar un fichero no valido.Resultado

Pruebas 87

Completado.EstadoEstable.

5.4. Pruebas de Rendimiento de la Aplicacion

A continuacion analizaremos el rendimiento y posible mejora que aportala aplicacion de acuerdo con la comparacion de la ejecucion en entornos conruido y sin ruido de los test de benchmark, NAS Paralell Benchmarks (ramaNPB3.2-SER) considerados en el apartado de antecedentes.

Las pruebas seran realizadas sobre un procesador Intel Core2 Duo T7200,usando, para la planificacion no exclusiva, el planificador multicore del kernelde Linux 2.6.22.15.

De las pruebas realizadas se obtendran tres datos estadısticos de impor-tancia: la media, la varianza y el coeficiente de variacion. Las pruebas serealizaran usando la aplicacion en modo normal con y sin ruido de fondo,y en modo exclusivo. Se tomaran medidas del empobrecimiento de la mues-tra en su ejecucion con ruido con respecto a la prueba tomada sin ruido defondo, y a continuacion se compararan ambos resultados con las medicionesrealizadas bajo exclusividad de procesador con el fin de obtener el porcen-taje de mejora de la solucion obtenida ante una ejecucion normal, con y sinprocesos de fondo.

Las mediciones se tomaran siguiendo las siguientes formulas:

Media Se calcula de la forma estandar:x = 1

n

∑ni=1(xi)

Varianza Corresponde a:S2 = 1

n−1

∑ni=1(xi − x)

Empobrecimiento La formula empleada para su calculo es:empobrecimiento = 1− (1V arianzadelamuestraconruido

V arianzadelamuestrasinruido )

Mejora Se calcula como:mejora = 1− (1 varianza

varianzaenexclusividad)

Para la obtencion de estadısticas, cada prueba se realizo en diez ocasio-nes.

88 5.4. Pruebas de Rendimiento de la Aplicacion

En los resultados, por motivos de espacio no se incluiran todos los resul-tados obtenidos sino tan solo los tres datos indicados con anterioridad paracada caso.

A continuacion se incluyen los resultados obtenidos de las pruebas obte-nidas durante las mediciones especificadas.

5.4.1. Pruebas No Exclusivas Sin Ruido

En la Tabla 5.1 se observan los resultados obtenidos en las medicionesestandar, es decir en las mediciones realizadas sobre un proceso ejecutandosebajo el planificador estandar de Linux con reemplazo.

En los resultados se observa que el cociente de variacion alcanza valoreselevados, superando en algun caso el 50 %, lo que indica que la fiabilidad dela muestra no es muy elevada.

No de ciclos Fallos en L2 Fallos en L1 (I) Fallos en L1(D)

bt.S

Media 352.499.977 3.261 28.036 1.860.000

Varianza 762.143.302.344 3.310.305 23.055.152 242.172.208

Cociente de variacion 0,25 % 55,79 % 17,13 % 0,84 %

is.S

Media 39.695.619 767 1.378 105.506

Varianza 312.740.499.546 1.270.185 4.870 104.973


lu-hp.S

Media 175.186.766 2.306 19.928 3.837.878

Varianza 321.760.503.088 3.239.976 916.563 64.651.207


lu.S

Media 177.349.515 2.081 23.568 3.476.408

Varianza 138.163.085.576 1.273.692 6.818.650 2.854.859


sp.S

Media 174.738.731 4.816 28.394 3.266.724

Varianza 623.326.821.562 4.651.787 6.613.768 6.235.034


ua.S

Media 2.576.405.913 1.078.370 48.106 50.456.874

Varianza 131.616.712.100.111 86.552.694.427 2.176.890 1.340.172.865


Cuadro 5.1: Resultados de las mediciones estandar sin ruido

Pruebas 89

5.4.2. Pruebas No Exclusivas Con Ruido

Estas pruebas no muestran diferencia con las anteriores con la salvedadque durante su ejecucion se iniciaron intencionadamente procesos de fondoque combinasen tanto una alta carga de procesador como una alta actividadde entrada/salida.

Los resultados, que podemos evaluar en la Tabla 5.2, muestran empo-brecimientos en la fiabilidad de la mayorıa de las mediciones. En algunas,no obstante, el empobrecimiento es negativo. Esto se explica si se tiene encuenta que, en realidad, el primer sistema de medicion sin ruido no estabacompletamente libre de interferencias.

Comparando los resultados en empobrecimiento de Karma Linux 2008con ruido con los que se publicaron de Karma original en [1], podemosobservar que el planificador multicore de Linux mejora los resultados aldisponer de varios nucleos para distribuir la carga. No obstante, la forma deobtencion del ruido ha sido distinta, por lo que estos resultados no son tanconcluyentes en principio como puede apreciarse a simple vista.

5.4.3. Pruebas Bajo el Entorno Exclusivo

Estas pruebas se realizaron mediante el modo exclusivo de glperfex, esdecir, se le indico a la aplicacion lperfex que para las mediciones a realizarse requerıa el entorno de exclusividad del procesador desarrollado con el finde mejorar la medicion y la variacion de las muestras.

En esta ocasion se selecciono en la interfaz que se ejecutaran las pruebassobre la CPU0 del Intel Core2 Duo T7200.

RTAI lanza un proceso en el procesador escogido de modo exclusivo (latarea sera ejecutada en ese procesador sin ser reemplazada). Si seleccionara-mos dos procesadores, RTAI seleccionarıa aquel con menor carga de procesosen tiempo real para lanzar la tarea.

Las pruebas en este caso no se dividen entre pruebas con ruido y pruebassin ruido ya que los resultados obtenidos en ambas situaciones no muestrandiferencias relevantes (las tareas de Linux se ven postergadas en su uso,motivo por el que la medicion carece de ruido, nuestra tarea no puede serreemplazada).

90 5.4. Pruebas de Rendimiento de la Aplicacion


bt.S

Media 354.884.155 14.755 46.253 1.868.571

Varianza 1.125.889.636.453 28.464.662 1.935.204.824 224.169.572


Empobrecimiento 32,31 % 88,37 % 98,81 % -8,03 %

is.S

Media 39.988.446 1.759 1.543 112.822

Varianza 806.941.900.505 1.467.873 762.019 576.946.071


Empobrecimiento 61,24 % 13,47 % 99,36 % 99,98 %

lu-hp.S

Media 176.105.599 6.923 22.233 3.855.104

Varianza 294.135.373.472 3.923.527 15.985.847 774.662.732


Empobrecimiento -9,39 % 17,42 % 94,27 % 91,65 %

lu.S

Media 178.213.427 7.291 25.552 3.481.716

Varianza 121.675.944.894 32.898.824 559.462.005 82.294.866


Empobrecimiento -13,55 % 96,13 % 98,78 % 96,53 %

sp.S

Media 176.325.891 20.350 31.226 3.274.074

Varianza 1.787.535.336.985 2.569.747.778 6.820.124 333.338.206


Empobrecimiento 65,13 % 99,82 % 3,03 % 98,13 %

ua.S

Media 2.609.919.907 4.773.160 84.893 50.543.727

Varianza 228.514.900.869.419 52.736.674.402 7.426.875.267 9.463.472.940


Empobrecimiento 42,40 % -64,12 % 99,97 % 85,84 %

Cuadro 5.2: Resultados obtenidos para las pruebas estandar con ruido

En la Tabla 5.3 se observa una disminucion notable de la varianza y delcociente de variacion en la mayorıa de las muestras, lo que se refleja en unalto porcentaje de mejora con respecto a la medicion usando el planificadorestandar ya sea con procesamiento de fondo o sin el.

El Campo Mejora se refiere a:

1. Mejora con respecto a la prueba no exclusiva sin ruido.

2. Mejora con respecto a la prueba no exclusiva con ruido.

Una de las diferencias que se pueden extraer en la comparacion con [1]es la mejora de la ejecucion de tareas con ruido en el planificador de Linux,esto hace que en muchas ocasiones la mejora resulte menor que en la versionde Karma Linux original.

Pruebas 91


bt.S

Media 352.308.025 5.238 15.088 1.847.476

Varianza 632.320.045.424 388.458 24.228 244.347.100


Mejora (1) 43,84 % 98,64 % 100,00 % -9,00 %

Mejora (2) 17,03 % 88,27 % 99,89 % -0,90 %

is.S

Media 39.538.981 5.492 1.127 113.715

Varianza 4.786.736.142 972.981 2.257 16.680


Mejora (1) 99,41 % 33,71 % 99,70 % 100,00 %

Mejora (2) 98,47 % 23,40 % 53,65 % 84,11 %

lu-hp.S

Media 174.690.302 5.743 15.198 3.833.006

Varianza 14.262.748.372 315.312 48.717 25.111.561


Mejora (1) 95,15 % 91,96 % 99,70 % 96,76 %

Mejora (2) 95,57 % 90,27 % 94,68 % 61,16 %

lu.S

Media 176.895.184 5.607 15.444 3.477.858

Varianza 79.649.456.248 257.597 15.164 2.040.348


Mejora (1) 34,54 % 99,22 % 100,00 % 97,52 %

Mejora (2) 42,35 % 79,78 % 99,78 % 28,53 %

sp.S

Media 173.663.312 4.876 14.717 3.260.188

Varianza 59.353.695.166 191.681 34.958 4.854.312


Mejora (1) 96,68 % 99,99 % 99,49 % 98,54 %

Mejora (2) 90,48 % 95,88 % 99,47 % 22,14 %

ua.S

Media 2.569.790.995 434.231 24.370 50.469.484

Varianza 112.591.615.415.012 13.510.795.086 44.777 908.205.309


Mejora (1) 50,73 % 74,38 % 100,00 % 90,40 %

Mejora (2) 14,45 % 84,39 % 97,94 % 32,23 %

Cuadro 5.3: Resultados de las mediciones bajo entorno exclusivo

Capıtulo 6

Conclusiones y FuturasMejoras

6.1. Conclusiones

Cuando planteabamos la definicion de los objetivos del proyecto hablaba-mos de tres apartados fundamentales a los que debıa dar solucion: la adap-tacion de Karma Linux a sistemas multiprocesador, una mejora de la usa-bilidad de la aplicacion de medicion y la autonomıa de la plataforma. Porello la mejor manera de establecer unas conclusiones acerca del proyecto esdesarrollarlas con respecto a cada objetivo planteado.

Adaptacion a Sistemas Multiprocesador El planteamiento inicialpartıa de la base de una distribucion, Karma Linux que hacıa posiblela medicion de eventos en sistemas computacionales monoprocesador.El objetivo era utilizar esta aplicacion de forma que aislara la medicionde eventos en un unico nucleo del procesador de manera no intrusiva.

Las pruebas aplicadas al sistema han demostrado la validez de la solu-cion para realizar mediciones mas seguras, tal y como pudimos ver enel cuadro comparativo. La mejora, al aislar toda la carga en un nucleo,incluye tanto la eliminacion de ciclos innecesarios empleados duranteel reemplazo del proceso en el planificador, como la mejora en la varia-cion de los resultados obtenidos en las mediciones, algo imprescindiblesi se quiere obtener una medicion de fiabilidad.

Como comentabamos en el capıtulo anterior, las pruebas no exclusivasfueron realizadas usando el planificador multicore del kernel de Linux2.6.22.15 sobre el procesador Intel Core 2 Duo T7200. Esto hace que no

93

94 6.1. Conclusiones

hayamos podido hacer una comparacion pormenorizada con los resul-tados de Karma Linux original [1], ya que estos fueron realizados conel planificador estandar del kernel 2.6.15.1 sobre AMD K8. Esto varıasustancialmente las condiciones de las comparaciones, no obstante, laconclusion final, es que ambas soluciones plantean resultados optimos,cada uno en su ambito de ejecucion.

Mejora de la Usabiliad El desarrollo de la interfaz glperfex ha mejoradola interaccion del usuario con la aplicacion concebida. De esta maneraahora los usuarios menos experimentados no tendran gran dificultadpara realizar sus pruebas en un entorno sencillo, donde poder alma-cenar los resultados y graficas de una manera eficiente facilitando eltratamiento posterior de las mismas.

glperfex permite detectar en tiempo de ejecucion el numero de proce-sadores que tiene la maquina, lo que posibilita tanto la eleccion delprocesador donde aislar la tarea, como el ajuste de la funcionalidadpara monoprocesador y multiprocesador.

Tambien, el control de errores, que contempla la posibilidad de com-probar si el binario introducido esta compilado para la arquitectura yfue enlazado de manera correcta, nos permite detectar las incompati-bilidades del programa que se desea medir.

Autonomıa de la Plataforma La autonomıa de la plataforma se ha con-seguido aunque no de forma estandar. Debido a que restriccionesimplıcitas a la solucion a desarrollar y al lenguaje impuesto por elpropio sistema han imposibilitado la creacion de un sistema multipla-taforma capaz de ser ejecutado por diversos sistemas operativos, lasolucion que se ha adoptado es la de incluir el entorno y la aplicacionen una distribucion que contenga su propio sistema operativo capaz dedetectar el sistema sobre el que se ejecuta y adaptarse a el. Gracias aesto se consigue que sin necesidad de ninguna operacion adicional quela aplicacion este disponible para su uso una vez arrancado el sistema.

6.1.1. Conclusiones personales

Karma Linux fue iniciado hace cuatro anos por Pedro Navajas Modelo.El dıa de su lectura de proyecto mis conocimientos, al igual que el de loscompaneros que acudimos, distaban mucho de alcanzar a comprender latematica y metodologıa utilizada para alcanzar la solucion del problema.Poco despues Ezequiel me propuso retomar el proyecto y adaptarlo a lascondiciones que hemos enumerado a lo largo del manual tecnico, y, a pesarde la falta de preparacion previa, mi respuesta fue sı. Ası empezo un procesode investigacion, a traves de la revision del codigo y el manual tecnico, de

Conclusiones y Futuras Mejoras 95

contacto con desarrolladores a traves de listas de correo y de muchas lecturascomplementarias, que ha dado como resultado este trabajo.

La filosofıa del software libre hace posible las bases sobre las que secimenta el proyecto. Pedro aparco el trabajo hace dos anos, pero gracias asu codigo y documentacion libres pude involucrarme en el mismo desde elprincipio, hacer las modificaciones que se publican en este documento, y enel futuro podra ser retomado por nuevos programadores que den nuevos ymas eficientes enfoques a la solucion.

Uno de los principales problemas de los proyectos fin de carrera mas am-biciosos es que, por falta de tiempo y medios, muchos quedan en el olvidosin llegar a funcionar completamente. Si estos proyectos buscaran la colabo-racion de la comunidad de desarrolladores de software libre a traves de loscanales adecuados, es posible que alcanzaran cotas jamas pensadas graciasal trabajo de programadores interesados en la materia de cualquier lugar delmundo. El ejemplo fundamental de este proceso de desarrollo es el kernelde Linux, iniciado just for fun por Linus Torvalds en 1991, y un proyectoapoyado por desarrolladores de algunas de las empresas mas importantesdel sector informatico en la actualidad.

Esa debe ser la base del desarrollo tecnologico, eso hace que la sociedadavance hacia metas nunca contempladas. Nunca debe escribirse software envano, nunca.

6.2. Futuras mejoras

El proyecto presenta algunos puntos en los que se puede mejorar, estandoalgunos ya en desarrollo:

En cuanto a la aplicacion, la interfaz podrıa incorporar una pequenaventana con la ejecucion por terminal del programa que se ejecuta,esto nos darıa la posibilidad de valorar si la ejecucion de nuestro pro-grama ha sido la correcta, ya que las malas ejecuciones tambien semiden, y esto podrıa llevar a errores. Sin embargo no se trata de unaactualizacion de importancia vital.

La ejecucion exclusiva no presenta control del proceso, esto hace que untest que presente un bucle infinito pueda llegar a bloquear la maquina.Este es el punto fundamental del trabajo actual, estamos en contactocon desarrolladores de RTAI para llegar a un camino satisfactorio eneste sentido. La solucion radica en desactivar una CPU para el uso deLinux, de manera que el nucleo sea siempre accesible para RTAI, pero

96 6.2. Futuras mejoras

no para el planificador estandar. Esta solucion evitarıa ruido entre me-diciones repetidas, ademas de salvar el sistema de bloqueos. Se puedeexaminar el hilo de la lista de correo en [31].

Bibliografıa

[1] Pedro Navajas Modelo. Karma Linux. “Distribucion de Linux en Tiem-po Real para la Medicion de Eventos”. Manual Tecnico. Universidadde Cordoba. Cordoba. 2006.

[2] Love R., Linux Kernel Develompent - Segunda Edicion. Sams Publis-hing, ISBN: 0-672-32720-1, Estados Unidos, 2005.

[3] Intel Technology Journal. Volume 06. Issue 01. 14 de Febrero de 2002ISSN 1535766X.

[4] Revista Technology@Intelhttp://www.intel.com/espanol/technology/magazine/computing/multi-core-software-1006.htmUltima Comprobacion: 15/05/2008.

[5] Latin Insights@Intel bloghttp://blogs.intel.com/latininsights/2007/07/el fin de la era de los mhz y.htmlUltima Comprobacion: 15/05/2008.

[6] Pagina Web de RTAIhttps://www.rtai.orgUltima Comprobacion: 6/06/2008.

[7] Pagina Web de Performance APIhttp://icl.cs.utk.edu/papi/Ultima Comprobacion: 30/05/2008.

[8] Especificacion del Estandar LSB sobre la Instalacion de Softwarehttp://refspecs.freestandards.org/LSB 3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html#SWINSTALL-INTROUltima Comprobacion: 17/05/2008.

[9] Anuncio de Publicacion de LSB 1 en Barrapuntohttp://barrapunto.com/articles/01/07/01/1536239.shtmlUltima Comprobacion: 17/05/2008.

97

98 BIBLIOGRAFIA

[10] Linux Standard Base Plans cross-format Package APIhttp://www.linux.com/articles/59502Ultima Comprobacion: 15/05/2008.

[11] Pagina Web de Intel VTune Performance Analyzerhttp://www.intel.com/cd/software/products/asmo-na/eng/vtune/239144.htmUltima Comprobacion: 12/05/2008.

[12] Osciloscopio USB. Proyecto de fin de carrera de Pablo Hoffman y Mar-tin Szmulewicz. Universidad ORT de Montevideo, Uruguay.http://pablohoffman.com/cgi-bin/twiki/bin/view/Oscusb/DocCap04HardwareUltima Comprobacion: 12/05/2008.

[13] Analisis de Sistemas Operativos de Tiempo Real Libreshttp://www.ciclope.info/doc/rtos/rtlinux.phpUltima Comprobacion: 30/05/2008.

[14] RTAI. Artıculo de Wikipedia Inglesahttp://en.wikipedia.org/wiki/RTAIUltima Comprobacion: 30/05/2008.

[15] Benchmark. Artıculo de Wikipediahttp://es.wikipedia.org/wiki/BenchmarkUltima Comprobacion: 6/06/2008.

[16] SPEC. Artıculo de Wikipediahttp://es.wikipedia.org/wiki/SPECUltima Comprobacion: 15/05/2008.

[17] Pedro Navajas y Ezequiel Herruzo. Medicion de los contadores hardwaredel procesador en modo exclusivo de ejecucion. Artıculo presentado yaceptado en el I Congreso Espanol de Informatica (CEDI 2005).

[18] William Saphir, Alex Woo, and Maurice Yarrow. The nas parallel ben-chmarks 2.1 results. Report NAS-96-010, Agosto de 1996.

[19] GNU General Public License, version 2http://www.gnu.org/licenses/gpl-2.0.htmlUltima Comprobacion: 2/06/2008.

[20] GNU General Public License. Artıculo de Wikipediahttp://es.wikipedia.org/wiki/GPLUltima Comprobacion: 6/06/2008.

[21] Consejo Superior de Informatica. Estaciones de Trabajo, Pruebas deVerificacion y Control.

BIBLIOGRAFIA 99

http://www.csi.map.es/csi/silice/Hw-cpu27.htmlUltima Comprobacion: 15/05/2008.

[22] CSV. Artıculo de Wikipedia Inglesahttp://en.wikipedia.org/wiki/Comma-separated valuesUltima Comprobacion: 15/05/2008.

[23] Common Format and MIME Type for CSV Filescsv http://tools.ietf.org/html/rfc4180Ultima Comprobacion: 27/05/2008.

[24] Fielded Text Standard Referencehttp://www.fieldedtext.org/Standard/FTRef0.6.odtUltima Comprobacion: 15/05/2008.

[25] How To: The Comma Separated Value (CSV) File Formathttp://www.creativyst.com/Doc/Articles/CSV/CSV01.htmUltima Comprobacion: 15/05/2008.

[26] An EBNF definition of the CSV format with explanationhttp://supercsv.sourceforge.net/csvSpecification.htmlUltima Comprobacion: 15/05/2008.

[27] Examples for generating a Debian Live CDs and othershttp://wiki.debian.org/DebianLive/ExamplesUltima Comprobacion: 3/06/2008.

[28] Diego Lopez Zamarron. Arquitectura de un Sistema Operativo de Tiem-po Real. Universidad Politecnica de Madridhttp://gayuba1.datsi.fi.upm.es/ dlopez/rtos.phpUltima Comprobacion: 21/05/2008.

[29] The RTAI Development Team. RTAI API Documentation. Technicalreport, RTAI, 2004.https://web.aero.polimi.it/documentation/vesuvio/html/api/Ultima Comprobacion: 21/05/2008.

[30] The RTAI Development Team. DIAPM RTAI - Beginner’s Guide. 2002,https://www.aero.polimi.it/rtai/documentation/articles/guide.htmlUltima Comprobacion: 24/05/2008.

[31] Isolating a task in a CPU thread on RTAI Mailing List.https://mail.rtai.org/pipermail/rtai/2008-June/thread.html#19697Ultima Comprobacion: 6/06/2008.

Apendice A

Manual de Usuario

El siguiente documento incluye las instrucciones necesarias para la utili-zacion satisfactoria de glperfex, una interfaz grafica sencilla para la medicionde eventos de procesador en un ambiente determinista.

La medicion de eventos de procesador en la ejecucion de un programapuede dar pistas muy valiosas al desarrollador para la optimizacion del mis-mo. Esto incluye informacion acerca del numero de ciclos de procesador queconsume un programa al ser usado, el numero de fallos de cache tanto denivel 1, como de nivel 2..., que influira radicalmente en programas disenadospara sistemas sensibles, por ejemplo sistemas empotrados, donde es necesa-rio ajustar hasta el mas pequeno detalle de rendimiento.

Sin embargo, dichas mediciones son influidas por los ruidos propios delos sistemas operativos multitarea, donde la concurrencia de procesos, consus consecuentes reemplazos provocan errores en las mediciones, que puedenllevar nuestro desarrollo por enfoques equivocados.

La aplicacion glperfex proporciona una solucion a este problema. Dispo-ne, a traves de bibliotecas especıficas para la medicion de una gran variedadde eventos, detectados al encender la maquina. Ademas provee una solu-cion al problema del ruido en las mediciones de los eventos, gracias a unmodo particular de ejecucion que permite ejecutar nuestro programa en unprocesador en modo exclusivo (aislando tambien tareas en sistemas multi-procesador).

glperfex se incluye en Karma Linux 2008, una distribucion deGNU/Linux configurada especialmente para lograr dicho objetivo. No obs-tante es posible instalar todos los elementos necesarios para su funciona-miento en cualquier maquina de arquitecturas x86 y x86 64. Sin embargo,concebimos Karma para facilitar el acceso a la aplicacion a usuarios no

101

102 A.1. Requisitos

avanzados, de modo que puedan realizar las pruebas de un modo totalmenteportable y sin necesidad de instalar todo el sistema en su maquina, a pesarde, y como explicaremos a continuacion, ofrecer al usuario la posibilidad deinstalar todo el sistema del mismo modo que se instala cualquier distribucionde GNU/Linux.

A.1. Requisitos

A.1.1. Requisitos del Sistema Completo

Para la ejecucion y/o instalacion de Karma Linux 2008 son necesarioslos siguientes requisitos hardware (todo el software necesario se incluye enla distribucion).

Procesador de arquitecturas x86 o x86 64 de entre los siguientes mo-delos:

• Intel Pentium III

• Intel Pentium 4

• AMD Opteron

• AMD Athlon

• Intel Itanium

• Intel Core2 series

Lector de DVDs.

5GB de espacio libre en el Disco Duro en caso de desear la instalacion.

A.1.2. Requisitos de Glperfex

A pesar de que el documento enfoca la utilizacion y puesta a punto delsistema Karma Linux 2008 completo, es conveniente indicar los requisitosde la aplicacion para los usuarios que quieran tratarla en su propio sistema.

A.1.2.1. Requisitos Hardware

Procesador de arquitecturas x86 o x86 64 de entre los siguientes mo-delos:

• Intel Pentium III

Manual de Usuario 103

• Intel Pentium 4

• AMD Opteron

• AMD Athlon

• Intel Itanium

• Intel Core2 series

A.1.2.2. Requisitos Software

Cualquier distribucion de GNU/Linux.

Kernel de la rama 2.6 incluyendo los parches de RTAI y perfctr parael mismo, y compilado con las opciones requeridas por perfctr para lamedicion de eventos.

PAPI 3.5 o superior.

RTAI 3.5 o superior.

Aplicacion lperfex, con fichero ejecutable situado en alguna carpetaincluida en la variable PATH del sistema.

Python 2.4

WxPython 2.8

A.2. Instalacion

A.2.1. Instalacion de Karma Linux 2008

Karma Linux 2008 se trata, a diferencia de su antecesora1, de una dis-tribucion basada en Debian GNU/Linux. Esto hace que la instalacion dela misma sea sencilla para un usuario de nivel medio/bajo, igual que lainstalacion de Debian Lenny2.

Los pasos a seguir son los siguientes:

1. Inserte el DVD en su unidad, despues de comprobar que la opcion decarga de ese dispositivo es la primera en el orden de arranque de laBIOS.

1Karma Linux fue concebida como una distribucion basada en Gentoo2Puesto que la instalacion es la propia de Debian Lenny al ser una modificacion de la

misma, seguimos los pasos tal y como se indican en el manual del instalador de Debian,http://d-i.alioth.debian.org/manual/es.i386/apas03.html

104 A.2. Instalacion

2. Una vez que se inicie el instalador, se le mostrara una pantalla inicialde bienvenida. Pulse Enter para arrancar, o lea las instrucciones paraobtener informacion de otros metodos y parametros para la instalacion.

3. Despues de unos instantes se le pedira que elija su idioma. Use lasteclas de desplazamiento para elegirlo y pulse Enter para continuar.Seguidamente se le solicitara seleccionar su paıs, las opciones que semuestran incluiran paıses en donde se habla su idioma. Si su paıs nose encuentra en la lista corta puede acceder a una lista con todos lospaıses en el mundo.

4. Puede que necesite confirmar su mapa de teclado. Elija el valor pro-puesto a menos que sepa que no es el adecuado.

5. Ahora sientese y espere mientras el instalador de Debian detecta suhardware y carga los otros componentes de la instalacion desde elDVD.

6. A continuacion el instalador intentara detectar su hardware de redy configurar la red usando DHCP. Podra configurar la red de formamanual si no esta en una red o no tiene DHCP.

7. Ahora toca particionar sus discos. Primero se le dara la oportunidadde particionar automaticamente bien el disco entero o bien el espaciolibre disponible en su disco (particionado guiado). Esta opcion es lamas recomendable para usuarios noveles o alguien con prisa. Escoja laManual en el menu si no desea particionado automatico.

Si tiene una particion DOS o Windows que quiera preservar, tengacuidado con el particionado automatico. Si elije particionado manual,puede usar el instalador para redimensionar particiones FAT o NTFS ydejar espacio para la instalacion de: simplemente seleccione la particiony especifique su nuevo tamano.

8. En la siguiente pantalla vera su tabla de particiones, como se forma-tearan las particiones, y donde seran montadas. Elija una particionsi desea modificarla o eliminarla. Si ha efectuado un particionado au-tomatico, solamente se le permitira elegir Finalizar particionado en elmenu, para usar lo que se ha definido. Recuerde que debe crear por lomenos una particion de intercambio y montar una particion en /.

9. Ahora el debian-installer formatea sus particiones y empieza a instalarel sistema base, lo que puede tomar un tiempo. Tras esto se llevara acabo la instalacion del nucleo.

10. A continuacion debe configurar su zona horaria y su reloj. El insta-lador intentara seleccionar la configuracion automaticamente y solo le


preguntara si no puede hacerlo. Tras esta configuracion se crean lascuentas de usuarios. Por omision, solo necesitara dar la contrasena parala cuenta del usuario root (administrador) y la informacion necesariapara crear una cuenta para un usuario normal.

11. El sistema base que se instala al principio es una instalacion funcional,pero mınima. El paso siguiente le permite instalar paquetes adicionalesy seleccionar tareas de forma que el sistema instalado sea mas operati-vo. Debe configurar apt antes de que se puedan instalar los paquetes,ya que esta configuracion define de donde se obtendran los paquetes.Por omision se instala la tarea del “Sistema estandar” y es la quegeneralmente deberıa estar instalada.

12. El ultimo paso es la instalacion del gestor de arranque. El instaladoranadira automaticamente al menu de arranque y mostrara un aviso sidetecta otros sistemas operativos en su ordenador. GRUB se instalade forma predeterminada en el sector de arranque del primer discoduro, lo que generalmente es una buena eleccion. Podra cambiarlo einstalarlo en otra ubicacion si ası lo desea.

13. Ahora el debian-installer le indicara que la instalacion ha finalizado.Retire el CDROM o el medio que haya utilizado para la instalaciony pulse Enter para reiniciar su maquina. Esta debera arrancar en elsistema que acaba de instalar para que pueda acceda al mismo.

A.2.2. Instalacion de la Aplicacion

Para instalar glperfex en un sistema que cumpla con las condicionesestablecidas en los requisitos de la aplicacion existe un paquete deb que rea-lizara todo el trabajo (en sistemas tipo Debian). La instalacion del paquetese realiza mediante el comando dpkg, de la siguiente manera:

# dpkg -i glperfex-1.0_all.deb

La desinstalacion es analoga a la de cualquier programa en Debian,# apt-get remove glperfex. Tambien es posible instalar glperfex en siste-mas de empaquetado rpm, utilizado para ello el programa alien que convierteel formato.

106 A.3. Uso de la Aplicacion

A.3. Uso de la Aplicacion

A continuacion se presentan las instrucciones para realizar correctamentetodos los objetivos de uso que contempla glperfex.

A.3.1. Abrir Glperfex

glperfex esta accesible en Herramientas del sistema a traves del menu deAplicaciones de gnome, Figura A.1. Por supuesto, tambien puede ser acce-dido a traves de lınea de comandos, simplemente tecleando glperfex. Elresto de la aplicacion esta localizado en /usr/share/glperfex.

Figura A.1: Manual de Usuario: abrir glperfex

A.3.2. Generar Medicion con Planificador Estandar

Como adelantamos en la introduccion, glperfex puede usarse en medicio-nes exclusivas, optimizadas para la medicion con el menor ruido posible, ymediante el uso del planificador normal del kernel de Linux.

Para realizar una medicion con el Planificador de Linux, basta con se-leccionar en “Modo de Ejecucion” la opcion Normal, como vemos en laFigura A.2, de esta manera, se desactiva la opcion de elegir el procesador


Figura A.2: Manual de Usuario: Medicion con Planificador Estandar

donde ejecutar la tarea, esto se debe a que el planificador de Linux deci-dira el reparto de la carga del sistema de acuerdo con su propio criterio. Eneste mismo panel podemos escoger el numero de repeticiones que haremosde la medicion, entre una y veinte, en “Numero de Ejecuciones”, y el bina-rio a ejecutar. Este binario debe ser tener una descripcion parecida a la delCuadro A.1 al ejecutar el comando file /ruta/nombreejecutable.

invitado@karma:~/ruta$ file nombrejecutablenombreejecutable: ELF 32-bit LSB executable, Intel 80386,version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked(uses shared libs), not stripped

Cuadro A.1: Manual de Usuario: caracterısticas validas de un ejecutable

Esto nos indica que es un fichero ejecutable, que cumple con el estandarELF, y que esta enlazado dinamicamente y compilado para 32 bits. El eje-cutable puede ser abierto mediante un dialogo activado al pulsar en el boton“...”, o escribiendo su ruta completa. En caso de estar incluido en una car-peta del PATH del sistema, podremos escribir el nombre del ejecutable direc-tamente.


Una vez hemos realizado la configuracion de la ejecucion, es momentode seleccionar los contadores a medir, Figura A.3.

Figura A.3: Manual de Usuario: Medicion con Planificador Estandar

La lista de contadores clasica incluye los siguiente eventos a medir3:

PAPI L1 DCM Level 1 data cache misses

PAPI L1 ICM: Level 1 instruction cache misses

PAPI L2 DCM: Level 2 data cache misses

PAPI L2 ICM: Level 2 instruction cache misses

PAPI L1 TCM: Level 1 cache misses

PAPI L2 TCM: Level 2 cache misses

PAPI CA SHR: Requests for exclusive access to shared cache line

PAPI CA CLN: Requests for exclusive access to clean cache line

PAPI CA ITV: Requests for cache line intervention

3Han sido publicados tal y como muestra la salida de lperfex


PAPI TLB DM: Data translation lookaside buffer misses

PAPI TLB IM: Instruction translation lookaside buffer misses

PAPI L1 LDM: Level 1 load misses

PAPI L1 STM: Level 1 store misses

PAPI L2 LDM: Level 2 load misses

PAPI L2 STM: Level 2 store misses

PAPI BTAC M: Branch target address cache misses

PAPI HW INT: Hardware interrupts

PAPI BR CN: Conditional branch instructions

PAPI BR TKN: Conditional branch instructions taken

PAPI BR NTK: Conditional branch instructions not taken

PAPI BR MSP: Conditional branch instructions mispredicted

PAPI BR PRC: Conditional branch instructions correctly predicted

PAPI TOT IIS: Instructions issued

PAPI TOT INS: Instructions completed

PAPI FP INS: Floating point instructions

PAPI BR INS: Branch instructions

PAPI RES STL: Cycles stalled on any resource

PAPI TOT CYC: Total cycles

PAPI L1 DCH: Level 1 data cache hits

PAPI L1 DCA: Level 1 data cache accesses

PAPI L2 DCA: Level 2 data cache accesses

PAPI L2 DCR: Level 2 data cache reads

PAPI L2 DCW: Level 2 data cache writes

PAPI L1 ICH: Level 1 instruction cache hits

PAPI L2 ICH: Level 2 instruction cache hits

PAPI L1 ICA: Level 1 instruction cache accesses


PAPI L2 ICA: Level 2 instruction cache accesses

PAPI L1 ICR: Level 1 instruction cache reads

PAPI L2 ICR: Level 2 instruction cache reads

PAPI L2 TCH: Level 2 total cache hits

PAPI L1 TCA: Level 1 total cache accesses

PAPI L2 TCA: Level 2 total cache accesses

PAPI L2 TCR: Level 2 total cache reads

PAPI L2 TCW: Level 2 total cache writes

PAPI FML INS: Floating point multiply instructions

PAPI FDV INS: Floating point divide instructions

PAPI FP OPS: Floating point operations

Una vez seleccionados los contadores necesarios, pulsamos en el boton“Ejecutar Test” y se generaran los resultados. Si hemos seleccionado solouna ejecucion, apareceran los resultados con el aspecto de la Figura A.4,con mas de una ejecucion se generara una grafica comparativa, tal y comose aprecia en la Figura A.5.

A.3.3. Generar Medicion Exclusiva

Como caso alternativo de medicion contemplamos la medicion exclusi-va, lanzando el programa a ejecutar como un proceso de tiempo real. Laseleccion de este caso se realiza en el mismo apartado que realizamos la me-dicion estandar, es decir, seleccionamos en la pestana de Configuracion, enel cuadro “Modo de Ejecucion”, Exclusiva, Figura A.6. Como observamosal pulsar la opcion, ahora sı se nos permite seleccionar el procesador dondelanzar el programa. El funcionamiento es el siguiente:

Al seleccionar una CPU solamente, el sistema lanzara la tarea de formaexclusiva sobre ese procesador.

Al seleccionar mas de una CPU, RTAI decidira donde se lanzara deforma exclusiva el proceso dependiendo de la carga de tareas en tiemporeal.

El resto del proceso es analogo al de la medicion estandar, por lo quesimplemente se sigue el proceso del apartado .


Figura A.4: Manual de Usuario: Medicion con Planificador Estandar 1

A.3.4. Guardar Resultados de una Medicion

Una vez generada una medicion, como serıa el caso de la Figuras A.4 yA.5, glperfex nos permite guardar los resultados de la misma en un ficherode formato CSV4. Este formato es compatible con la mayorıa de hojas decalculo del mercado (incluyendo OpenOffice.org Calc y Microsoft Office),por lo que trabajar con los resultados de las mediciones sera sencillo.

Para guardar la medicion accederemos a la opcion Guardar Resultadodel menu “Archivo”, tal y como podemos ver en la Figura A.7. Despues,se nos abrira un dialogo donde simplemente especificaremos la ruta dondealmacenar el fichero y el nombre que deseemos darle.

A.3.5. Guardar Grafica de una Medicion

Del mismo modo que vimos en el apartado anterior, al generarse unagrafica podemos guadar la misma para utilizarla con posterioridad en algundocumento. Gracias a la biblioteca utilizada para generarla, la imagen puede

4Mas informacion acerca del formato CSV http://en.wikipedia.org/wiki/Comma-separated values


Figura A.5: Manual de Usuario: Resultados con Planificador Estandar 2

ser almacenada en una gran cantidad de formatos conocidos, entre los quese incluyen png, jpg o gif.

Para guardar la medicion accederemos a la opcion Guardar Graficadel menu “Archivo”, tal y como podemos ver en la Figura A.7. Despues,se nos abrira un dialogo donde simplemente especificaremos la ruta dondealmacenar la grafica y el nombre que deseemos darle. Es importante recal-car de nuevo que en mediciones donde solo se realice una repeticion, no sepermitira guardar la grafica al no haber sido generada.

A.3.6. Cargar una Medicion Previa

Como resultado de la opcion de copia de las mediciones que se descri-bio en el apartado A.3.4, glperfex incluye una ultima opcion de uso quepermite cargar en el programa una medicion realizada con anterioridad.

Para abrir un resultado, accederemos tal y como hicimos en las dosopciones de guardar al menu “Archivo”, y accedemos a la opcion Abrir.Una vez ahı se nos pedira la ruta del fichero y el nombre, cargandose alseleccionar el mismo en el panel de resultados de la ultima pestana, tal ycomo si se hubiera realizado una nueva medicion.


Figura A.6: Manual de Usuario: Ejecucion en Modo Exclusivo

Esta opcion sera util cuando queramos comparar in situ ejecuciones deun mismo programa.

A.4. Ayuda y Licencia

Toda la informacion de ayuda, ası como los creditos e informacion decontacto, y la licencia del programa esta disponible en el menu “Ayuda”,junto al menu de archivo que veıamos en las figuras anteriores.

glperfex es software libre bajo licencia GNU GPL v3, por lo tanto, cum-ple con la libertad 0 de la definicion de software libre: “Libertad para usar(ejecutar) el programa, con cualquier proposito”. En el manual de usuario,debido al ambito sobre el que se enfoca la redaccion del texto, esta serıa launica libertad a nombrar, sin embargo, si el usuario desea seguir investigan-do, y hacerse partıcipe de las tres libertades restantes:

1. La libertad de estudiar como funciona el programa, y adaptarlo a lasnecesidades necesidades. El acceso al codigo fuente es una condicionprevia para esto.

114 A.4. Ayuda y Licencia

Figura A.7: Manual de Usuario: Menu Archivo

2. La libertad de distribuir copias, para ayudar a la comunidad.

3. La libertad de mejorar el programa y hacer publicas las mejoras alos demas, de modo que toda la comunidad se beneficie. El acceso alcodigo fuente es un requisito previo para esto.

Puede encontrar toda la informacion y codigo fuente necesarios enhttp://consejo-eps.uco.es/karma.

Apendice B

Manual de Codigo

El siguiente documento presenta la documentacion de codigo de la apli-cacion glperfex, interfaz sencilla para lperfex, aplicacion para la medicion nointrusiva de eventos de procesador.

La documentacion ha sido generada utilizando el programa Doxygen.Doxygen es un generador de documentacion para C++, C, Java, Objective-C, Python, IDL (versiones Corba y Microsoft) y en cierta medida para PHP,C# y D. Funciona en la mayorıa de sistemas Unix ası como en Windowsy MacOS X. Esta licenciado bajo la licencia de GNU GPL v2 y es utiliza-do por infinidad de aplicaciones de software libre para la generacion de sudocumentacion, entre ellas destacan:

Abiword.

ALSA (Advanced Linux Sound Architecture Project).

Kdevelop y muchos otros proyectos de KDE.

MediaWiki

MySQL.

Pidgin.

ReactOS.

Samba.

ScummVM.

115

116 B.1. Referencia de la Clase glperfex::MainFrame

La organizacion de la documentacion es sencilla, se iran exponiendo or-denadamente cada una de las siete clases del programa, enumerando susatributos publicos mas importantes y realizando un analisis comentado delos metodos acompanados de su codigo.

B.1. Referencia de la Clase glperfex::MainFrame

Clase que contiene el marco principal de la aplicacion grafica, dentro deel se activaran las pestanas donde se configuran las diferentes opciones delprograma expresadas en pestanas.

Metodos publicos

def init

Constructor de la clase MainFrame ( p. 116).

def GetAndSendSelections

Este metodo recoge las selecciones que se han realizado y comprueba si sepuede proceder a aplicar la medicion.

def OnOpen

Este metodo abre los resultados que estan almacenados en algun fichero.

def OnSave

Este metodo guarda los resultados de la ejecucion en caso de haber sidogenerados estos.

def OnSaveDraw

Este metodo guarda la grafica despues de comprobar si esta ha sido gene-rada.

def OnAbout

Este metodo construye la ventana de About, donde podremos consultar losautores de la aplicacion ası como su licencia completa.

def OnExit

Este metodo cierra la ventana.

Manual de Codigo 117

Atributos publicos

filehelpmenubarrunButtoniconnbconfigcountersstats

B.1.1. Descripcion detallada

Clase que contiene el marco principal de la aplicacion grafica, dentro deel se activaran las pestanas donde se configuran las diferentes opciones delprograma expresadas en pestanas.

Es decir, la pestana de Configuracion, clase Configuration, la pestana deContadores, clase Counters y la pestana de Resultados, clase Results.

Parametros:

wx.Frame Hereda de la clase wx.Frame

Definicion en la lınea 27 del archivo glperfex.py.

B.1.2. Documentacion de las funciones miembro

B.1.2.1. def glperfex::MainFrame:: init ( self)

Constructor de la clase MainFrame (p. 116).

Parametros:

self Puntero al objeto actual.


31 :

32 # Iniciamos la clase de la que hereda MainFrame


33 wx.Frame.__init__(self,None,wx.ID_ANY,title="Glperfex",

size = (600,400),

34 style = wx.DEFAULT_FRAME_STYLE | wx.NO_FULL_REPAINT_ON_RESIZE)

35

36 # Barra de Estatus

37 self.CreateStatusBar()

38

39 # Creamos el menu con sus submenus

40 # Menu Archivo

41

42 self.file = wx.Menu()

43

44 # Opcion de abrir fichero

45 openFile = wx.MenuItem(self.file, 101, ’&Abrir\tCtrl+O’)

46 openFile.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/fileopen.png’))

47 self.file.AppendItem(openFile)

48

49 # Opcion de guardar resultado de mediciones

50 saveFile = wx.MenuItem(self.file, 102, ’&Guardar Resultado\tCtrl+S’)

51 saveFile.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/filesave.png’))

52 self.file.AppendItem(saveFile)

53

54 # Opcion de guardar la grafica generada

55 saveGraphic = wx.MenuItem(self.file, 105, ’&Guardar Grafica\tCtrl+G’)

56 saveGraphic.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/filesaveas.png’))

57 self.file.AppendItem(saveGraphic)

58

59 self.file.AppendSeparator()

60

61 quit = wx.MenuItem(self.file, 103, ’&Salir\tCtrl+Q’)

62 quit.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/exit.png’))

63 self.file.AppendItem(quit)

64

65 # Menu Ayuda

66

67 self.help = wx.Menu()

68

69 about = wx.MenuItem(self.file, 104, ’&Acerca &de’)

70 about.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/help-about.png’))

71 self.help.AppendItem(about)

72

73 self.menubar = wx.MenuBar()

74 self.menubar.Append(self.file, "&Archivo")

75 self.menubar.Append(self.help, "Ay&uda")

76 self.SetMenuBar(self.menubar)

77 self.runButton = wx.Button(self, -1, "Ejecutar Test")

78 self.runButton.SetMinSize((160,27))

79

80 # Establecemos el icono de la aplicacion.

81 self.icon = wx.EmptyIcon()

82 self.icon.CopyFromBitmap(wx.Bitmap("/usr/share/glperfex/icons/glperfex.png",

wx.BITMAP_TYPE_ANY))

83 self.SetIcon(self.icon)

84


85

86

87 # Hacemos bind con las funciones que queremos ejecutar en el menu.

88 self.Bind(wx.EVT_MENU, self.OnOpen, id = 101)

89 self.Bind(wx.EVT_MENU, self.OnSave, id = 102)

90 self.Bind(wx.EVT_MENU, self.OnExit, id =103)

91 self.Bind(wx.EVT_MENU, self.OnAbout, id=104)

92 self.Bind(wx.EVT_MENU, self.OnSaveDraw, id=105)

93

94 # Creamos el NoteBook donde se introduciran los diferentes paneles.

95 self.nb = wx.Notebook(self,-1,style=0)

96

97 # Creamos las paginas de nuestro NoteBook, con los tres paneles cada uno

en una

98 # pesta~na.

99 self.config = configuracion.Configuration(self.nb)

100 self.counters = contadores.Counters(self.nb)

101 self.stats = resultados.Results(self.nb)

102

103

104 # A~nadimos las paginas al NoteBook

105 self.nb.AddPage(self.config, "Configuracion")

106 self.nb.AddPage(self.counters, "Contadores")

107 self.nb.AddPage(self.stats, "Resultados")

108

109 # Finalmente introducimos el NoteBook

110 sizer = wx.BoxSizer(wx.VERTICAL)

111 sizer.Add(self.nb, 1, wx.EXPAND)

112 sizer.Add(self.runButton, 0, wx.ALIGN_BOTTOM|wx.ALIGN_CENTER_HORIZONTAL|

wx.ADJUST_MINSIZE, 0)

113 self.SetSizer(sizer)

114

115 self.Bind(wx.EVT_BUTTON, self.GetAndSendSelections,

id=self.runButton.GetId())

116

## Este metodo recoge las selecciones que se han realizado y comprueba

si se puede proceder a aplicar la medicion.

B.1.2.2. def glperfex::MainFrame::GetAndSendSelections ( self,event)

Este metodo recoge las selecciones que se han realizado y comprueba sise puede proceder a aplicar la medicion.

Parametros:

self Puntero al objeto actual.event Evento que activa el metodo al accionarse en el panel.



120 :

121

122 # Se recogen los contadores seleccionados de la pesta~na de Contadores

123 listofCounters = self.counters.GetSelectedCountersList()

124 # Se recogen las selecciones de la pesta~na de Configuracion

125 tupleofCommands = self.config.GetCommand()

126

127 # No existe ningun fichero binario

128 if tupleofCommands == "empty":

129 dial = wx.MessageDialog(None, ’No ha sido introducido ningun fichero

binario’,

130 ’Aviso’, wx.OK | wx.ICON_EXCLAMATION)

131 dial.ShowModal()

132 dial.Destroy()

133

134 #El fichero introducido no es un binario valido

135 elif tupleofCommands == "invalid":

136 dial = wx.MessageDialog(None, ’El fichero introducido no es un binario

valido’,



139 dial.Destroy()

140

141 # No se ha seleccionado ningun contador.

142 elif len(listofCounters) == 0:

143 dial = wx.MessageDialog(None, ’No ha sido seleccionado ningun Contador’,



146 dial.Destroy()

147

148 # Caso correcto, se incia la ejecucion con el comando fabricado y se limpia

el comando

149 # y se envıan los resultados a la Pesta~na de Resultados.

150 else:

151 commandDict = {}

152 i = 0

153 for element in listofCounters:

154 com = ("lperfex -e " + listofCounters[i] + " " + tupleofCommands[0]

+ " " +

155 tupleofCommands[1] + " -- ", tupleofCommands[2])

156 commandDict[listofCounters[i]] = com

157 i = i + 1

158

159 self.stats.SetList(commandDict)

160

161 self.stats.SetResults(1)

162

## Este metodo abre los resultados que estan almacenados en algun fichero.

B.1.2.3. def glperfex::MainFrame::OnOpen ( self, event)

Este metodo abre los resultados que estan almacenados en algun fichero.


Parametros:


event Evento que activa el metodo al accionarse en el panel.


166 :

167

168 dlg = wx.FileDialog(self, "Abrir", os.getcwd(), "", "*.csv", wx.OPEN)

169 if dlg.ShowModal() == wx.ID_OK:

170 #Metemos la ruta en el boton de comandos

171 self.stats.Load(dlg.GetPath())

172 self.stats.SetResults(2)

173 dlg.Destroy()

174

## Este metodo guarda los resultados de la ejecucion en caso de haber sido

generados estos.

B.1.2.4. def glperfex::MainFrame::OnSave ( self, event)

Este metodo guarda los resultados de la ejecucion en caso de haber sidogenerados estos.

Parametros:




178 :

179

180 if self.stats.generated:

181 dlg = wx.FileDialog(self,"Guardar", os.getcwd(), ".csv","*.csv", wx.SAVE)


183 self.stats.Get(dlg.GetPath())

184 dlg.Destroy()

185 else:

186 dial = wx.MessageDialog(None, ’Aun no ha sido generado ningun resultado’,



189 dial.Destroy()

190

## Este metodo guarda la grafica despues de comprobar si esta ha sido generada.


B.1.2.5. def glperfex::MainFrame::OnSaveDraw ( self, event)

Este metodo guarda la grafica despues de comprobar si esta ha sidogenerada.

Parametros:




194 :

195 if self.stats.GetDraw(""):

196 pass

197

198 else:

199 dial = wx.MessageDialog(None, ’Aun no ha sido generada ninguna

grafica’, ’Aviso’,

200 wx.OK | wx.ICON_EXCLAMATION)


202 dial.Destroy()

203

204

## Este metodo construye la ventana de About, donde podremos consultar los

autores de la aplicacion ası como su licencia completa

B.1.2.6. def glperfex::MainFrame::OnAbout ( self, event)

Este metodo construye la ventana de About, donde podremos consultarlos autores de la aplicacion ası como su licencia completa.

Parametros:




208 :

209

210 description = """

211 Glperfex es una interfaz de usuario simple a

212 lperfex, una aplicacion para la medicion de eventos a

213 traves de Performance API (PAPI) de procesador usando


214 el planificador de Linux o RTAI.

215

216 Glperfex y Lperfex fueron concebidos como herramientas

217 de trabajo para la distribucion Karma GNU/Linux,

218 Proyecto Fin de Carrera para Ingenierıa Tecnica en

219 Informatica de Sistemas, cursada en la Escuela

220 Politecnica Superior de la Universidad de Cordoba.

221 """

222 # Se obtiene la licencia del fichero COPYING

223 fp = open(’COPYING’,’r’)

224

225 if fp:

226 licence = fp.read()

227 else:

228 licence = "Puede descargar una copia de GNU GPL v3 en

http://www.gnu.org/licenses/gpl.html"

229

230

231 info = wx.AboutDialogInfo()

232

233 info.SetIcon(wx.Icon(’/usr/share/glperfex/icons/glperfex.png’,

wx.BITMAP_TYPE_PNG))

234 info.SetName(’Glperfex’)

235 info.SetVersion(’1.0’)

236 info.SetDescription(description)

237 info.SetCopyright(’(C) 2008 Fernando Garcıa Aranda\nPedro Navajas Modelo’)

238 info.SetWebSite(’http://consejo-eps.uco.es/karma’)

239 info.SetLicence(licence)

240 info.AddDeveloper(’Fernando Garcıa Aranda\[email protected]\n

\nPedro Navajas Modelo\[email protected]’)

241 info.AddDocWriter(’Fernando Garcıa Aranda\[email protected]’)

242

243

244 wx.AboutBox(info)

245

## Este metodo cierra la ventana

B.1.2.7. def glperfex::MainFrame::OnExit ( self, event)

Este metodo cierra la ventana.

Parametros:




249 :

124 B.2. Referencia de la Clase configuracion::Configuration

250

251 self.Close(True)

252

253

254

if __name__ == "__main__":

La documentacion para esta clase fue generada a partir del siguientefichero:

glperfex.py

B.2. Referencia de la Clase configura-cion::Configuration

Desde esta clase se muestran las opciones de Configuracion de la ejecu-cion de lperfex.

Metodos publicos

def initConstructor de la Clase Configuration ( p. 124).

def OpenFileEste metodo abre un dialogo para abrir un fichero, en este caso el ejecu-table de la medicion.

def EnableOrDisableCheckboxesEste metodo habilita las Checkboxes que senalan la posibildad de elegirel procesador, o procesadores donde ejecutaremos el proceso a medir enfuncion de si hemos elegido el modo normal (0), que deshabilita, o unodistinto de cero, que habilita las Checkboxes.

def GetCommandEste metodo trata el Comando que sera enviado.

Atributos publicos

ioexecutionMode


cpusnumlistofCheckBoxeslabelsc1label2executablebrowseButtoncommand


Desde esta clase se muestran las opciones de Configuracion de la ejecu-cion de lperfex.

Es decir las antiguas opciones de lperfex -x, lperfex -s y lperfex -sx.Ademas de ello se le une a esta cadena el fichero ejecutable (debe ser unbinario enlazado con la libc) que sera ejecutado. Se trata de un Panel en laventana principal (MainFrame) de Glperfex.

Parametros:

wx.Panel Hereda de la clase wx.Panel

Definicion en la lınea 24 del archivo configuracion.py.


B.2.2.1. def configuracion::Configuration:: init ( self, parent)

Constructor de la Clase Configuration (p. 124).

Parametros:


parent Puntero al objeto padre.


29 :

30

31


32 # Iniciamos la clase de las que hereda la clase Configuration,

es decir wx.Panel

33 wx.Panel.__init__(self, parent)

34

35 #

36 self.io = io.IOInterface()

37

38 #Modo de Ejecucion del binario

39 executionList = [’Normal’, ’Exclusiva’]

40 self.executionMode = wx.RadioBox(self, -1, "Modo de Ejecucion", (10, 10),

wx.DefaultSize,

41 executionList, 2, 2)

42

43

44 # Se recoge el numero de CPUs de la maquina sobre la que se ejecuta el

programa

45

46 self.cpusnum = num = os.sysconf(’SC_NPROCESSORS_ONLN’)

47

48

49 # Construimos la static box dependiendo del numero de CPUs de la maquina

50 if self.cpusnum <= 2:

51 wx.StaticBox(self, -1, ’CPUs Activas’, (150, 10), size=(100, 67))

52

53 elif self.cpusnum % 2 == 0:

54 wx.StaticBox(self, -1, ’CPUs Activas’, (150, 10), size=(77*

(self.cpusnum/2), 67))

55 else:

56 wx.StaticBox(self, -1, ’CPUs Activas’, (150, 10), size=(77*

(self.cpusnum/2 + 1), 67))

57

58 # Imprimimos por pantalla las CheckBoxes correspondientes a los

procesadores de la

59 # maquina en filas de 2

60

61 self.listofCheckBoxes = []

62 i = 0

63 x = 160

64 while i < self.cpusnum:

65 y = 26

66 j = 0

67 while j < 2 and self.cpusnum != i:

68 label = "CPU " + str(i)

69 self.listofCheckBoxes.append(wx.CheckBox(self, -1 ,label, (x,y)))

70 y += 26

71 i += 1

72 j += 1

73 x += 70

74

75 # Activamos o desactivamos las CheckBoxes dependiendo de si hemos escogido

ejecucion

76 # en modo exclusivo o modo normal, ya que en modo normal el planificador

del kernel

77 # de linux actuara a su modo.


78

79 if self.executionMode.GetSelection() == 0:

80 for i in self.listofCheckBoxes:

81 i.Disable()

82

83

84

85 wx.StaticBox(self, -1, ’Configuracion para la Ejecucion’, (10, 95),

size=(430, 100))

86

87

88 # Numero de ejecuciones, se permite entre 1 y 20

89

90 self.label = wx.StaticText(self,-1," Numero de Ejecuciones",(15,125))

91 self.sc1 = wx.SpinCtrl(self, -1, ’’, (180, 120), (60, -1), min=1, max=20)

92

93

94 # Se recoge el nombre del binario a ejecutar, ya sea por cuadro de texto

(label2)

95 # o a traves del dato que nos da el browseButton.

96

97 self.label2 = wx.StaticText(self, -1, " Binario a Ejecutar",(15,160))

98 self.executable = wx.TextCtrl(self, -1,"", (140,155),(260, 27))

99 self.browseButton = wx.Button(self, -1, "...",(400,155),(27,27))

100

101 # Enlazamos las funciones de abrir fichero al browseButton y de activar

o desactivar

102 # dependiendo de si cambiamos la seleccion de la RADIOBOX.

103

104 self.Bind(wx.EVT_BUTTON, self.OpenFile, id=self.browseButton.GetId())

105 self.Bind(wx.EVT_RADIOBOX, self.EnableOrDisableCheckboxes,

id=self.executionMode.GetId())

106

107

108 self.command = ("","")

109

## Este metodo abre un dialogo para abrir un fichero, en este caso el ejecutable

B.2.2.2. def configuracion::Configuration::OpenFile ( self,event)

Este metodo abre un dialogo para abrir un fichero, en este caso el ejecu-table de la medicion.

El dialogo es el dialgo estandar que nos proporciona wxPython.

Parametros:





114 :

115

116 dlg = wx.FileDialog(self, "Choose a file", os.getcwd(), "", "*", wx.OPEN)


118 self.executable.SetValue(dlg.GetPath()) #Metemos la ruta en el boton

de comandos

119 dlg.Destroy()

120

121

## Este metodo habilita las Checkboxes que se~nalan la posibildad de elegir el

procesador,

B.2.2.3. def configura-cion::Configuration::EnableOrDisableCheckboxes ( self,event)

Este metodo habilita las Checkboxes que senalan la posibildad de elegir elprocesador, o procesadores donde ejecutaremos el proceso a medir en funcionde si hemos elegido el modo normal (0), que deshabilita, o uno distinto decero, que habilita las Checkboxes.

Parametros:



127 :

128

129



132 i.Disable()

133 else:


135 i.Enable()

136

## Este metodo trata el Comando que sera enviado. Primero se obtendra

el valor que hay

B.2.2.4. def configuracion::Configuration::GetCommand ( self)

Este metodo trata el Comando que sera enviado.


Primero se obtendra el valor que hay registrado en el campo del texto.Despues se comprobara si esta vacıo. En caso de tener barras se compruebaque exista y sea un fichero ejecutable con el metodo de la clase IOInterfaceCheckExecutableFile, si no tiene barras, se buscara si esta en el PATH yextraera su directorio y sometiendolo entonces al mismo proceso de compro-bacion que de las barras. Posteriormente recogera los datos escogidos en elresto de los paneles y devolvera una tupla con los datos.

Parametros:


Devuelve:

”invalid” En caso de que el fichero a ejecutar no sea valido”empty” En caso de que no se haya introducido un fichero a ejecutar.(mode,nexecutions,str(executable)) En caso en que todo salga correcto,devuelve una tupla de tres elementos, con el modo de ejecucion escogido,el numero de ejecuciones, y la direccion del ejecutable.


150 :

151

152

153 executable = self.executable.GetValue()

154

155 # Si el fichero ejecutable que nos introduce el usuario esta vacıo

se devuelve

156 # la cadena "empty"

157 if executable == "" :

158 return "empty"

159

160 # En caso de tener los directorios completos, comprobamos con la

clase de IO

161 # que sea un ejecutable correcto

162 elif ’/’ in executable:

163 if self.io.CheckExecutableFile(executable) == False:

164 return "invalid"

165

166 # En caso de no tener barras, habra que extraer el directorio y

el nombre del

167 # fichero con el metodo DividePath, cuando lo tengamos habra que

comprobar

168 # como en el caso anterior que el fichero es un ejecutable correcto.

169 elif ’/’ not in executable:

170 returnedValue = self.io.DividePath(executable)

171 directory = returnedValue[0]

172 filename = returnedValue[1]

130 B.3. Referencia de la Clase contadores::Counters

173 if self.io.CheckExecutableFile(directory + filename) == False:

174 return "invalid"

175

176 # Se recoge el modo de ejecucion, si es Normal se pone "" en la opcion


178 mode = ""

179

180 # En caso contrario el modo de ejecucion sera exclusivo "-x" y por defecto

181 # ejecutaremos si no hay nada ejecutado la CPU 0, es decir pondremos un 1

182 # en el parametro.

183 else:

184 mode = "-x"

185 ncpusallowed = 1

186

187 #En caso de haber una seleccion se realiza el siguiente algoritmo

para

188 #introducir el parametro necesario por glperfex

189 for i in range(self.cpusnum):

190 if(self.listofCheckBoxes[i].GetValue()):

191 ncpusallowed += pow(2,i)

192 if(ncpusallowed == 0):

193 ncpusallowed = 1

194

195 # El modo sera -n numerodecpus

196 mode += " -n " + str(ncpusallowed)

197

198 # Se recoge el numero de ejecuciones a realizar

199 nexecutions = "-s " + str(self.sc1.GetValue())

200

201 # Si todo ha salido bien devolvemos la tupla con el modo de ejecucion,

el numero

202 # de ejecuciones y el nombre del fichero ejecutable con su ruta

completa

203 return mode, nexecutions, str(executable)

204


configuracion.py

B.3. Referencia de la Clase contadores::Counters

Desde esta clase se muestran los contadores que pueden ser medidos enla Ejecucion.


Metodos publicos

def init

Constructor de la Clase Counters ( p. 130).

def OnSelect

Este metodo controla la seleccion de los distintos contadores.

def OnSelectAll

Este metodo selecciona todos los contadores de la lista.

def OnSelectNone

Este metodo borra todos los contadores de la lista.

def GetSelectedCountersList

Este obtiene los elementos seleccionados de la lista.

Atributos publicos

io

selectedCountersList

list


Desde esta clase se muestran los contadores que pueden ser medidos enla Ejecucion.

Una vez el usuario ha observado dichos contadores puede seleccionaraquellos que desee medir. Se trata de un Panel en la ventana principal (Main-Frame) de Glperfex.

Parametros:


Definicion en la lınea 30 del archivo contadores.py.



B.3.2.1. def contadores::Counters:: init ( self, parent)

Constructor de la Clase Counters (p. 130).

Parametros:




35 :

36

37 # Se llama a la clase padre, para iniciar el constructor de la misma.


39

40 #Objeto de la clase IO.


42

43 # Cajas verticales y horizontales.

44 vbox = wx.BoxSizer(wx.VERTICAL)

45 hbox = wx.BoxSizer(wx.HORIZONTAL)

46

47 # Se construyen los panels de la izquierda y la derecha.

48 leftPanel = wx.Panel(self, -1)

49 rightPanel = wx.Panel(self, -1)

50

51 # Incializamos la lista de Contadores Seleccionados.

52 self.selectedCountersList = []

53

54 self.list = CheckListCtrl(rightPanel)

55 self.list.InsertColumn(0, ’Contador’, width=140)

56 self.list.InsertColumn(1, ’Descripcion’, width=400)

57

58

59 # Colocamos el nombre del Contador, desde el dicconario de Contadores

60 # y lo introducimos en la columna 0 y en la columna 1 introducimos la

61 # descripcion.

62 for key in self.io.dictofCounters:

63 index = self.list.InsertStringItem(0,key)

64 self.list.SetStringItem(index,1, self.io.dictofCounters[key])

65

66 # Creamos una nueva caja de division

67 vbox2 = wx.BoxSizer(wx.VERTICAL)

68

69 # Creamos los botones para Seleccionar Todo o seleccionar nada.

70 sel = wx.Button(leftPanel, -1, ’Selec. Todo’, size=(100, -1))

71 des = wx.Button(leftPanel, -1, ’Selec. Nada’, size=(100, -1))


72

73 # Asignamos los botones creados al metodo que les corresponde.

74 self.Bind(wx.EVT_BUTTON, self.OnSelectAll, id=sel.GetId())

75 self.Bind(wx.EVT_BUTTON, self.OnSelectNone, id=des.GetId())

76 self.Bind(wx.EVT_LIST_ITEM_ACTIVATED, self.OnSelect)

77

78 # A~nadimos los botones a la caja de division que acabamos de crear

79 vbox2.Add(sel, 0, wx.TOP, 5)

80 vbox2.Add(des)

81

82 # Introducimos la caja de division en el panel de la izquierda.

83 leftPanel.SetSizer(vbox2)

84

85 # A~nadimos la lista donde introdujimos los contadores y la

descripcion

86 # a la caja vbox.

87 vbox.Add(self.list, 1, wx.EXPAND | wx.TOP, 3)

88

89 # A~nadimos la caja vbox al panel de la derecha.

90 rightPanel.SetSizer(vbox)

91

92 # A~nadimos los paneles de la izquierda y derecha a la caja

principal

93 # que establecera primero el de la izquierda y segundo el

de la derecha

94 # a su derecha

95 hbox.Add(leftPanel, 0, wx.EXPAND | wx.RIGHT, 5)

96 hbox.Add(rightPanel, 1, wx.EXPAND)

97 hbox.Add((3, -1))

98

99 # Colocamos la hbox en el panel y ya tenemos el Frame.

100 self.SetSizer(hbox)

101

102 self.Centre()

103 self.Show(True)

104

105

## Este metodo controla la seleccion de los distintos contadores.

B.3.2.2. def contadores::Counters::OnSelect ( self, event)

Este metodo controla la seleccion de los distintos contadores.

Si no esta seleccionado y se activa se selecciona y viceversa.

Parametros:




110 :

111 selectedElement = self.list.GetFirstSelected()

112

113 if self.list.IsChecked(selectedElement):

114 self.list.CheckItem(selectedElement,False)

115 else:

116 self.list.CheckItem(selectedElement)

117

118

B.3.2.3. def contadores::Counters::OnSelectAll ( self, event)

Este metodo selecciona todos los contadores de la lista.

Parametros:




122 :

123 num = self.list.GetItemCount()

124 for i in range(num):

125 self.list.CheckItem(i)

126

## Este metodo borra todos los contadores de la lista.

B.3.2.4. def contadores::Counters::OnSelectNone ( self, event)

Este metodo borra todos los contadores de la lista.

Parametros:




130 :



133 self.list.CheckItem(i, False)

134

## Este obtiene los elementos seleccionados de la lista.


B.3.2.5. def contadores::Counters::GetSelectedCountersList (self)

Este obtiene los elementos seleccionados de la lista.

Parametros:


Devuelve:

self.selectedCountersList Devuelve una lista con los nombres de los con-tadores seleccionados


138 :


140 self.selectedCountersList = []


142 if i == 0: self.selectedCountersList = []

143 if self.list.IsChecked(i):

144 self.selectedCountersList.append(str

(self.list.GetItemText(i)))

145 return self.selectedCountersList

146

147

148

## Esta clase construye una Lista de Control con Checkboxes, la utilizaremos

para que el usuario seleccione los contadores.


contadores.py

B.4. Referencia de la Clase contado-res::CheckListCtrl


136 B.4. Referencia de la Clase contadores::CheckListCtrl

Diagrama de herencias de contadores::CheckListCtrl

Diagrama de colaboracion para contadores::CheckListCtrl:

Metodos publicos

def init

Constructor de la Clase CheckListCtrl ( p. 135).



Hereda de varias clases de wxPython como vemos en los parametros.

Parametros:

wx.ListCtrl

CheckListCtrlMixin

ListCtrlAutoWidthMixin




B.4.2.1. def contadores::CheckListCtrl:: init ( self, parent)

Constructor de la Clase CheckListCtrl (p. 135).

Parametros:




158 :

159 wx.ListCtrl.__init__(self, parent, -1, style=wx.LC_REPORT |

wx.SUNKEN_BORDER)

160 CheckListCtrlMixin.__init__(self)

161 ListCtrlAutoWidthMixin.__init__(self)

162

163

164


contadores.py

B.5. Referencia de la Clase resultados::Results

Esta clase controla la interfaz de Resultados, dentro de ella encontra-mos un notebook con pestanas borrables donde se registran los resultadosgenerados desde la clase de interfaz de entrada y salida.

Metodos publicos

def init

Constructor de la clase Resultados.

138 B.5. Referencia de la Clase resultados::Results

def SetResults

Inserta los resultados de las ejecuciones en sus listas correspondientes,cada nuevo resultado en una pestana nueva del NoteBook.

def RemoveTab

Borra cada elemento de la lista de Pestanas.

def SetList

Inicia los diccionarios.

def Load

Carga en el diccionario de resultados los valores del fichero a abrir.

def Get

Extrae los valores de la ejecucion de la pestana actual para escribirlos enun fichero.

def GetDraw

Guarda en el fichero que se indica la grafica obtenida, en caso de haberseobtenido.

Atributos publicos

ionblistOfTabsigeneratedsizercommandDictdictionaryOfResults


Esta clase controla la interfaz de Resultados, dentro de ella encontra-mos un notebook con pestanas borrables donde se registran los resultadosgenerados desde la clase de interfaz de entrada y salida.

Se trata de un Panel en la ventana principal (MainFrame) de Glperfex.


Parametros:


Definicion en la lınea 28 del archivo resultados.py.


B.5.2.1. def resultados::Results:: init ( self, parent)

Constructor de la clase Resultados.

Llama a los constructores de las clases de las que hereda y construye lainterfaz. Tambien enlaza los eventos a las funciones correspondientes.

Parametros:




35 :

36

37

38 #Se inician los constructores de las superclases



41 # Se construye el NoteBook (la lista de pesta~nas) ası como la lista de

42 # pesta~nas y el contador de las mismas

43 self.nb = wx.aui.AuiNotebook(self,-1

,style=wx.aui.AUI_NB_WINDOWLIST_BUTTON|

44 wx.aui.AUI_NB_TAB_MOVE|wx.aui.AUI_NB_TAB_SPLIT|

wx.aui.AUI_NB_SCROLL_BUTTONS

45 |wx.aui.AUI_NB_DEFAULT_STYLE)

46

47 self.listOfTabs = []

48 self.i = 0

49 self.generated = False

50

51 # Se a~nade el NoteBook a la ventana de Resultados

52 self.sizer = wx.BoxSizer(wx.HORIZONTAL)

53 self.sizer.Add(self.nb, 1, wx.EXPAND)

54 self.SetSizer(self.sizer)

55

56 # Hacemos un bind del evento de cierre de la pesta~na al metodo que

57 # las borra

58 self.Bind(wx.aui.EVT_AUINOTEBOOK_PAGE_CLOSE, self.RemoveTab)


59

60

## Inserta los resultados de las ejecuciones en sus listas correspondientes,

cada nuevo resultado en una pesta~na nueva del NoteBook.

B.5.2.2. def resultados::Results::SetResults ( self, option)

Inserta los resultados de las ejecuciones en sus listas correspondientes,cada nuevo resultado en una pestana nueva del NoteBook.

Parametros:


option Opcion que fija si hemos de colocar unos resultados de unaejecucion simple, es decir, sin grafica, o una ejecucion con mas deuna ejecucion, es decir con grafica.


65 :

66

67 # A~nadiendo pesta~na de Resultados

68 if self.nb.GetPageCount() == 0:

69 self.i = 0

70 name = "Resultado " + str(self.i)

71 results = ResultsPanel(self.nb)

72

73 a = 0

74 self.i = self.i + 1

75

76 if option == 1:

77 for key in self.commandDict:

78 self.dictionaryOfResults[key] = self.GetResults(

self.commandDict[key])

79 a = self.dictionaryOfResults[key][0]

80

81 else:

82 for key in self.dictionaryOfResults:

83 a = self.dictionaryOfResults[key][0]

84

85 print self.dictionaryOfResults

86

87 if a == 1:

88 results.DecideStructure(1,self.dictionaryOfResults)


90 index = results.list1.InsertStringItem(0,key)

91 results.list1.SetStringItem(index, 1,

92 str(self.dictionaryOfResults[key][1][0]))



94 str(self.dictionaryOfResults[key][4]))



97

98 else:

99 results.DecideStructure(2,self.dictionaryOfResults)


101 index = results.list1.InsertStringItem(0,key)


103 str(self.dictionaryOfResults[key][2]).replace(’,’,’.’))


105 str(self.dictionaryOfResults[key][3]).replace(’,’,’.’))





110

111

112

113 self.nb.AddPage(results, name)

114

115 self.listOfTabs.append(results)

116 self.generated = True

117

## Borra cada elemento de la lista de Pesta~nas.

B.5.2.3. def resultados::Results::RemoveTab ( self, event)

Borra cada elemento de la lista de Pestanas.

Parametros:



121 :

122

123 index = self.nb.GetSelection()

124 del self.listOfTabs[index]

125

## Inicia los diccionarios.

B.5.2.4. def resultados::Results::SetList ( self, orcommandDict)

Inicia los diccionarios.


Parametros:


orcomamandDict Introduce en CommandDict el valor deseado (eldiccionario que se trae desde fuera).


130 :

131 self.commandDict = {}

132 self.commandDict = orcommandDict

133 self.dictionaryOfResults = {}

134

## Carga en el diccionario de resultados los valores del fichero a abrir.

B.5.2.5. def resultados::Results::Load ( self, filename)

Carga en el diccionario de resultados los valores del fichero a abrir.

Parametros:


filename Nombre del fichero a leer.


138 :

139 self.dictionaryOfResults = self.io.ReadCSV(filename)

140

141

## Extrae los valores de la ejecucion de la pesta~na actual para escribirlos en

un fichero.

B.5.2.6. def resultados::Results::Get ( self, filename)

Extrae los valores de la ejecucion de la pestana actual para escribirlosen un fichero.

Parametros:


filename Nombre del fichero a escribir



145 :


147 self.io.WriteCSV(self.listOfTabs[index].dictionaryOfResults,filename)

148

## Guarda en el fichero que se indica la grafica obtenida, en caso de haberse

obtenido.

B.5.2.7. def resultados::Results::GetDraw ( self, filename)

Guarda en el fichero que se indica la grafica obtenida, en caso de haberseobtenido.

Parametros:


filename Nombre del fichero a guardar.

Devuelve:

True En caso de que se haya generado la grafica.False En caso de que no se haya generado.


154 :

155 if self.generated == True:


157 if self.listOfTabs[index].isDrawn == True:

158 self.io.SaveDraw(self.listOfTabs[index].client,filename)

159 return True

160 else:

161 return False

162 else:

163 return False

164

165

166

## La clase ResultsPanel se ocupa de manejar las pesta~nas que se cargan en

la clase Resultados


resultados.py

144 B.6. Referencia de la Clase resultados::ResultsPanel

B.6. Referencia de la Clase resulta-dos::ResultsPanel

La clase ResultsPanel (p. 144) se ocupa de manejar las pestanas quese cargan en la clase Resultados.

Metodos publicos

def init

Constructor de la Clase ResultsPanel ( p. 144).

def DecideStructure

Este metodo nos construye los resultados que figuraran en la pestana decada resultado, la construccion dependera del numero de filas que tenga,es decir, si la ejecucion se realizo una sola vez, solo tendra que ofrecerresultados individuales, en caso contrario mostramos la grafica y las eje-cuciones medias.

def OnSelect

El metodo OnSelect es llamado al activar el evento de seleccion de unresultado medio de la lista de resultados medios con el objetivo de imprimiren la lista de resultados individuales dichos resultados y dibujar la grafica.

Atributos publicos

hboxisDrawndictionaryOfResultsrowslist1clientlist2sizer2


La clase ResultsPanel (p. 144) se ocupa de manejar las pestanas quese cargan en la clase Resultados.


Parametros:

wx.Panel Herada de la clase wx.Panel



B.6.2.1. def resultados::ResultsPanel:: init ( self, parent)

Constructor de la Clase ResultsPanel (p. 144).

Parametros:




174 :

175


177

178 self.hbox = wx.BoxSizer(wx.VERTICAL)

179 self.isDrawn = False

180

## Este metodo nos construye los resultados que figuraran en la pesta~na

B.6.2.2. def resultados::ResultsPanel::DecideStructure ( self,rows, dictionaryOfResults)

Este metodo nos construye los resultados que figuraran en la pestana decada resultado, la construccion dependera del numero de filas que tenga, esdecir, si la ejecucion se realizo una sola vez, solo tendra que ofrecer resultadosindividuales, en caso contrario mostramos la grafica y las ejecuciones medias.

Parametros:


rows Numero de columnas del panel.

dictionaryOfResults Diccionario de Resultados, desde el que se re-llenara el panel.



189 :

190

191 # Recibimos tanto las filas, es decir, numero de ejecuciones,

como el

192 # diccionario de resultados

193 self.dictionaryOfResults = dictionaryOfResults

194 self.rows = rows

195

196 # En este caso existe solo una ejecucion, por lo que solo debemos

reflejar

197 # los resultados individuales

198

199 if rows == 1:

200

201 # Resultados Individuales

202 self.list1 = wx.ListCtrl(self, -1 ,style=wx.LC_REPORT|wx.LC_SINGLE_SEL)

203 self.list1.InsertColumn(0, ’Contador’, width=140)

204 self.list1.InsertColumn(1, ’Resultado’, width=140)

205 self.list1.InsertColumn(2, ’Tiempo’)

206 self.list1.InsertColumn(3, ’T_Sys’)

207

208 # Encajamos la pesta~na

209

210 self.hbox.Add(self.list1, 1, wx.EXPAND)

211 self.SetSizer(self.hbox)

212

213 # En caso de que exista mas de una fila fabricaremos la lista de

214 # resultados medios, list1, y la de resultados individuales

215

216 else:

217

218 # Grafica con las ejecuciones individulaes

219

220 self.client = plot.PlotCanvas(self)

221

222 # Resultados medios

223


225


227 self.list1.InsertColumn(1, ’Resultado Medio’, width=140)

228 self.list1.InsertColumn(2, ’Desviacion’,width=140)

229 self.list1.InsertColumn(3, ’Tiempo’)

230 self.list1.InsertColumn(4, ’T_Sys’)

231

232 # Resultados individuales

233


235

236 self.list2.InsertColumn(0, ’N’, width=40)



238 self.list2.InsertColumn(2, ’Resultado’, width=140)

239

240 #Encajamos la pesta~na

241

242 self.sizer2 = wx.BoxSizer(wx.HORIZONTAL)

243

244 self.hbox.Add(self.list1, 1, wx.EXPAND)

245 self.hbox.Add(self.sizer2, 1, wx.EXPAND)

246

247 self.sizer2.Add(self.list2,1,wx.EXPAND)

248 self.sizer2.Add(self.client,1,wx.EXPAND)

249

250 self.SetSizer(self.hbox)

251 self.Bind(wx.EVT_LIST_ITEM_SELECTED, self.OnSelect)

252

253

## El metodo OnSelect es llamado al activar el evento de seleccion de

un resultado medio de la lista de resultados medios con el objetivo de

imprimir en la lista de resultados individuales dichos resultados y dibujar

la grafica.

B.6.2.3. def resultados::ResultsPanel::OnSelect ( self, event)

El metodo OnSelect es llamado al activar el evento de seleccion de unresultado medio de la lista de resultados medios con el objetivo de imprimiren la lista de resultados individuales dichos resultados y dibujar la grafica.

Parametros:




257 :

258

259

260 # Recoger el nombre del primer evento seleccionado

261 ev = self.list1.GetItemText(self.list1.GetFirstSelected())

262

263 # Cogemos el resultado del evento

264 tup = self.dictionaryOfResults[self.list1.GetItemText(self.list1.

GetFirstSelected())]

265

266 data1 = [] #linea de resultados

267 data2 = [] #linea de la media

268

269 #Definimos un numero maximo a cero y un numero minimo a infinito


270 maxm = 0

271 minm = 100000000000000000000000000000000000000

272

273 #Implementacion de los elementos de la lista

274 self.list2.DeleteAllItems()

275

276 # Recorremos los resultados que hay, dados por el primer dato de

la tupla

277 for i in range(tup[0]):

278 value = int(tup[1][i]) #Valor del resultado i

279 reverseIndex = tup[0] - int(i) - 1

280

281 #Construimos las listas de datos para imprimir

282 data1.append((int(i)+1, value))

283 data2.append((int(i)+1, tup[2]))

284

285 # Modificando los valores maximos o minimos del resultado

286 if maxm < value:

287 maxm = value

288 if minm > value:

289 minm = value

290

291 #Insertamos los resultados individuales en la lista grafica de

292 # resultados

293 index = self.list2.InsertStringItem(0,str(reverseIndex+1))

294 self.list2.SetStringItem(index,1,ev)

295 self.list2.SetStringItem(index,2,tup[1][reverseIndex])

296

297

298 # Damos un margen de 200 por abajo si no es negativo (abajo lo haremos

299 # para el margen de arriba)

300

301 minm = minm -200

302 if minm-200 < 0:

303 minm = 0

304

305 #Dibujamos

306 line1 = plot.PolyLine(data1, legend=’Resultados’, colour=’pink’,width=3)

307 line2 = plot.PolyLine(data2, legend=’Media’, colour=’grey’, width=2)

308 gc = plot.PlotGraphics([line1,line2],"Ejecucion de " + ev, ’Numero de

Ejecucion’,

309 ’Resultado’)

310 self.client.Draw(gc, xAxis= (1,tup[0]), yAxis= (minm,maxm+200))

311 self.isDrawn = True

312

313


resultados.py


B.7. Referencia de la Clase io::IOInterface

Esta clase sirve como una interfaz de glperfex a lperfex, de manera queel resto de clases puedan despreocuparse de los aspectos mas complicadoscomo leer ficheros, escribir en ellos o comunicarse con la entrada y salida delperfex.

Metodos publicos

def init

Constructor de la Clase IOInterface ( p. 149).

def GetDictionary

Este metodo devuelve el diccionario de Contadores de la maquina.

def AddItemToSelectionList

Este metodo anade un item a la lista de seleccion.

def RemoveItemFromSelectionList

Este metodo borra un item de la lista de seleccion.

def CleanSelectionList

Este metodo borra toda la lista de seleccion.

def GetSelectionList

Este metodo devuelve la lista de seleccion.

def GetResults

Este metodo devuelve los resultados obtenidos al ejecutar un comando delperfex, es quiza el metodo mas importante de glperfex, ya que es juntoal metodo que obtiene la lista de eventos el que ofrece la interaccion conlperfex.

def DividePath

Este metodo obtiene el directorio y lo une al nombre del fichero tras com-probar que se aloja en un directorio valido en la variable PATH del siste-ma.

def CheckExecutableFile

Este metodo comprueba si el fichero introducido se trata de un ficheroejecutable valido a traves de la salida del comando file, es decir, si setrata de un fichero ELF de 32 bits lincado dinamicamente.

150 B.7. Referencia de la Clase io::IOInterface

def ReadCSV

Este metodo lee un fichero .csv dado por paramametros tal y como esta-blecimos en la definicion del manual tecnico y devuelve un diccionario deresultados tal y como si se hubiera realizado una medicion normal.

def WriteCSV

Este metodo escribe un fichero .csv dado por paramametros tal y comoestablecimos en la definicion del manual tecnico.

def SaveDraw

Este metodo guarda un fichero utilizando el metodo SaveFile del objetocliente.

Atributos publicos

selectionListdictofCounterscommand


Esta clase sirve como una interfaz de glperfex a lperfex, de manera queel resto de clases puedan despreocuparse de los aspectos mas complicadoscomo leer ficheros, escribir en ellos o comunicarse con la entrada y salida delperfex.

Definicion en la lınea 21 del archivo io.py.


B.7.2.1. def io::IOInterface:: init ( self)

Constructor de la Clase IOInterface (p. 149).

Parametros:




25 :

26

27 #Inicializamos la lista de sleccion

28 self.selectionList = []

29

30 # Inicialixamos el diccionario de contadores y obtenemos los

contadores de la

31 # maquina con el comando lperfex -l

32 self.dictofCounters = {}

33 command = ’lperfex -l’

34 pipe = os.popen(command)

35 standardOutput = pipe.readlines()

36 pipe.close()

37

38 # Es necesario eliminar ademas de datos no relacionados con

contadores

39 # dos contadores que no funcionan bien

40 for line in standardOutput:

41 if "PAPI_" in line and not "PAPI_L1_ICH" in line and not

"PAPI_L2_LDM" in line:

42 auxList = line.split(’\t’)

43 self.dictofCounters[auxList[0]] = auxList[1][:-1]

44

45 #Command

46 self.command = ""

47

## Este metodo devuelve el diccionario de Contadores de la maquina

B.7.2.2. def io::IOInterface::GetDictionary ( self)

Este metodo devuelve el diccionario de Contadores de la maquina.

Parametros:


Devuelve:

self.dictionaryofCounters El diccionario de contadores de la maquina.


51 :

52 return self.dictofCounters

53

## Este metodo a~nade un item a la lista de seleccion.


B.7.2.3. def io::IOInterface::AddItemToSelectionList ( self,item)

Este metodo anade un item a la lista de seleccion.

Parametros:


item Elemento a anadir.


57 :

58 self.selectionList.append(item)

59

## Este metodo borra un item de la lista de seleccion.

B.7.2.4. def io::IOInterface::RemoveItemFromSelectionList (self, item)

Este metodo borra un item de la lista de seleccion.

Parametros:


item Elemento a borrar.


63 :

64 self.selectionList.remove(item)

65

## Este metodo borra toda la lista de seleccion.

B.7.2.5. def io::IOInterface::CleanSelectionList ( self)

Este metodo borra toda la lista de seleccion.

Parametros:




68 :

69 self.selectionList = []

70

## Este metodo devuelve la lista de seleccion.

B.7.2.6. def io::IOInterface::GetSelectionList ( self)

Este metodo devuelve la lista de seleccion.

Parametros:


Devuelve:

self.selectionList Devuelve la lista de seleccion.


74 :

75 return self.selectionList

76

## Este metodo devuelve los resultados obtenidos al ejecutar un

comando de lperfex, es quiza el

B.7.2.7. def io::IOInterface::GetResults ( self, command)

Este metodo devuelve los resultados obtenidos al ejecutar un comandode lperfex, es quiza el metodo mas importante de glperfex, ya que es juntoal metodo que obtiene la lista de eventos el que ofrece la interaccion conlperfex.

Dependiendo de si es un path absoluto, o tiene otro tipo de dato setratara de una manera u otra. Una vez se ha desplazado al directorio seejecuta el comando usando a su vez time para obtener el tiempo que tardo enrealizar la ejecucion. En el momento de ejecutarse se obtiene la salida por lastdout y la stderr y se obtiene la informacion deseada. Una vez recopiladase devuelven los datos.

Parametros:



command Comando a ejecutar.

Devuelve:

(len(resultsList),resultsList, media, desviacion,treal,tsys) Es una tuplacon la lista de resultados de la ejecucion, mas los resultados que sehicieron, la media, desviacion, tiempo real y de sistema.


88 :

89 resultsList = []

90 dictofCounters = {}

91

92 commandos = command[1]

93

94 #OPCION CON PATH ABSOLUTO

95

96 if ’/’ in commandos:

97 n = len(commandos) - 1

98

99 while commandos[n-1] != ’/’:

100 n -= 1

101 directory = commandos[0:n]

102 filename = commandos[n:len(commandos)]

103 ok = True

104

105 #OPCION CON OTRO TIPO DE PATH

106 else:

107 tupl = self.DividePath(commandos)

108 ok = tupl[2]

109 directory = tupl[0]

110 filename = tupl[1]

111

112 print directory + filename

113

114

115 if ok == False:

116 return

117

118 realcommand = "cd " + directory + " && " +

"/usr/bin/time --format=\"real\t%es\nsys\t%Ss\" " +

119 command[0] + " ./" + filename + " 2>&1"

120

121

122 pipe = os.popen(realcommand)


124 pipe.close()

125 media = 0

126 desviacion = 0

127 treal = 0


128 tsys = 0

129


131 auxList = line.split(’\t’)

132 print auxList

133

134 if("PAPI_" in line and "Evento" not in line):

135 resultsList.append(auxList[2][:-1])

136

137 elif("PAPI_" and "Evento" and "Media" in line):

138 media = auxList[2][:-1]

139 elif("PAPI_" and "Evento" and "Desvia" in line):

140 desviacion = auxList[2][:-1]

141 elif("sys" in line):

142 tsys = auxList[1][:-1]

143 elif("real" in line):

144 treal = auxList[1][:-1]

145

146 return len(resultsList),resultsList, media, desviacion,treal,tsys

147

148

## Este metodo obtiene el directorio y lo une al nombre del fichero

B.7.2.8. def io::IOInterface::DividePath ( self, command)

Este metodo obtiene el directorio y lo une al nombre del fichero trascomprobar que se aloja en un directorio valido en la variable PATH delsistema.

Parametros:


command Comando que se recogio sin formato absoluto.

Devuelve:

directory+’/’,filename,ok Devuelve una tupla con la ruta obtenida in-dicando si fue obtenida correctamente.


156 :

157 ok = False

158 pipe = os.popen("echo $PATH")

159 standardOutput = pipe.read()

160 pipe.close()

161 path = standardOutput[0:-1].split(’:’)

162 filename = command


163 pipe = os.popen("whereis -b " + command)

164 standardOutput = pipe.read()

165 pipe.close()

166

167 list = standardOutput[0:-1].split(’ ’)

168 print list

169 for elemento in list[1:]:

170 n = len(elemento)-1

171 if ’/’ in elemento : #Hay que curarse en salud ante

bucles infinitos

172 while elemento[n] != ’/’:

173 n -= 1

174 if elemento[0:n] in path:

175 directory = elemento[0:n]

176 ok = True

177

178 return directory + ’/’,filename,ok

179

## Este metodo comprueba si el fichero introducido se trata de un fichero

ejecutable valido

B.7.2.9. def io::IOInterface::CheckExecutableFile ( self,filePath)

Este metodo comprueba si el fichero introducido se trata de un ficheroejecutable valido a traves de la salida del comando file, es decir, si se tratade un fichero ELF de 32 bits lincado dinamicamente.

Parametros:


filePath Path del fichero a comprobar.

Devuelve:

True En caso de que sea un fichero valido.False En caso en que no sea un fichero valido.


187 :

188 command = "file " + filePath

189 print command

190 pipe = os.popen(command)


192 pipe.close

193



195 if "ELF 32-bit LSB executable" and "dynamically linked" in line:

196 return True

197

198 return False

199

## Este metodo lee un fichero .csv dado por paramametros tal y como establecimos

en la

B.7.2.10. def io::IOInterface::ReadCSV ( self, filename)

Este metodo lee un fichero .csv dado por paramametros tal y como es-tablecimos en la definicion del manual tecnico y devuelve un diccionario deresultados tal y como si se hubiera realizado una medicion normal.

Parametros:


filename Nombre del fichero a leer.

Devuelve:

dictofResults Diccionario con los datos del fichero.


206 :

208 pf = open(filename,’r’)

209

210 i = 0

211 option = 1

212 n = 4

213

214 dictofResults = {}

215

216

217 for line in pf.readlines():

218 aux = line.split(’,’)

219

220 # Con estas comprobaciones averiguamos si es un fichero

221 # con varias ejecuciones o con una sola

222

223 # Con mas de una ejecucion

224 if i == 0 and len(aux) == 6:

225 option = 1

226

227 # Con una sola ejecucion

228 elif i == 0 and len(aux) == 4:


229 option = 0

230

231 # Ahora actuamos conforme a lo averiguado y construimos

las listas

232 # que vamos a devolver

233

234 # Con una sola ejecucion

235 elif option == 0 :

236 if "PAPI_" in aux[0]:

237 dictofResults[aux[0]] = (1,[aux[1]],0,0,str(aux[2]),

str(aux[3][:-1]))

238

239 # Con mas de una ejecucion

240 elif option == 1 :

241 if "PAPI_" in aux[0]:

242 dictofResults[aux[0]] = (int(aux[5]),[],float(aux[1]),

float(aux[2]),

243 str(aux[3]),str(aux[4]))

244 n = aux[0]

245

246 elif len(aux) == 2 and "N. Ej" not in aux[0] :

247 dictofResults[n][1].append(aux[1][:-1])

248

249 i = i + 1

250

251 pf.close()

252

253 return dictofResults

254

## Este metodo escribe un fichero .csv dado por paramametros tal y como

establecimos en la

B.7.2.11. def io::IOInterface::WriteCSV ( self, dictOfResults,filename)

Este metodo escribe un fichero .csv dado por paramametros tal y comoestablecimos en la definicion del manual tecnico.

Parametros:

self Puntero al objeto actual.dictOfResults Diccionario con los resultados que se desean escribir en

el fichero.filename Nombre del fichero a escribir.

Necesitamos comprobar todavıa si se abre el fichero.

Funcion para rescatar en una lista los resultados de una ejecucion

guardados en fichero



260 :

261 """Necesitamos comprobar todavıa si se abre el fichero.

262 Funcion para rescatar en una lista los resultados de una ejecucion

guardados en fichero"""

263

264 pf = open(filename,’w’)

265

266 for key in dictOfResults:

267 nex = dictOfResults[key][0]

268

269

270 # En este caso escribimos los datos de ejecuciones individuales

simplemente

271 if nex == 1:

272 line1 = "Contador,Resultado,Tiempo,Tiempo Sys\n\n"

273 pf.write(line1)

274


276 line2 = key + "," + str(dictOfResults[key][1][0])

+ "," + str(dictOfResults[key][4])

277 + "," + str(dictOfResults[key][5]) + "\n"

278 pf.write(line2)

279

280 pf.close()

281

282

283 # En eseta caso escribimos los datos de varias ejecuciones

284 else:

285

286 line1 = "Contador,Resultado medio,Desviacion,Tiempo,Tiempo Sys,

N. Ejecuciones\n\n"

287 pf.write(line1)

288

289


291 desv = str(dictOfResults[key][3]).replace(’,’,’.’)

292 med = str(dictOfResults[key][2]).replace(’,’,’.’)

293 # Resumen medio de las Ejecuciones

294 line2 = key + "," + str(med) + "," + str(desv) + "," +

str(dictOfResults[key][4])

295 + "," + str(dictOfResults[key][5]) + "," + str(nex) + "\n"

296 pf.write(line2)

297

298

299 # Empezamos a escribir las ejecuciones individuales

300 line3 = "N. Ejecucion,Resultado\n"

301 pf.write(line3)

302

303 j = 0

304

305 for i in dictOfResults[key][1]:

306 line4 = str(j+1) + "," + str(dictOfResults[key][1][j])

+ "\n"

307 pf.write(line4)


308 j = j + 1

309

310 line5 = "\n"

311 pf.write(line5)

312

313 pf.close()

## Este metodo guarda un fichero utilizando el metodo SaveFile del objeto

cliente.

B.7.2.12. def io::IOInterface::SaveDraw ( self, client, filename)

Este metodo guarda un fichero utilizando el metodo SaveFile del objetocliente.

Parametros:


client Objeto cliente.

filename Nombre del fichero a escribir.


318 :

319 client.SaveFile(filename)

320

321


io.py

Apendice C

Licencias

Copyleft o copia permitida (=left(de leave) =granted) comprende a ungrupo de derechos de autor caracterizados por eliminar las restricciones dedistribucion o modificacion de las que adolece el copyright, con la condicionde que el trabajo derivado se mantenga con el mismo regimen de derechosde autor que el original.

Bajo tales licencias pueden protegerse una gran diversidad de obras, talescomo programas informaticos, arte, cultura y ciencia, es decir practicamentecasi cualquier tipo de produccion creativa.

Sus partidarios la proponen como alternativa a las restricciones que im-ponen las normas planteadas en los derechos de autor, a la hora de hacer,modificar y distribuir copias de una obra determinada. Se pretende garan-tizar ası una mayor libertad para que cada receptor de una copia, o unaversion derivada de un trabajo, pueda, a su vez, usar, modificar y redistri-buir tanto el propio trabajo como las versiones derivadas del mismo. Ası,y en un entorno no legal, puede considerarse como opuesto al copyright oderechos de autor tradicionales.

El presente Proyecto contempla dos realidades del desarrollo de un pro-ducto software. Por un lado, contempla una aplicacion englobada en un siste-ma software, y por el otro la documentacion de todo el proceso de desarrolloy puesta en marcha del mismo. Esto genera contenido tanto informatico co-mo documental, lo que obliga a enfocar la forma de licenciar el proyecto dedos maneras diferentes. Pretendemos no obstante, que las licencias escogidassigan la filosofıa Copyleft que hemos definido con anterioridad.

Por ello, las licencias escogidas para cada ambito han sido, la GNU Ge-neral Public License en su version 3.0, para el programa informatico y laGNU Free Documentation License en su version 1.2, para la documentacion

161

162

del proyecto.

A continuacion se incluye el texto completo de las mismas, en ingles. Estoes debido a que las traducciones al castellano realizadas, no son reconocidasoficialmente por la Free Software Fundation.

Licencias 163

C.1. GNU General Public License

Version 3, 29 June 2007

Copyright c© 2007 Free Software Foundation, Inc. http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies of this

license document, but changing it is not allowed.

The GNU General Public License is a free, copyleft license for softwareand other kinds of works.

The licenses for most software and other practical works are designedto take away your freedom to share and change the works. By contrast, theGNU General Public License is intended to guarantee your freedom to shareand change all versions of a program–to make sure it remains free softwarefor all its users. We, the Free Software Foundation, use the GNU GeneralPublic License for most of our software; it applies also to any other workreleased this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price.Our General Public Licenses are designed to make sure that you have thefreedom to distribute copies of free software (and charge for them if youwish), that you receive source code or can get it if you want it, that you canchange the software or use pieces of it in new free programs, and that youknow you can do these things.

To protect your rights, we need to prevent others from denying you theserights or asking you to surrender the rights. Therefore, you have certainresponsibilities if you distribute copies of the software, or if you modify it:responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratisor for a fee, you must pass on to the recipients the same freedoms that youreceived. You must make sure that they, too, receive or can get the sourcecode. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps:(1) assert copyright on the software, and (2) offer you this License givingyou legal permission to copy, distribute and/or modify it.

For the developers’ and authors’ protection, the GPL clearly explainsthat there is no warranty for this free software. For both users’ and authors’sake, the GPL requires that modified versions be marked as changed, so

164 C.1. GNU General Public License

that their problems will not be attributed erroneously to authors of previousversions.

Some devices are designed to deny users access to install or run modifiedversions of the software inside them, although the manufacturer can do so.This is fundamentally incompatible with the aim of protecting users’ freedomto change the software. The systematic pattern of such abuse occurs inthe area of products for individuals to use, which is precisely where it ismost unacceptable. Therefore, we have designed this version of the GPL toprohibit the practice for those products. If such problems arise substantiallyin other domains, we stand ready to extend this provision to those domainsin future versions of the GPL, as needed to protect the freedom of users.

Finally, every program is threatened constantly by software patents. Sta-tes should not allow patents to restrict development and use of software ongeneral-purpose computers, but in those that do, we wish to avoid the spe-cial danger that patents applied to a free program could make it effectivelyproprietary. To prevent this, the GPL assures that patents cannot be usedto render the program non-free.

The precise terms and conditions for copying, distribution and modifi-cation follow.

Terms and Conditions

0. Definitions.

“This License” refers to version 3 of the GNU General Public License.

“Copyright” also means copyright-like laws that apply to other kindsof works, such as semiconductor masks.

“The Program” refers to any copyrightable work licensed under thisLicense. Each licensee is addressed as “you”. “Licensees” and “reci-pients” may be individuals or organizations.

To “modify” a work means to copy from or adapt all or part of the workin a fashion requiring copyright permission, other than the making ofan exact copy. The resulting work is called a “modified version” of theearlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a workbased on the Program.

To “propagate” a work means to do anything with it that, without per-mission, would make you directly or secondarily liable for infringementunder applicable copyright law, except executing it on a computer ormodifying a private copy. Propagation includes copying, distribution

Licencias 165

(with or without modification), making available to the public, and insome countries other activities as well.

To “convey” a work means any kind of propagation that enables otherparties to make or receive copies. Mere interaction with a user througha computer network, with no transfer of a copy, is not conveying.

An interactive user interface displays “Appropriate Legal Notices” tothe extent that it includes a convenient and prominently visible featurethat (1) displays an appropriate copyright notice, and (2) tells the userthat there is no warranty for the work (except to the extent that wa-rranties are provided), that licensees may convey the work under thisLicense, and how to view a copy of this License. If the interface pre-sents a list of user commands or options, such as a menu, a prominentitem in the list meets this criterion.

1. Source Code.

The “source code” for a work means the preferred form of the workfor making modifications to it. “Object code” means any non-sourceform of a work.

A “Standard Interface” means an interface that either is an officialstandard defined by a recognized standards body, or, in the case ofinterfaces specified for a particular programming language, one that iswidely used among developers working in that language.

The “System Libraries” of an executable work include anything, otherthan the work as a whole, that (a) is included in the normal form ofpackaging a Major Component, but which is not part of that MajorComponent, and (b) serves only to enable use of the work with thatMajor Component, or to implement a Standard Interface for which animplementation is available to the public in source code form. A “Ma-jor Component”, in this context, means a major essential component(kernel, window system, and so on) of the specific operating system (ifany) on which the executable work runs, or a compiler used to producethe work, or an object code interpreter used to run it.

The “Corresponding Source” for a work in object code form meansall the source code needed to generate, install, and (for an executablework) run the object code and to modify the work, including scripts tocontrol those activities. However, it does not include the work’s SystemLibraries, or general-purpose tools or generally available free programswhich are used unmodified in performing those activities but which arenot part of the work. For example, Corresponding Source includes in-terface definition files associated with source files for the work, and thesource code for shared libraries and dynamically linked subprogramsthat the work is specifically designed to require, such as by intimate


data communication or control flow between those subprograms andother parts of the work.

The Corresponding Source need not include anything that users canregenerate automatically from other parts of the Corresponding Sour-ce.

The Corresponding Source for a work in source code form is that samework.

2. Basic Permissions.

All rights granted under this License are granted for the term of copy-right on the Program, and are irrevocable provided the stated condi-tions are met. This License explicitly affirms your unlimited permissionto run the unmodified Program. The output from running a coveredwork is covered by this License only if the output, given its content,constitutes a covered work. This License acknowledges your rights offair use or other equivalent, as provided by copyright law.

You may make, run and propagate covered works that you do notconvey, without conditions so long as your license otherwise remainsin force. You may convey covered works to others for the sole purposeof having them make modifications exclusively for you, or provide youwith facilities for running those works, provided that you comply withthe terms of this License in conveying all material for which you do notcontrol copyright. Those thus making or running the covered works foryou must do so exclusively on your behalf, under your direction andcontrol, on terms that prohibit them from making any copies of yourcopyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely underthe conditions stated below. Sublicensing is not allowed; section 10makes it unnecessary.

3. Protecting Users’ Legal Rights From Anti-Circumvention Law.

No covered work shall be deemed part of an effective technologicalmeasure under any applicable law fulfilling obligations under article11 of the WIPO copyright treaty adopted on 20 December 1996, orsimilar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbidcircumvention of technological measures to the extent such circum-vention is effected by exercising rights under this License with respectto the covered work, and you disclaim any intention to limit opera-tion or modification of the work as a means of enforcing, against thework’s users, your or third parties’ legal rights to forbid circumventionof technological measures.

Licencias 167

4. Conveying Verbatim Copies.

You may convey verbatim copies of the Program’s source code as youreceive it, in any medium, provided that you conspicuously and appro-priately publish on each copy an appropriate copyright notice; keep in-tact all notices stating that this License and any non-permissive termsadded in accord with section 7 apply to the code; keep intact all no-tices of the absence of any warranty; and give all recipients a copy ofthis License along with the Program.

You may charge any price or no price for each copy that you convey,and you may offer support or warranty protection for a fee.

5. Conveying Modified Source Versions.

You may convey a work based on the Program, or the modificationsto produce it from the Program, in the form of source code under theterms of section 4, provided that you also meet all of these conditions:

a) The work must carry prominent notices stating that you modifiedit, and giving a relevant date.

b) The work must carry prominent notices stating that it is releasedunder this License and any conditions added under section 7. Thisrequirement modifies the requirement in section 4 to “keep intactall notices”.

c) You must license the entire work, as a whole, under this Licenseto anyone who comes into possession of a copy. This License willtherefore apply, along with any applicable section 7 additionalterms, to the whole of the work, and all its parts, regardless of howthey are packaged. This License gives no permission to license thework in any other way, but it does not invalidate such permissionif you have separately received it.

d) If the work has interactive user interfaces, each must display Ap-propriate Legal Notices; however, if the Program has interactiveinterfaces that do not display Appropriate Legal Notices, yourwork need not make them do so.

A compilation of a covered work with other separate and independentworks, which are not by their nature extensions of the covered work,and which are not combined with it such as to form a larger program,in or on a volume of a storage or distribution medium, is called an“aggregate” if the compilation and its resulting copyright are not usedto limit the access or legal rights of the compilation’s users beyondwhat the individual works permit. Inclusion of a covered work in anaggregate does not cause this License to apply to the other parts ofthe aggregate.


6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms ofsections 4 and 5, provided that you also convey the machine-readableCorresponding Source under the terms of this License, in one of theseways:

a) Convey the object code in, or embodied in, a physical product(including a physical distribution medium), accompanied by theCorresponding Source fixed on a durable physical medium custo-marily used for software interchange.

b) Convey the object code in, or embodied in, a physical product(including a physical distribution medium), accompanied by awritten offer, valid for at least three years and valid for as long asyou offer spare parts or customer support for that product model,to give anyone who possesses the object code either (1) a copyof the Corresponding Source for all the software in the productthat is covered by this License, on a durable physical mediumcustomarily used for software interchange, for a price no morethan your reasonable cost of physically performing this conveyingof source, or (2) access to copy the Corresponding Source from anetwork server at no charge.

c) Convey individual copies of the object code with a copy of thewritten offer to provide the Corresponding Source. This alterna-tive is allowed only occasionally and noncommercially, and onlyif you received the object code with such an offer, in accord withsubsection 6b.

d) Convey the object code by offering access from a designated pla-ce (gratis or for a charge), and offer equivalent access to the Co-rresponding Source in the same way through the same place atno further charge. You need not require recipients to copy theCorresponding Source along with the object code. If the placeto copy the object code is a network server, the CorrespondingSource may be on a different server (operated by you or a thirdparty) that supports equivalent copying facilities, provided youmaintain clear directions next to the object code saying where tofind the Corresponding Source. Regardless of what server hoststhe Corresponding Source, you remain obligated to ensure thatit is available for as long as needed to satisfy these requirements.

e) Convey the object code using peer-to-peer transmission, providedyou inform other peers where the object code and CorrespondingSource of the work are being offered to the general public at nocharge under subsection 6d.

Licencias 169

A separable portion of the object code, whose source code is exclu-ded from the Corresponding Source as a System Library, need not beincluded in conveying the object code work.

A “User Product” is either (1) a “consumer product”, which meansany tangible personal property which is normally used for personal,family, or household purposes, or (2) anything designed or sold forincorporation into a dwelling. In determining whether a product is aconsumer product, doubtful cases shall be resolved in favor of coverage.For a particular product received by a particular user, “normally used”refers to a typical or common use of that class of product, regardless ofthe status of the particular user or of the way in which the particularuser actually uses, or expects or is expected to use, the product. Aproduct is a consumer product regardless of whether the product hassubstantial commercial, industrial or non-consumer uses, unless suchuses represent the only significant mode of use of the product.

“Installation Information” for a User Product means any methods,procedures, authorization keys, or other information required to installand execute modified versions of a covered work in that User Productfrom a modified version of its Corresponding Source. The informationmust suffice to ensure that the continued functioning of the modifiedobject code is in no case prevented or interfered with solely becausemodification has been made.

If you convey an object code work under this section in, or with, orspecifically for use in, a User Product, and the conveying occurs aspart of a transaction in which the right of possession and use of theUser Product is transferred to the recipient in perpetuity or for a fixedterm (regardless of how the transaction is characterized), the Corres-ponding Source conveyed under this section must be accompanied bythe Installation Information. But this requirement does not apply ifneither you nor any third party retains the ability to install modi-fied object code on the User Product (for example, the work has beeninstalled in ROM).

The requirement to provide Installation Information does not includea requirement to continue to provide support service, warranty, or up-dates for a work that has been modified or installed by the recipient,or for the User Product in which it has been modified or installed.Access to a network may be denied when the modification itself ma-terially and adversely affects the operation of the network or violatesthe rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provi-ded, in accord with this section must be in a format that is publiclydocumented (and with an implementation available to the public in


source code form), and must require no special password or key forunpacking, reading or copying.

7. Additional Terms.

“Additional permissions” are terms that supplement the terms of thisLicense by making exceptions from one or more of its conditions. Ad-ditional permissions that are applicable to the entire Program shallbe treated as though they were included in this License, to the extentthat they are valid under applicable law. If additional permissions ap-ply only to part of the Program, that part may be used separatelyunder those permissions, but the entire Program remains governed bythis License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your optionremove any additional permissions from that copy, or from any partof it. (Additional permissions may be written to require their ownremoval in certain cases when you modify the work.) You may placeadditional permissions on material, added by you to a covered work,for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material youadd to a covered work, you may (if authorized by the copyright holdersof that material) supplement the terms of this License with terms:

a) Disclaiming warranty or limiting liability differently from theterms of sections 15 and 16 of this License; or

b) Requiring preservation of specified reasonable legal notices or aut-hor attributions in that material or in the Appropriate Legal No-tices displayed by works containing it; or

c) Prohibiting misrepresentation of the origin of that material, orrequiring that modified versions of such material be marked inreasonable ways as different from the original version; or

d) Limiting the use for publicity purposes of names of licensors orauthors of the material; or

e) Declining to grant rights under trademark law for use of sometrade names, trademarks, or service marks; or

f ) Requiring indemnification of licensors and authors of that mate-rial by anyone who conveys the material (or modified versions ofit) with contractual assumptions of liability to the recipient, forany liability that these contractual assumptions directly imposeon those licensors and authors.

All other non-permissive additional terms are considered “further res-trictions” within the meaning of section 10. If the Program as you

Licencias 171

received it, or any part of it, contains a notice stating that it is gover-ned by this License along with a term that is a further restriction, youmay remove that term. If a license document contains a further restric-tion but permits relicensing or conveying under this License, you mayadd to a covered work material governed by the terms of that licensedocument, provided that the further restriction does not survive suchrelicensing or conveying.

If you add terms to a covered work in accord with this section, youmust place, in the relevant source files, a statement of the additionalterms that apply to those files, or a notice indicating where to find theapplicable terms.

Additional terms, permissive or non-permissive, may be stated in theform of a separately written license, or stated as exceptions; the aboverequirements apply either way.

8. Termination.

You may not propagate or modify a covered work except as expresslyprovided under this License. Any attempt otherwise to propagate ormodify it is void, and will automatically terminate your rights underthis License (including any patent licenses granted under the thirdparagraph of section 11).

However, if you cease all violation of this License, then your licensefrom a particular copyright holder is reinstated (a) provisionally, unlessand until the copyright holder explicitly and finally terminates yourlicense, and (b) permanently, if the copyright holder fails to notify youof the violation by some reasonable means prior to 60 days after thecessation.

Moreover, your license from a particular copyright holder is reinstatedpermanently if the copyright holder notifies you of the violation bysome reasonable means, this is the first time you have received noticeof violation of this License (for any work) from that copyright holder,and you cure the violation prior to 30 days after your receipt of thenotice.

Termination of your rights under this section does not terminate thelicenses of parties who have received copies or rights from you underthis License. If your rights have been terminated and not permanentlyreinstated, you do not qualify to receive new licenses for the samematerial under section 10.

9. Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive orrun a copy of the Program. Ancillary propagation of a covered work


occurring solely as a consequence of using peer-to-peer transmission toreceive a copy likewise does not require acceptance. However, nothingother than this License grants you permission to propagate or modifyany covered work. These actions infringe copyright if you do not acceptthis License. Therefore, by modifying or propagating a covered work,you indicate your acceptance of this License to do so.

10. Automatic Licensing of Downstream Recipients.

Each time you convey a covered work, the recipient automatically re-ceives a license from the original licensors, to run, modify and propa-gate that work, subject to this License. You are not responsible forenforcing compliance by third parties with this License.

An “entity transaction” is a transaction transferring control of an or-ganization, or substantially all assets of one, or subdividing an orga-nization, or merging organizations. If propagation of a covered workresults from an entity transaction, each party to that transaction whoreceives a copy of the work also receives whatever licenses to the workthe party’s predecessor in interest had or could give under the previousparagraph, plus a right to possession of the Corresponding Source ofthe work from the predecessor in interest, if the predecessor has it orcan get it with reasonable efforts.

You may not impose any further restrictions on the exercise of therights granted or affirmed under this License. For example, you maynot impose a license fee, royalty, or other charge for exercise of rightsgranted under this License, and you may not initiate litigation (in-cluding a cross-claim or counterclaim in a lawsuit) alleging that anypatent claim is infringed by making, using, selling, offering for sale, orimporting the Program or any portion of it.

11. Patents.

A “contributor” is a copyright holder who authorizes use under thisLicense of the Program or a work on which the Program is based. Thework thus licensed is called the contributor’s “contributor version”.

A contributor’s “essential patent claims” are all patent claims ownedor controlled by the contributor, whether already acquired or hereafteracquired, that would be infringed by some manner, permitted by thisLicense, of making, using, or selling its contributor version, but do notinclude claims that would be infringed only as a consequence of furthermodification of the contributor version. For purposes of this definition,“control” includes the right to grant patent sublicenses in a mannerconsistent with the requirements of this License.

Each contributor grants you a non-exclusive, worldwide, royalty-freepatent license under the contributor’s essential patent claims, to make,

Licencias 173

use, sell, offer for sale, import and otherwise run, modify and propagatethe contents of its contributor version.

In the following three paragraphs, a “patent license” is any expressagreement or commitment, however denominated, not to enforce apatent (such as an express permission to practice a patent or covenantnot to sue for patent infringement). To “grant” such a patent licenseto a party means to make such an agreement or commitment not toenforce a patent against the party.

If you convey a covered work, knowingly relying on a patent license,and the Corresponding Source of the work is not available for anyoneto copy, free of charge and under the terms of this License, througha publicly available network server or other readily accessible means,then you must either (1) cause the Corresponding Source to be soavailable, or (2) arrange to deprive yourself of the benefit of the patentlicense for this particular work, or (3) arrange, in a manner consistentwith the requirements of this License, to extend the patent license todownstream recipients. “Knowingly relying” means you have actualknowledge that, but for the patent license, your conveying the coveredwork in a country, or your recipient’s use of the covered work in acountry, would infringe one or more identifiable patents in that countrythat you have reason to believe are valid.

If, pursuant to or in connection with a single transaction or arrange-ment, you convey, or propagate by procuring conveyance of, a coveredwork, and grant a patent license to some of the parties receiving thecovered work authorizing them to use, propagate, modify or convey aspecific copy of the covered work, then the patent license you grant isautomatically extended to all recipients of the covered work and worksbased on it.

A patent license is “discriminatory” if it does not include within thescope of its coverage, prohibits the exercise of, or is conditioned on thenon-exercise of one or more of the rights that are specifically grantedunder this License. You may not convey a covered work if you are aparty to an arrangement with a third party that is in the businessof distributing software, under which you make payment to the thirdparty based on the extent of your activity of conveying the work, andunder which the third party grants, to any of the parties who wouldreceive the covered work from you, a discriminatory patent license (a)in connection with copies of the covered work conveyed by you (orcopies made from those copies), or (b) primarily for and in connectionwith specific products or compilations that contain the covered work,unless you entered into that arrangement, or that patent license wasgranted, prior to 28 March 2007.


Nothing in this License shall be construed as excluding or limiting anyimplied license or other defenses to infringement that may otherwisebe available to you under applicable patent law.

12. No Surrender of Others’ Freedom.

If conditions are imposed on you (whether by court order, agreementor otherwise) that contradict the conditions of this License, they donot excuse you from the conditions of this License. If you cannot con-vey a covered work so as to satisfy simultaneously your obligationsunder this License and any other pertinent obligations, then as a con-sequence you may not convey it at all. For example, if you agree toterms that obligate you to collect a royalty for further conveying fromthose to whom you convey the Program, the only way you could satisfyboth those terms and this License would be to refrain entirely fromconveying the Program.

13. Use with the GNU Affero General Public License.

Notwithstanding any other provision of this License, you have permis-sion to link or combine any covered work with a work licensed underversion 3 of the GNU Affero General Public License into a single com-bined work, and to convey the resulting work. The terms of this Licensewill continue to apply to the part which is the covered work, but thespecial requirements of the GNU Affero General Public License, sec-tion 13, concerning interaction through a network will apply to thecombination as such.

14. Revised Versions of this License.

The Free Software Foundation may publish revised and/or new ver-sions of the GNU General Public License from time to time. Such newversions will be similar in spirit to the present version, but may differin detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Programspecifies that a certain numbered version of the GNU General PublicLicense “or any later version” applies to it, you have the option offollowing the terms and conditions either of that numbered versionor of any later version published by the Free Software Foundation. Ifthe Program does not specify a version number of the GNU GeneralPublic License, you may choose any version ever published by the FreeSoftware Foundation.

If the Program specifies that a proxy can decide which future versionsof the GNU General Public License can be used, that proxy’s publicstatement of acceptance of a version permanently authorizes you tochoose that version for the Program.

Licencias 175

Later license versions may give you additional or different permissions.However, no additional obligations are imposed on any author or copy-right holder as a result of your choosing to follow a later version.

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EX-TENT PERMITTED BY APPLICABLE LAW. EXCEPT WHENOTHERWISE STATED IN WRITING THE COPYRIGHT HOL-DERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM“AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EX-PRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,THE IMPLIED WARRANTIES OF MERCHANTABILITY ANDFITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISKAS TO THE QUALITY AND PERFORMANCE OF THE PRO-GRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DE-FECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SER-VICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW ORAGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER,OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYSTHE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOUFOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCI-DENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OFTHE USE OR INABILITY TO USE THE PROGRAM (INCLUDINGBUT NOT LIMITED TO LOSS OF DATA OR DATA BEING REN-DERED INACCURATE OR LOSSES SUSTAINED BY YOU ORTHIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPE-RATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOL-DER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSI-BILITY OF SUCH DAMAGES.

17. Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided abovecannot be given local legal effect according to their terms, reviewingcourts shall apply local law that most closely approximates an absolutewaiver of all civil liability in connection with the Program, unless awarranty or assumption of liability accompanies a copy of the Programin return for a fee.

End of Terms and Conditions

How to Apply These Terms to Your New Programs


If you develop a new program, and you want it to be of the greatestpossible use to the public, the best way to achieve this is to make itfree software which everyone can redistribute and change under theseterms.

To do so, attach the following notices to the program. It is safest toattach them to the start of each source file to most effectively sta-te the exclusion of warranty; and each file should have at least the“copyright” line and a pointer to where the full notice is found.

<one line to give the program’s name and a brief idea of what it does.>

Copyright (C) <textyear> <name of author>

This program is free software: you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation, either version 3 of the License, or

(at your option) any later version.

This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU General Public License for more details.

You should have received a copy of the GNU General Public License

along with this program. If not, see <http://www.gnu.org/licenses/>.

Also add information on how to contact you by electronic and papermail.

If the program does terminal interaction, make it output a short noticelike this when it starts in an interactive mode:

<program> Copyright (C) <year> <name of author>

This program comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’.

This is free software, and you are welcome to redistribute it

under certain conditions; type ‘show c’ for details.

The hypothetical commands show w and show c should show the ap-propriate parts of the General Public License. Of course, your pro-gram’s commands might be different; for a GUI interface, you woulduse an “about box”.

You should also get your employer (if you work as a programmer)or school, if any, to sign a “copyright disclaimer” for the program, ifnecessary. For more information on this, and how to apply and followthe GNU GPL, see http://www.gnu.org/licenses/.

The GNU General Public License does not permit incorporating yourprogram into proprietary programs. If your program is a subroutine

Licencias 177

library, you may consider it more useful to permit linking proprietaryapplications with the library. If this is what you want to do, use theGNU Lesser General Public License instead of this License. But first,please read http://www.gnu.org/philosophy/why-not-lgpl.html.

178 C.2. GNU Free Documentation License

C.2. GNU Free Documentation License

Version 1.2, November 2002

Copyright c© 2000,2001,2002 Free Software Foundation, Inc.

51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

Everyone is permitted to copy and distribute verbatim copies of thislicense document, but changing it is not allowed.

Preamble

The purpose of this License is to make a manual, textbook, or otherfunctional and useful document “free” in the sense of freedom: to assureeveryone the effective freedom to copy and redistribute it, with or withoutmodifying it, either commercially or noncommercially. Secondarily, this Li-cense preserves for the author and publisher a way to get credit for theirwork, while not being considered responsible for modifications made by ot-hers.

This License is a kind of “copyleft”, which means that derivative worksof the document must themselves be free in the same sense. It complementsthe GNU General Public License, which is a copyleft license designed forfree software.

We have designed this License in order to use it for manuals for freesoftware, because free software needs free documentation: a free programshould come with manuals providing the same freedoms that the softwaredoes. But this License is not limited to software manuals; it can be usedfor any textual work, regardless of subject matter or whether it is publishedas a printed book. We recommend this License principally for works whosepurpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, thatcontains a notice placed by the copyright holder saying it can be distributedunder the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditionsstated herein. The “Document”, below, refers to any such manual or work.

Licencias 179

Any member of the public is a licensee, and is addressed as “you”. You ac-cept the license if you copy, modify or distribute the work in a way requiringpermission under copyright law.

A “Modified Version” of the Document means any work containing theDocument or a portion of it, either copied verbatim, or with modificationsand/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter sectionof the Document that deals exclusively with the relationship of the publis-hers or authors of the Document to the Document’s overall subject (or torelated matters) and contains nothing that could fall directly within thatoverall subject. (Thus, if the Document is in part a textbook of mathematics,a Secondary Section may not explain any mathematics.) The relationshipcould be a matter of historical connection with the subject or with relatedmatters, or of legal, commercial, philosophical, ethical or political positionregarding them.

The “Invariant Sections” are certain Secondary Sections whose titlesare designated, as being those of Invariant Sections, in the notice that saysthat the Document is released under this License. If a section does not fitthe above definition of Secondary then it is not allowed to be designatedas Invariant. The Document may contain zero Invariant Sections. If theDocument does not identify any Invariant Sections then there are none.

The “Cover Texts” are certain short passages of text that are listed,as Front-Cover Texts or Back-Cover Texts, in the notice that says that theDocument is released under this License. A Front-Cover Text may be atmost 5 words, and a Back-Cover Text may be at most 25 words.

A “Transparent” copy of the Document means a machine-readablecopy, represented in a format whose specification is available to the generalpublic, that is suitable for revising the document straightforwardly with ge-neric text editors or (for images composed of pixels) generic paint programsor (for drawings) some widely available drawing editor, and that is suita-ble for input to text formatters or for automatic translation to a variety offormats suitable for input to text formatters. A copy made in an otherwi-se Transparent file format whose markup, or absence of markup, has beenarranged to thwart or discourage subsequent modification by readers is notTransparent. An image format is not Transparent if used for any substantialamount of text. A copy that is not “Transparent” is called “Opaque”.

Examples of suitable formats for Transparent copies include plain AS-CII without markup, Texinfo input format, LaTeX input format, SGMLor XML using a publicly available DTD, and standard-conforming simpleHTML, PostScript or PDF designed for human modification. Examples of


transparent image formats include PNG, XCF and JPG. Opaque formatsinclude proprietary formats that can be read and edited only by proprietaryword processors, SGML or XML for which the DTD and/or processing toolsare not generally available, and the machine-generated HTML, PostScriptor PDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plussuch following pages as are needed to hold, legibly, the material this Licenserequires to appear in the title page. For works in formats which do not haveany title page as such, “Title Page” means the text near the most prominentappearance of the work’s title, preceding the beginning of the body of thetext.

A section “Entitled XYZ” means a named subunit of the Documentwhose title either is precisely XYZ or contains XYZ in parentheses follo-wing text that translates XYZ in another language. (Here XYZ stands for aspecific section name mentioned below, such as “Acknowledgements”,“Dedications”, “Endorsements”, or “History”.) To “Preserve theTitle” of such a section when you modify the Document means that itremains a section “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the noticewhich states that this License applies to the Document. These WarrantyDisclaimers are considered to be included by reference in this License, butonly as regards disclaiming warranties: any other implication that theseWarranty Disclaimers may have is void and has no effect on the meaning ofthis License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either com-mercially or noncommercially, provided that this License, the copyright no-tices, and the license notice saying this License applies to the Document arereproduced in all copies, and that you add no other conditions whatsoeverto those of this License. You may not use technical measures to obstruct orcontrol the reading or further copying of the copies you make or distribute.However, you may accept compensation in exchange for copies. If you dis-tribute a large enough number of copies you must also follow the conditionsin section 3.

You may also lend copies, under the same conditions stated above, andyou may publicly display copies.

3. COPYING IN QUANTITY

Licencias 181

If you publish printed copies (or copies in media that commonly haveprinted covers) of the Document, numbering more than 100, and the Do-cument’s license notice requires Cover Texts, you must enclose the copiesin covers that carry, clearly and legibly, all these Cover Texts: Front-CoverTexts on the front cover, and Back-Cover Texts on the back cover. Bothcovers must also clearly and legibly identify you as the publisher of thesecopies. The front cover must present the full title with all words of the titleequally prominent and visible. You may add other material on the covers inaddition. Copying with changes limited to the covers, as long as they pre-serve the title of the Document and satisfy these conditions, can be treatedas verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly,you should put the first ones listed (as many as fit reasonably) on the actualcover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numberingmore than 100, you must either include a machine-readable Transparentcopy along with each Opaque copy, or state in or with each Opaque copya computer-network location from which the general network-using publichas access to download using public-standard network protocols a comple-te Transparent copy of the Document, free of added material. If you usethe latter option, you must take reasonably prudent steps, when you begindistribution of Opaque copies in quantity, to ensure that this Transparentcopy will remain thus accessible at the stated location until at least one yearafter the last time you distribute an Opaque copy (directly or through youragents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of theDocument well before redistributing any large number of copies, to givethem a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document underthe conditions of sections 2 and 3 above, provided that you release theModified Version under precisely this License, with the Modified Versionfilling the role of the Document, thus licensing distribution and modificationof the Modified Version to whoever possesses a copy of it. In addition, youmust do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct fromthat of the Document, and from those of previous versions (which


should, if there were any, be listed in the History section of the Docu-ment). You may use the same title as a previous version if the originalpublisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entitiesresponsible for authorship of the modifications in the Modified Version,together with at least five of the principal authors of the Document (allof its principal authors, if it has fewer than five), unless they releaseyou from this requirement.

C. State on the Title page the name of the publisher of the ModifiedVersion, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacentto the other copyright notices.

F. Include, immediately after the copyright notices, a license notice givingthe public permission to use the Modified Version under the terms ofthis License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections andrequired Cover Texts given in the Document’s license notice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled “History”, Preserve its Title, and add toit an item stating at least the title, year, new authors, and publisher ofthe Modified Version as given on the Title Page. If there is no sectionEntitled “History” in the Document, create one stating the title, year,authors, and publisher of the Document as given on its Title Page,then add an item describing the Modified Version as stated in theprevious sentence.

J. Preserve the network location, if any, given in the Document for pu-blic access to a Transparent copy of the Document, and likewise thenetwork locations given in the Document for previous versions it wasbased on. These may be placed in the “History” section. You may omita network location for a work that was published at least four yearsbefore the Document itself, or if the original publisher of the versionit refers to gives permission.

K. For any section Entitled “Acknowledgements” or “Dedications”, Pre-serve the Title of the section, and preserve in the section all the subs-tance and tone of each of the contributor acknowledgements and/ordedications given therein.

Licencias 183

L. Preserve all the Invariant Sections of the Document, unaltered in theirtext and in their titles. Section numbers or the equivalent are notconsidered part of the section titles.

M. Delete any section Entitled “Endorsements”. Such a section may notbe included in the Modified Version.

N. Do not retitle any existing section to be Entitled “Endorsements” orto conflict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendicesthat qualify as Secondary Sections and contain no material copied from theDocument, you may at your option designate some or all of these sectionsas invariant. To do this, add their titles to the list of Invariant Sections inthe Modified Version’s license notice. These titles must be distinct from anyother section titles.

You may add a section Entitled “Endorsements”, provided it containsnothing but endorsements of your Modified Version by various parties–forexample, statements of peer review or that the text has been approved byan organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, anda passage of up to 25 words as a Back-Cover Text, to the end of the list ofCover Texts in the Modified Version. Only one passage of Front-Cover Textand one of Back-Cover Text may be added by (or through arrangementsmade by) any one entity. If the Document already includes a cover text forthe same cover, previously added by you or by arrangement made by thesame entity you are acting on behalf of, you may not add another; but youmay replace the old one, on explicit permission from the previous publisherthat added the old one.

The author(s) and publisher(s) of the Document do not by this Licensegive permission to use their names for publicity for or to assert or implyendorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released underthis License, under the terms defined in section 4 above for modified versions,provided that you include in the combination all of the Invariant Sectionsof all of the original documents, unmodified, and list them all as Invariant


Sections of your combined work in its license notice, and that you preserveall their Warranty Disclaimers.

The combined work need only contain one copy of this License, andmultiple identical Invariant Sections may be replaced with a single copy.If there are multiple Invariant Sections with the same name but differentcontents, make the title of each such section unique by adding at the endof it, in parentheses, the name of the original author or publisher of thatsection if known, or else a unique number. Make the same adjustment tothe section titles in the list of Invariant Sections in the license notice of thecombined work.

In the combination, you must combine any sections Entitled “History”in the various original documents, forming one section Entitled “History”;likewise combine any sections Entitled “Acknowledgements”, and any sec-tions Entitled “Dedications”. You must delete all sections Entitled “Endor-sements”.

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other docu-ments released under this License, and replace the individual copies of thisLicense in the various documents with a single copy that is included in thecollection, provided that you follow the rules of this License for verbatimcopying of each of the documents in all other respects.

You may extract a single document from such a collection, and distributeit individually under this License, provided you insert a copy of this Licenseinto the extracted document, and follow this License in all other respectsregarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENTWORKS

A compilation of the Document or its derivatives with other separateand independent documents or works, in or on a volume of a storage ordistribution medium, is called an “aggregate” if the copyright resulting fromthe compilation is not used to limit the legal rights of the compilation’s usersbeyond what the individual works permit. When the Document is included inan aggregate, this License does not apply to the other works in the aggregatewhich are not themselves derivative works of the Document.

Licencias 185

If the Cover Text requirement of section 3 is applicable to these copiesof the Document, then if the Document is less than one half of the entireaggregate, the Document’s Cover Texts may be placed on covers that bracketthe Document within the aggregate, or the electronic equivalent of covers ifthe Document is in electronic form. Otherwise they must appear on printedcovers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribu-te translations of the Document under the terms of section 4. ReplacingInvariant Sections with translations requires special permission from theircopyright holders, but you may include translations of some or all InvariantSections in addition to the original versions of these Invariant Sections. Youmay include a translation of this License, and all the license notices in theDocument, and any Warranty Disclaimers, provided that you also includethe original English version of this License and the original versions of thosenotices and disclaimers. In case of a disagreement between the translationand the original version of this License or a notice or disclaimer, the originalversion will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Dedi-cations”, or “History”, the requirement (section 4) to Preserve its Title(section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document exceptas expressly provided for under this License. Any other attempt to copy,modify, sublicense or distribute the Document is void, and will automaticallyterminate your rights under this License. However, parties who have receivedcopies, or rights, from you under this License will not have their licensesterminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of theGNU Free Documentation License from time to time. Such new versions willbe similar in spirit to the present version, but may differ in detail to addressnew problems or concerns. See http://www.gnu.org/copyleft/.


Each version of the License is given a distinguishing version number. Ifthe Document specifies that a particular numbered version of this License“or any later version” applies to it, you have the option of following theterms and conditions either of that specified version or of any later versionthat has been published (not as a draft) by the Free Software Foundation.If the Document does not specify a version number of this License, you maychoose any version ever published (not as a draft) by the Free SoftwareFoundation.

ADDENDUM: How to use this License for yourdocuments

To use this License in a document you have written, include a copy ofthe License in the document and put the following copyright and licensenotices just after the title page:

Copyright c© YEAR YOUR NAME. Permission is granted tocopy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.2 or anylater version published by the Free Software Foundation; withno Invariant Sections, no Front-Cover Texts, and no Back-CoverTexts. A copy of the license is included in the section entitled“GNU Free Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,replace the “with . . . Texts.” line with this:

with the Invariant Sections being LIST THEIR TITLES, withthe Front-Cover Texts being LIST, and with the Back-CoverTexts being LIST.

If you have Invariant Sections without Cover Texts, or some other com-bination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we re-commend releasing these examples in parallel under your choice of free soft-ware license, such as the GNU General Public License, to permit their usein free software.

Download - Karma Linux

Top Related