Linux Benchmarking CÓMO
  por André D. Balsa, andrewbalsa@usa.net  <mailto:andrew­
  balsa@usa.net>
  Traducido por: Joaquín Cuenca Abela, jcuenca@patan.ele­
  inf.uv.es
  v0.12, 15 de Agosto de 1997

  El Linux Benchmarking CÓMO trata sobre algunos aspectos asociados con
  el _b_e_n_c_h_m_a_r_k_i_n_g 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...
  ______________________________________________________________________

  Índice general


  1. Introducción
     1.1 ¿Por qué el benchmarking es tan importante?
     1.2 Consideraciones no válidas en la medida del rendimiento

  2. Procedimientos de medida e interpretación de resultados
     2.1 Entendiendo la elección de la herramienta
        2.1.1 Las herramientas de medida sintéticas vs. las de aplicaciones
        2.1.2 Tests de alto nivel vs. test de bajo nivel
     2.2 Tests estándares disponibles para Linux
     2.3 Enlaces y referencias

  3. El Linux Benchmarking Toolkit (LBT)
     3.1 Bases lógicas
     3.2 Selección de herramientas
     3.3 Duración de las pruebas
     3.4 Comentarios
        3.4.1 Compilación del Núcleo 2.0.0:
        3.4.2 Whetstone:
        3.4.3 Xbench-0.2:
        3.4.4 UnixBench versión 4.01:
        3.4.5 Banco de pruebas BYTEmark de BYTE Magazine BYTEmark:
     3.5 Posibles mejoras
     3.6 El formulario de informe LBT
     3.7 Pruebas del rendimiento de la red
     3.8 Pruebas SMP

  4. Prueba de ejemplo y resultados
  5. Falsedades y fallos del benchmarking
     5.1 Comparar manzanas con naranjas
     5.2 Información incompleta
     5.3 Software/hardware Propietario
     5.4 Relevancia

  6. FAQ (Preguntas Frecuentes)
  7. Copyright, reconocimientos y miscelánea
     7.1 Cómo se produjo este documento
     7.2 Copyright
     7.3 Nuevas versiones de este documento
     7.4 Realimentación
     7.5 Agradecimientos
     7.6 Pliego de descargo
     7.7 Marcas registradas


  ______________________________________________________________________



  11..  IInnttrroodduucccciióónn


  _"_L_o _q_u_e _n_o _p_o_d_e_m_o_s _d_e_c_i_r _a_c_e_r_c_a _d_e _n_o_s_o_t_r_o_s _m_i_s_m_o_s _d_e_b_e_r_í_a _d_e_s_a_p_a_r_e_c_e_r
  _e_n _e_l _s_i_l_e_n_c_i_o_._"

       _L_u_d_w_i_g _W_i_t_t_g_e_n_s_t_e_i_n _(_1_8_8_9_-_1_9_5_1_)_, _f_i_l_ó_s_o_f_o _a_u_s_t_r_í_a_c_o


  _B_e_n_c_h_m_a_r_k_i_n_g significa mmeeddiirr 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 nnoo
  tiene en cuenta la sencillez de utilización, estética o ergonomía o
  cualquier otro tipo de juicio subjetivo.

  El _B_e_n_c_h_m_a_r_k_i_n_g 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 _b_e_n_c_h_m_a_r_k_i_n_g trata con hechos y datos, no con
  opiniones ni aproximaciones.


  11..11..  ¿¿PPoorr qquuéé eell bbeenncchhmmaarrkkiinngg  eess ttaann iimmppoorrttaannttee??


  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 o satisfacer
  unas necesidades de rendimiento mientras instalamos un sistema Linux.
  En otras palabras, cuando tenemos que hacernos las siguientes
  preguntas:

  ·  ¿Cómo puedo maximizar el rendimiento con un presupuesto dado?

  ·  ¿Cómo puedo minizar costes manteniendo un nivel mínimo en el
     rendimiento?

  ·  ¿Cómo puedo obtener la mejor relación calidad/precio (con un
     presupuesto o unas exigencias dadas)?

  Tendremos que examinar, comparar o crear _b_e_n_c_h_m_a_r_k_s. 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 _b_e_c_h_m_a_r_k_s, 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 _b_e_n_c_h_m_a_r_k_i_n_g 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,
  esto es, 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 ccoossttee, 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 eessttaabbiilliiddaadd suele ser más importante que la velocidad.


  11..22..  CCoonnssiiddeerraacciioonneess nnoo vváálliiddaass eenn llaa mmeeddiiddaa ddeell rreennddiimmiieennttoo


  Se pueden leer muy amenudo en los grupos de noticias y las listas de
  correo, pero aun así:
  1. Reputación del fabricante (no se puede medir y es insensato).

  2. Cuota de mercado del fabricante (insensato e irrelevante).

  3. Parámetros irracionales (por ejemplo, supersticiones o prejuicios:
     ¿Compraría un procesador que se llame 131313ZAP pintado de rosa?)

  4. Valor estimado (insensato, irracional y no se puede medir).

  5. 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 (-- N.T.: En Mi Modesta Opinión--) , 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.

  6. La opiniones del tipo ``tiene lo que paga'' son sólo eso:
     opiniones. Denme hechos, por favor.


  22..  PPrroocceeddiimmiieennttooss ddee mmeeddiiddaa ee iinntteerrpprreettaacciióónn ddee rreessuullttaaddooss


  Unas cuantas recomendaciones semiobvias:

  1. Primera y principal, iiddeennttiiffiiqquuee eell rreennddiimmiieennttoo oobbjjeettiivvoo. ¿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?

  2. UUttiilliiccee hheerrrraammiieennttaass eessttáánnddaarr. 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).

  3. Dé una ddeessccrriippcciióónn ccoommpplleettaa de su configuración (vea el artículo
     LBT más adelante).

  4. Trate de aaiissllaarr uunnaa vvaarriiaabbllee. Las medidas comparativas dan más
     información que las ``absolutas''. YYaa nnoo ppuueeddoo iinnssiissttiirr mmááss eenn eessttee
     ppuunnttoo.

  5. VVeerriiffiiqquuee ssuuss rreessuullttaaddooss. Ejecute sus pruebas unas cuantas veces y
     compruebe las fluctuaciones en los resultados, de haberlas. Las
     fluctuaciones inexplicables invalidarán sus resultados.

  6. Si cree que su esfuerzo en la medición del rendimiento ha producido
     información útil, ccoommppáárrttaallaa con la comunidad Linux de forma bbrreevvee
     y ccoonncciissaa.

  7. Por favor, oollvvííddeessee ddee llooss BBooggooMMiippss. Me he prometido que algún día
     implementaré un rapidísimo ASIC con el bucle de los BogoMips
     enganchado en él. ¡Entonces veremos lo que tengamos que ver!


  22..11..  EEnntteennddiieennddoo llaa eelleecccciióónn ddee llaa hheerrrraammiieennttaa



  22..11..11..  LLaass hheerrrraammiieennttaass ddee mmeeddiiddaa ssiinnttééttiiccaass vvss.. llaass ddee aapplliiccaacciioonneess


  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 WWhheettssttoonnee,
  programado originalmente en 1972 por Harold Curnow en FORTRAN (¿o fue
  en ALGOL?) y todavía ampliamente utilizada. El conjunto de
  herramientas Whetstone medirá el rendimiento de la unidad de punto
  flotante de la CPU.

  La crítica principal que puede hacérsele 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
  esto, ya que hemos de tener presente que fueron programadas hace 25
  años (¡y diseñadas en fechas anteriores!), 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
  eessppeeccííffiiccoo 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.:

       _`_`_U_n_a _U_n_i_d_a_d _d_e _C_o_m_a _F_l_o_t_a_n_t_e _(_F_l_o_a_t_i_n_g _P_o_i_n_t _U_n_i_t, FPU)
       acelera los programas diseñados para utilizar matemáticas en
       coma flotante: suelen ser 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 enteros y en coma flotante.
       Como resultado, Cyrix ha decidido poner énfasis en el ``par­
       alelismo'' a la hora de diseñar el procesador 6x86 para
       acelerar los programas que entremezclan estos dos tipos de
       instrucciones.



       _E_l _m_o_d_e_l_o _d_e _e_x_c_l_u_s_i_ó_n _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e _d_e _l_o_s
       _x_8_6 _p_e_r_m_i_t_e _l_a _r_e_s_o_l_u_c_i_ó_n _d_e _i_n_s_t_r_u_c_c_i_o_n_e_s _c_o_n _e_n_t_e_r_o_s _m_i_e_n_­
       _t_r_a_s _s_e _e_j_e_c_u_t_a _u_n_a _i_n_s_t_r_u_c_c_i_ó_n _e_n _c_o_m_a _f_l_o_t_a_n_t_e_. _P_o_r
  _c_o_n_t_r_a_, _n_o _s_e _p_u_e_d_e _e_j_e_c_u_t_a_r _u_n_a _s_e_g_u_n_d_a _i_n_s_t_r_u_c_c_i_ó_n _e_n _c_o_m_a
  _f_l_o_t_a_n_t_e _s_i _y_a _s_e _e_s_t_a_b_a _e_j_e_c_u_t_a_n_d_o _a_n_t_e_r_i_o_r_m_e_n_t_e _u_n_a_. _P_a_r_a
  _e_l_i_m_i_n_a_r _l_a _l_i_m_i_t_a_c_i_ó_n _e_n _e_l _r_e_n_d_i_m_i_e_n_t_o _c_r_e_a_d_a _p_o_r _e_l _m_o_d_­
  _e_l_o _d_e _e_x_c_l_u_s_i_ó_n _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e_, _e_l _p_r_o_c_e_­
  _s_a_d_o_r _6_x_8_6 _p_u_e_d_e _r_e_a_l_i_z_a_r _e_s_p_e_c_u_l_a_t_i_v_a_m_e_n_t_e _h_a_s_t_a _c_u_a_t_r_o
  _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n _c_o_m_a _f_l_o_t_a_n_t_e _a_l _c_h_i_p _F_P_U _m_i_e_n_t_r_a_s _s_i_g_u_e
  _e_j_e_c_u_t_a_n_d_o _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n_t_e_r_a_s_. _P_o_r _e_j_e_m_p_l_o_, _e_n _u_n_a
  _s_e_c_u_e_n_c_i_a _d_e _c_ó_d_i_g_o _c_o_n _d_o_s _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n _c_o_m_a _f_l_o_t_a_n_t_e
  _(_F_L_T_s_) _s_e_g_u_i_d_a_s _p_o_r _s_e_i_s _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n_t_e_r_a_s _(_I_N_T_s_) _y
  _s_e_g_u_i_d_a_s _p_o_r _d_o_s _F_L_T_s _m_á_s_, _e_l _p_r_o_c_e_s_a_d_o_r _6_x_8_6 _p_u_e_d_e _m_a_n_d_a_r
  _l_a_s _d_i_e_z _i_n_s_t_r_u_c_c_i_o_n_e_s _a_n_t_e_r_i_o_r_e_s _a _l_a_s _u_n_i_d_a_d_e_s _d_e _e_j_e_­
  _c_u_c_i_ó_n _a_p_r_o_p_i_a_d_a_s _a_n_t_e_s _d_e _q_u_e _s_e _t_e_r_m_i_n_e _l_a _p_r_i_m_e_r_a _F_L_T_. _S_i
  _n_i_n_g_u_n_a _d_e _l_a_s _i_n_s_t_r_u_c_c_i_o_n_e_s _f_a_l_l_a _(_e_l _c_a_s_o _t_í_p_i_c_o_)_, _l_a _e_j_e_­
  _c_u_c_i_ó_n _c_o_n_t_i_n_u_a _c_o_n _l_a_s _u_n_i_d_a_d_e_s _d_e _e_n_t_e_r_o_s _y _d_e _c_o_m_a
  _f_l_o_t_a_n_t_e _t_e_r_m_i_n_a_n_d_o _l_a_s _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n _p_a_r_a_l_e_l_o_. _S_i _u_n_a _d_e
  _l_a_s _F_L_T_s _f_a_l_l_a _(_e_l _c_a_s_o _a_t_í_p_i_c_o_)_, _l_a _c_a_p_a_c_i_d_a_d _d_e _e_j_e_c_u_c_i_ó_n
  _e_s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6 _p_e_r_m_i_t_e _q_u_e _s_e _r_e_s_t_a_u_r_e _e_l _e_s_t_a_d_o _d_e_l
  _p_r_o_c_e_s_a_d_o_r _d_e _f_o_r_m_a _q_u_e _s_e_a _c_o_m_p_a_t_i_b_l_e _c_o_n _e_l _m_o_d_e_l_o _d_e
  _e_x_c_l_u_s_i_ó_n _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e _d_e_l _x_8_6_.



       _U_n _e_x_a_m_e_n _d_e _l_o_s _t_e_s_t _d_e _r_e_n_d_i_m_i_e_n_t_o _r_e_v_e_l_a _q_u_e _l_o_s _t_e_s_t
       _s_i_n_t_é_t_i_c_o_s _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e _u_t_i_l_i_z_a _u_n _c_ó_d_i_g_o
       _c_o_n _s_o_l_o _o_p_e_r_a_c_i_o_n_e_s _d_e _c_o_m_a _f_l_o_t_a_n_t_e_, _q_u_e _n_o _e_s _l_o _q_u_e _n_o_s
       _e_n_c_o_n_t_r_a_m_o_s _e_n _l_a_s _a_p_l_i_c_a_c_i_o_n_e_s _d_e_l _m_u_n_d_o _r_e_a_l_. _E_s_t_e _t_i_p_o _d_e
       _t_e_s_t_s _n_o _a_p_r_o_v_e_c_h_a _l_a _c_a_p_a_c_i_d_a_d _d_e _e_j_e_c_u_c_i_ó_n _e_s_p_e_c_u_l_a_t_i_v_a
       _p_r_e_s_e_n_t_e _e_n _e_l _p_r_o_c_e_s_a_d_o_r _6_x_8_6_. _C_y_r_i_x _c_r_e_e _q_u_e _l_a_s _p_r_u_e_b_a_s
       _q_u_e _u_t_i_l_i_z_a_n _h_e_r_r_a_m_i_e_n_t_a_s _n_o _s_i_n_t_é_t_i_c_a_s_, _b_a_s_a_d_a_s _e_n _a_p_l_i_c_a_­
       _c_i_o_n_e_s _d_e_l _m_u_n_d_o _r_e_a_l _r_e_f_l_e_j_a_n _m_e_j_o_r _e_l _r_e_n_d_i_m_i_e_n_t_o _r_e_a_l _q_u_e
       _p_u_e_d_e_n _o_b_t_e_n_e_r _l_o_s _u_s_u_a_r_i_o_s_. _L_a_s _a_p_l_i_c_a_c_i_o_n_e_s _d_e_l _m_u_n_d_o _r_e_a_l
       _c_o_n_t_i_e_n_e_n _i_n_s_t_r_u_c_c_i_o_n_e_s _m_e_z_c_l_a_d_a_s _d_e _e_n_t_e_r_o_s _y _d_e _c_o_m_a
       _f_l_o_t_a_n_t_e _y _u_t_i_l_i_z_a_n _p_o_r _t_a_n_t_o_, _l_a _c_a_p_a_c_i_d_a_d _d_e _e_j_e_c_u_c_i_ó_n
       _e_s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6_._'_'


  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, SSPPEECC, la organización sin ánimo de
  lucro que dise 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.


  22..11..22..  TTeessttss ddee aallttoo nniivveell vvss.. tteesstt ddee bbaajjoo nniivveell


  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... esto puede ser util en caso de comprar un sistema y
  no se sabe 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.


  22..22..  TTeessttss eessttáánnddaarreess ddiissppoonniibblleess ppaarraa LLiinnuuxx


  EMMO un test sencillo que cualquiera puede hacer cuando actualiza
  cualquier componentes 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:

       "Cambiar de A a B lleva a una mejora de un x % en el tiempo
       de compilación del núcleo de Linux bajo estas y estas condi­
       ciones".


  ¡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 iinnddiivviidduuaall bastante bueno.
  Sin embargo en muchos casos, los resultados de un test no puede ser
  reproducido 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 página central http://www.silkroad.com/bass/linux/bm.html 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:

       _`_`_L_a _v_e_r_s_i_ó_n _o_r_i_g_i_n_a_l _y _l_a_s _v_e_r_s_i_o_n_e_s _l_i_g_e_r_a_m_e_n_t_e _m_o_d_i_f_i_­
       _c_a_d_a_s _d_e _B_Y_T_E _U_n_i_x _B_e_n_c_h_m_a_r_k_s _s_e _d_i_f_e_r_e_n_c_i_a_n _e_n _v_a_r_i_a_s _c_o_s_a_s
       _q_u_e _l_o_s _h_a_c_e_n _s_e_r _u_n _i_n_d_i_c_a_d_o_r _i_n_u_s_u_a_l_m_e_n_t_e _p_o_c_o _f_i_a_b_l_e _d_e_l
       _r_e_n_d_i_m_i_e_n_t_o _d_e_l _s_i_s_t_e_m_a_. _H_e _h_e_c_h_o _q_u_e _l_o_s _v_a_l_o_r_e_s _d_e _m_i_s
       _`_`_í_n_d_i_c_e_s_'_' _p_a_r_e_z_c_a_n _m_u_y _d_i_f_e_r_e_n_t_e_s _p_a_r_a _e_v_i_t_a_r _c_o_n_f_u_s_i_o_n_e_s
       _c_o_n _e_l _v_i_e_j_o _t_e_s_t_._'_'


  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 majordomo@wauug.erols.com
  escribiendo en el cuerpo ``subscribe bench''. El Grupo de Usuarios de
  Unix del Area de Washington está en proceso de crear una página Web
  http://wauug.erols.com/bench sobre los test de rendimiento en Linux.

  También recientemente, Uwe F. Mayer, 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 página Web
  http://math.vanderbilt.edu:80/~mayer/linux/bmark.html 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 _X_F_r_e_e_8_6_-_b_e_n_c_h_m_a_r_k_s _S_u_r_v_e_y http://www.goof.com/xbench/ 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 las tasas 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.


  22..33..  EEnnllaacceess yy rreeffeerreenncciiaass


  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 5566 pprruueebbaass ddiiffeerreenntteess, 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 prueba lmbench
  http://reality.sgi.com/lm/lmbench/lmbench.html de Larry McVoy. Citando
  a David C. Niemi:

       _`_`_L_i_n_u_s _y _D_a_v_i_d _M_i_l_l_e_r _l_a _u_t_i_l_i_z_a_n _m_u_c_h_o _y_a _q_u_e _e_s _c_a_p_a_z _d_e
       _r_e_a_l_i_z_a_r _m_e_d_i_d_a_s _ú_t_i_l_e_s _d_e _b_a_j_o _n_i_v_e_l _y _t_a_m_b_i_é_n _p_u_e_d_e _m_e_d_i_r
       _e_l _t_r_a_s_v_a_s_e _y _l_a _l_a_t_e_n_c_i_a _d_e _l_a _r_e_d _s_i _t_i_e_n_e _d_o_s _o_r_d_e_n_a_d_o_r_e_s
       _p_a_r_a _h_a_c_e_r _l_o_s _t_e_s_t_s_. _P_e_r_o _n_o _i_n_t_e_n_t_a _c_o_n_s_e_g_u_i_r _a_l_g_o _a_s_í
       _c_o_m_o _u_n _`_`_r_e_n_d_i_m_i_e_n_t_o _d_e_l _s_i_s_t_e_m_a_'_' _g_e_n_e_r_a_l_._._._'_'


  Alfred Aburto puso en marcha un lugar FTP bastante completo en cuanto
  a utilidades lliibbrreess de medida del rendimiento
  (ftp://ftp.nosc.mil/pub/aburto).  Las herramientas Whetstone
  utilizadas en el LBT se encontraron aquí.


  También tenemos el FFAAQQ mmuullttiippaarrttee ddee EEuuggeennee MMiiyyaa que deja regularmente
  en comp.benchmarks; es una referencia excelente.


  33..  EEll LLiinnuuxx BBeenncchhmmaarrkkiinngg TToooollkkiitt ((LLBBTT))


  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.


  33..11..  BBaasseess llóóggiiccaass


  É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 ssiinnttééttiiccoo debe ejercitar un subsistema particular hasta
     su máxima capacidad.

  6. Los resultados de los tests ssiinnttééttiiccooss NNOO 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.


  33..22..  SSeelleecccciióónn ddee hheerrrraammiieennttaass


  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.


  33..33..  DDuurraacciióónn ddee llaass pprruueebbaass



  1. Compilación del Núcleo 2.0.0: 5 - 30 minutos, dependiendo del
     rendimiento rreeaall 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.


  33..44..  CCoommeennttaarriiooss


  33..44..11..  CCoommppiillaacciióónn ddeell NNúúcclleeoo 22..00..00::



  ·  QQuuéé:: 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, ssiinn 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.

  ·  RReessuullttaaddooss:: tiempo de compilación en minutos y segundos (por favor,
     no indique las fracciones de segundo).


  33..44..22..  WWhheettssttoonnee::


  ·  QQuuéé:: 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.

  ·  RReessuullttaaddooss:: una cifra del rendimiento de punto flotante en MWIPS.

  33..44..33..  XXbbeenncchh--00..22::


  ·  QQuuéé:: 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.

  ·  RReessuullttaaddooss:: una figure del rendimiento de X en xStones.

  ·  Nota: esta prueba, tal como está, es obsoleta. Debería ser
     reescrita.

  33..44..44..  UUnniixxBBeenncchh vveerrssiióónn 44..0011::


  ·  QQuuéé:: 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.

  ·  RReessuullttaaddooss:: un índice del sistema.

  33..44..55..  BBaannccoo ddee pprruueebbaass BBYYTTEEmmaarrkk ddee BBYYTTEE MMaaggaazziinnee BBYYTTEEmmaarrkk::


  ·  QQuuéé:: proporciona una buena medida del rendimiento de la CPU. Aquí
     hay un extracto de la documentación: _"_E_s_t_a_s _p_r_u_e_b_a_s _e_s_t_á_n _p_e_n_s_a_d_a_s
     _p_a_r_a _e_x_p_o_n_e_r _e_l _l_í_m_i_t_e _s_u_p_e_r_i_o_r _t_e_ó_r_i_c_o _d_e _l_a _a_r_q_u_i_t_e_c_t_u_r_a _d_e _C_P_U_,
     _F_P_U _y _m_e_m_o_r_i_a _d_e _u_n _s_i_s_t_e_m_a_. _N_o _p_u_e_d_e_n _m_e_d_i_r _t_r_a_n_s_f_e_r_e_n_c_i_a_s _d_e
     _v_í_d_e_o_, _d_i_s_c_o _o _r_e_d _(_é_s_t_o_s _s_o_n _d_o_m_i_n_i_o_s _d_e _u_n _c_o_n_j_u_n_t_o _d_e _p_r_u_e_b_a_s
     _d_i_f_e_r_e_n_t_e_s_)_.  _D_e_b_e_r_í_a _u_s_t_e_d_, _p_o_r _l_o _t_a_n_t_o_, _u_t_i_l_i_z_a_r _l_o_s _r_e_s_u_l_t_a_d_o_s
     _d_e _e_s_t_a_s _p_r_u_e_b_a_s _c_o_m_o _p_a_r_t_e_, _n_o _c_o_m_o _u_n _t_o_d_o_, _e_n _c_u_a_l_q_u_i_e_r
     _e_v_a_l_u_a_c_i_ó_n _d_e _u_n _s_i_s_t_e_m_a_._"

  ·  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 íínnddiiccee ddee llaa
     mmeemmoorriiaa; calcule la media geométrica de los índices de las pruebas
     NUMERIC SORT, IDEA, HUFFMAN y FP EMULATION; éste es el íínnddiiccee ddee
     eenntteerrooss.

  ·  RReessuullttaaddooss:: un índice de memoria y un índice de enteros calculado
     tal como se explica anteriormente.

  33..55..  PPoossiibblleess mmeejjoorraass


  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.


  33..66..  EEll ffoorrmmuullaarriioo ddee iinnffoorrmmee LLBBTT

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



  33..77..  PPrruueebbaass ddeell rreennddiimmiieennttoo ddee llaa rreedd

  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)


  33..88..  PPrruueebbaass SSMMPP


  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" (_f_i_n_e_-_g_r_a_i_n_e_d), pero no tengo más
  información al respecto ahora mismo.

  Según David Niemi, _" _._._. _s_h_e_l_l_8 [parte del Unixbench 4.01]_h_a_c_e _u_n _b_u_e_n
  _t_r_a_b_a_j_o _c_o_m_p_a_r_a_n_d_o _h_a_r_d_w_a_r_e _s_i_m_i_l_a_r_e _e_n _l_o_s _m_o_d_o_s _S_M_P _y _U_P_._"



  44..  PPrruueebbaa ddee eejjeemmpplloo yy rreessuullttaaddooss


  Ejecuté el LBT en la máquina de mi casa, un Linux de clase Pentium que
  puse a mi lado y usé para escribir este COMO. Aquí tiene el Formulario
  de Informe LBT de este sistema:


  LINUX BENCHMARKING TOOLKIT REPORT FORM



  CPU



  ==



  Vendor: Cyrix/IBM



  Model: 6x86L P166+



  Core clock: 133 MHz



  Motherboard vendor: Elite Computer Systems (ECS)



  Mbd. model: P5VX-Be



  Mbd. chipset: Intel VX



  Bus type: PCI



  Bus clock: 33 MHz



  Cache total: 256 KB



  Cache type/speed: Pipeline burst 6 ns



  SMP (number of processors): 1



  RAM

  ====



  Total: 32 MB



  Type: EDO SIMMs



  Speed: 60 ns



  Disk



  ====



  Vendor: IBM



  Model: IBM-DAQA-33240



  Size: 3.2 GB



  Interface: EIDE



  Driver/Settings: Bus Master DMA mode 2



  Video board



  ===========



  Vendor: Generic S3



  Model: Trio64-V2



  Bus: PCI



  Video RAM type: EDO DRAM

  Video RAM total: 2 MB



  X server vendor: XFree86



  X server version: 3.3



  X server chipset choice: S3 accelerated



  Resolution/vert. refresh rate: 1152x864 @ 70 Hz



  Color depth: 16 bits



  Kernel



  =====



  Version: 2.0.29



  Swap size: 64 MB



  gcc



  ===



  Version: 2.7.2.1



  Options: -O2



  libc version: 5.4.23



  Test notes



  ==========

  Carga muy ligera. Las pruebas anteriores se ejecutaron activando
  algunas de las capacidades mejoradas del Cyrix/IBM 6x86, mediante el
  programa setx86: fast ADS, fast IORT, Enable DTE, fast LOOP, fast Lin.
  VidMem.



  RESULTS



  ========



  Linux kernel 2.0.0 Compilation Time: 7m12s



  Whetstones: 38.169 MWIPS.



  Xbench: 97243 xStones.



  BYTE Unix Benchmarks 4.01 system INDEX: 58.43



  BYTEmark integer INDEX: 1.50



  BYTEmark memory INDEX: 2.50



  Comments



  =========



  Este es un sistema muy estable con un rendimiento homogéneo, ideal
  para el uso en casa o para el desarrollo con Linux. ¡Informaré de los
  resultados con un procesador 6x86MX tan pronto como le eche las manos
  encima!



  55..  FFaallsseeddaaddeess yy ffaallllooss ddeell bbeenncchhmmaarrkkiinngg


  Después de reunir este COMO empecé a comprender por qué se asocian tan
  frecuentemente las palabras "falsedad" y "fallo" con el
  benchmarking...


  55..11..  CCoommppaarraarr mmaannzzaannaass ccoonn nnaarraannjjaass



  ¿O debería decir Apples (-- N. del T.: Apple = manzana, pero también
  una famosa compaa que fabrica ordenadores--) con PCs? Es una disputa
  tan obvia y antigua que no ahondaré en los detalles. Dudo que el
  tiempo que tarda en cargarse Word en un Mac comparado a la media de un
  Pentium sea una medida real de nada. Al igual que el tiempo de
  arranque de un Linux y un Windows NT, etc... Procure lo más posible
  comprar máquinas idénticas con una sola modificación.

  55..22..  IInnffoorrmmaacciióónn iinnccoommpplleettaa


  Un solo ejemplo ilustrará este fallo común. A menudo uno lee en
  comp.os.linux.hardware la siguiente frase o similar: "Acabo de poner
  el procesador XYZ a nnn MHz y ahora compilar el núcleo de linux me
  lleva sólo i minutos" (ajustar XYZ, nnn e i a lo que se requiera). Es
  irritante, porque no se da más información, esto es, no sabemos
  siquiera la cantidad de RAM, tamaño del fichero de intercambio, otras
  tareas que se ejecutan simultáneamente, versión del núcleo, módulos
  seleccionados, tipo de disco duro, versión del gcc, etc... Le
  recomiendo que use el Formulario de Informe LBT, que al menos
  proporciona un marco de información estándar.


  55..33..  SSooffttwwaarree//hhaarrddwwaarree PPrrooppiieettaarriioo

  Un conocido fabricante de procesadores publicó una vez los resultados
  de unas pruebas producidas por una versión especial, adaptada, de gcc.
  Aparte las consideraciones éticas, estos resultados no tenían sentido,
  ya que el 100% seguiría usando la versión estándar de gcc. Lo mismo va
  para el hardware propietario. El benchmarking es mucho más útil cuando
  trata con hardware off-the-shelf y sofware libre.

  55..44..  RReelleevvaanncciiaa

  Estamos hablando de Linux, ¿no? De manera que deberíamos olvidarnos de
  pruebas producidas en otros sistemoas operativos (este es un caso
  especial del "Comparando manzanas y naranjas" que vimos
  anteriormente). Además, si vamos a hacer pruebas del rendimiento de un
  servidor Web, nnoo debemos resaltar el rendimiento de la FPU ni otra
  información irrelevante.  En tales casos, menos es más. TTaammppooccoo
  necesitamos mencionar la edad de nuestro gato, el humor del que
  estábamos mientras hacíamos la prueba, etc...

  66..  FFAAQQ ((PPrreegguunnttaass FFrreeccuueenntteess))


     PP11..
        ¿Hay alguna medida aislada del mérito de los sistemas Linux?

     RR:: No, gracias al cielo nadie ha salido todavía con una medida
        Lhinuxstone (tm). Y si hubiera una, no tendría mucho sentido:
        los sistemas Linux se usan para diversas tareas, desde
        servidores Web muy cargados hasta estaciones gráficas para uso
        individual. Ninguna medida de mérito por separado puede
        describir el rendimiento de un sistema Linux bajo tales
        situaciones diferentes.

     PP22..
        Entonces, ¿qué tal una docena de cifras resumiendo el
        rendimiento de diversos sistemas Linux?

     RR:: Esa sería la situación ideal. Me gustaría ver que se hace
        realidad. ¿Voluntarios para un LLiinnuuxx BBeenncchhmmaarrkkiinngg PPrroojjeecctt? ¿Con
        un sitio web y una base de datos en línea, completa y con
        informes bien diseñados?

     PP33..
        ... ¿BogoMips...?

     RR:: Los BogoMips no tienen nada que ver con el rendimiento de su
        sistema. Lea el BogoMips Mini-HOWTO.

     PP44..
        ¿Cuá es el 'mejor' banco de pruebas para Linux?

     RR:: Todo depende de qué aspecto del rendimiento de un sistema Linux
        quiera medir uno. Hay diferentes bancos de pruebas para medir la
        red (tasa sostenida de transferencia Ethernet), servidores de
        ficheros (NFS), E/S de disco, FPU, enteros, gráficos, 3D, ancho
        de banda procesador-memoria, rendimiento CAD, tiempo de
        transacción, rendimiento SQL, rendimiento de servidor web,
        rendimiento en tiempo real (_R_e_a_l_-_T_i_m_e), rendimiento del CD-ROM,
        rendimiento de Quake (¡!), etc... HDYS (-- HDYS = Hasta Donde Yo
        Sé (AFAIK = As Far As I Know)--) , no existe ningún conjunto de
        pruebas para Linux que realice todas estas pruebas.

     PP55..
        ¿Cuál es el procesador más rápido sobre el que corre Linux?

     RR:: ¿Más rápido en qué tarea? Si estamos orientados a un gran
        procesamiento de números, un Alpha de gran velocidad de reloj
        (600MHz y superior) debería ser más rápido que ninguna otra
        cosa, ya que los Alpha se han diseñado para ese tipo de
        rendimiento. Si, por otro lado, uno quiere poner un servidor de
        news muy rápido, es probable que la elección de un subsistema de
        disco duro muy rápido y muchísima RAM de un rendimiento mucho
        más alto que un cambio de procesador, por la misma cantidad de
        $.

     PP66..
        Permítame rehacer la pregunta anterior, entonces: ¿hay algún
        procesador que sea más rápido para aplicaciones de propósito
        general?

     RR:: Esa es una difícil con truco, pero tiene una respuesta muy
        sencilla: NNOO. Siempre podremos diseñar un sistema más rápido
        incluso para aplicaciones de uso general, independientemente del
        procesador. Normalmente, siendo todos los demás elementos
        iguales, mayores tasas de reloj darán sistemas de mayor
        rendimiento (y también más dolores de cabeza). Sacando un viejo
        Pentium a 100MHz de una (no suele ser así) placa madre
        actualizable, y enchufando la versión a 200MHz, uno debería
        sentir el "umppffff" extra. Por supuesto, con sólo 16 MBytes de
        RAM, se podría haber hecho la misma inversión, más sabiamente,
        en unos SIMM extra...

     PP77..
        ¿De manera que la velocidad de reloj influye en el rendimiento
        del sistema?

     RR:: Para la mayoría de las tareas excepto los bucles NOP vacíos (por
        cierto, son eliminados por los compiladores optimizadores
        modernos), un aumento en la velocidad del reloj no nos dará un
        aunmento lineal en rendimiento. Los programas muy pequeños e
        intensivos que quepan enteros en la caché primaria del
        procesador (la caché L1, normalmente de 8 o 16K), obtendrán un
        aumento de rendimiento equivalente al de la velocidad de reloj,
        pero la mayoría de los programas "reales" son mucho más grandes
        que eso, tienen bucles que no caben en la caché L1, comparten la
        caché L2 (externa) con otros procesos, dependen de componentes
        externos y obtendrán incrementos mucho menores de rendimiento.
        Esto es así porque la caché L1 funciona a la misma velocidad de
        reloj que el procesador, mientras que la mayoría de las caché L2
        y el resto de los subsistemas (DRAM, por ejemplo, funcionan de
        forma asíncrona a menores velocidades.

     PP88..
        Bien, entonces, una última pregunta sobre el asunto: ¿cual es el
        procesador que proporciona una mejor tasa precio/rendimiento
        para usos de propósito general de Linux?

     RR:: ¡Definir "uso de propósito general de Linux no es fácil! Para
        cualquier aplicación particular, siempre hay un procesador con
        EL MEJOR precio/rendimiento en un momento dado, pero cambia tan
        frecuentemente como los fabricantes sacan al mercado nuevos
        procesadores, de manera que responder Procesador XYZ
        ejecutándose a n MHz sería una respuesta válida sólo
        temporalmente. De todas maneras, el precio del procesador es
        insignificante comparado al precio global del sistema que vamos
        a poner, De manera que, realmente, la cuestión debería ser ¿cómo
        podemos maximizar la tasa precio/rendimiento de un sistema dado?
        Y la respuesta a esa cuestión depende muchísimo de los
        requerimientos mínimos de rendimiento y en el coste
        mínimo/máximo establecido para la configuración que estamos
        considerando. Algunas veces, el hardware que podemos comprar en
        las tiendas no nos dará el rendimiento mínimo necesario, y la
        única alternativa serán costosos sistemas RISC. Para algunos
        usos, recomiendo un sistema equilibrado y homogéneo :-); la
        elección de un procesador es una decisión importante, pero no
        más que elegir el tipo y capacidad del disco duro, la cantidad
        de RAM, la tarjeta de vídeo, etc...

     PP99..
        ¿Qué es un incremento "significativo" de rendimiento?

     RR:: Yo diría que cualquier cosa por debajo de 1% no es significativo
        (podría ser descrito como "marginal"). Nosotros, los humanos,
        difícilmente distinguiremos la diferencia entre dos sistemas con
        una diferencia en tiempo de respuesta del 5%. Por supuesto,
        algunos de los más duros realizadores de pruebas no son humanos,
        y le dirán que, comparando dos sistemas con índices de 65'9 y
        66'5, este último es "definitivamente más rápido".

     PP1100..
        ¿Cómo obtengo incrementos "significativos" en renadimiento al
        menor coste?

     RR:: Como la mayoría del código fuente para Linux está disponible, un
        examen atento y un rediseño algorítmico de las subrutinas clave
        podrían alcanzar incrementos de rendimiento en órdenes de
        magnitud en algunos casos. Si estamos tratando con un proyecto
        comercial y no deseamos meternos demasiado en el código C,
        ppooddrrííaammooss llllaammaarr aa uunn ccoonnssuullttoorr ddee LLiinnuuxx. Lea el Consultants-
        HOWTO.


  77..  CCooppyyrriigghhtt,, rreeccoonnoocciimmiieennttooss yy mmiisscceelláánneeaa


  77..11..  CCóómmoo ssee pprroodduujjoo eessttee ddooccuummeennttoo


  El primer paso fue leer la sección 4 "Escribir y enviar un HOWTO" del
  HOWTO Index de Greg Hankins.

  No sabía absolutamente nada sobre SGML o LaTeX, pero estuve tentado de
  usar un paquete de generación automática de documentación tras leer
  varios comentarios sobre las SGML-Tools. Sin embargo, insertar
  etiquetas manualmente en un documento me recuerda los días en que
  ensamblé a mano un programa monitor de 512 bytes para un
  microprocesador de 8 bits ya difunto, de manera que tomé las fuentes
  de LyX, lo compilé, y usé su modo LinuxDoc. Recomiendo la combinación:
  LLyyXX yy SSGGMMLL--TToooollss.

  77..22..  CCooppyyrriigghhtt


  El Linux Benchmarking HOWTO es copyright (C) 1997 de _André D. Balsa.
  Los documentos HOWTO de Linux pueden ser reproducidos y distribuidos
  en su totalidad o en parte, en cualquier medio físico o electrónico,
  siempre que se mantenga esta noticia de copyright en todas las copias.
  Se permite y anima a la distribución comercial; sin embargo, el autor
  quería que se le avisase de tales distribuciones.

  Todas las traducciones, trabajos derivados, o trabajos agregados que
  incorporen cualquier documento HOWTO de Linux deberán estar cubiertos
  por este copyright. Esto es, no puede procudir un trabajo derivado de
  un HOWTO e imponer restricciones adicionales sobre su distribución. Se
  podrían permitir excepciones a estas restricciones bajo ciertas
  condiciones; por favor, póngase en contacto con el coordinador del
  Linux HOWTO en la dirección que damos más adelante.

  En resumen, nos gustaría promover la diseminación de esta información
  a través de cuantos más canales sea posible. Sin embargo, queríamos
  retener el copyright de los documentos HOWTO, y nos gustaría que nos
  avisase de cualquier plan para redistribuir los HOWTO.

  Si tiene preguntas, diríjase por favor a Greg Hankins, el coordinador
  de Linux HOWTO en gregh@sunsite.unc.edu mediante correo electrónico o
  llamando al +1 404 853 9989.


  77..33..  NNuueevvaass vveerrssiioonneess ddee eessttee ddooccuummeennttoo


  Se pondrán las nuevas versiones del Linux Benchmarking-HOWTO en
  sunsite.unc.edu y en sitios espejo. Allí encontrará otros formatos,
  como las versiones PostScript y dvi en el directorio other-formats. El
  Linux Benchmarking-HOWTO también está disponible para clientes WWW
  como Grail, un navegador Web escrito en Python. También será enviado
  con regularidad en comp.os.linux.answers.

  La versión en castellano de este HOWTO la encontrará en el sitio del
  Insflug http://www.insflug.org


  77..44..  RReeaalliimmeennttaacciióónn


  Se buscan sugerencias y correciones. Se reconocerá a los
  contribuyentes.  No necesito 'flames'.

  Siempre me puede localizar en andrewbalsa@usa.net.

  77..55..  AAggrraaddeecciimmiieennttooss

  David Niemi, el autor del conjunto de aplicaciones Unixbench, ha
  probado ser una fuente infinita de información y críticas (válidas).

  También me gustaría agradecer a Greg Hankins, el coordinador del Linux
  HOWTO y uno de los mayores contribuyentes al paquete SGML-tools, a
  Linus Torvalds y a la comunidad Linux al completo. Este HOWTO es mi
  manera de dar algo a cambio.

  77..66..  PPlliieeggoo ddee ddeessccaarrggoo


  Su experiencia puede variar (y variará). Tenga en cuenta que el
  benchmarking es un tema delicado, y una actividad que consume grandes
  cantidades de tiempo y energía.

  77..77..  MMaarrccaass rreeggiissttrraaddaass

  Pentium y Windows NT son marcas registradas de Intel Corporation y
  Microsoft Corporation respectivamente.

  BYTE y BYTEmark son marcas comerciales de McGraw-Hill, Inc.

  Cyrix y 6x86 son marcas comerciales de Cyrix Corporation.

  Linux no es una marca comercial, y esperemos que nunca lo sea.