Linux Benchmarking CÓMO <author>por André D. Balsa, <url url="mailto:andrewbalsa@usa.net" name="andrewbalsa@usa.net "> &nl; Traducido por: Joaquín Cuenca Abela, <htmlurl url="mailto:jcuenca@patan.eleinf.uv.es" name="jcuenca@patan.eleinf.uv.es"> <date>v0.12, 15 de Agosto de 1997 <abstract>El Linux Benchmarking CÓMO trata sobre algunos aspectos asociados con el <it/benchmarking/ en los sistemas Linux y presentas unas herramientas (algo toscas) para realizar medidas del rendimiento de su sistema, que podría proporcionar una cantidad significativa de información en un par de horas. Quizás también ayude a hacer que disminuya el número de artículos sobre el tema que se envían a comp.os.linux.hardware... </abstract> <toc> <sect>Introducción "Lo que no podemos decir acerca de nosotros mismos debería desaparecer en el silencio." <quote>Ludwig Wittgenstein (1889-1951), filósofo austríaco </quote> <it/Benchmarking/ significa <bf/medir/ la velocidad con la que un ordenador ejecuta una tarea, de forma que se puedan realizar comparaciones entre diferentes combinaciones de programas/componentes. Esta definición <bf/no/ tiene en cuenta la sencillez de utilización, estética o ergonomía o cualquier otro tipo de juicio subjetivo. El <it/Benchmarking/ es una tarea repetitiva, tediosa, y hay que llevar cuidado con los detalles. Es muy normal que los resultados no sean los que uno espera y que estén sujetos a interpretación (puede que hoy en día ésta sea la parte más importante). Para finalizar, el <it/benchmarking/ trata con hechos y datos, no con opiniones ni aproximaciones. <sect1>¿Por qué el <it/benchmarking/ es tan importante? Aparte de las razones apuntadas en el BogoMips Mini-CÓMO (sección 8, párrafo 2), podemos tener que ceñirnos a un presupuesto y/o satisfacer unas necesidades de rendimiento mientras instalamos un sistema Linux. En otras palabras, cuando tenemos que hacernos las siguientes preguntas: <itemize> <item>¿Cómo puedo maximizar el rendimiento con un presupuesto dado? <item>¿Cómo puedo minizar costes manteniendo un nivel mínimo en el rendimiento? <item>¿Cómo puedo obtener la mejor relación calidad/precio (con un presupuesto o unas exigencias dadas)? </itemize> tendremos que examinar, comparar y/o crear <it/benchmarks/. Minimizar costes sin tener que mantener un rendimiento en particular implica utilizar una máquina con partes desfasadas (aquel viejo 386SX-16 que está tirado en el garaje podría servir) y no necesita <it/bechmarks/, y maximizar el rendimiento sin que importe el dinero no es una situación muy realista (a menos que quiera poner un Cray en su casa - la unidad de alimentación recubierta con cuero es bonita, ¿verdad?). El <it/benchmarking/ de por si no tiene sentido, y es una estúpida pérdida de tiempo y dinero; solo tiene sentido como una parte de un proceso, i.e. si tiene que hacer una elección entre dos o más alternativas. Normalmente otro parámetro a tener en cuenta en el proceso de decisión es el <bf>coste</bf>, pero también la disponibilidad, el servicio, la seguridad, estrategia o cualquier otra característica medible y racional que tenga que ver con un ordenador. Por ejemplo, cuando comparamos el rendimiento de diferentes versiones del núcleo de Linux, la <bf/estabilidad/ suele ser más importante que la velocidad. <sect1>Consideraciones no válidas en la medida del rendimiento Se pueden leer muy amenudo en los grupos de noticias y las listas de correo, pero aun así: <enum> <item>Reputación del fabricante (no se puede medir y es insensato). <item>Cuota de mercado del fabricante (insensato e irrelevante). <item>Parámetros irracionales (por ejemplo, supersticiones o prejuicios: ¿Compraría un procesador que se llame 131313ZAP pintado de rosa?) <item>Valor estimado (insensato, irracional y no se puede medir). <item>Cantidad de propaganda: creo que éste es la peor. Personalmente, estoy harto de los logos ``XXX inside'' o ``kkkkkws compatible'' (ahora se ha unido a la banda el ``aaaaa Powered'' - ¿Quién será el próximo?). EMMO<footnote>N.T.: En Mi Modesta Opinión</footnote>, los billones de pesetas gastados en campañas de este tipo estarían mejor empleados en equipos de investigación que se ocupen de desarrollar nuevos procesadores libres de fallos, más rápidos y más baratos :-). Ningún tipo de publicidad puede arreglar un fallo en la unidad de coma flotante en la nueva hornada de procesadores que acaba de instalar en su placa base, pero en cambio un procesador rediseñado sí puede hacerlo. <item>La opiniones del tipo ``tiene lo que paga'' son sólo eso: opiniones. Denme hechos, por favor. </enum> <sect>Procedimientos de medida e interpretación de resultados Un cuantas recomendaciones semiobvias: <enum> <item>Primera y principal, <bf>identifique el rendimiento objetivo</bf>. ¿Qué es exactamente lo que trata de medir? ¿De qué forma la medida del rendimiento le ayudará después a tomar una decisión? ¿Cuánto tiempo y cuántos recursos está dispuesto a gastar en el proceso de medida? <item><bf>Utilice herramientas estándar</bf>. Use una versión del núcleo estable y actualizada, así como un gcc, libc, y una herramienta de medida del rendimiento actualizados y estándares. Abreviando, utilice el LBT (ver más adelante). <item>De una <bf>descripción completa</bf> de su configuración (vea el artículo LBT más adelante). <item>Trate de <bf>aislar una variable</bf>. Las medidas comparativas dan más información que las ``absolutas''. <bf>Ya no puedo insistir más en este punto</bf>. <item><bf>Verifique sus resultados</bf>. Ejecute sus pruebas unas cuantas veces y compruebe las fluctuaciones en los resultados, de haberlas. Las fluctuaciones inexplicables invalidarán sus resultados. <item>Si cree que su esfuerzo en la medición del rendimiento ha producido información útil, <bf>compártala</bf> con la comunidad Linux de forma <bf/breve/ y <bf/concisa/. <item>Por favor, <bf>olvídese de los BogoMips</bf>. Me he prometido que algún día implementaré un rapidísimo ASIC con el bluque de los BogoMips enganchado en él. ¡Entonces veremos lo que tengamos que ver! </enum> <sect1>Entendiendo la elección de la herramienta <sect2>Las herramientas de medida sintéticas vs. las de aplicaciones Antes de perder el tiempo escogiendo entre todos los tipos de herramientas de medida, se debe hacer una elección básica entre las herramientas ``sintéticas'' y las de ``aplicación''. Las herramientas sintéticas están especialmente diseñadas para medir el rendimiento de un componente individual de un ordenador, normalmente llevando el componente escogido a su máxima capacidad. Un ejemplo de una herramienta sintética muy conocida es el <bf/Whetstone/, programado originalmente en 1972 por Harold Curnow en FORTRAN (¿o fue en ALGOL?) y todavía ampliamente utilizada. El conjunto de herramientas Whestone medirá el rendimiento de la unidad de punto flotante de la CPU. La crítica principal que puede hacersele a las medidas ``sintéticas'' es que no representan el rendimiento del sistema en las situaciones de la vida real. Tomemos por ejemplo las herramientas Whetstone: el blucle principal es muy pequeño y podría caber fácilmente en la caché primaria de la CPU, manteniendo el bus de la unidad de punto flotante (FPU) constantemente lleno y ejercitando, por tanto, la FPU a su máxima velocidad. No podemos criticar las herramientas Whetstone por ésto, ya que hemos de tener presente que fueron programadas hace 25 años (¡y diseñadas en fechas anteriores a ésta!), pero hemos de asegurarnos de que interpretamos los resultados con cuidado cuando medimos microprocesadores modernos. Otro punto a tener en cuenta sobre los tests sintéticos es que, idealmente, deberían darnos información acerca de un aspecto <bf/específico/ del sistema que estamos comprobando, independientemente del resto de componentes: un test sintético sobre la E/S de las tarjetas Ethernet debería devolver el mismo resultado (o al menos similar) independientemente de si se ejecuta en un 386SX-16 con 4 MBytes de RAM o de si se ejecuta en un Pentium 200 MMX con 64 MBytes de RAM. Sin embargo, el test medirá la rendimiento global de la combinación CPU/placa base/Bus/tarjeta Ethernet/Subsistema de memoria/DMA: no es muy útil, ya que la variación en el procesador podría causar un impacto mayor en los resultados que la variación en la tarjeta de red Ethernet (naturalmente, ésto es suponiendo que estamos utilizando la misma combinación de controlador/núcleo, que también pueden producir grandes cambios). Para terminar, un error muy común es hacer la media de varios tests sintéticos y decir que esta media es una buena representación del rendimiento en la vida real de un sistema. Aquí tenemos un comentario acerca de los tests FPU, citado con permiso de Cyrix Corp.: <quote>``Una Unidad de Coma Flotante (<it/Floating Point Unit/, FPU) acelera los programas diseñados para utilizar matemáticas en coma flotante: típicamente programas de CAD, hojas de cálculo, juegos 3D y diseño de aplicaciones. Sin embargo, hoy en día las aplicaciones más populares para PC utilizan al mismo tiempo instrucciones en enteras y en coma flotante. Como resultado, Cyrix ha decidido poner énfasis en el ``paralelismo'' a la hora de diseñar el procesador 6x86 para acelerar los programas que entremezclan estos dos tipos de instrucciones. </quote> <quote> El modelo de exclusión de la unidad de coma flotante de los x86 permite la resolución de instrucciones con enteros mientras se ejecuta una instrucción en coma flotante. Por contra, no se puede ejecutar una segunda instrucción en coma flotante si ya se estaba ejecutando anteriormente una. Para eliminar la limitación en el rendimiento creada por el modelo de exclusión de la unidad de coma flotante, el procesador 6x86 puede realizar especulativamente hasta cuatro instrucciones en coma flotante al chip FPU mientras sigue ejecutando instrucciones enteras. Por ejemplo, en una secuencia de código con dos instrucciones en coma flotante (FLTs) seguidas por seis instrucciones enteras (INTs) y seguidas por dos FLTs más, el procesador 6x86 puede mandar las diez instrucciones anteriores a las unidades de ejecución apropiadas antes de que se termine la primera FLT. Si ninguna de las instrucciones falla (el caso típico), la ejecución continua con las unidades de enteros y de coma flotante terminando las instrucciones en paralelo. Si una de las FLTs falla (el caso atípico), la capacidad de ejecución especulativa del 6x86 permite que se restaure el estado del procesador de forma que sea compatible con el modelo de exclusión de la unidad de coma flotante del x86. </quote> <quote>Un examen de los test de rendimiento revela que los test sintéticos de la unidad de coma flotante utiliza un código con solo operaciones de coma flotante, que no es lo que nos encontramos en las aplicaciones del mundo real. Este tipo de tests no aprovecha la capacidad de ejecución especulativa presente en el procesador 6x86. Cyrix cree que las pruebas que utilizan herramientas no sintéticas, basadas en aplicaciones del mundo real pueden reflejar mejor el rendimiento actual que pueden obtener los usuarios. Las aplicaciones del mundo real contienen instrucciones mezcladas de enteros y de coma flotante y utilizan por tanto, la capacidad de ejecución especulativa del 6x86.'' </quote> Por lo tanto, la tendencia en los tests de rendimiento es elegir las aplicaciones más comunes y utilizarlas para medir el rendimiento del sistema completo. Por ejemplo, <bf/SPEC/, la organización sin ánimo de lucro que diseño las herramientas SPECINT y SPECFP, ha lanzado un proyecto para un nuevo conjunto de herramientas basadas en aplicaciones. Pero de nuevo, sería muy raro que alguna herramienta comercial de medida del rendimiento incluya código Linux. Resumiendo, los tests sintéticos son válidos mientras comprenda sus propósitos y limitaciones. Las herramientas basadas en aplicaciones reflejarán mejor el rendimiento global del sistema, pero no hay ninguna disponible para Linux. <sect2>Tests de alto nivel vs. test de bajo nivel Los tests de bajo nivel miden directamente el rendimiento de los componentes: el reloj de la CPU, los tiempos de la DRAM y de la caché SRAM, tiempo de acceso medio al disco duro, latencia, tiempo de cambio de pista, etc... ésto puede ser util en caso de comprar un sistema y no se saber con que componentes viene, pero una forma mejor de comprobar estos datos es abrir la caja, hacer un listado con los nombres que pueda conseguir y obtener una hoja de características de cada componente encontrado (normalmente disponibles en la red). Otro uso de los tests de bajo nivel es comprobar que un controlador de núcleo ha sido correctamente instalado para un componente específico: si tiene la hoja de especificaciones del componente, puede comparar los resultados del test de bajo nivel con las especificaciones teóricas (las impresas). Los tests de alto nivel están más enfocados a medir el rendimiento de la combinación componente/controlador/SO de un aspecto específico del sistema, como por ejemplo el rendimiento de E/S con ficheros, o el rendimiento de una determinada combinación de componentes/controlador/SO/aplicación, p.e. un test Apache en diferentes sistemas. Por supuesto, todos los tests de bajo nivel son sintéticos. Los tests de alto nivel pueden ser sintéticos o de aplicación. <sect1>Tests estándares disponibles para Linux EMMO un test sencillo que cualquiera puede hacer cuando actualiza cualquier componente en su Linux es hacer una compilación del núcleo antes y después de la actualización del componente o del programa y comparar los tiempos de compilación. Si todas las demás combinaciones se mantienen igual, entonces el test es válido como medida del rendimiento en la compilación, y uno ya puede decir que: <quote>"Cambiar de A a B lleva a una mejora de un x % en el tiempo de compilación del núcleo de Linux bajo éstas y éstas condiciones". </quote> ¡Ni más, ni menos! Ya que la compilación del núcleo es una tarea muy normal en Linux, y ya que ejercita muchas de las funciones que se realizan normalmente en los tests (excepto el rendimiento con las instrucciones en coma flotante), podemos concluir que es un test <bf/individual/ bastante bueno. Sin embargo en muchos casos, los resultados de un test no puede reproducirse por otros usuarios Linux debido a las variaciones en la configuración de los programas/componentes y por tanto este tipo de pruebas no puede utilizarse como ``vara de medida'' para comparar distintos sistemas (a menos que nos pongamos todos de acuerdo en compilar un núcleo estándar - ver más adelante). Desgraciadamente, no hay herramientas de medida del rendimiento específicas para Linux, exceptuando el Byte Linux Benchmarks, que son una versión modificada del The Byte Unix Benchmarks que data de Mayo de 1991 (los módulos de Linux se deben a Jon Tombs, autores originales Ben Smith, Rick Grehan y Tom Yager). Hay una <htmlurl url="http://www.silkroad.com/bass/linux/bm.html" name="página central"> para el Byte Linux Benchmarks. David C. Niemi puso por ahí una versión del Byte Unix Benchmarks mejorada y actualizada. Para evitar confusiones con alguna versión anterior la llamó UnixBench 4.01. Aquí está lo que David escribió sobre sus modificaciones: <quote>``La versión original y las versiones ligeramente modificadas de BYTE Unix Benchmarks se diferencian en varias cosas que los hacen ser un indicador inusualmente poco fiable del rendimiento del sistema. He hecho que los valores de mis ``índices'' parezcan muy diferentes para evitar confusiones con el viejo test.'' </quote> David ha creado una lista de correo majordomo para la discusión sobre las pruebas de rendimiento para Linux y para el resto de SOs. Puede unirse a la lista enviando un mensaje a <url url="mailto:majordomo@wauug.erols.com" name="majordomo@wauug.erols.com"> escribiendo en el cuerpo del mismo ``subscribe bench''. El Grupo de Usuarios de Unix del Area de Washington está en proceso de crear una <htmlurl url="http://wauug.erols.com/bench" name="página Web"> sobre los test de rendimiento en Linux. También recientemente, Uwe F. Mayer, <url url="mailto:mayer@math.vanderbilt.edu" name="mayer@math.vanderbilt.edu"> portó el conjunto de pruebas Byte Bytemark a Linux. Éste es un moderno conjunto de herramientas que Rick Grehan envió a BYTE Magazine para comprobar la CPU, FPU y el rendimiento del sistema de memoria de los modernos sistemas de microordenador (hay pruebas estrictamente orientadas al rendimiento del procesador, sin tener en cuenta el rendimiento de la E/S o del sistema). Uwe también ha creado una <htmlurl url="http://math.vanderbilt.edu:80/~mayer/linux/bmark.html" name="página Web"> con una base de datos de los resultados de las pruebas de su versión del Linux BYTEmark benchmarks. Si busca pruebas sintéticas para Linux, en sunsite.unc.edu podrá encontrar unas cuantas. Para comprobar la velocidad relativa de los servidores X y de las tarjetas gráficas, el conjunto de herramientas xbench-0.2 creado por Claus Gittinger está disponible en sunsite.unc.edu, ftp.x.org y otros lugares. Xfree86.org rechaza (prudentemente) el llevar o recomendar ninguna prueba. El <htmlurl url="http://www.goof.com/xbench/" name="XFree86-benchmarks Survey"> es una página Web con una base de datos de los resultados de x-bench. Para el intercambio de E/S de disco, el programa hdparm (incluido con muchas distribuciones, si no lo tiene puede encontrarlo en sunsite.unc.edu) puede medir los ratios de transferencia si lo invoca con las opciones -t y -T. Hay muchas otras herramientas disponibles de forma libre en Internet para comprobar varios aspectos del rendimiento de su Linux. <sect1>Enlaces y referencias El comp.benchmarks.faq creado por Dave Sill es la referencia estándar en las pruebas de rendimiento. No es específico de Linux, pero es una lectura recomendada para cualquiera que se quiera ver seriamente implicado en las pruebas de rendimiento. Está disponible en muchos FTPs y páginas Web y muestra <bf/56 pruebas diferentes/, con enlaces a direcciones FTP o páginas Web donde se pueden recoger. Algunas de las pruebas que se mencionan son comerciales (SPEC, por ejemplo). No voy a nombrar todos y cada uno de los tests que se mencionan en comp.benchmarks.faq, pero hay al menos una prueba de bajo nivel que me gustaría comentar: la <htmlurl url="http://reality.sgi.com/lm/lmbench/lmbench.html" name="prueba lmbench">, de Larry McVoy. Citando a David C. Niemi: <quote>``Linus y David Miller la utilizan mucho ya que es capaz de realizar útiles medidas de bajo nivel y también puede medir el trasvase y la latencia de la red si tiene dos ordenadores para hacer los tests. Pero no intenta conseguir algo así como un general ``rendimiento del sistema''...'' </quote> Un <htmlurl url="ftp://ftp.nosc.mil/pub/aburto" name="lugar FTP"> bastante completo en cuanto a utilidades <bf/libres/ de medida del rendimiento puesto en marcha por Alfred Aburto. Las herramientas Whetstone utilizadas en el LBT se encontraron aquí. También tenemos el <bf/FAQ multiparte de Eugene Miya/ que deja regularmente en comp.benchmarks; es una referencia excelente. <sect>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, i.e. 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. <sect1>Bases lógicas Ésto es sólo de sentido común: <enum> <item>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. <item>Todo el código fuente de los programas de estar libremente disponible en la Red, por razones obvias. <item>Los tests deben proporcionar una representación sencilla de los resultados que refleje el rendimiento medido. <item>Debe haber una mezcla de tests sintéticos y de tests de aplicación (con resultados separados, por supuesto). <item>Cada test <bf/sintético/ debe ejercitar un subsistema particular hasta su máxima capacidad. <item>Los resultados de los tests <bf/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). <item>Los tests de aplicación deben consistir en tareas usualmente ejecutadas en los sistemas Linux. </enum> <sect1>Selección de herramientas He seleccionada cinco conjuntos de herramientas, tratando de evitar, en la medida de lo posible, el solapamiento de pruebas. Son éstas: <enum> <item>Compilación del Núcleo 2.0.0 (con la configuración por defecto) utilizando gcc. <item>La versión 10/03/97 de Whetstone (la última que ha sacado Roy Longbottom). <item>xbench-0.2 (con los parámetros de ejecución rápida). <item>La versión 4.01 de UnixBench (resultados parciales). <item>La distribución 2 de la versión beta de los test BYTEmark de la revista BYTE Magazine (resultados parciales). </enum> Para las pruebas 4 y 5, ``(resultados parciales)'' significa que no se tendrán en cuenta todos los resultados producidos por estos tests. <sect1>Duración de las pruebas <enum> <item>Compilación del Núcleo 2.0.0: 5 - 30 minutos, dependiendo del rendimiento <bf/real/ de su sistema. <item>Whetstone: 100 segundos. <item>Xbench-0.2: < 1 hora. <item>Versión 4.01 de los tests UnixBench: aprox. 15 minutos. <item>Los tests BYTEmark de BYTE Magazine: aprox. 10 minutos. </enum> <sect1>Comentarios <sect2>Compilación del Núcleo 2.0.0: <itemize> <item><bf>Qué:</bf> es el único test de aplicación que hay en el LBT. <item>El código está ampliamente difundido (i.e. finalmente he encontrado alguna utilidad a mis viejos CD-ROMs con Linux). <item>Muchos linuxeros recompilan el núcleo a menudo, por lo que es un medida significativa del rendimiento global del sistema. <item>El núcleo es grande y gcc utiliza una gran cantidad de memoria: se atenua la importancia de la caché L2. <item>Hace un uso frecuente de la E/S al disco. <item>Procedimiento para realizar la prueba: conseguir el código de la versión 2.0.0 del núcleo, compilarlo con las opciones por Test procedure: get a pristine 2.0.0 source, compile with default options (make config, press Enter repeatedly). The reported time should be the time spent on compilation i.e. after you type make zImage, <bf>not</bf> including make dep, make clean. Note that the default target architecture for the kernel is the i386, so if compiled on another architecture, gcc too should be set to cross-compile, with i386 as the target architecture. <item><bf>Results: </bf>compilation time in minutes and seconds (please don't report fractions of seconds). </itemize> <sect2>Whetstone: <itemize> <item><bf>What: </bf>measures pure floating point performance with a short, tight loop. The source (in C) is quite readable and it is very easy to see which floating-point operations are involved. <item>Shortest test in the LBT :-). <item>It's an "Old Classic" test: comparable figures are available, its flaws and shortcomings are well known. <item>Test procedure: the newest C source should be obtained from Aburto's site. Compile and run in double precision mode. Specify gcc and -O2 as precompiler and precompiler options, and define POSIX 1 to specify machine type. <item><bf>Results: </bf>a floating-point performance figure in MWIPS. </itemize> <sect2>Xbench-0.2: <itemize> <item><bf>What:</bf> measures X server performance. <item>The xStones measure provided by xbench is a weighted average of several tests indexed to an old Sun station with a single-bit-depth display. Hmmm... it is questionable as a test of modern X servers, but it's still the best tool I have found. <item>Test procedure: compile with -O2. We specify a few options for a shorter run:<tt> ./xbench -timegoal 3 > results/name_of_your_linux_box.out</tt>. To get the xStones rating, we must run an awk script; the simplest way is to type <tt>make summary.ms</tt>. Check the summary.ms file: the xStone rating for your system is in the last column of the line with your machine name specified during the test. <item><bf>Results:</bf> an X performance figure in xStones. <item>Note: this test, as it stands, is outdated. It should be re-coded. </itemize> <sect2>UnixBench version 4.01: <itemize> <item><bf>What:</bf> measures overall Unix performance. This test will exercice the file I/O and kernel multitasking performance. <item>I have discarded all arithmetic test results, keeping only the system-related test results. <item>Test procedure: make with -O2. Execute with<tt> ./Run -1</tt> (run each test once). You will find the results in the ./results/report file. Calculate the geometric mean of the EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS and SYSTEM CALL OVERHEAD indexes. <item><bf>Results:</bf> a system index. </itemize> <sect2>BYTE Magazine's BYTEmark benchmarks: <itemize> <item><bf>What:</bf> provides a good measure of CPU performance. Here is an excerpt from the documentation: "These benchmarks are meant to expose the theoretical upper limit of the CPU, FPU, and memory architecture of a system. They cannot measure video, disk, or network throughput (those are the domains of a different set of benchmarks). You should, therefore, use the results of these tests as part, not all, of any evaluation of a system." <item>I have discarded the FPU test results since the Whetstone test is just as representative of FPU performance. <item>I have split the integer tests in two groups: those more representative of memory-cache-CPU performance and the CPU integer tests. <item>Test procedure: make with -O2. Run the test with <tt>./nbench > myresults.dat</tt> or similar. Then, from myresults.dat, calculate geometric mean of STRING SORT, ASSIGNMENT and BITFIELD test indexes; this is the <bf>memory index</bf>; calculate the geometric mean of NUMERIC SORT, IDEA, HUFFMAN and FP EMULATION test indexes; this is the <bf>integer index</bf>. <item><bf>Results:</bf> a memory index and an<bf> </bf>integer index calculated as explained above. </itemize> <sect1>Possible improvements The ideal benchmark suite would run in a few minutes, with synthetic benchmarks testing every subsystem separately and applications benchmarks providing results for different applications. It would also automatically generate a complete report and eventually email the report to a central database on the Web. We are not really interested in portability here, but it should at least run on all recent (> 2.0.0) versions and flavours (i386, Alpha, Sparc...) of Linux. If anybody has any idea about benchmarking network performance in a simple, easy and reliable way, with a short (less than 30 minutes to setup and run) test, please contact me. <sect1>LBT Report Form Besides the tests, the benchmarking procedure would not be complete without a form describing the setup, so here it is (following the guidelines from comp.benchmarks.faq): <code>LINUX BENCHMARKING TOOLKIT REPORT FORM </code> <code>CPU == Vendor: Model: Core clock: Motherboard vendor: Mbd. model: Mbd. chipset: Bus type: Bus clock: Cache total: Cache type/speed: SMP (number of processors): </code> <code>RAM ==== Total: Type: Speed: </code> <code>Disk ==== Vendor: Model: Size: Interface: Driver/Settings: </code> <code>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: </code> <code>Kernel ===== Version: Swap size: </code> <code>gcc === Version: Options: libc version: </code> <code>Test notes ========== </code> <code>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: </code> <code>Comments* ========= * This field is included for possible interpretations of the results, and as such, it is optional. It could be the most significant part of your report, though, specially if you are doing comparative benchmarking. </code> <sect1>Network performance tests Testing network performance is a challenging task since it involves at least two machines, a server and a client machine, hence twice the time to setup and many more variables to control, etc... On an ethernet network, I guess your best bet would be the ttcp package. (to be expanded) <sect1>SMP tests SMP tests are another challenge, and any benchmark specifically designed for SMP testing will have a hard time proving itself valid in real-life settings, since algorithms that can take advantage of SMP are hard to come by. It seems later versions of the Linux kernel (> 2.1.30 or around that) will do "fine-grained" multiprocessing, but I have no more information than that for the moment. According to David Niemi, " ... shell8 [part of the Unixbench 4.01 benchmaks]does a good job at comparing similar hardware/OS in SMP and UP modes." <sect>Example run and results The LBT was run on my home machine, a Pentium-class Linux box that I put together myself and that I used to write this HOWTO. Here is the LBT Report Form for this system: <verb>LINUX BENCHMARKING TOOLKIT REPORT FORM </verb> <verb>CPU </verb> <verb>== </verb> <verb>Vendor: Cyrix/IBM </verb> <verb>Model: 6x86L P166+ </verb> <verb>Core clock: 133 MHz </verb> <verb>Motherboard vendor: Elite Computer Systems (ECS) </verb> <verb>Mbd. model: P5VX-Be </verb> <verb>Mbd. chipset: Intel VX </verb> <verb>Bus type: PCI </verb> <verb>Bus clock: 33 MHz </verb> <verb>Cache total: 256 KB </verb> <verb>Cache type/speed: Pipeline burst 6 ns </verb> <verb>SMP (number of processors): 1 </verb> <verb>RAM </verb> <verb>==== </verb> <verb>Total: 32 MB </verb> <verb>Type: EDO SIMMs </verb> <verb>Speed: 60 ns </verb> <verb>Disk </verb> <verb>==== </verb> <verb>Vendor: IBM </verb> <verb>Model: IBM-DAQA-33240 </verb> <verb>Size: 3.2 GB </verb> <verb>Interface: EIDE </verb> <verb>Driver/Settings: Bus Master DMA mode 2 </verb> <verb>Video board </verb> <verb>=========== </verb> <verb>Vendor: Generic S3 </verb> <verb>Model: Trio64-V2 </verb> <verb>Bus: PCI </verb> <verb>Video RAM type: EDO DRAM </verb> <verb>Video RAM total: 2 MB </verb> <verb>X server vendor: XFree86 </verb> <verb>X server version: 3.3 </verb> <verb>X server chipset choice: S3 accelerated </verb> <verb>Resolution/vert. refresh rate: 1152x864 @ 70 Hz </verb> <verb>Color depth: 16 bits </verb> <verb>Kernel </verb> <verb>===== </verb> <verb>Version: 2.0.29 </verb> <verb>Swap size: 64 MB </verb> <verb>gcc </verb> <verb>=== </verb> <verb>Version: 2.7.2.1 </verb> <verb>Options: -O2 </verb> <verb>libc version: 5.4.23 </verb> <verb>Test notes </verb> <verb>========== </verb> <verb>Very light load. The above tests were run with some of the special Cyrix/IBM 6x86 features enabled with the setx86 program: fast ADS, fast IORT, Enable DTE, fast LOOP, fast Lin. VidMem. </verb> <verb>RESULTS </verb> <verb>======== </verb> <verb>Linux kernel 2.0.0 Compilation Time: 7m12s </verb> <verb>Whetstones: 38.169 MWIPS. </verb> <verb>Xbench: 97243 xStones. </verb> <verb>BYTE Unix Benchmarks 4.01 system INDEX: 58.43 </verb> <verb>BYTEmark integer INDEX: 1.50 </verb> <verb>BYTEmark memory INDEX: 2.50 </verb> <verb>Comments </verb> <verb>========= </verb> <verb>This is a very stable system with homogeneous performance, ideal for home use and/or Linux development. I will report results with a 6x86MX processor as soon as I can get my hands on one! </verb> <sect>Pitfalls and caveats of benchmarking After putting together this HOWTO I began to understand why the words "pitfalls" and "caveats" are so often associated with benchmarking... <sect1>Comparing apples and oranges Or should I say Apples and PCs ? This is so obvious and such an old dispute that I won't go into any details. I doubt the time it takes to load Word on a Mac compared to an average Pentium is a real measure of anything. Likewise booting Linux and Windows NT, etc... Try as much as possible to compare identical machines with a single modification. <sect1>Incomplete information A single example will illustrate this very common mistake. One often reads in comp.os.linux.hardware the following or similar statement: "I just plugged in processor XYZ running at nnn MHz and now compiling the linux kernel only takes i minutes" (adjust XYZ, nnn and i as required). This is irritating, because no other information is given, i.e. we don't even know the amount of RAM, size of swap, other tasks running simultaneously, kernel version, modules selected, hard disk type, gcc version, etc... I recommend you use the LBT Report Form, which at least provides a standard information framework. <sect1>Proprietary hardware/software A well-known processor manufacturer once published results of benchmarks produced by a special, customized version of gcc. Ethical considerations apart, those results were meaningless, since 100% of the Linux community would go on using the standard version of gcc. The same goes for proprietary hardware. Benchmarking is much more useful when it deals with off-the-shelf hardware and free (in the GNU/GPL sense) software. <sect1>Relevance We are talking Linux, right ? So we should forget about benchmarks produced on other operating systems (this is a special case of the "Comparing apples and oranges" pitfall above). Also, if one is going to benchmark Web server performance, <bf>do not</bf> quote FPU performance and other irrelevant information. In such cases, less is more. Also, you do <bf>not</bf> need to mention the age of your cat, your mood while benchmarking, etc.. <sect>FAQ <descrip> <tag>Q1.</tag>Is there any single figure of merit for Linux systems ? <tag>A:</tag>No, thankfully nobody has yet come up with a Lhinuxstone (tm) measurement. And if there was one, it would not make much sense: Linux systems are used for many different tasks, from heavily loaded Web servers to graphics workstations for individual use. No single figure of merit can describe the performance of a Linux system under such different situations. <tag>Q2.</tag>Then, how about a dozen figures summarizing the performance of diverse Linux systems ? <tag>A:</tag>That would be the ideal situation. I would like to see that come true. Anybody volunteers for a <bf>Linux Benchmarking Project</bf> ? With a Web site and an on-line, complete, well-designed reports database ? <tag>Q3.</tag>... BogoMips ... ? <tag>A:</tag>BogoMips has nothing to do with the performance of your system. Check the BogoMips Mini-HOWTO. <tag>Q4.</tag>What is the "best" benchmark for Linux ? <tag>A:</tag>It all depends on which performance aspect of a Linux system one wants to measure. There are different benchmarks to measure the network (Ethernet sustained transfer rates), file server (NFS), disk I/O, FPU, integer, graphics, 3D, processor-memory bandwidth, CAD performance, transaction time, SQL performance, Web server performance, real-time performance, CD-ROM performance, Quake performance (!), etc ... AFAIK no bechmark suite exists for Linux that supports all these tests. <tag>Q5.</tag>What is the fastest processor under Linux ? <tag>A:</tag>Fastest at what task ? If one is heavily number-crunching oriented, a very high clock rate Alpha (600 MHz and going) should be faster than anything else, since Alphas have been designed for that kind of performance. If, on the other hand, one wants to put together a very fast news server, it is probable that the choice of a fast hard disk subsystem and lots of RAM will result in higher performance improvements than a change of processor, for the same amount of $. <tag>Q6.</tag>Let me rephrase the last question, then: is there a processor that is fastest for general purpose applications ? <tag>A:</tag>This is a tricky question but it takes a very simple answer: <bf>NO</bf>. One can always design a faster system even for general purpose applications, independent of the processor. Usually, all other things being equal, higher clock rates will result in higher performance systems (and more headaches too). Taking out an old 100 MHz Pentium from an (usually not) upgradable motherboard, and plugging in the 200 MHz version, one should feel the extra "hummph". Of course, with only 16 MBytes of RAM, the same investment would have been more wisely spent on extra SIMMs... <tag>Q7.</tag>So clock rates influence the performance of a system ? <tag>A:</tag>For most tasks except for NOP empty loops (BTW these get removed by modern optimizing compilers), an increase in clock rate will not give you a linear increase in performance. Very small processor intensive programs that will fit entirely in the primary cache inside the processor (the L1 cache, usually 8 or 16 K) will have a performance increase equivalent to the clock rate increase, but most "true" programs are much larger than that, have loops that do not fit in the L1 cache, share the L2 (external) cache with other processes, depend on external components and will give much smaller performance increases. This is because the L1 cache runs at the same clock rate as the processor, whereas most L2 caches and all other subsystems (DRAM, for example) will run asynchronously at lower clock rates. <tag>Q8.</tag>OK, then, one last question on that matter: which is the processor with the best price/performance ratio for general purpose Linux use ? <tag>A:</tag>Defining "general purpose Linux use" in not an easy thing ! For any particular application, there is always a processor with THE BEST price/performance ratio at any given time, but it changes rather frequently as manufacturers release new processors, so answering Processor XYZ running at n MHz would be a snapshot answer. However, the price of the processor is insignificant when compared to the price of the whole system one will be putting together. So, really, the question should be how can one maximize the price/performance ratio for a given system ? And the answer to that question depends heavily on the minimum performance requirements and/or maximum cost established for the configuration being considered. Sometimes, off-the-shelf hardware will not meet minimum performance requirements and expensive RISC systems will be the only alternative. For home use, I recommend a balanced, homogeneous system for overall performance (now go figure what I mean by balanced and homogeneous :-); the choice of a processor is an important decision , but no more than choosing hard disk type and capacity, amount of RAM, video card, etc... <tag>Q9.</tag>What is a "significant" increase in performance ? <tag>A:</tag>I would say that anything under 1% is not significant (could be described as "marginal"). We, humans, will hardly perceive the difference between two systems with a 5 % difference in response time. Of course some hard-core benchmarkers are not humans and will tell you that, when comparing systems with 65.9 and 66.5 performance indexes, the later is "definitely faster". <tag>Q10.</tag>How do I obtain "significant" increases in performance at the lowest cost ? <tag>A:</tag>Since most source code is available for Linux, careful examination and algorithmic redesign of key subroutines could yield order-of-magnitude increases in performance in some cases. If one is dealing with a commercial project and does not wish to delve deeply in C source code a <bf>Linux consultant should be called in</bf>. See the Consultants-HOWTO. </descrip> <sect>Copyright, acknowledgments and miscellaneous <sect1>How this document was produced The first step was reading section 4 "Writing and submitting a HOWTO" of the HOWTO Index by Greg Hankins. I knew absolutely nothing about SGML or LaTeX, but was tempted to use an automated documentation generation package after reading the various comments about SGML-Tools. However, inserting tags manually in a document reminds me of the days I hand-assembled a 512 byte monitor program for a now defunct 8-bit microprocessor, so I got hold of the LyX sources, compiled it, and used its LinuxDoc mode. Highly recommended combination: <bf>LyX and SGML-Tools</bf>. <sect1>Copyright The Linux Benchmarking HOWTO is copyright (C) 1997 by André D. Balsa. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. If you have questions, please contact Greg Hankins, the Linux HOWTO coordinator, at gregh@sunsite.unc.edu via email, or at +1 404 853 9989. <sect1>New versions of this document New versions of the Linux Benchmarking-HOWTO will be placed on sunsite.unc.edu and mirror sites. There are other formats, such as a Postscript and dvi version in the other-formats directory. The Linux Benchmarking-HOWTO is also available for WWW clients such as Grail, a Web browser written in Python. It will also be posted regularly to comp.os.linux.answers. <sect1>Feedback Suggestions, corrections, additions wanted. Contributors wanted and acknowledged. Flames not wanted. I can always be reached at andrewbalsa@usa.net. <sect1>Acknowledgments David Niemi, the author of the Unixbench suite, has proved to be an endless source of information and (valid) criticism. I also want to thank Greg Hankins, the Linux HOWTO coordinator and one of the main contributors to the SGML-tools package, Linus Torvalds and the entire Linux community. This HOWTO is my way of giving back. <sect1>Disclaimer Your mileage may, and will, vary. Be aware that benchmarking is a touchy subject and a great time-and-energy consuming activity. <sect1>Trademarks Pentium and Windows NT are trademarks of Intel and Microsoft Corporations respectively. BYTE and BYTEmark are trademarks of McGraw-Hill, Inc. Cyrix and 6x86 are trademarks of Cyrix Corporation. Linux is not a trademark, hopefully never will be. </article>