Para medir la carga se usan los programas denominados monitores, vistos anteriormente en el capítulo 1. Sin embargo, interesa caracterizar la carga cuantitativamente para definir de forma objetiva la utilización de un sistema por parte de los usuarios. El objetivo de esta caracterización es conseguir reproducirla para evaluar ese sistema con un fin determinado. Evidentemente, una carga de un sistema particular es difícil de reproducir, pues para empezar varía en el tiempo, y, además, la carga interacciona con el sistema de modo bastante impredecible, por lo cual la interacción con un nuevo sistema no tiene por qué ser la misma.

Por ello, para caracterizar una carga es primero necesario definir los objetivos de la caracterización: en función de ellos, se determinan los parámetros que se tienen que medir y su representación. Algunos de los parámetros a medir pueden ser, por ejemplo:

Tiempo de CPU.

Número de operaciones E/S, distribuciones de las operaciones.

Uso de la memoria.

El objetivo de este capítulo es ver los métodos que se usan para reproducir una carga de prueba, es decir, los métodos de creación de una carga que, de alguna forma, reproduzca el consumo de recursos de un sistema determinado. Esta carga de prueba debe de tener las siguientes características principales:

reproductibilidad: que sea fácil de reproducir para cualquier tipo de sistema.

compacidad: que contenga poco código, y que no sobrecargue el sistema ni tarde demasiado tiempo en ejecutarse.

compatibilidad: esta es la característica más importante. La carga de prueba debe de ser compatible con todos los sistemas que sean susceptibles de ser medidos. Se verá más sobre este tema en el apartado de benchmarks.

escalabilidad: es decir, que el mismo benchmark sirva para ordenadores con una gama amplia de velocidades, que siga siendo útil a lo largo del tiempo, y que de resultados significativos, o sea, que sirvan para diferenciar las prestaciones de los sistemas que se evalúan.

En resumen, para crear un benchmark estándar se suelen seguir los siguientes pasos:

1. Establecimiento de los objetivos del estudio.
2. Estudio de la carga del sistema o sistemas que se van a tratar.
3. Creación o elección de una serie de programas que sirven para medir tales prestaciones.
4. Análisis y presentación gráfica de los resultados.

3.2 Cargas de prueba

Hay diferentes clasificaciones de las cargas de prueba:

reales, es decir, la carga reproduce exactamente la del sistema original, pero esto tiene una serie de problemas: no es excesivamente flexible; es difícil de reproducir exactamente los datos originales a los que se aplicaban los programas; muchas veces los programas son confidenciales o simplemente no se está autorizado a copiarlos, y, además, puede haber diferencias hardware y software entre el sistema original y el sistema a medir que hagan que no se puedan ejecutar los programas en el nuevo sistema.

sintéticas, son aquellas que resumen la carga original, tomando las características más sobresalientes. Estas, además de evitar los problemas de las cargas reales, pueden ser portadas a diferentes sistemas, modificadas sin afectar la operación del sistema, y pueden incluir programas que sirvan para medir las prestaciones de la carga.

Dentro de las cargas sintéticas, que son las más usadas, a su vez se dividen en dos tipos:

Naturales, que también se suelen denominar benchmarks, están formadas por un grupo de programas extraídos de la carga real. Sin embargo, hay muchos factores que influyen en la carga de un sistema, como el factor de multiprogramación, la memoria, y el número máximo de usuarios, que causan que la mayoría de las veces no se comporten de la misma forma.

Artificiales, que son diversos tipos de cargas creadas artificialmente, que intentan reproducir la carga original.

3.2.1 Cargas Artificiales

Se pueden dividir en ejecutables y no ejecutables, siendo estas últimas básicamente una simulación del comportamiento del sistema. Dentro de las primeras, a su vez, hay varios tipos:

3.2.1.1 Instrucción de suma

Consiste en medir el tiempo que se tarda en realizar esta operación. Este tipo de carga es sumamente simple, sólo mide la CPU y se ha quedado ya bastante obsoleta, aunque sirvió en las épocas en que las prestaciones de la CPU eran determinantes de las prestaciones del sistema.

3.2.1.2 Mix

