3. El Linux Benchmarking Toolkit (LBT)

Quiero proponer un conjunto básico de herramientas de medida para Linux. Es sólo una versión preliminar de un general Linux Benchmarking Toolkit, que será expandido y mejorado. Tómelo como lo que es, esto es, como una propuesta. Si no cree que es un conjunto de herramientas válido, sientase libre de enviarme un correo electrónico con sus críticas y estaré encantado de hacer los cambios y mejoras, si puedo. Sin embargo, antes de tomar una decisión, lea este CÓMO y las referencias mencionadas: las críticas informadas serán bienvenidas, las críticas sin fundamento no.

3.1 Bases lógicas

Ésto es sólo de sentido común:

1. No debe llevar un día el ejecutarlo. Cuando hay que hacer tests comparativos (varias ejecuciones), no hay nadie que esté dispuesto a pasar días tratando de averiguar la mejor configuración de un sistema. Idealmente, el conjunto completo de pruebas debe llevar unos 15 minutos en una máquina media.
2. Todo el código fuente de los programas de estar libremente disponible en la Red, por razones obvias.
3. Los tests deben proporcionar una representación sencilla de los resultados que refleje el rendimiento medido.
4. Debe haber una mezcla de tests sintéticos y de tests de aplicación (con resultados separados, por supuesto).
5. Cada test sintético debe ejercitar un subsistema particular hasta su máxima capacidad.
6. Los resultados de los tests sintéticos NO deben mezclarse en un sólo resultado general (ésto acaba con la toda la idea que hay detrás de los tests sintéticos, con una considerable pérdida de información).
7. Los tests de aplicación deben consistir en tareas usualmente ejecutadas en los sistemas Linux.

3.2 Selección de herramientas

He seleccionado cinco conjuntos de herramientas, tratando de evitar, en la medida de lo posible, el solapamiento de pruebas. Son éstas:

1. Compilación del Núcleo 2.0.0 (con la configuración por defecto) utilizando gcc.
2. La versión 10/03/97 de Whetstone (la última que ha sacado Roy Longbottom).
3. xbench-0.2 (con los parámetros de ejecución rápida).
4. La versión 4.01 de UnixBench (resultados parciales).
5. La distribución 2 de la versión beta de los test BYTEmark de la revista BYTE Magazine (resultados parciales).

Para las pruebas 4 y 5, ``(resultados parciales)'' significa que no se tendrán en cuenta todos los resultados producidos por estos tests.

3.3 Duración de las pruebas

1. Compilación del Núcleo 2.0.0: 5 - 30 minutos, dependiendo del rendimiento real de su sistema.
2. Whetstone: 100 segundos.
3. Xbench-0.2: < 1 hora.
4. Versión 4.01 de los tests UnixBench: aprox. 15 minutos.
5. Los tests BYTEmark de BYTE Magazine: aprox. 10 minutos.

3.4 Comentarios

Compilación del Núcleo 2.0.0:

• Qué: es el único test de aplicación que hay en el LBT.
• El código está ampliamente difundido (finalmente he encontrado alguna utilidad a mis viejos CD-ROMs con Linux).
• Muchos linuxeros recompilan el núcleo a menudo, por lo que es un medida significativa del rendimiento global del sistema.
• El núcleo es grande y gcc utiliza una gran cantidad de memoria: se atenua la importancia de la caché L2.
• Hace un uso frecuente de la E/S al disco.
• Procedimiento para realizar la prueba: conseguir el código de la versión 2.0.0 del núcleo, compilarlo con las opciones por defecto (make config, pulsar Intro repetidamente). El tiempo a informar debería ser el que se inverte en la compilación; esto es, después de que escribe make zImage, sin incluir make dep, make clean. Tenga en cuenta que la arquitectura objetivo por defecto del núcleo es i386, de manera que si compila en otras arquitecturas, debería configurar también gcc para hacer una compilación cruzada, teniendo i386 como arquitectura objetivo.
• Resultados: tiempo de compilación en minutos y segundos (por favor, no indique las fracciones de segundo).

Whetstone:

• Qué: mide el rendimiento de punto flotante puro con un bucle corto. El fuente (en C) es muy legible y es fácil de ver qué operaciones en punto flotante intervienen.
• Es la prueba más corta del LBT :-).
• Es una prueba "Clásica": hay disponibles cifras comparativas, sus defectos y deficiencias son bien conocidos.
• Procedimiento para realizar la prueba: se debería obtener el código en C más reciente del sitio de Aburto. Compile y ejecute en modo de doble precisión. Especifique gcc y -O2 como opciones de precompilador y compilador, y defina POSIX 1 para especificar el tipo de máquina.
• Resultados: una cifra del rendimiento de punto flotante en MWIPS.

Xbench-0.2:

• Qué: mide el rendimiento del servidor X.
• La medida xStones proporcionada por xbench es una media ponderada de varias pruebas referidas a una vieja estación Sun con una pantalla de un solo bit de profundidad. Hmmm... es cuestionable como test para servidores X modernos, pero sigue siendo la mejor herramienta que he encontrado.
• Procedimiento para realizar la prueba: compilar con -O2. Especificamos unas pocas opciones para una ejecución más rápida:./xbench -timegoal 3 > results/name_of_your_linux_box.out. Para obtener la calificación xStones, debemos ejecutar un guión (script) en awk; la manera más rápida es escribir make summary.ms. Compruebe el fichero summary.ms: la calificación xStone de su sistema está en la última columna del renglón que tiene el nombre de su máquina que especificó durante la prueba.
• Resultados: una figure del rendimiento de X en xStones.
• Nota: esta prueba, tal como está, es obsoleta. Debería ser reescrita.

