Página siguiente
Página anterior
Índice general
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.
Ésto es sólo de sentido común:
- 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.
- Todo el código fuente de los programas de estar libremente
disponible en la Red, por razones obvias.
- Los tests deben proporcionar una representación sencilla de los
resultados que refleje el rendimiento medido.
- Debe haber una mezcla de tests sintéticos y de tests de
aplicación (con resultados separados, por supuesto).
- Cada test sintético debe ejercitar un subsistema particular
hasta su máxima capacidad.
- 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).
- Los tests de aplicación deben consistir en tareas usualmente
ejecutadas en los sistemas Linux.
He seleccionado cinco conjuntos de herramientas, tratando de evitar,
en la medida de lo posible, el solapamiento de pruebas. Son éstas:
- Compilación del Núcleo 2.0.0 (con la configuración por defecto)
utilizando gcc.
- La versión 10/03/97 de Whetstone (la última que ha sacado Roy
Longbottom).
- xbench-0.2 (con los parámetros de ejecución rápida).
- La versión 4.01 de UnixBench (resultados parciales).
- 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.
- Compilación del Núcleo 2.0.0: 5 - 30 minutos, dependiendo del
rendimiento real de su sistema.
- Whetstone: 100 segundos.
- Xbench-0.2: < 1 hora.
- Versión 4.01 de los tests UnixBench: aprox. 15 minutos.
- Los tests BYTEmark de BYTE Magazine: aprox. 10 minutos.
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.
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.
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.
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)
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."
Página siguiente
Página anterior
Índice general