Linux benchmarking como

´
Linux Benchmarking COMO
por Andr´ D. Balsa, andrewbalsa@usa.net <mailto:andrewbalsa@usa.net>
e
Traducido por: Joaquń Cuenca Abela, jcuenca@patan.eleinf.uv.es
ı v0.12, 15 de Agosto de 1997

´
El Linux Benchmarking COMO trata sobre algunos aspectos asociados con el benchmarking en los
sistemas Linux y presentas unas herramientas (algo toscas) para realizar medidas del rendimiento de
´
su sistema, que podrá proporcionar una cantidad significativa de informacion en un par de horas.
ı
´ ´
Quizas tambien ayude a hacer que disminuya el numero de artćulos sobre el tema que se enván a
´ ı ı
comp.os.linux.hardware...

Contents

1 Introducci´ n
o 2
1.1 ¿Por qu´ el benchmarking es tan importante? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
e 2
1.2 Consideraciones no v´ lidas en la medida del rendimiento . . . . . . . . . . . . . . . . . . . . . . . .
a 3

2 Procedimientos de medida e interpretaci´ n de resultados
o 3
2.1 Entendiendo la elecci´ n de la herramienta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 4
2.1.1 Las herramientas de medida sint´ ticas vs. las de aplicaciones . . . . . . . . . . . . . . . . . .
e 4
2.1.2 Tests de alto nivel vs. test de bajo nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Tests est´ ndares disponibles para Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a 5
2.3 Enlaces y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

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

4 Prueba de ejemplo y resultados 12

1. Introducci´ n
o 2

5 Falsedades y fallos del benchmarking 15
5.1 Comparar manzanas con naranjas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Informaci´ n incompleta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 15
5.3 Software/hardware Propietario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 Relevancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 FAQ (Preguntas Frecuentes) 15

7 Copyright, reconocimientos y miscel´ nea
a 18
7.1 C´ mo se produjo este documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 18
7.2 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3 Nuevas versiones de este documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.4 Realimentaci´ n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 18
7.5 Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.6 Pliego de descargo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.7 Marcas registradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1 Introducci´ n
o

”Lo que no podemos decir acerca de nosotros mismos deberá desaparecer en el silencio.”
ı

Ludwig Wittgenstein (1889-1951), fil´ sofo austráco
o ı

Benchmarking significa medir la velocidad con la que un ordenador ejecuta una tarea, de forma que se puedan realizar
comparaciones entre diferentes combinaciones de programas/componentes. Esta definici´ n no tiene en cuenta la
o
sencillez de utilizaci´ n, est´ tica o ergonomá o cualquier otro tipo de juicio subjetivo.
o e ı
El Benchmarking es una tarea repetitiva, tediosa, y hay que llevar cuidado con los detalles. Es muy normal que los
e o ı ´
resultados no sean los que uno espera y que est´ n sujetos a interpretaci´ n (puede que hoy en dá esta sea la parte m´ s
a
importante).
Para finalizar, el benchmarking trata con hechos y datos, no con opiniones ni aproximaciones.

1.1 ¿Por qu´ el benchmarking es tan importante?
e
´
Aparte de las razones apuntadas en el BogoMips Mini-COMO (secci´ n 8, p´ rrafo 2), podemos tener que ce˜ irnos a
o a n
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?
o

• ¿C´ mo puedo minizar costes manteniendo un nivel mńimo en el rendimiento?
o ı

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

2. Procedimientos de medida e interpretaci´ n de resultados
o 3

Tendremos que examinar, comparar o crear benchmarks. Minimizar costes sin tener que mantener un rendimiento en
particular implica utilizar una m´ quina con partes desfasadas (aquel viejo 386SX-16 que est´ tirado en el garaje podrá
a a ı
servir) y no necesita bechmarks, y maximizar el rendimiento sin que importe el dinero no es una situaci´ n muy realista
o
(a menos que quiera poner un Cray en su casa - la unidad de alimentaci´ n recubierta con cuero es bonita, ¿verdad?).
o
El benchmarking de por si no tiene sentido, y es una est´ pida p´ rdida de tiempo y dinero; solo tiene sentido como una
u e
parte de un proceso, esto es, si tiene que hacer una elecci´ n entre dos o m´ s alternativas.
o a
Normalmente otro par´ metro a tener en cuenta en el proceso de decisi´ n es el coste, pero tambi´ n la disponibilidad, el
a o e
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 estabilidad suele ser
u
m´ s importante que la velocidad.
a

1.2 Consideraciones no v´ lidas en la medida del rendimiento
a

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).
o

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

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

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