Un mix de instrucciones es una especificación que incluye diferentes instrucciones en diferentes frecuencias. Para hallar las frecuencias en las que hay que incluir cada instrucción o tipo de instrucción se realiza una monitorización de las instrucciones ejecutadas, usualmente mediante un monitor hardware. Los programas no tienen porqué hacer nada útil, simplemente ejecutan instrucciones. A partir del tiempo total de ejecución del mix, se halla lo que se tarda en media en ejecutar una instrucción, a partir de lo cual se calcula los millones de instrucciones por segundo o mips.

El míx más popular es el de Gibson, desarrollado por Jack C. Gibson para los sistemas IBM 704, que se presenta en el cuadro 1

Evidentemente, un mix es un programa de bajo nivel en código máquina, y, por tanto, este tipo de pruebas son específicas de un tipo de CPU, arquitectura y sistema operativo determinado.

Hoy en día no son demasiada utilidad porque el tiempo que tarda una instrucción en los microprocesadores actuales es variable, dependiendo del estado del pipeline, la caché, el modo de direccionamiento, e incluso los argumentos que se le pasan a la instrucción.

En cualquier caso, un mix solo mide la velocidad de la CPU, y si el sistema no está limitado por la misma, el número de instrucciones sólo no refleja las prestaciones del sistema.

3.2.1.3 Kernel

Los kernel son programas que tratan de representar lo más característico de una carga, por ejemplo, la ejecución de funciones con coma flotante. Uno de ellos es, por ejemplo, la ejecución de la función de Ackerman. Evidentemente, tienen que seleccionarse en función de la carga real del sistema; sólo dará mediciones acertadas en caso de que se asemeje a la carga original.

3.2.1.4 Programas sintéticos

Son programas que simplemente consumen recursos de los diferentes subsistemas del ordenador: CPU, disco, entrada salida, sin hacer por lo demás nada útil. El consumo de recursos se regula por una serie de parámetros de control; y los resultados habrá que calibrarlos para relacionarlos con la carga real.

3.3 Benchmarks

Normalmente, los benchmarks tiene habitualmente el objetivo de comparar diferentes ordenadores, periféricos y redes, a la hora de adquirir o ampliar un sistema determinado. Pueden servir también para sintonizar y planificar la carga de un sistema, identificando los problemas de un sistema mediante la forma como se ejecuta una prueba determinada.

Hoy en día, lo más habitual en un benchmark es

Que lo lleve a cabo una empresa o institución independiente, que habitualmente es pagada por sus servicios. La empresa recibe una copia del sistema a evaluar, realiza el trabajo necesario para que se ejecuten los programas, y entrega los resultados al fabricante. Esto, más o menos, garantiza la independencia de los resultados. En muchos casos, las empresas son revistas o están contratadas por revistas, que presentan los resultados obtenidos a los lectores.

Que sean estándar, habitualmente propuestos por un consorcio de empresas. Es decir, son una serie de programas, que todos o la mayoría de los fabricantes conoce y está de acuerdo en respetar los resultados, y cada fabricante es responsable de llevar a cabo las pruebas y de publicar los resultados.

En general, un benchmark recibe dos definiciones:

es una forma de evaluar las prestaciones de un sistema informático, en general; y

es un conjunto de programas reales, escritos en lenguajes de alto nivel, que representan una carga real genérica.

Para conseguir un benchmark hace falta:

Determinar los objetivos de uso.

Escoger el programa según los objetivos.

Estudiar los factores que influyan en el rendimiento: SO, compiladores, librerías usadas, caché, etc.

Un benchmark se usa en la adquisición de equipos, sintonización de sistemas y de capacidad, comparación de compiladores y diseño de sistemas informáticos o compiladores.

En los apartados siguientes veremos una serie de benchmarks que se suelen utilizar en la actualidad.

3.3.1 LINPACK

LINPACK es un programa de álgebra lineal creado por Dongarra en 1976. Consiste en una serie de multiplicaciones de matrices, contenidas en unas subrutinas habitualmente denominadas BLAS. Dongarra ha establecido una base de datos de prestaciones, PDB o Performance Database, a la cual se puede acceder mediante la WWW.

3.3.2 SPEC

