Página siguiente Página anterior Índice general

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:

Whetstone:

Xbench-0.2:

UnixBench versión 4.01:

Banco de pruebas BYTEmark de BYTE Magazine BYTEmark:

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."


Página siguiente Página anterior Índice general