´
5. Cantidad de propaganda: creo que este 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?). EMMO1 ,
e a o
los billones de pesetas gastados en campa˜ as de este tipo estarán mejor empleados en equipos de investigaci´ n
n ı o
que se ocupen de desarrollar nuevos procesadores libres de fallos, m´ s r´ pidos y m´ s baratos :-). Ning´ n tipo de
a a a u
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.
n ı

6. La opiniones del tipo “tiene lo que paga” son s´ lo eso: opiniones. Denme hechos, por favor.
o

2 Procedimientos de medida e interpretaci´ n de resultados
o

Unas cuantas recomendaciones semiobvias:

1. Primera y principal, identifique el rendimiento objetivo. ¿Qu´ es exactamente lo que trata de medir? ¿De qu´
e e
forma la medida del rendimiento le ayudar´ despu´ s a tomar una decisi´ n? ¿Cu´ nto tiempo y cu´ ntos recursos
a e o a a
est´ dispuesto a gastar en el proceso de medida?
a

2. Utilice herramientas est´ ndar. Use una versi´ n del n´ cleo estable y actualizada, as´ como un gcc, libc, y
a o u ı
una herramienta de medida del rendimiento actualizados y est´ ndares. Abreviando, utilice el LBT (ver m´ s
a a
adelante).

3. D´ una descripci´ n completa de su configuraci´ n (vea el artćulo LBT m´ s adelante).
e o o ı a

4. Trate de aislar una variable. Las medidas comparativas dan m´ s informaci´ n que las “absolutas”. Ya no puedo
a o
insistir m´ s en este punto.
a
1
N.T.: En Mi Modesta Opini´ n
o

o 4

5. Verifique sus resultados. Ejecute sus pruebas unas cuantas veces y compruebe las fluctuaciones en los resulta-
dos, de haberlas. Las fluctuaciones inexplicables invalidar´ n sus resultados.
a

o o ´
6. Si cree que su esfuerzo en la medici´ n del rendimiento ha producido informaci´ n util, comp´ rtala con la
a
comunidad Linux de forma breve y concisa.

7. Por favor, olv´dese de los BogoMips. Me he prometido que alg´ n dá implementar´ un rapid´simo ASIC con el
ı u ı e ı
´
bucle de los BogoMips enganchado en el. ¡Entonces veremos lo que tengamos que ver!

2.1 Entendiendo la elecci´ n de la herramienta
o

2.1.1 Las herramientas de medida sint´ ticas vs. las de aplicaciones
e