SPEC, que son las iniciales de System Performance Evaluation Cooperative, es un consorcio de fabricantes de microprocesadores, ordenadores y estaciones de trabajo. La misión de SPEC es principalmente desarrollar una serie de programas que se van a utilizar para medir diversos aspectos de las prestaciones de un ordenador, y publicar los resultados de esos tests según han sido proporcionados por los fabricantes.

SPEC consiste en realidad en tres grupos diferentes:

• OSG, o Open Systems Group, que crea benchmarks para procesadores y sistemas que ejecutan UNIX, Windows NT y VMS.
• HPC, o High Performance Group, que mide prestaciones de ordenadores dedicados a cálculo intensivo, y
• GPC, o Graphics Performance Characterization Group, que mide prestaciones de subsistemas gráficos, OpenGL y XWindows.

SPEC solo especifica los programas que se van a utilizar para medir prestaciones y la forma de ejecutarlos, pero no los ejecuta, sino que confía en los fabricantes para ejecutarlos, con la condición de que los resultados serán supervisados por SPEC, y se presentarán en su página Web: http://www.specbench.org. En realidad, dado el carácter público de los benchmark, cualquiera puede ejecutarlos (siempre que el ordenador cumpla las características que se especifican en la página Web, como 64 megas de memoria, miles de megas de disco, y tiempo y ganas).

Los benchmark de SPEC han tenido diversas versiones, la última de las cuales es la SPEC95; las versiones anteriores son la 89 y la 92; siempre hay que tener en cuenta la versión a la hora de comparar prestaciones, y se suele especificar.

Hay que tener en cuenta que los fabricantes de ordenadores, siendo como son, hacen todo lo posible para obtener los mejores resultados; por ejemplo, hay una empresa, KAP, que se dedica a optimizar los compiladores para que ejecuten bien el código SPEC y de otros benchmarks, básicamente el código que ejecuta multiplicaciones de matrices. Esto hace que den buenos resultados en las tasas "agresivas", aunque no necesariamente en las conservadoras.

La mayoría de los fabricantes de ordenadores incluyen en sus páginas Web las medidas SPEC de sus equipos, eso sí, con las críticas correspondientes y poniendo claramente de relieve donde sobresalen. Incluso se basan en los resultados dados en estos benchmarks para tomar decisiones de diseño con respecto a sus máquinas.

Como suele suceder, ya se está pensando en la siguiente versión, SPEC98, y se están solicitando conjuntos de aplicaciones que se puedan incluir en el.

3.3.2.1 Cint/Cfp

En concreto, SPEC95 se compone de dos grupos de programas: CINT95, 8 programas de cálculo de enteros intensivo, y CFP95, 10 programas de cálculo intensivo de coma flotante.

099.go	Inteligencia Arficial: juega al go
124.m88ksim	Simulador del Motorola 88k: ejecuta un programa de prueba
126.gcc	Nueva versión de gcc, construye código SPARC.
129.compress	Comprime y descomprime fichero en memoria
130.li	Intérpreta código LISP
132.ijpeg	Compresión y descompresión de gráficos.
134.perl	Manipula cadenas (anágramas) y números primos en PERL.
147.vortex	Base de datos.

El conjunto de pruebas de coma flotante es el siguiente:

101.tomcatv	Programa de generación de tramas
102.swim	Programa de agua poco profunda con rejilla 513x513
103.su2cor	Física cuántica: simulación de Montecarlo.
104.hydro2d	Astrofísica: ecuación de Navier-Stokes
107.mgrid	Solución multirejilla en un campo potencial en 3 dimensiones
110.applu	Ecuación diferencial parcial elíptica parabólica
125.turb3d	Simulación turbulencia homogénea isotrópica en un cubo
141.apsi	Resuelve problemas relacionados con la temperatura, viento, velocidad y distribución de la polución.
145.fpppp	Química cuántica
146.wave5	Física de plasmas, simulación de partículas electromagnéticas.

Tras medir lo que tardan en ejecutarse estos programas, se dan una serie de cantidades, algunas relacionadas con la velocidad, y otras relacionadas con el throughput, es decir, el número de programas del mismo tipo que un ordenador es capaz de manejar. Por ejemplo, para SPECint, se darán

		Velocidad
		Conservador	Agresivo
	Velocidad	SPECint_base95	SPECint95
	Throughput	SPECint_rate_base95	SPECint_rate95