UnixBench versión 4.01:

• Qué: mide el rendimiento global de Unix. Esta prueba ejercitará el rendimiento de E/S de ficheros y multitarea del núcleo.
• He descartado los resultados de todas las pruebas aritméticas, quedándome sólo con los resultados relacionados con el sistema.
• Procedimiento para realizar la prueba: compilar con -O2. Ejecutar con ./Run -1 (ejecutar cada prueba una vez). Encontrará los resultados en el fichero ./results/report. Calcule la media geométrica de los índices EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS y SYSTEM CALL OVERHEAD.
• Resultados: un índice del sistema.

Banco de pruebas BYTEmark de BYTE Magazine BYTEmark:

• Qué: proporciona una buena medida del rendimiento de la CPU. Aquí hay un extracto de la documentación: "Estas pruebas están pensadas para exponer el límite superior teórico de la arquitectura de CPU, FPU y memoria de un sistema. No pueden medir transferencias de vídeo, disco o red (éstos son dominios de un conjunto de pruebas diferentes). Debería usted, por lo tanto, utilizar los resultados de estas pruebas como parte, no como un todo, en cualquier evaluación de un sistema."
• He descartado los resultados de la prueba de FPU ya que la prueba Whetstone es representativa del rendimiento de la FPU.
• He dividido las pruebas de enteros en dos grupos: aquellos más representativos del rendimiento memoria-caché-CPU y las pruebas de enteros de la CPU.
• Procedimiento para realizar la prueba: compilar con -O2. Ejecutar la prueba con ./nbench > myresults.dat o similar. Entonces, de myresults.dat, calcule la media geométrica de los índices de las pruebas STRING SORT, ASSIGNMENT y BITFIELD; éste es el índice de la memoria; calcule la media geométrica de los índices de las pruebas NUMERIC SORT, IDEA, HUFFMAN y FP EMULATION; éste es el índice de enteros.
• Resultados: un índice de memoria y un índice de enteros calculado tal como se explica anteriormente.

3.5 Posibles mejoras

El conjunto ideal de pruebas debería ejecutarse en pocos minutos, con pruebas sintéticas que examinen cada subsistema por separado y pruebas de aplicación que den resultados para diferentes aplicaciones. También debería generar de forma automática un informe completo y quizá enviarlo por correo a la base de datos central en la Web.

No estamos interesados en la portabilidad, pero debería al menos poder ser ejecutado en cualquier versión reciente (> 2.0.0) y 'sabor' (i386, Alpha, Sparc...) de Linux.

Si alguien tiene alguna idea al respecto de probar la red de una manera sencilla, fácil y fiable, con una prueba corta (menos de 30 minutos en configuración y ejecución), por favor, póngase en contacto conmigo.

3.6 El formulario de informe LBT

Aparte de las pruebas, el procedimiento de 'benchmarking' no estaría completo sin un formulario describiendo la configuración, de manera que aquí está (siguiendo la guía de comp.benchmarks.faq):

LINUX BENCHMARKING TOOLKIT REPORT FORM

CPU 
== 
Vendor: 
Model: 
Core clock: 
Motherboard vendor: 
Mbd. model: 
Mbd. chipset: 
Bus type: 
Bus clock: 
Cache total: 
Cache type/speed: 
SMP (number of processors): 

RAM 
==== 
Total: 
Type: 
Speed: 

Disk 
==== 
Vendor: 
Model: 
Size: 
Interface: 
Driver/Settings: 

Video board 
=========== 
Vendor: 
Model: 
Bus:
Video RAM type: 
Video RAM total: 
X server vendor: 
X server version: 
X server chipset choice: 
Resolution/vert. refresh rate: 
Color depth: 

Kernel 
===== 
Version: 
Swap size:

gcc 
=== 
Version: 
Options: 
libc version: 

Test notes 
==========

RESULTS 
======== 
Linux kernel 2.0.0 Compilation Time: (minutes and seconds) 
Whetstones: results are in MWIPS. 
Xbench: results are in xstones. 
Unixbench Benchmarks 4.01 system INDEX:  
BYTEmark integer INDEX:
BYTEmark memory INDEX:

Comments* 
========= 
* Este campo se incluye para una posible interpretación de los resultados,
y como tal, es opcional. Podría ser la parte más significativa del
informe, sin embargo, especialmente si está haciendo pruebas comparativas.

3.7 Pruebas del rendimiento de la red

Probar el rendimiento de una red es un reto, ya que implica al menos tener dos máquinas, un servidor y un cliente, y por lo tanto el doble de tiempo para configurar, más variables a controlar, etc... En una red ethernet, pienso que su mejor apuesta sería el paquete ttcp. (por expandir)

3.8 Pruebas SMP

Las pruebas SMP son otro reto, y cualquier banco de pruebas diseñado específicamente para probar SMP tendrá dificultades probándose a sí misma en configuraciones de la vida real, ya que los algoritmos que pueden tomar ventaja de SMP son difíciles de realizar. Parece que las últimas versiones del núcleo de Linux (> 2.1.30 o por ahí) harán multiproceso "muy granulado" (fine-grained), pero no tengo más información al respecto ahora mismo.

Según David Niemi, " ... shell8 [parte del Unixbench 4.01]hace un buen trabajo comparando hardware similare en los modos SMP y UP."

Hosting by: hurra.com
Generated: 2007-01-26 18:00:33