Antes de perder el tiempo escogiendo entre todos los tipos de herramientas de medida, se debe hacer una elecci´ n
o
b´ sica entre las herramientas “sint´ ticas” y las de “aplicaci´ n”.
a e o
Las herramientas sint´ ticas est´ n especialmente dise˜ adas para medir el rendimiento de un componente individual de
e a n
un ordenador, normalmente llevando el componente escogido a su m´ xima capacidad. Un ejemplo de una herramienta
a
sint´ tica muy conocida es el Whetstone, programado originalmente en 1972 por Harold Curnow en FORTRAN (¿o
e
fue en ALGOL?) y todavá ampliamente utilizada. El conjunto de herramientas Whetstone medir´ el rendimiento de
ı a
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
ı e e
en las situaciones de la vida real. Tomemos por ejemplo las herramientas Whetstone: el blucle principal es muy
peque˜ o y podrá caber f´ cilmente en la cach´ primaria de la CPU, manteniendo el bus de la unidad de punto flotante
n ı a e
(FPU) constantemente lleno y ejercitando, por tanto, la FPU a su m´ xima velocidad. No podemos criticar las her-
a
ramientas Whetstone por esto, ya que hemos de tener presente que fueron programadas hace 25 a˜ os (¡y dise˜ adas
n n
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án darnos informaci´ n acerca de
e ı o
un aspecto espec´fico del sistema que estamos comprobando, independientemente del resto de componentes: un test
ı
sint´ tico sobre la E/S de las tarjetas Ethernet deberá devolver el mismo resultado (o al menos similar) independien-
e ı
temente 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
a o
´
Ethernet/Subsistema de memoria/DMA: no es muy util, ya que la variaci´ n en el procesador podrá causar un impacto
o ı
´
mayor en los resultados que la variaci´ n en la tarjeta de red Ethernet (naturalmente, esto es suponiendo que estamos
o
utilizando la misma combinaci´ n de controlador/n´ cleo, que tambi´ n pueden producir grandes cambios).
o u e
Para terminar, un error muy com´ n es hacer la media de varios tests sint´ ticos y decir que esta media es una buena
u e
representaci´ n del rendimiento en la vida real de un sistema.
o
Aqu´ tenemos un comentario acerca de los tests FPU, citado con permiso de Cyrix Corp.:
ı

“Una Unidad de Coma Flotante (Floating Point Unit, FPU) acelera los programas dise˜ ados para
n
utilizar matem´ ticas en coma flotante: suelen ser programas de CAD, hojas de c´ lculo, juegos 3D y
a a
dise˜ o de aplicaciones. Sin embargo, hoy en dá las aplicaciones m´ s populares para PC utilizan al
n ı a
mismo tiempo instrucciones en enteros y en coma flotante. Como resultado, Cyrix ha decidido poner
enfasis en el “paralelismo” a la hora de dise˜ ar el procesador 6x86 para acelerar los programas que
´ n
entremezclan estos dos tipos de instrucciones.

El modelo de exclusi´ n de la unidad de coma flotante de los x86 permite la resoluci´ n de instrucciones
o o
con enteros mientras se ejecuta una instrucci´ n en coma flotante. Por contra, no se puede ejecutar
o
una segunda instrucci´ n en coma flotante si ya se estaba ejecutando anteriormente una. Para eliminar
o

o 5

la limitaci´ n en el rendimiento creada por el modelo de exclusi´ n de la unidad de coma flotante, el
o o
procesador 6x86 puede realizar especulativamente hasta cuatro instrucciones en coma flotante al chip
FPU mientras sigue ejecutando instrucciones enteras. Por ejemplo, en una secuencia de c´ digo con dos
o
instrucciones en coma flotante (FLTs) seguidas por seis instrucciones enteras (INTs) y seguidas por dos
FLTs m´ s, el procesador 6x86 puede mandar las diez instrucciones anteriores a las unidades de ejecuci´ n
a o
apropiadas antes de que se termine la primera FLT. Si ninguna de las instrucciones falla (el caso t´pico),
ı
la ejecuci´ n continua con las unidades de enteros y de coma flotante terminando las instrucciones en
o
paralelo. Si una de las FLTs falla (el caso at´pico), la capacidad de ejecuci´ n especulativa del 6x86
ı o
permite que se restaure el estado del procesador de forma que sea compatible con el modelo de exclusi´ n
o
de la unidad de coma flotante del x86.

Un examen de los test de rendimiento revela que los test sint´ ticos de la unidad de coma flotante utiliza
e
un c´ digo con solo operaciones de coma flotante, que no es lo que nos encontramos en las aplicaciones
o
del mundo real. Este tipo de tests no aprovecha la capacidad de ejecuci´ n especulativa presente en
o
el procesador 6x86. Cyrix cree que las pruebas que utilizan herramientas no sint´ ticas, basadas en
e
aplicaciones del mundo real reflejan mejor el rendimiento real que pueden obtener los usuarios. Las
aplicaciones del mundo real contienen instrucciones mezcladas de enteros y de coma flotante y utilizan
por tanto, la capacidad de ejecuci´ n especulativa del 6x86.”
o

Por lo tanto, la tendencia en los tests de rendimiento es elegir las aplicaciones m´ s comunes y utilizarlas para medir el
a
´ n´
rendimiento del sistema completo. Por ejemplo, SPEC, la organizaci´ n sin animo de lucro que dise˜ o las herramientas
o
SPECINT y SPECFP, ha lanzado un proyecto para un nuevo conjunto de herramientas basadas en aplicaciones. Pero
de nuevo, será muy raro que alguna herramienta comercial de medida del rendimiento incluya c´ digo Linux.
ı o
Resumiendo, los tests sint´ ticos son v´ lidos mientras comprenda sus prop´ sitos y limitaciones. Las herramientas
e a o
basadas en aplicaciones reflejar´ n mejor el rendimiento global del sistema, pero no hay ninguna disponible para
a
Linux.

2.1.2 Tests de alto nivel vs. test de bajo nivel

Los tests de bajo nivel miden directamente el rendimiento de los componentes: el reloj de la CPU, los tiempos de
la DRAM y de la cach´ SRAM, tiempo de acceso medio al disco duro, latencia, tiempo de cambio de pista, etc...
e
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
u
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).
o
Los tests de alto nivel est´ n m´ s enfocados a medir el rendimiento de la combinaci´ n componente/controlador/SO
a a o
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.
o o
Por supuesto, todos los tests de bajo nivel son sint´ ticos. Los tests de alto nivel pueden ser sint´ ticos o de aplicaci´ n.
e e o