Todas las tasas son medias geométricas de los resultados obtenidos por cada uno de los diferentes métodos, no aritméticas, es decir:

Estas medias geométricas se suelen utilizar cuando las prestaciones de los diferentes componentes no se suman, sino que se acumulan, como se verá más adelante.

Algunos fabricantes de ordenadores, a pesar de usar estas medidas, suelen criticar algunos de sus aspectos: la principal crítica es que la media oculta los resultados individuales de cada uno de los tests; uno de los tests puede dar mejor resultado para una máquina A que para otra B y sin embargo, la media ser mejor para B; por ello se presentan siempre los resultados individuales, para que cada persona pueda mirar los resultados que le interesan.

Estos tests miden también sólo la combinación CPU/memoria/compilador, no el sistema completo, en el cual pueden influir mucho las prestaciones de entrada salida o las de red, sin embargo, hay otros tests que pueden medir estos subsistemas; esto causa también que algunos fabricantes, como IBM, logren optimizar sus compiladores para que reconozcan en código SPEC y conseguir así mejores resultados.

Además, los "_rate" miden ls prestaciones de ordenadores ejecutando muchas copias del mismo programa, no diferentes proramas, y por lo tanto son poco respresentativos de sistemas reales.

En algunos casos, las medidas aportadas por los fabricantes son erróneas, como sucedió con los SPEC92 suministrados por Intel para el Pentium Pro a 200Mhz. A causa de un error en los compiladores usados, los resultados dados por uno de los tests eran exagerados. Más adelante, Intel tuvo que reducir el SPECint92 en un 10%.

3.3.2.2 OSG Web 96

Este programa mide prestaciones de ordenadores usando el comando GET sobre páginas estáticas. Consiste en un programa que hace una serie de peticiones usando el protocolo HTTP/1.0, usando ficheros de diferente tamaño.

3.3.2.3 OSG SFS 93

Es un test para servidores de ficheros a nivel de sistema. Básicamente es un sistema completo para medir e informar de prestaciones de servidores NFS (Network file system, sistema estándar de ficheros en UNIX; véase tema 1). El resultado del test da el tiempo medio que tardan en ejecutarse las operaciones NFS, y el número de usuarios que se pueden soportar.

SFS 1.1 contiene un benchmark, 096.laddis, que genera una carga sintética basada en una abstracción de carga de trabajo. Actualmente se está trabajando en una nueva versión de SFS, la 1.2, que modifique la carga de trabajo y que incluya el protocolo NFS 3.0.

También tiene críticas este benchmark de los fabricantes de ordenadores. Según ellos:

• está demasiado inclinado hacia las operaciones de escritura,
• la carga que representa es continua, y no discontinua y por ráfagas, como suee ser lo normal,
• el número de usuarios que se menciona tampoco es representativo del número de usuarios reales que puede soportar el sistema.

3.3.2.4 OSG SDM 91

Benchmark para desarrollo de software en un entorno multitarea, caracteriza la capacidad de un sistema en un entorno UNIX multi-usuario. Contiene scripts de UNIX, que ejercitan el sistema operativo completo, así como los componentes de entrada/salida y la CPU. Contiene dos benchmarks: 057.sdet, que representa un entorno de desarrollo comercial en UNIX y C, y 061.kenbus1, que representa el uso de UNIX y C en un entorno de investigación y desarrollo.

El principal problema que presentan es que están obsoletos, porque no tienen en cuenta el sistema de ventanas, ni la red, y además las cargas de trabajo modeladas son las normales en sistemas más pequeños que los actuales.

3.3.2.5 SPEChpc96

Este benchmark sirve para medir prestaciones de superordenadores, incluyendo todo tipo de ordenadores masivamente paralelos y vectoriales. Incluye aplicaciones usadas realmente en la industria para resolver problemas: unos para procesamiento sísmico (SPECseis96) y otro de química computacional (SPECchem96). Ambas están escritas en C, y proporcionan información suplementaria a SPECfp96, ya que en este caso se trata de aplicaciones reales, no de aplicaciones sintéticas.

