  Linux Benchmarking CMO
  por Andr D. Balsa, andrewbalsa@usa.net  <mailto:andrew
  balsa@usa.net>
  Traducido por: Joaqun Cuenca Abela, jcuenca@patan.ele
  inf.uv.es
  v0.12, 15 de Agosto de 1997

  El Linux Benchmarking CMO 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
  podra proporcionar una cantidad significativa de informacin en un
  par de horas. Quizs tambin ayude a hacer que disminuya el nmero de
  artculos sobre el tema que se envan a comp.os.linux.hardware...
  ______________________________________________________________________

  ndice general


  1. Introduccin
     1.1 Por qu el benchmarking es tan importante?
     1.2 Consideraciones no vlidas en la medida del rendimiento

  2. Procedimientos de medida e interpretacin de resultados
     2.1 Entendiendo la eleccin de la herramienta
        2.1.1 Las herramientas de medida sintticas vs. las de aplicaciones
        2.1.2 Tests de alto nivel vs. test de bajo nivel
     2.2 Tests estndares disponibles para Linux
     2.3 Enlaces y referencias

  3. El Linux Benchmarking Toolkit (LBT)
     3.1 Bases lgicas
     3.2 Seleccin de herramientas
     3.3 Duracin de las pruebas
     3.4 Comentarios
        3.4.1 Compilacin del Ncleo 2.0.0:
        3.4.2 Whetstone:
        3.4.3 Xbench-0.2:
        3.4.4 UnixBench versin 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 Informacin incompleta
     5.3 Software/hardware Propietario
     5.4 Relevancia

  6. FAQ (Preguntas Frecuentes)
  7. Copyright, reconocimientos y miscelnea
     7.1 Cmo se produjo este documento
     7.2 Copyright
     7.3 Nuevas versiones de este documento
     7.4 Realimentacin
     7.5 Agradecimientos
     7.6 Pliego de descargo
     7.7 Marcas registradas


  ______________________________________________________________________



  11..  IInnttrroodduucccciinn


  _"_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 mmeeddiirr la velocidad con la que un ordenador
  ejecuta una tarea, de forma que se puedan realizar comparaciones entre
  diferentes combinaciones de programas/componentes. Esta definicin nnoo
  tiene en cuenta la sencillez de utilizacin, esttica o ergonoma 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 estn sujetos a interpretacin (puede que hoy en
  da sta sea la parte ms 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.


  11..11..  PPoorr qquu eell bbeenncchhmmaarrkkiinngg  eess ttaann iimmppoorrttaannttee??


  Aparte de las razones apuntadas en el BogoMips Mini-CMO (seccin 8,
  prrafo 2), podemos tener que ceirnos a un presupuesto o satisfacer
  unas necesidades de rendimiento mientras instalamos un sistema Linux.
  En otras palabras, cuando tenemos que hacernos las siguientes
  preguntas:

    Cmo puedo maximizar el rendimiento con un presupuesto dado?

    Cmo puedo minizar costes manteniendo un nivel mnimo en el
     rendimiento?

    Cmo puedo obtener la mejor relacin 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 mquina con partes desfasadas (aquel viejo 386SX-16 que est
  tirado en el garaje podra 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 situacin
  muy realista (a menos que quiera poner un Cray en su casa - la unidad
  de alimentacin 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 estpida prdida
  de tiempo y dinero; solo tiene sentido como una parte de un proceso,
  esto es, si tiene que hacer una eleccin entre dos o ms alternativas.

  Normalmente otro parmetro a tener en cuenta en el proceso de decisin
  es el ccoossttee, pero tambin la disponibilidad, el servicio, la
  seguridad, estrategia o cualquier otra caracterstica medible y
  racional que tenga que ver con un ordenador. Por ejemplo, cuando
  comparamos el rendimiento de diferentes versiones del ncleo de Linux,
  la eessttaabbiilliiddaadd suele ser ms importante que la velocidad.


  11..22..  CCoonnssiiddeerraacciioonneess nnoo vvlliiddaass eenn llaa mmeeddiiddaa ddeell rreennddiimmiieennttoo


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

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

  3. Parmetros irracionales (por ejemplo, supersticiones o prejuicios:
     Comprara 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'' - Quin ser el
     prximo?). EMMO (-- N.T.: En Mi Modesta Opinin--) , los billones
     de pesetas gastados en campaas de este tipo estaran mejor
     empleados en equipos de investigacin que se ocupen de desarrollar
     nuevos procesadores libres de fallos, ms rpidos y ms baratos
     :-). Ningn 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 rediseado
     s puede hacerlo.

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


  22..  PPrroocceeddiimmiieennttooss ddee mmeeddiiddaa ee iinntteerrpprreettaacciinn ddee rreessuullttaaddooss


  Unas cuantas recomendaciones semiobvias:

  1. Primera y principal, iiddeennttiiffiiqquuee eell rreennddiimmiieennttoo oobbjjeettiivvoo. Qu es
     exactamente lo que trata de medir? De qu forma la medida del
     rendimiento le ayudar despus a tomar una decisin? Cunto tiempo
     y cuntos recursos est dispuesto a gastar en el proceso de medida?

  2. UUttiilliiccee hheerrrraammiieennttaass eessttnnddaarr. Use una versin del ncleo estable y
     actualizada, as como un gcc, libc, y una herramienta de medida del
     rendimiento actualizados y estndares. Abreviando, utilice el LBT
     (ver ms adelante).

  3. D una ddeessccrriippcciinn ccoommpplleettaa de su configuracin (vea el artculo
     LBT ms adelante).

  4. Trate de aaiissllaarr uunnaa vvaarriiaabbllee. Las medidas comparativas dan ms
     informacin que las ``absolutas''. YYaa nnoo ppuueeddoo iinnssiissttiirr mmss eenn eessttee
     ppuunnttoo.

  5. VVeerriiffiiqquuee ssuuss rreessuullttaaddooss. Ejecute sus pruebas unas cuantas veces y
     compruebe las fluctuaciones en los resultados, de haberlas. Las
     fluctuaciones inexplicables invalidarn sus resultados.

  6. Si cree que su esfuerzo en la medicin del rendimiento ha producido
     informacin til, ccoommpprrttaallaa con la comunidad Linux de forma bbrreevvee
     y ccoonncciissaa.

  7. Por favor, oollvvddeessee ddee llooss BBooggooMMiippss. Me he prometido que algn da
     implementar un rapidsimo ASIC con el bucle de los BogoMips
     enganchado en l. Entonces veremos lo que tengamos que ver!


  22..11..  EEnntteennddiieennddoo llaa eelleecccciinn ddee llaa hheerrrraammiieennttaa



  22..11..11..  LLaass hheerrrraammiieennttaass ddee mmeeddiiddaa ssiinnttttiiccaass vvss.. llaass ddee aapplliiccaacciioonneess


  Antes de perder el tiempo escogiendo entre todos los tipos de
  herramientas de medida, se debe hacer una eleccin bsica entre las
  herramientas ``sintticas'' y las de ``aplicacin''.

  Las herramientas sintticas estn especialmente diseadas para medir
  el rendimiento de un componente individual de un ordenador,
  normalmente llevando el componente escogido a su mxima capacidad. Un
  ejemplo de una herramienta sinttica muy conocida es el WWhheettssttoonnee,
  programado originalmente en 1972 por Harold Curnow en FORTRAN (o fue
  en ALGOL?) y todava ampliamente utilizada. El conjunto de
  herramientas Whetstone medir el rendimiento de la unidad de punto
  flotante de la CPU.

  La crtica principal que puede hacrsele a las medidas ``sintticas''
  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 pequeo y podra caber fcilmente 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
  mxima velocidad. No podemos criticar las herramientas Whetstone por
  esto, ya que hemos de tener presente que fueron programadas hace 25
  aos (y diseadas 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 sintticos es que,
  idealmente, deberan darnos informacin acerca de un aspecto
  eessppeeccffiiccoo del sistema que estamos comprobando, independientemente del
  resto de componentes: un test sinttico sobre la E/S de las tarjetas
  Ethernet debera 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 combinacin
  CPU/placa base/Bus/tarjeta Ethernet/Subsistema de memoria/DMA: no es
  muy til, ya que la variacin en el procesador podra causar un
  impacto mayor en los resultados que la variacin en la tarjeta de red
  Ethernet (naturalmente, sto es suponiendo que estamos utilizando la
  misma combinacin de controlador/ncleo, que tambin pueden producir
  grandes cambios).

  Para terminar, un error muy comn es hacer la media de varios tests
  sintticos y decir que esta media es una buena representacin 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 diseados para utilizar matemticas en
       coma flotante: suelen ser programas de CAD, hojas de
       clculo, juegos 3D y diseo de aplicaciones. Sin embargo,
       hoy en da las aplicaciones ms 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 disear 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 ms comunes y utilizarlas para medir el rendimiento del
  sistema completo. Por ejemplo, SSPPEECC, la organizacin 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, sera muy raro que alguna herramienta
  comercial de medida del rendimiento incluya cdigo Linux.

  Resumiendo, los tests sintticos son vlidos mientras comprenda sus
  propsitos y limitaciones. Las herramientas basadas en aplicaciones
  reflejarn mejor el rendimiento global del sistema, pero no hay
  ninguna disponible para Linux.


  22..11..22..  TTeessttss ddee aallttoo nniivveell vvss.. tteesstt ddee bbaajjoo nniivveell


  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 caractersticas de
  cada componente encontrado (normalmente disponibles en la red).

  Otro uso de los tests de bajo nivel es comprobar que un controlador de
  ncleo ha sido correctamente instalado para un componente especfico:
  si tiene la hoja de especificaciones del componente, puede comparar
  los resultados del test de bajo nivel con las especificaciones
  tericas (las impresas).

  Los tests de alto nivel estn ms enfocados a medir el rendimiento de
  la combinacin componente/controlador/SO de un aspecto especfico del
  sistema, como por ejemplo el rendimiento de E/S con ficheros, o el
  rendimiento de una determinada combinacin de
  componentes/controlador/SO/aplicacin, p.e. un test Apache en
  diferentes sistemas.

  Por supuesto, todos los tests de bajo nivel son sintticos. Los tests
  de alto nivel pueden ser sintticos o de aplicacin.


  22..22..  TTeessttss eessttnnddaarreess ddiissppoonniibblleess ppaarraa LLiinnuuxx


  EMMO un test sencillo que cualquiera puede hacer cuando actualiza
  cualquier componentes en su Linux es hacer una compilacin del ncleo
  antes y despus de la actualizacin del componente o del programa y
  comparar los tiempos de compilacin. Si todas las dems combinaciones
  se mantienen igual, entonces el test es vlido como medida del
  rendimiento en la compilacin, y uno ya puede decir que:

       "Cambiar de A a B lleva a una mejora de un x % en el tiempo
       de compilacin del ncleo de Linux bajo estas y estas condi
       ciones".


  Ni ms, ni menos!

  Ya que la compilacin del ncleo 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 iinnddiivviidduuaall 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
  configuracin 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 ncleo estndar - ver ms adelante).

  Desgraciadamente, no hay herramientas de medida del rendimiento
  especficas para Linux, exceptuando el Byte Linux Benchmarks, que son
  una versin modificada del The Byte Unix Benchmarks que data de Mayo
  de 1991 (los mdulos de Linux se deben a Jon Tombs, autores originales
  Ben Smith, Rick Grehan y Tom Yager).

  Hay una pgina central http://www.silkroad.com/bass/linux/bm.html para
  el Byte Linux Benchmarks.

  David C. Niemi puso por ah una versin del Byte Unix Benchmarks
  mejorada y actualizada. Para evitar confusiones con alguna versin
  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 discusin 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 pgina Web
  http://wauug.erols.com/bench sobre los test de rendimiento en Linux.

  Tambin 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 tambin ha creado una pgina Web
  http://math.vanderbilt.edu:80/~mayer/linux/bmark.html con una base de
  datos de los resultados de las pruebas de su versin del Linux
  BYTEmark benchmarks.

  Si busca pruebas sintticas para Linux, en sunsite.unc.edu podr
  encontrar unas cuantas. Para comprobar la velocidad relativa de los
  servidores X y de las tarjetas grficas, 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 pgina
  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.


  22..33..  EEnnllaacceess yy rreeffeerreenncciiaass


  El comp.benchmarks.faq creado por Dave Sill es la referencia estndar
  en las pruebas de rendimiento. No es especfico 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 pginas Web y muestra 5566 pprruueebbaass ddiiffeerreenntteess, con enlaces a
  direcciones FTP o pginas 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
  gustara 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 lliibbrreess de medida del rendimiento
  (ftp://ftp.nosc.mil/pub/aburto).  Las herramientas Whetstone
  utilizadas en el LBT se encontraron aqu.


  Tambin tenemos el FFAAQQ mmuullttiippaarrttee ddee EEuuggeennee MMiiyyaa que deja regularmente
  en comp.benchmarks; es una referencia excelente.


  33..  EEll LLiinnuuxx BBeenncchhmmaarrkkiinngg TToooollkkiitt ((LLBBTT))


  Quiero proponer un conjunto bsico de herramientas de medida para
  Linux. Es slo una versin preliminar de un general Linux Benchmarking
  Toolkit, que ser expandido y mejorado. Tmelo como lo que es, esto
  es, como una propuesta. Si no cree que es un conjunto de herramientas
  vlido, sientase libre de enviarme un correo electrnico con sus
  crticas y estar encantado de hacer los cambios y mejoras, si puedo.
  Sin embargo, antes de tomar una decisin, lea este CMO y las
  referencias mencionadas: las crticas informadas sern bienvenidas,
  las crticas sin fundamento no.


  33..11..  BBaasseess llggiiccaass


  sto es slo de sentido comn:


  1. No debe llevar un da el ejecutarlo. Cuando hay que hacer tests
     comparativos (varias ejecuciones), no hay nadie que est dispuesto
     a pasar das tratando de averiguar la mejor configuracin de un
     sistema. Idealmente, el conjunto completo de pruebas debe llevar
     unos 15 minutos en una mquina media.

  2. Todo el cdigo fuente de los programas de estar libremente
     disponible en la Red, por razones obvias.

  3. Los tests deben proporcionar una representacin sencilla de los
     resultados que refleje el rendimiento medido.

  4. Debe haber una mezcla de tests sintticos y de tests de aplicacin
     (con resultados separados, por supuesto).

  5. Cada test ssiinnttttiiccoo debe ejercitar un subsistema particular hasta
     su mxima capacidad.

  6. Los resultados de los tests ssiinnttttiiccooss NNOO deben mezclarse en un
     slo resultado general (sto acaba con la toda la idea que hay
     detrs de los tests sintticos, con una considerable prdida de
     informacin).

  7. Los tests de aplicacin deben consistir en tareas usualmente
     ejecutadas en los sistemas Linux.


  33..22..  SSeelleecccciinn ddee hheerrrraammiieennttaass


  He seleccionado cinco conjuntos de herramientas, tratando de evitar,
  en la medida de lo posible, el solapamiento de pruebas. Son stas:


  1. Compilacin del Ncleo 2.0.0 (con la configuracin por defecto)
     utilizando gcc.

  2. La versin 10/03/97 de Whetstone (la ltima que ha sacado Roy
     Longbottom).

  3. xbench-0.2 (con los parmetros de ejecucin rpida).

  4. La versin 4.01 de UnixBench (resultados parciales).

  5. La distribucin 2 de la versin beta de los test BYTEmark de la
     revista BYTE Magazine (resultados parciales).

  Para las pruebas 4 y 5, ``(resultados parciales)'' significa que no se
  tendrn en cuenta todos los resultados producidos por estos tests.


  33..33..  DDuurraacciinn ddee llaass pprruueebbaass



  1. Compilacin del Ncleo 2.0.0: 5 - 30 minutos, dependiendo del
     rendimiento rreeaall de su sistema.

  2. Whetstone: 100 segundos.

  3. Xbench-0.2: < 1 hora.

  4. Versin 4.01 de los tests UnixBench: aprox. 15 minutos.

  5. Los tests BYTEmark de BYTE Magazine: aprox. 10 minutos.


  33..44..  CCoommeennttaarriiooss


  33..44..11..  CCoommppiillaacciinn ddeell NNcclleeoo 22..00..00::



    QQuu:: es el nico test de aplicacin que hay en el LBT.

    El cdigo est ampliamente difundido (finalmente he encontrado
     alguna utilidad a mis viejos CD-ROMs con Linux).

    Muchos linuxeros recompilan el ncleo a menudo, por lo que es un
     medida significativa del rendimiento global del sistema.

    El ncleo 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 cdigo de la
     versin 2.0.0 del ncleo, compilarlo con las opciones por defecto
     (make config, pulsar Intro repetidamente). El tiempo a informar
     debera ser el que se inverte en la compilacin; esto es, despus
     de que escribe make zImage, ssiinn incluir make dep, make clean. Tenga
     en cuenta que la arquitectura objetivo por defecto del ncleo es
     i386, de manera que si compila en otras arquitecturas, debera
     configurar tambin gcc para hacer una compilacin cruzada, teniendo
     i386 como arquitectura objetivo.

    RReessuullttaaddooss:: tiempo de compilacin en minutos y segundos (por favor,
     no indique las fracciones de segundo).


  33..44..22..  WWhheettssttoonnee::


    QQuu:: mide el rendimiento de punto flotante puro con un bucle corto.
     El fuente (en C) es muy legible y es fcil de ver qu operaciones
     en punto flotante intervienen.

    Es la prueba ms corta del LBT :-).

    Es una prueba "Clsica": hay disponibles cifras comparativas, sus
     defectos y deficiencias son bien conocidos.

    Procedimiento para realizar la prueba: se debera obtener el cdigo
     en C ms reciente del sitio de Aburto. Compile y ejecute en modo de
     doble precisin. Especifique gcc y -O2 como opciones de
     precompilador y compilador, y defina POSIX 1 para especificar el
     tipo de mquina.

    RReessuullttaaddooss:: una cifra del rendimiento de punto flotante en MWIPS.

  33..44..33..  XXbbeenncchh--00..22::


    QQuu:: mide el rendimiento del servidor X.

    La medida xStones proporcionada por xbench es una media ponderada
     de varias pruebas referidas a una vieja estacin 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 ejecucin ms
     rpida:./xbench -timegoal 3 > results/name_of_your_linux_box.out.
     Para obtener la calificacin xStones, debemos ejecutar un guin
     (script) en awk; la manera ms rpida es escribir make summary.ms.
     Compruebe el fichero summary.ms: la calificacin xStone de su
     sistema est en la ltima columna del rengln que tiene el nombre
     de su mquina que especific durante la prueba.

    RReessuullttaaddooss:: una figure del rendimiento de X en xStones.

    Nota: esta prueba, tal como est, es obsoleta. Debera ser
     reescrita.

  33..44..44..  UUnniixxBBeenncchh vveerrssiinn 44..0011::


    QQuu:: mide el rendimiento global de Unix. Esta prueba ejercitar el
     rendimiento de E/S de ficheros y multitarea del ncleo.

    He descartado los resultados de todas las pruebas aritmticas,
     quedndome slo 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
     geomtrica de los ndices EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE
     THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL
     SCRIPTS y SYSTEM CALL OVERHEAD.

    RReessuullttaaddooss:: un ndice del sistema.

  33..44..55..  BBaannccoo ddee pprruueebbaass BBYYTTEEmmaarrkk ddee BBYYTTEE MMaaggaazziinnee BBYYTTEEmmaarrkk::


    QQuu:: proporciona una buena medida del rendimiento de la CPU. Aqu
     hay un extracto de la documentacin: _"_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 ms
     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 geomtrica de los ndices de las
     pruebas STRING SORT, ASSIGNMENT y BITFIELD; ste es el nnddiiccee ddee llaa
     mmeemmoorriiaa; calcule la media geomtrica de los ndices de las pruebas
     NUMERIC SORT, IDEA, HUFFMAN y FP EMULATION; ste es el nnddiiccee ddee
     eenntteerrooss.

    RReessuullttaaddooss:: un ndice de memoria y un ndice de enteros calculado
     tal como se explica anteriormente.

  33..55..  PPoossiibblleess mmeejjoorraass


  El conjunto ideal de pruebas debera ejecutarse en pocos minutos, con
  pruebas sintticas que examinen cada subsistema por separado y pruebas
  de aplicacin que den resultados para diferentes aplicaciones. Tambin
  debera generar de forma automtica un informe completo y quiz
  enviarlo por correo a la base de datos central en la Web.

  No estamos interesados en la portabilidad, pero debera al menos poder
  ser ejecutado en cualquier versin 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, fcil y fiable, con una prueba corta (menos de 30
  minutos en configuracin y ejecucin), por favor, pngase en contacto
  conmigo.


  33..66..  EEll ffoorrmmuullaarriioo ddee iinnffoorrmmee LLBBTT

  Aparte de las pruebas, el procedimiento de 'benchmarking' no estara
  completo sin un formulario describiendo la configuracin, de manera
  que aqu est (siguiendo la gua 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 interpretacin de los resultados,
  y como tal, es opcional. Podra ser la parte ms significativa del
  informe, sin embargo, especialmente si est haciendo pruebas comparativas.
  ______________________________________________________________________



  33..77..  PPrruueebbaass ddeell rreennddiimmiieennttoo ddee llaa rreedd

  Probar el rendimiento de una red es un reto, ya que implica al menos
  tener dos mquinas, un servidor y un cliente, y por lo tanto el doble
  de tiempo para configurar, ms variables a controlar, etc... En una
  red ethernet, pienso que su mejor apuesta sera el paquete ttcp. (por
  expandir)


  33..88..  PPrruueebbaass SSMMPP


  Las pruebas SMP son otro reto, y cualquier banco de pruebas diseado
  especficamente para probar SMP tendr dificultades probndose a s
  misma en configuraciones de la vida real, ya que los algoritmos que
  pueden tomar ventaja de SMP son difciles de realizar. Parece que las
  ltimas versiones del ncleo de Linux (> 2.1.30 o por ah) harn
  multiproceso "muy granulado" (_f_i_n_e_-_g_r_a_i_n_e_d), pero no tengo ms
  informacin al respecto ahora mismo.

  Segn 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_._"



  44..  PPrruueebbaa ddee eejjeemmpplloo yy rreessuullttaaddooss


  Ejecut el LBT en la mquina 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 homogneo, 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!



  55..  FFaallsseeddaaddeess yy ffaallllooss ddeell bbeenncchhmmaarrkkiinngg


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


  55..11..  CCoommppaarraarr mmaannzzaannaass ccoonn nnaarraannjjaass



  O debera decir Apples (-- N. del T.: Apple = manzana, pero tambin
  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 ms posible
  comprar mquinas idnticas con una sola modificacin.

  55..22..  IInnffoorrmmaacciinn iinnccoommpplleettaa


  Un solo ejemplo ilustrar este fallo comn. 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 ncleo de linux me
  lleva slo i minutos" (ajustar XYZ, nnn e i a lo que se requiera). Es
  irritante, porque no se da ms informacin, esto es, no sabemos
  siquiera la cantidad de RAM, tamao del fichero de intercambio, otras
  tareas que se ejecutan simultneamente, versin del ncleo, mdulos
  seleccionados, tipo de disco duro, versin del gcc, etc... Le
  recomiendo que use el Formulario de Informe LBT, que al menos
  proporciona un marco de informacin estndar.


  55..33..  SSooffttwwaarree//hhaarrddwwaarree PPrrooppiieettaarriioo

  Un conocido fabricante de procesadores public una vez los resultados
  de unas pruebas producidas por una versin especial, adaptada, de gcc.
  Aparte las consideraciones ticas, estos resultados no tenan sentido,
  ya que el 100% seguira usando la versin estndar de gcc. Lo mismo va
  para el hardware propietario. El benchmarking es mucho ms til cuando
  trata con hardware off-the-shelf y sofware libre.

  55..44..  RReelleevvaanncciiaa

  Estamos hablando de Linux, no? De manera que deberamos olvidarnos de
  pruebas producidas en otros sistemoas operativos (este es un caso
  especial del "Comparando manzanas y naranjas" que vimos
  anteriormente). Adems, si vamos a hacer pruebas del rendimiento de un
  servidor Web, nnoo debemos resaltar el rendimiento de la FPU ni otra
  informacin irrelevante.  En tales casos, menos es ms. TTaammppooccoo
  necesitamos mencionar la edad de nuestro gato, el humor del que
  estbamos mientras hacamos la prueba, etc...

  66..  FFAAQQ ((PPrreegguunnttaass FFrreeccuueenntteess))


     PP11..
        Hay alguna medida aislada del mrito de los sistemas Linux?

     RR:: No, gracias al cielo nadie ha salido todava con una medida
        Lhinuxstone (tm). Y si hubiera una, no tendra mucho sentido:
        los sistemas Linux se usan para diversas tareas, desde
        servidores Web muy cargados hasta estaciones grficas para uso
        individual. Ninguna medida de mrito por separado puede
        describir el rendimiento de un sistema Linux bajo tales
        situaciones diferentes.

     PP22..
        Entonces, qu tal una docena de cifras resumiendo el
        rendimiento de diversos sistemas Linux?

     RR:: Esa sera la situacin ideal. Me gustara ver que se hace
        realidad. Voluntarios para un LLiinnuuxx BBeenncchhmmaarrkkiinngg PPrroojjeecctt? Con
        un sitio web y una base de datos en lnea, completa y con
        informes bien diseados?

     PP33..
        ... BogoMips...?

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

     PP44..
        Cu es el 'mejor' banco de pruebas para Linux?

     RR:: 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, grficos, 3D, ancho
        de banda procesador-memoria, rendimiento CAD, tiempo de
        transaccin, 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 ningn conjunto de
        pruebas para Linux que realice todas estas pruebas.

     PP55..
        Cul es el procesador ms rpido sobre el que corre Linux?

     RR:: Ms rpido en qu tarea? Si estamos orientados a un gran
        procesamiento de nmeros, un Alpha de gran velocidad de reloj
        (600MHz y superior) debera ser ms rpido que ninguna otra
        cosa, ya que los Alpha se han diseado para ese tipo de
        rendimiento. Si, por otro lado, uno quiere poner un servidor de
        news muy rpido, es probable que la eleccin de un subsistema de
        disco duro muy rpido y muchsima RAM de un rendimiento mucho
        ms alto que un cambio de procesador, por la misma cantidad de
        $.

     PP66..
        Permtame rehacer la pregunta anterior, entonces: hay algn
        procesador que sea ms rpido para aplicaciones de propsito
        general?

     RR:: Esa es una difcil con truco, pero tiene una respuesta muy
        sencilla: NNOO. Siempre podremos disear un sistema ms rpido
        incluso para aplicaciones de uso general, independientemente del
        procesador. Normalmente, siendo todos los dems elementos
        iguales, mayores tasas de reloj darn sistemas de mayor
        rendimiento (y tambin ms dolores de cabeza). Sacando un viejo
        Pentium a 100MHz de una (no suele ser as) placa madre
        actualizable, y enchufando la versin a 200MHz, uno debera
        sentir el "umppffff" extra. Por supuesto, con slo 16 MBytes de
        RAM, se podra haber hecho la misma inversin, ms sabiamente,
        en unos SIMM extra...

     PP77..
        De manera que la velocidad de reloj influye en el rendimiento
        del sistema?

     RR:: Para la mayora de las tareas excepto los bucles NOP vacos (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 pequeos e
        intensivos que quepan enteros en la cach primaria del
        procesador (la cach L1, normalmente de 8 o 16K), obtendrn un
        aumento de rendimiento equivalente al de la velocidad de reloj,
        pero la mayora de los programas "reales" son mucho ms 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 obtendrn 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 mayora de las cach L2
        y el resto de los subsistemas (DRAM, por ejemplo, funcionan de
        forma asncrona a menores velocidades.

     PP88..
        Bien, entonces, una ltima pregunta sobre el asunto: cual es el
        procesador que proporciona una mejor tasa precio/rendimiento
        para usos de propsito general de Linux?

     RR:: Definir "uso de propsito general de Linux no es fcil! Para
        cualquier aplicacin 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
        ejecutndose a n MHz sera una respuesta vlida slo
        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 cuestin debera ser cmo
        podemos maximizar la tasa precio/rendimiento de un sistema dado?
        Y la respuesta a esa cuestin depende muchsimo de los
        requerimientos mnimos de rendimiento y en el coste
        mnimo/mximo establecido para la configuracin que estamos
        considerando. Algunas veces, el hardware que podemos comprar en
        las tiendas no nos dar el rendimiento mnimo necesario, y la
        nica alternativa sern costosos sistemas RISC. Para algunos
        usos, recomiendo un sistema equilibrado y homogneo :-); la
        eleccin de un procesador es una decisin importante, pero no
        ms que elegir el tipo y capacidad del disco duro, la cantidad
        de RAM, la tarjeta de vdeo, etc...

     PP99..
        Qu es un incremento "significativo" de rendimiento?

     RR:: Yo dira que cualquier cosa por debajo de 1% no es significativo
        (podra ser descrito como "marginal"). Nosotros, los humanos,
        difcilmente distinguiremos la diferencia entre dos sistemas con
        una diferencia en tiempo de respuesta del 5%. Por supuesto,
        algunos de los ms duros realizadores de pruebas no son humanos,
        y le dirn que, comparando dos sistemas con ndices de 65'9 y
        66'5, este ltimo es "definitivamente ms rpido".

     PP1100..
        Cmo obtengo incrementos "significativos" en renadimiento al
        menor coste?

     RR:: Como la mayora del cdigo fuente para Linux est disponible, un
        examen atento y un rediseo algortmico de las subrutinas clave
        podran 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 cdigo C,
        ppooddrraammooss llllaammaarr aa uunn ccoonnssuullttoorr ddee LLiinnuuxx. Lea el Consultants-
        HOWTO.


  77..  CCooppyyrriigghhtt,, rreeccoonnoocciimmiieennttooss yy mmiisscceellnneeaa


  77..11..  CCmmoo ssee pprroodduujjoo eessttee ddooccuummeennttoo


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

  No saba absolutamente nada sobre SGML o LaTeX, pero estuve tentado de
  usar un paquete de generacin automtica de documentacin tras leer
  varios comentarios sobre las SGML-Tools. Sin embargo, insertar
  etiquetas manualmente en un documento me recuerda los das 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 combinacin:
  LLyyXX yy SSGGMMLL--TToooollss.

  77..22..  CCooppyyrriigghhtt


  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 fsico o electrnico,
  siempre que se mantenga esta noticia de copyright en todas las copias.
  Se permite y anima a la distribucin comercial; sin embargo, el autor
  quera que se le avisase de tales distribuciones.

  Todas las traducciones, trabajos derivados, o trabajos agregados que
  incorporen cualquier documento HOWTO de Linux debern estar cubiertos
  por este copyright. Esto es, no puede procudir un trabajo derivado de
  un HOWTO e imponer restricciones adicionales sobre su distribucin. Se
  podran permitir excepciones a estas restricciones bajo ciertas
  condiciones; por favor, pngase en contacto con el coordinador del
  Linux HOWTO en la direccin que damos ms adelante.

  En resumen, nos gustara promover la diseminacin de esta informacin
  a travs de cuantos ms canales sea posible. Sin embargo, queramos
  retener el copyright de los documentos HOWTO, y nos gustara que nos
  avisase de cualquier plan para redistribuir los HOWTO.

  Si tiene preguntas, dirjase por favor a Greg Hankins, el coordinador
  de Linux HOWTO en gregh@sunsite.unc.edu mediante correo electrnico o
  llamando al +1 404 853 9989.


  77..33..  NNuueevvaass vveerrssiioonneess ddee eessttee ddooccuummeennttoo


  Se pondrn 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 tambin est disponible para clientes WWW
  como Grail, un navegador Web escrito en Python. Tambin ser enviado
  con regularidad en comp.os.linux.answers.

  La versin en castellano de este HOWTO la encontrar en el sitio del
  Insflug http://www.insflug.org


  77..44..  RReeaalliimmeennttaacciinn


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

  Siempre me puede localizar en andrewbalsa@usa.net.

  77..55..  AAggrraaddeecciimmiieennttooss

  David Niemi, el autor del conjunto de aplicaciones Unixbench, ha
  probado ser una fuente infinita de informacin y crticas (vlidas).

  Tambin me gustara 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.

  77..66..  PPlliieeggoo ddee ddeessccaarrggoo


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

  77..77..  MMaarrccaass rreeggiissttrraaddaass

  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.