2.2 Tests est´ ndares disponibles para Linux
a

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
o u e o
de compilaci´ n. Si todas las dem´ s combinaciones se mantienen igual, entonces el test es v´ lido como medida del
o a a
rendimiento en la compilaci´ n, y uno ya puede decir que:
o

o 6

”Cambiar de A a B lleva a una mejora de un x % en el tiempo de compilaci´ n del n´ cleo de Linux
o u
bajo estas y estas condiciones”.

¡Ni m´ s, ni menos!
a
Ya que la compilaci´ n del n´ cleo es una tarea muy normal en Linux, y ya que ejercita muchas de las funciones
o u
que se realizan normalmente en los tests (excepto el rendimiento con las instrucciones en coma flotante), podemos
concluir que es un test individual 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
o
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).
u a a
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
o o
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 Bench-
a
marks.
David C. Niemi puso por ah´ una versi´ n del Byte Unix Benchmarks mejorada y actualizada. Para evitar confusiones
ı o
con alguna versi´ n anterior la llam´ UnixBench 4.01. Aqu´ est´ lo que David escribi´ sobre sus modificaciones:
o o ı a o

“La versi´ n original y las versiones ligeramente modificadas de BYTE Unix Benchmarks se diferen-
o
cian en varias cosas que los hacen ser un indicador inusualmente poco fiable del rendimiento del sistema.
He hecho que los valores de mis “ńdices” parezcan muy diferentes para evitar confusiones con el viejo
ı
test.”

David ha creado una lista de correo majordomo para la discusi´ n sobre las pruebas de rendimiento para Linux y para
o
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
a a
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
e o
´
Bytemark a Linux. Este es un moderno conjunto de herramientas que Rick Grehan envi´ a BYTE Magazine para
o
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
e a
con una base de datos de los resultados de las pruebas de su versi´ n del Linux BYTEmark benchmarks.
o
Si busca pruebas sint´ ticas para Linux, en sunsite.unc.edu podr´ encontrar unas cuantas. Para comprobar la velocidad
e a
relativa de los servidores X y de las tarjetas gr´ ficas, el conjunto de herramientas xbench-0.2 creado por Claus Git-
a
tinger est´ disponible en sunsite.unc.edu, ftp.x.org y otros lugares. Xfree86.org rechaza (prudentemente) el llevar o
a
recomendar ninguna prueba.
El XFree86-benchmarks Survey http://www.goof.com/xbench/ es una p´ gina Web con una base de datos de
a
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.

3. El Linux Benchmarking Toolkit (LBT) 7

2.3 Enlaces y referencias