3.3.3 BYTEmark

(Obsérvese la hábil mayusculización del nombre de la revista, para que se parezca a SPECmark). BYTEmark es un conjunto de pruebas creada por la revista Byte, y ejecutada por la propia revista sobre cualquier ordenador que se le ponga a mano. Los programas utilizados son de dominio público, y están accesibles desde la página Web de Byte. El documento que describe BYTEmark está en http://www.byte.com/bmark/bdoc.htm.

BYTEmark pretende ser un test estándar para todo tipo de sistemas, y por ello consiste en una serie de programas escritos en ANSI C. Esto significa que evalúa tanto la CPU/FPU y memoria como la eficacia del compilador; el razonamiento de Byte es que si el compilador es malo y genera malos programas, también sufrirán los demás programas que se ejecuten en la misma plataforma. A su vez, se suelen dar dos resultados, uno de enteros y otro de coma flotante.

Las ventajas que tiene este test es que se ha diseñado para que sea escalable y multiplataforma, y fácil de usar en ordenadores personales. Se dan tanto los resultados "crudos", es decir, el número de "iteraciones" del test, y además la relación con respecto a una máquina "base" (inicialmente un Dell con un Pentium a 90 MHz).

Clasificación numérica	Clasifica una matriz de enteros de 32 bits
Clasificación de cadenas	Clasifica cadenas de longitud arbitraria
Campo de bits	Ejecuta funciones de manipulación de bits
Emulación de coma flotante	Un paquete de coma flotante
Coeficientes de Fourier	Rutina de análisis numérico para calcular aproximaciones en serie de ondas
Algoritmo de asignación	Asignación de tareas
Compresión de Huffman	Algoritmo de compresión de texto y gráficos
Encriptación IDEA	Algoritmo de cifrado por bloques
Red neuronal	Simulación de un perceptrón multicapa con retropropagación
Descomposición LU	Algoritmo robusto para resolver ecuaciones lineales

Uno de los principales problemas a los que se enfrentó este benchmark fue cuando se informó que el Pentium era más rápido que el Pentium Pro ejecutando código de 16 bits. Esto se debió a un error del compilador, que hacía que el programa fuera más lento cuando se asignaba memoria con la función malloc()sin alinear el bloque a un grupo completo de 4 bytes. En versiones posteriores, se corrigió el error.

3.3.4 TPC

Siguiendo con esta interminable lista de benchmarks, llegamos a TPC, propuestos por el Transaction Processing Performance Council, y destinado a medir prestaciones de sistemas completos cliente/servidor, incluyendo tanto los ordenadores cliente, como los servidores, como el sistema de comunicaciones entre ellos, y los sistemas de E/S.

Hoy en día se usan principalmente 2 benchmarks: TCP-C y TPC-D, que evalúa "sistemas de toma de decisiones", incluyendo grandes bases de datos y muchos tipos de peticiones diferentes.

El más usado, tpc-c, trata de modelar un sistema de transacciones en línea, incluye 9 tablas, y realiza 5 tipos de transacciones: nuevas pedidos, servir pedidos, incluir pagos de clientes, recuperar el último pedido de un cliente, y monitorizar el nivel de inventario de los artículos pedidos recientemente; las transacciones se envían desde un terminal con un interfaz de pantalla completo.

Los resultados se presentan de dos formas: como transacciones por segundo, y como precio por transacción. Este último incluye el coste completo del sistema, incluyendo cosas como el coste de mantenimiento a 3 años.

3.4 Consejos sobre la elaboración de un benchmark