El comp.benchmarks.faq creado por Dave Sill es la referencia est´ ndar en las pruebas de rendimiento. No es espec´fico
a ı
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 56 pruebas diferentes, con enlaces a
a a
direcciones FTP o p´ ginas Web donde se pueden recoger. Algunas de las pruebas que se mencionan son comerciales
a
(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á comentar:
ı la prueba lmbench
http://reality.sgi.com/lm/lmbench/lmbench.html de Larry McVoy. Citando a David C. Niemi:

“Linus y David Miller la utilizan mucho ya que es capaz de realizar medidas utiles de bajo nivel y
´
tambi´ n puede medir el trasvase y la latencia de la red si tiene dos ordenadores para hacer los tests. Pero
e
no intenta conseguir algo as´ como un “rendimiento del sistema” general...”
ı

Alfred Aburto puso en marcha un lugar FTP bastante completo en cuanto a utilidades libres de medida del rendimiento
(ftp://ftp.nosc.mil/pub/aburto). Las herramientas Whetstone utilizadas en el LBT se encontraron aqu´. ı
Tambi´ n tenemos el FAQ multiparte de Eugene Miya que deja regularmente en comp.benchmarks; es una referencia
e
excelente.

3 El Linux Benchmarking Toolkit (LBT)

Quiero proponer un conjunto b´ sico de herramientas de medida para Linux. Es s´ lo una versi´ n preliminar de un
a o o
general Linux Benchmarking Toolkit, que ser´ expandido y mejorado. T´ melo como lo que es, esto es, como una
a o
propuesta. Si no cree que es un conjunto de herramientas v´ lido, sientase libre de enviarme un correo electr´ nico con
a o
sus cr´ticas y estar´ encantado de hacer los cambios y mejoras, si puedo. Sin embargo, antes de tomar una decisi´ n,
ı e o
´
lea este COMO y las referencias mencionadas: las cr´ticas informadas ser´ n bienvenidas, las cr´ticas sin fundamento
ı a ı
no.

3.1 Bases l´ gicas
o
´
Esto es s´ lo de sentido com´ n:
o u

1. No debe llevar un dá el ejecutarlo. Cuando hay que hacer tests comparativos (varias ejecuciones), no hay
ı
nadie que est´ dispuesto a pasar dás tratando de averiguar la mejor configuraci´ n de un sistema. Idealmente, el
e ı o
conjunto completo de pruebas debe llevar unos 15 minutos en una m´ quina media.
a

2. Todo el c´ digo fuente de los programas de estar libremente disponible en la Red, por razones obvias.
o

3. Los tests deben proporcionar una representaci´ n sencilla de los resultados que refleje el rendimiento medido.
o

4. Debe haber una mezcla de tests sint´ ticos y de tests de aplicaci´ n (con resultados separados, por supuesto).
e o

5. Cada test sint´ tico debe ejercitar un subsistema particular hasta su m´ xima capacidad.
e a

6. Los resultados de los tests sint´ ticos NO deben mezclarse en un s´ lo resultado general (´ sto acaba con la toda
e o e
la idea que hay detr´ s de los tests sint´ ticos, con una considerable p´ rdida de informaci´ n).
a e e o

7. Los tests de aplicaci´ n deben consistir en tareas usualmente ejecutadas en los sistemas Linux.
o


3.2 Selecci´ n de herramientas
o

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

1. Compilaci´ n del N´ cleo 2.0.0 (con la configuraci´ n por defecto) utilizando gcc.
o u o

´
2. La versi´ n 10/03/97 de Whetstone (la ultima que ha sacado Roy Longbottom).
o

3. xbench-0.2 (con los par´ metros de ejecuci´ n r´ pida).
a o a

4. La versi´ n 4.01 de UnixBench (resultados parciales).
o

5. La distribuci´ n 2 de la versi´ n beta de los test BYTEmark de la revista BYTE Magazine (resultados parciales).
o o

Para las pruebas 4 y 5, “(resultados parciales)” significa que no se tendr´ n en cuenta todos los resultados producidos
a
por estos tests.

3.3 Duraci´ n de las pruebas
o

1. Compilaci´ n del N´ cleo 2.0.0: 5 - 30 minutos, dependiendo del rendimiento real de su sistema.
o u

2. Whetstone: 100 segundos.

3. Xbench-0.2: < 1 hora.

4. Versi´ n 4.01 de los tests UnixBench: aprox. 15 minutos.
o

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

3.4 Comentarios

3.4.1 ´
Compilaci´ n del Nucleo 2.0.0:
o

• Qu´ : es el unico test de aplicaci´ n que hay en el LBT.
e ´ o

• El c´ digo est´ ampliamente difundido (finalmente he encontrado alguna utilidad a mis viejos CD-ROMs con
o a
Linux).

• Muchos linuxeros recompilan el n´ cleo a menudo, por lo que es un medida significativa del rendimiento global
u
del sistema.

• El n´ cleo es grande y gcc utiliza una gran cantidad de memoria: se atenua la importancia de la cach´ L2.
u e

• 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
o o u
opciones por defecto (make config, pulsar Intro repetidamente). El tiempo a informar deberá ser el que se
ı
inverte en la compilaci´ n; esto es, despu´ s de que escribe make zImage, sin incluir make dep, make clean.
o e
Tenga en cuenta que la arquitectura objetivo por defecto del n´ cleo es i386, de manera que si compila en
u
otras arquitecturas, deberá configurar tambi´ n gcc para hacer una compilaci´ n cruzada, teniendo i386 como
ı e o
arquitectura objetivo.

• Resultados: tiempo de compilaci´ n en minutos y segundos (por favor, no indique las fracciones de segundo).
o


3.4.2 Whetstone:

• Qu´ : mide el rendimiento de punto flotante puro con un bucle corto. El fuente (en C) es muy legible y es f´ cil
e a
de ver qu´ operaciones en punto flotante intervienen.
e

• Es la prueba m´ s corta del LBT :-).
a

• Es una prueba ”Cl´ sica”: hay disponibles cifras comparativas, sus defectos y deficiencias son bien conocidos.
a

• Procedimiento para realizar la prueba: se deberá obtener el c´ digo en C m´ s reciente del sitio de Aburto.
ı o a
Compile y ejecute en modo de doble precisi´ n. Especifique gcc y -O2 como opciones de precompilador y
o
compilador, y defina POSIX 1 para especificar el tipo de m´ quina.
a

• Resultados: una cifra del rendimiento de punto flotante en MWIPS.

3.4.3 Xbench-0.2:

• Qu´ : mide el rendimiento del servidor X.
e

• 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
o
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
o
m´ s r´ pida:./xbench -timegoal 3 > results/name of your linux box.out. Para obtener la
a a
calificaci´ n xStones, debemos ejecutar un gui´ n (script) en awk; la manera m´ s r´ pida es escribir make sum-
o o a a
o a ´
mary.ms. Compruebe el fichero summary.ms: la calificaci´ n xStone de su sistema est´ en la ultima columna
del rengl´ n que tiene el nombre de su m´ quina que especific´ durante la prueba.
o a o

• Resultados: una figure del rendimiento de X en xStones.

• Nota: esta prueba, tal como est´ , es obsoleta. Deberá ser reescrita.
a ı

3.4.4 UnixBench versi´ n 4.01:
o

• Qu´ : mide el rendimiento global de Unix. Esta prueba ejercitar´ el rendimiento de E/S de ficheros y multitarea
e a
del n´ cleo.
u

• He descartado los resultados de todas las pruebas aritm´ ticas, qued´ ndome s´ lo con los resultados relacionados
e a o
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 ńdices
a e ı
EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING,
PROCESS CREATION, SHELL SCRIPTS y SYSTEM CALL OVERHEAD.

• Resultados: un ńdice del sistema.
ı

3.4.5 Banco de pruebas BYTEmark de BYTE Magazine BYTEmark:

• Qu´ : proporciona una buena medida del rendimiento de la CPU. Aqu´ hay un extracto de la documentaci´ n:
e ı o
”Estas pruebas est´ n pensadas para exponer el l´mite superior te´ rico de la arquitectura de CPU, FPU y
a ı o
memoria de un sistema. No pueden medir transferencias de v´deo, disco o red (´ stos son dominios de un
ı e
conjunto de pruebas diferentes). Deberá usted, por lo tanto, utilizar los resultados de estas pruebas como
ı
parte, no como un todo, en cualquier evaluaci´ n de un sistema.”
o


• 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´ -
a e
CPU y las pruebas de enteros de la CPU.

• Procedimiento para realizar la prueba: compilar con -O2. Ejecutar la prueba con ./nbench > myre-
sults.dat o similar. Entonces, de myresults.dat, calcule la media geom´ trica de los ńdices de las pruebas
e ı
STRING SORT, ASSIGNMENT y BITFIELD; este es el ńdice de la memoria; calcule la media geom´ trica
´ ı e
de los ńdices de las pruebas NUMERIC SORT, IDEA, HUFFMAN y FP EMULATION; este es el ńdice de
ı ´ ı
enteros.

• Resultados: un ńdice de memoria y un ńdice de enteros calculado tal como se explica anteriormente.
ı ı

3.5 Posibles mejoras

El conjunto ideal de pruebas deberá ejecutarse en pocos minutos, con pruebas sint´ ticas que examinen cada subsistema
ı e
por separado y pruebas de aplicaci´ n que den resultados para diferentes aplicaciones. Tambi´ n deberá generar de
o e ı
forma autom´ tica un informe completo y quiz´ enviarlo por correo a la base de datos central en la Web.
a a
No estamos interesados en la portabilidad, pero deberá al menos poder ser ejecutado en cualquier versi´ n reciente (>
ı o
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
a
(menos de 30 minutos en configuraci´ n y ejecuci´ n), por favor, p´ ngase en contacto conmigo.
o o o

3.6 El formulario de informe LBT

Aparte de las pruebas, el procedimiento de ’benchmarking’ no estará completo sin un formulario describiendo la
ı
configuraci´ n, de manera que aqu´ est´ (siguiendo la guá de comp.benchmarks.faq):
o ı a ı

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,
o
y como tal, es opcional. Podr´a ser la parte m´s significativa del
ı a
informe, sin embargo, especialmente si est´ haciendo pruebas comparativas.
a

4. Prueba de ejemplo y resultados 12

3.7 Pruebas del rendimiento de la red

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

3.8 Pruebas SMP

Las pruebas SMP son otro reto, y cualquier banco de pruebas dise˜ ado espec´ficamente para probar SMP tendr´
n ı a
dificultades prob´ ndose a s´ misma en configuraciones de la vida real, ya que los algoritmos que pueden tomar ventaja
a ı
´
de SMP son difćiles de realizar. Parece que las ultimas versiones del n´ cleo de Linux (> 2.1.30 o por ah´) har´ n
ı u ı a
multiproceso ”muy granulado” (fine-grained), pero no tengo m´ s informaci´ n al respecto ahora mismo.
a o
Seg´ n David Niemi, ” ... shell8 [parte del Unixbench 4.01]hace un buen trabajo comparando hardware similare en
u
los modos SMP y UP.”

4 Prueba de ejemplo y resultados

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
e a e
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
e
para el uso en casa o para el desarrollo con Linux. <Informar´ de los
e
resultados con un procesador 6x86MX tan pronto como le eche las manos
encima!

5. Falsedades y fallos del benchmarking 15

5 Falsedades y fallos del benchmarking

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

5.1 Comparar manzanas con naranjas

¿O deberá decir Apples2 con PCs? Es una disputa tan obvia y antigua que no ahondar´ en los detalles. Dudo que
ı e
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
a a
id´ nticas con una sola modificaci´ n.
e o

5.2 Informaci´ n incompleta
o

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

5.3 Software/hardware Propietario

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

5.4 Relevancia

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

6 FAQ (Preguntas Frecuentes)
P1.
¿Hay alguna medida aislada del m´ rito de los sistemas Linux?
e

R:
No, gracias al cielo nadie ha salido todavá con una medida Lhinuxstone (tm). Y si hubiera una, no tendrá
ı ı
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
a e
de un sistema Linux bajo tales situaciones diferentes.
2
N. del T.: Apple = manzana, pero tambi´ n una famosa compa˜ á que fabrica ordenadores
e nı

6. FAQ (Preguntas Frecuentes) 16

P2.
Entonces, ¿qu´ tal una docena de cifras resumiendo el rendimiento de diversos sistemas Linux?
e

R:
Esa será la situaci´ n ideal. Me gustará ver que se hace realidad. ¿Voluntarios para un Linux Benchmarking
ı o ı
Project? ¿Con un sitio web y una base de datos en lńea, completa y con informes bien dise˜ ados?
ı n

P3.
... ¿BogoMips...?

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

P4.
¿Cu´ es el ’mejor’ banco de pruebas para Linux?
a

R:
Todo depende de qu´ aspecto del rendimiento de un sistema Linux quiera medir uno. Hay diferentes bancos de
e
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,
a o
rendimiento SQL, rendimiento de servidor web, rendimiento en tiempo real (Real-Time), rendimiento del CD-
ROM, rendimiento de Quake (¡!), etc... HDYS3 , no existe ning´ n conjunto de pruebas para Linux que realice
u
todas estas pruebas.

P5.
¿Cu´ l es el procesador m´ s r´ pido sobre el que corre Linux?
a a a

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

P6.
Perm´tame rehacer la pregunta anterior, entonces: ¿hay alg´ n procesador que sea m´ s r´ pido para aplicaciones
ı u a a
de prop´ sito general?
o

R:
Esa es una difćil con truco, pero tiene una respuesta muy sencilla: NO. Siempre podremos dise˜ ar un sistema
ı n
m´ s r´ pido incluso para aplicaciones de uso general, independientemente del procesador. Normalmente, siendo
a a
todos los dem´ s elementos iguales, mayores tasas de reloj dar´ n sistemas de mayor rendimiento (y tambi´ n m´ s
a a e a
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á sentir el ”umppffff” extra. Por supuesto, con s´ lo 16 MBytes de
o ı o
RAM, se podrá haber hecho la misma inversi´ n, m´ s sabiamente, en unos SIMM extra...
ı o a

P7.
¿De manera que la velocidad de reloj influye en el rendimiento del sistema?
3
HDYS = Hasta Donde Yo S´ (AFAIK = As Far As I Know)
e

6. FAQ (Preguntas Frecuentes) 17

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

P8.
´
Bien, entonces, una ultima pregunta sobre el asunto: ¿cual es el procesador que proporciona una mejor tasa
precio/rendimiento para usos de prop´ sito general de Linux?
o

R:
¡Definir ”uso de prop´ sito general de Linux no es f´ cil! Para cualquier aplicaci´ n particular, siempre hay un
o a o
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
a
MHz será una respuesta v´ lida s´ lo temporalmente. De todas maneras, el precio del procesador es insignificante
ı a o
comparado al precio global del sistema que vamos a poner, De manera que, realmente, la cuesti´ n deberá
o ı
ser ¿c´ mo podemos maximizar la tasa precio/rendimiento de un sistema dado? Y la respuesta a esa cuesti´ n
o o
depende much´simo de los requerimientos mńimos de rendimiento y en el coste mńimo/m´ ximo establecido
ı ı ı a
para la configuraci´ n que estamos considerando. Algunas veces, el hardware que podemos comprar en las
o
a ı ´
tiendas no nos dar´ el rendimiento mńimo necesario, y la unica alternativa ser´ n costosos sistemas RISC. Para
a
algunos usos, recomiendo un sistema equilibrado y homog´ neo :-); la elecci´ n de un procesador es una decisi´ n
e o o
importante, pero no m´ s que elegir el tipo y capacidad del disco duro, la cantidad de RAM, la tarjeta de v´deo,
a ı
etc...

P9.
¿Qu´ es un incremento ”significativo” de rendimiento?
e

R:
Yo dirá que cualquier cosa por debajo de 1% no es significativo (podrá ser descrito como ”marginal”).
ı ı
Nosotros, los humanos, difćilmente 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
a a
que, comparando dos sistemas con ńdices de 65’9 y 66’5, este ultimo es ”definitivamente m´ s r´ pido”.
ı ´ a a

P10.
¿C´ mo obtengo incrementos ”significativos” en renadimiento al menor coste?
o

R:
Como la mayorá del c´ digo fuente para Linux est´ disponible, un examen atento y un redise˜ o algor´tmico de
ı o a n ı
´
las subrutinas clave podrán alcanzar incrementos de rendimiento en ordenes de magnitud en algunos casos. Si
ı
estamos tratando con un proyecto comercial y no deseamos meternos demasiado en el c´ digo C, podrámos
o ı
llamar a un consultor de Linux. Lea el Consultants-HOWTO.

7. Copyright, reconocimientos y miscel´ nea
a 18

7 Copyright, reconocimientos y miscel´ nea
a

7.1 C´ mo se produjo este documento
o

El primer paso fue leer la secci´ n 4 ”Escribir y enviar un HOWTO” del HOWTO Index de Greg Hankins.
o
No sabá absolutamente nada sobre SGML o LaTeX, pero estuve tentado de usar un paquete de generaci´ n autom´ tica
ı o a
de documentaci´ n tras leer varios comentarios sobre las SGML-Tools. Sin embargo, insertar etiquetas manualmente
o
en un documento me recuerda los dás en que ensambl´ a mano un programa monitor de 512 bytes para un microproce-
ı e
sador de 8 bits ya difunto, de manera que tom´ las fuentes de LyX, lo compil´ , y us´ su modo LinuxDoc. Recomiendo
e e e
la combinaci´ n: LyX y SGML-Tools.
o

7.2 Copyright

El Linux Benchmarking HOWTO es copyright (C) 1997 de Andr´ D. Balsa. Los documentos HOWTO de Linux
e
pueden ser reproducidos y distribuidos en su totalidad o en parte, en cualquier medio f´sico o electr´ nico, siempre que
ı o
se mantenga esta noticia de copyright en todas las copias. Se permite y anima a la distribuci´ n comercial; sin embargo,
o
el autor querá 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
a
imponer restricciones adicionales sobre su distribuci´ n. Se podrán permitir excepciones a estas restricciones bajo
o ı
ciertas condiciones; por favor, p´ ngase en contacto con el coordinador del Linux HOWTO en la direcci´ n que damos
o o
m´ s adelante.
a
En resumen, nos gustará promover la diseminaci´ n de esta informaci´ n a trav´ s de cuantos m´ s canales sea posible.
ı o o e a
Sin embargo, querámos retener el copyright de los documentos HOWTO, y nos gustará 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.
o

7.3 Nuevas versiones de este documento

Se pondr´ n las nuevas versiones del Linux Benchmarking-HOWTO en sunsite.unc.edu y en sitios espejo. All´ en-
a ı
contrar´ otros formatos, como las versiones PostScript y dvi en el directorio other-formats. El Linux Benchmarking-
a
HOWTO tambi´ n est´ disponible para clientes WWW como Grail, un navegador Web escrito en Python. Tambi´ n
e a e
ser´ enviado con regularidad en comp.os.linux.answers.
a
La versi´ n en castellano de este HOWTO la encontrar´ en el sitio del Insflug http://www.insflug.org
o a

7.4 Realimentaci´ n
o

Se buscan sugerencias y correciones. Se reconocer´ a los contribuyentes. No necesito ’flames’.
a
Siempre me puede localizar en andrewbalsa@usa.net.

7.5 Agradecimientos

David Niemi, el autor del conjunto de aplicaciones Unixbench, ha probado ser una fuente infinita de informaci´ n y
o
cr´ticas (v´ lidas).
ı a

7. Copyright, reconocimientos y miscel´ nea
a 19

Tambi´ n me gustar´a agradecer a Greg Hankins, el coordinador del Linux HOWTO y uno de los mayores con-
e ı
tribuyentes 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.6 Pliego de descargo

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

7.7 Marcas registradas

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.

Linux benchmarking como

Más contenido relacionado

La actualidad más candente (13)

Similar a Linux benchmarking como (20)

Más de Instituto Tecnologico De Pachuca (20)

Último (20)

Linux benchmarking como