• Representar en la carga de prueba solo el comportamiento medio, es decir, no tener en cuenta la variabilidad del sistema; aunque la media de peticiones de E/S y el uso de CPU puede ser similar en el benchmark y en el sistema real, en sistemas reales varía mucho.
• Ignorar los efectos de la caché y de los buffers del sistema: cuando la caché se llena, los fallos de página pueden hacer que los programas se ejecuten más lente. Asimismo, cuando se escriben o leen bloques, el que quepan enteros dentro del buffer puede afectar mucho a las prestaciones.
• Ignorar los efectos de la monitorización: el monitor tiene que escribir y leer de disco, por ejemplo, y realizar análisis sobre los resultados, lo cual habrá que tener en cuenta a la hora de dar los resultados finales.
• No asegurar las mismas condiciones iniciales: en sistemas de la complejidad de los actuales, el estado del pipeline, de las diversas cachés y de la memoria virtual puede afectar bastante el estado de las mediciones; habrá que asegurarse de que todos estén en el mismo estado al comienzo de las mediciones.
• Recolectar muchos datos sin hacer ningún análisis: esto es más habitual de lo que aparece; hacer muchas mediciones sin analizarlos, es decir, hallar medias, desviaciones, comparar, representar gráficamente, no sirve de nada; hay que elaborar las mediciones obtenidas y presentarlas de forma atractiva al posible usuario.

A la vez, algunas de las equivocaciones hechas "a posta" pueden ser:

• Usar configuraciones diferentes para la misma carga de trabajo en dos sistemas.

• Trucar los compiladores para que optimicen la carga de trabajo de los benchmarks, o cambiar la carga de trabajo cuando se hace la adaptación a un sistema determinado.
• Especificar los tests de forma que favorezcan a una máquina más que a otra.
• Usar benchmarks muy pequeños, de forma que quepan totalmente en la caché; y que no produzcan prácticamente cambios de contexto.

3.5 Análisis de resultados

Definamos algunos conceptos de estadística:

• Variable aleatoria: una variable es aleatoria si toma uno de un conjunto especificado de valores con una probabilidad especificada.
• Media o valor esperado

Es decir, la suma de los valores tomados por la variable aleatoria por sus probabilidades.

• Varianza: la varianza es la media de las distancias de la variable aleatoria a la media al cuadrado, es decir

La varianza se suele denotar ², y su raiz cuadrada, denominada desviación estándar, .

• Moda: El valor más probable, es decir, x_i, que sea el más probable.
• Mediana: el percentil-50, es decir, el valor en el cual la función de densidad acumulativa es 50.

La media, la mediana y la moda son tres ejemplos de lo que se denominan índices de tendencia centrales, y son el tipo de índices que sirven para representar una muestra completa. La media y la mediana siempre existen y son únicos, sin embargo la moda puede no existir en algunas distribuciones. En caso de que sea una distribución normal, las tres son iguales.

El problema es seleccionar una de las tres para representar la muestra. Las reglas que se suelen seguir son las siguientes:

• Si los datos están agrupados en categorías, se usa la moda.
• Si el total es lo que interesa, se usa la media.
• Si la distribución no está totalmente centrada, se usa la mediana.

Por ejemplo, para representar el recurso más usado en un sistema, se usaría la moda; para representar la carga, la mediana, ya que suele ser una distrubición poco centrada, sin embargo para el tiempo de llegada de peticiones a un sistema se suele usar la media.

Algunas equivocaciones comunes a la hora de elegir un índice central son:

• Elegir la media para valores que son significativamente diferentes, y
• multiplicar la media para obtener la media de un producto, lo cual solo se puede hacer si las variables son estadísticamente independientes.

Además de la media habitual, o media aritmética, a veces se utiliza también la media geométrica, como se ha visto para los SPEC.

Normalmente, para resumir la variabilidad de una variable, se debe de dar la media aritmética y la varianza, o el rango de variación, o los percentiles de 10 y de 90. Pero siempre se tiene que dar algún índice de variabilidad, tanto con respecto a la variabilidad de las mediciones tomadas en las mismas condiciones como a las mediciones de una variable en distintas condiciones.

3.6 Representación gráfica de los resultados

A la hora de representar gráficamente el resultado de un benchmark, o de cualquier tipo de medición de prestaciones o de carga de trabajo, es conveniente seguir las siguientes reglas:

• Minimización del esfuerzo por parte del lector: cuanto más fácil sea leer un gráfico, mejor. Por ejemplo, a la hora de poner una caja con la clave del gráfico o etiquetar las curvas, siempre será más fácil hacer lo último, puesto que no requiere comparación por parte del lector.
• Maximizar información: debe de haber información suficiente en el gráfico para hacerla autosuficiente; será mucho mejor poner la descripción de las variables que sus nombres, pues estos obligan a referirse al texto; y la descripción, cuanto más completa, mejor.
• Minimizar la tinta: presentar el máximo de información con el mínimo de tinta. Demasiada información hace el gráfico poco interesante; por ejemplo, las líneas de la rejilla no deberán de mostrarse a no ser que sean necesarias; deberán evitarse ejes superiores e inferiores, y habrá que ajustar la escala y las variables para que haya la máxima información posible.
• Usar prácticas comúnmente aceptadas: como el eje x para la variable dependiente, el y para la dependiente, el origen en el 0,0, las abscisas y ordenadas en orden creciente. Si no se hace así, el lector tendrá que echar un rato hasta que entienda de qué va el tema.
• Evitar la ambigüedad: mostrar los ejes, las sugdivisiones, las medidas, escalas, identificar cada una de las barras, hacerlo fácil de leer.
• No poner demasiada información ni demasiada poca: por ejemplo, traducir directamente una tabla a un gráfico sin ningún tipo de análisis suele ser absurdo, pues tiene la misma información, aunque la transmita de otra forma. Por otro lado, poner un gráfico con las medias sin indicar desviaciones estándar o rangos tampoco suele ser adecuado. Las medidas que se hagan deben de traducirse si es posible en un solo gráfico, o al menos un gráfico por cantidad a medir, evitando medidas que comuniquen poca información, por ejemplo.

Algunos errores que se suelen cometer son los siguientes:

• Presentar demasiadas alternativas en un solo gráfico: no se deben de meter más de cinco o seis curvas en una sola gráfica, y en todo caso un gráfico de barras no debería de tener más de 10 barras, uno de tarta 8 componentes, uno de curvas 6. En un histograma, cada "cubo" debe de tener al menos 5 puntos de datos.
• Presentar muchas variables y en un solo gráfico: sobre todo si tienen diferentes escalas, ahorra espacio pero hace que la información se confunda.
• Usar símbolos en lugar de texto: en vez del nombre dado en una variable, debería de usarse lo que contiene una variable; por ejemplo, en vez de %CPU, se debería de usar Porcentaje de CPU dedicado al usuario, en un tipo de letra más pequeño.
• Seleccionar las escalas mal : como la mayoría de las veces lo hace el propio programa, uno tiene a quien echarle la culpa, pero es mejor hacerlo a mano, por ejemplo, cuando las variables tienen unos valores transitorios iniciales pequeños, y luego aumentan mucho.
• Usar un gráfico de líneas en vez de uno de barras: en variables categóricas, se debe de usar un gráfico de barras.

Por supuesto, a veces estas equivocaciones se suelen hacer a posta, sobre todo si uno quiere demostrar algo con los gráficos. El saber este tipo de cosas ayuda también a identificarlas cuando uno se las encuentra:

• Usar orígenes no nulos para hacer énfasis de la diferencia: cuando la diferencia es pequeña, se usa un origen no nulo para que parezca más grande. Hay una regla que dice que la altura del punto más alto debe de ser tres cuartos del offset horizontal del punto que haya más a la derecha.
• Trazar cantidades aleatorias sin los intervalos de confianza: la media transmite poca información si no se acompaña de la desviación típica, o rango o algún momento.
• Usar pictogramas escalados por altitud: a veces se usan barquitos, o cochecitos, o chuminaditas para trazar una información. Siempre hay que tener en cuenta que es la altura, y no la superficie, lo que representa la cantidad; si se mira solo la superficie, puede resultar que una cantidad parezca n² veces mejor que otra, cuando solo es n veces mejor.
• Usar tamaños de célula no adecuados en histogramas, y usar escalas partidas en gráficos de columnas. En el primer caso, hay que aplicar tests estadísticos para comprobar que se haya hecho adecuadamente; siempre tendrá que haber al menos 5 puntos experimentales en cada cubo.

3.7 Ejercicios

1. ¿Qué indice de tendencia central debería de usarse para informar de los siguientes variables: tiempo de respuesta, número de paquetes por día, número de paquetes por segundo, frecuencia de palabras en un lenguaje? ¿Y la configuración media de un ordenador personal por tipo de CPU, tamaño de memoria, tipo de disco, número de periféricos, coste?