Download EVALUACIÓN Y CONFIGURACIÓN DE EQUIPOS INFORMÁTICOS

EVALUACIÓN Y CONFIGURACIÓN DE EQUIPOS
INFORMÁTICOS
Javier Téllez
1
Objetivo: Realización de distintas pruebas para medir y comparar
el rendimiento de distintas arquitecturas.
1. En teléfonos móviles
1.1
1.2
1.3
1.4
1.5
Pruebas
Simulación
Prueba real sobre el Nokia 6230
Prueba real sobre el Sony Ericsson K300
Prueba sobre un ordenador portátil
2. Estrés térmico en un Intel Pentium 100
2
1. EN TELÉFONOS MÓVILES
No sólo los ordenadores, ya sean de escritorio, portátiles y de ahí para arriba tienen derecho a
tener procesadores potentes no? También los teléfonos móviles, y no hace falta ir a los
smartphones de última generación, a las PDA con WindowsCE, o a la que ha sacado Nokia bajo
Linux1, para encontrarnos aparatos con procesadores de buenas prestaciones. El primer
dispositivo en que se realizarán las pruebas de rendimiento es un Nokia 6230.
Sólo nos interesan algunas de sus características2:
Aplicaciones Java™
 Todas las aplicaciones pueden eliminarse
 Juegos y aplicaciones personales descargables a
través de tecnología Java™ (MIDP 2.0)
 Tamaño máximo de descarga: 128 KB por
aplicación
Conexiones
 Navegación XHTML (WAP 2.0) a través de pila
TCP/IP
Transmisión de datos
 GPRS (General Packet Radio Service)* Clase 10
(4+1, 3+2)
 EDGE* Clase 10 (4+1, 3+2): Velocidad de hasta
236,8 Kbit/s
 Transferencia de datos de hasta 43,2 Kbit/s en
redes HSCSD
 Multitarea
 TCP/IP
Personalización
 Midlets Java
 Juegos: Posibilidad de descargar nuevos juegos
Si no tuviera soporte para aplicaciones Java, en concreto la configuración CLDC (Constrained
Limited Device Connected) y alguno de los perfiles MIDP1.0 o MIDP2.0, sería bastante
complicado poder ejecutar aplicaciones (llamadas Midlets en este entorno) en el dispositivo.
En concreto, se pueden escribir aplicaciones en Java usando las librerías que ofrece
gratuitamente Sun Microsystems a través de su página Web. También puede descargarse el
WTK (Wireless ToolKit) de Sun, o de otro fabricante, Nokia, Sony Ericsson, que es una de las
que mejor soporte y código fuente aportan, etc. Para el código de este trabajo se ha empleado el
IDE de Eclipse (gran consumo de memoria, pero sin duda de lo mejor que hay) y el plugin
WTK de Sony Ericsson para su integración en Eclipse.
1
Como dato curioso, fue presentado en la La II Conferencia Internacional de Software Libre Málaga (sin
participación activa de la UMA), por el responsable de Nokia para la zona occidental de Andalucía, con
bastante mala fortuna. Le pasó casi lo mismo que a Bill Gates. Durante la presentación, en un portátil que
parecía en las últimas, apareció de pronto el mensaje “Windows se está preparando para la suspensión”
en primer plano. Los reunidos comenzaron a reirse ante el hecho, ya que la conferencia era sobre la
presentación de un nuevo producto que funcionaba bajo Linux, en unas conferencias donde la mayoría
usaba, y hasta llevaban su portátiles con Linux. Salió por su propio pie.
2
http://www.nokia.es/telefonos/modelos/nokia6230/caracteristicas_id6230.jsp
3
El procesador que usa el Nokia 6230 es un modelo de las casa ARM, en concreto un ARM9.
Así nos lo describe ARM:
El amplio conjunto de características de la familia ARM9 permite a los desarrolladores
implementar sistemas punteros, al mismo tiempo que se permite un considerable ahorro en área
de integración del chip, tiempo de desarrollo, costes de los mismos y consumo.
La familia ARM9 ofrece un rango de núcleos de microprocesadores
RISC de 32 bits, de alto rendimiento y optimizados para bajo
consumo, para una amplia variedad de aplicaciones. Construidos
alrededor del núcleo del robusto procesador ARM9TDMI, la familia
ARM9 trabaja hasta a 250 MHz sobre una tecnología de 0.13µm,
incorporando el juego de instrucciones de 16 bits Thumb, que mejora la
densidad del código hasta un 40%.
La familia ARM9 abarca los procesadores “cached processor macrocells” ARM920T y
ARM922T, cada uno de los cuales ha sido desarrollado para entornos con diferentes
necesidades:
• ARM922T: Dual 8k caches para aplicaciones bajo Symbian OS, Windows CE, Linux
y Palm OS
• ARM920T: Dual 16k caches para aplicaciones bajo Symbian OS, Windows CE, Linux
y Palm OS
Sus características más destacadas se listan a continuación:











Procesador RISC de 32 bits y juegos de instrucciones ARM y Thumb.
5 etapas de segmentación (búsqueda, decodificación, ejecución, memoria y escritura).
Interfaz de interconexión AMBA única de 32 bits.
Unidad de gestión de memoria (MMU Memory Management Unit) soporta
WindowsCE, Symbian OS, Linux y Palm OS.
Cachés de datos e instrucciones integradas.
Buffer de escritura de 8 entradas, para evitar que el procesador se quede atascado
cuando se realizan escrituras a la memoria externa.
Portable a tecnologías de integración en silicio de 0.18µm, 0.15 µm y 0.13 µm.
El diseño del procesador permite ajustar dinámicamente la velocidad del procesador, o
incluso pararlo, para ajustarse a las necesidades inmediatas de procesamiento.
El bus del sistema y la memoria externa pueden también marchar a una velocidad
menor que el procesador, para reducir el consumo de memoria.
Cachés Write-back y Write-through seleccionables por regiones.
Sistema de interrupciones de baja latencia y soporte para memoria virtual para
aplicaciones bajo SO.
4
Otra visión del núcleo de ambos procesadores. La principal diferencia es el tamaño de
las cachés.
1.1 PRUEBAS
Para realizar las pruebas se ha escrito un pequeño Midlet3 de Java para su ejecución en el
teléfono móvil. En el caso del Nokia 6230, tras crear la aplicación y empaquetarla en su
correspondiente archivo .jar y su descriptor con extensión .jad, se transfiere al móvil usando la
aplicación que para ello ofrece Nokia en su página Web, el PC Suite. Otra forma hubiera sido
subirlos a un servidor y descargarlos desde el móvil a través de una conexión GPRS con el
servidor. La primera solución es más barata.
Las dos pruebas a realizar son simples debido a la poca pericia del autor de este trabajo. Primero
se intentará medir la velocidad del procesador ejecutando instrucciones que teóricamente sólo
requieren de un ciclo para su ejecución, como una operación de testeo o sumar 2. Como se
emplea Java, hace falta un intermediario (la máquina virtual) que es el encargado de recoger el
código (bytecode) e interpretarlo sobre el hardware del teléfono. Las modernas máquinas
virtuales usan compilación JIT (Just In Time) que compila el código tras la carga del programa
para producir código nativo de la plataforma sobre la que se ejecuta.
La segunda prueba está relacionada con la memoria y también con la capacidad de cálculo.
Consiste en multiplicar dos arrays arrays bidimensionales (matrices), multiplicarlas y calcular
su traza. Esta operación se repite gran cantidad de veces, con lo que hay que alojar gran
cantidad de objetos en memoria, ya que se crea para cada iteración un nuevo objeto Matriz (con
tres arrays bidimensionales para las operaciones).
La interfaz gráfica es lo más simple posible, para no molestar al procesador con tareas pesadas
que falsearían la medición.
3
El proyecto generado para esta aplicación se encuentra en el directorio junto con este documento en la
carpeta “CEI”
5
La clase Midlet es la que se carga al inicio, y desde ésta, cuando se presione “Empezar” se
ejecutarán las pruebas, en el método commandAction.
import javax.microedition.midlet.*;
import javax.microedition.io.*;
import javax.microedition.lcdui.*;
import java.util.*;
import java.io.*;
/**
* @author jtellez
*/
public class CEI extends MIDlet implements CommandListener {
public static Display display;
private Form f_inicio;
public static Command ENTRAR_COMMAND = new Command("Empezar",
Command.ITEM, 0);
public static Command SALIR_COMMAND = new Command("Salir", Command.EXIT, 1);
private StringItem si;
private StringItem sii;
//********* CONSTRUCTOR PRICIPAL ************************************
public CEI() { //obtengo la referencia unica a la pantalla del dispositivo
display = Display.getDisplay(this);
///////////// INICIALIZACIÓN PANTALLA PRINCIPAL /////////////////////////
f_inicio = new Form("Evaluación CEI");
f_inicio.addCommand(ENTRAR_COMMAND); //los dos comandos en la base del móvil
f_inicio.addCommand(SALIR_COMMAND);
si = new StringItem("", " ");
f_inicio.append(si);
sii = new StringItem("","");
f_inicio.append(sii);
f_inicio.setCommandListener(this); //para los dos comandos: Empezar y Salir
display.setCurrent(f_inicio); //esto pone el formulario en la pantalla del móvil
}
public void startApp() {
Runtime runtime = Runtime.getRuntime();
runtime.gc();
long free = runtime.freeMemory(); //al empezar pongo la cantidad de memoria
long total = runtime.totalMemory(); //total y libre del móvil en pantalla
si.setText("Mem libre=" + free + "\n");
sii.setText("Mem total=" + total + "\n");
f_inicio.append("Pulse Empezar!\n");
}
public void pauseApp() { }
public void destroyApp(boolean unconditional) { }
6
public void commandAction(Command c, Displayable s){
if (c == SALIR_COMMAND) {
destroyApp(true);
notifyDestroyed();
}
else if (c == ENTRAR_COMMAND) {
f_inicio.append("Probando procesador....");
Matriz matrix = new Matriz();// = new Matriz();
f_inicio.append(matrix.getPerformanceDetails()); // velocidad CPU
long inicio = new Date().getTime();
for (int i=0; i<900;i++){
matrix = new Matriz();
matrix.multiplica(); //multiplicación masiva de 2 matrices
}
long fin = new Date().getTime();
f_inicio.append("Prueba con matrices.");
f_inicio.append("traza="+matrix.traza());
f_inicio.append("tiempo="+String.valueOf(fin-inicio)+"ms"); //tiempo xra multiplic
}
}
}
7
La segunda clase de la aplicación es la clase Matriz, multiplica matrices cuadradas e intenta
estimar la velocidad del procesador
/**
* Clase Matriz, xra multiplicar 2 matrices y producir una tercera y para calcular la *velocidad
del procesador
*/
public class Matriz {
int size = 3;
int[][] m1 ={ {9919,11121,3111},
{8311,81411,81311},
{81711,8811,81311}
};
int[][] m2 ={ {91919,11121,63111},
{87311,87411,8311},
{87711,87811,8311}
};
int[][] m3 = { {0,0,0},
{0,0,0},
{0,0,0}
};
public void multiplica(){
for (int i=0;i<size;i++)
for (int j=0;j<size;j++)
for (int k=0;k<size;k++)
m3[i][j] += m1[i][k] * m2[k][j];
}
public int traza(){
int sum=0;
for (int i=0;i<size;i++)
sum += m3[i][i];
return sum;
}
/**
* Velocidad estimada de la CPU en MHz, suponiendo que se usa un compilador
* Java. Se supone que operaciones simples sólo consumen 1 ciclo.
*En maxi se guarda el máximo nº de iteraciones para calcular la velocidad
* The
estimated speed of the CPU multiplied by 10 to have one decimal *figure.
* This decimal figure is rounded to the nearest value. If maxi is to low to *measure the
time, returns 0.
*/
public int getMHz(int maxi){
int i= 2;
long duration, start= System.currentTimeMillis();
while (--maxi != 0)
{
if ((maxi & 1) == 0)
i += 2;
}
duration= System.currentTimeMillis() - start;
int mhz= 0;
if (duration != 0)
8
{
//
mhz = nº ciclos para el bucle : 6
//
* nº bucles : i
//
/ (nº ciclos por segundo en 1MHz / nº ms en 1s / 100)
//
= 1000000 / 1000 /100
//
= 10 así k divido por 10
//
/ duración en ms
//
mhz tiene valor en MHz multiplicado x 100 para
//
tener 2 dígitos decimales
mhz= (int) (6l * (long)i / 10l / duration);
//
el decimal
if ((mhz - (mhz / 10) * 10) >= 5)
mhz= mhz + 10;
mhz /= 10;
if (mhz == 0)
mhz= 1;
}
return mhz;
}
/**
* Se usa la función anterior para dar detalles
*/
public String getPerformanceDetails(){
long start, duration, memoryDuration;
int mHz= 0;
int nbIter= 10;
final int minimumDuration= 1500;
int memoryNbIter;
do{
if (nbIter < 0){
nbIter= Integer.MAX_VALUE;
}
start= System.currentTimeMillis();
mHz= getMHz(nbIter);
duration= System.currentTimeMillis() - start;
Thread.yield();
if (duration < 50){
nbIter *= 10;
}
else if (duration < minimumDuration){
int newNbIter= minimumDuration * nbIter / (int)duration * 12 / 10 + 1;
if ((duration <= minimumDuration / 2) && (newNbIter > nbIter))
nbIter= newNbIter;
else
nbIter *= 2;
}
}
while (((mHz == 0) || (duration < minimumDuration)) && (nbIter !=
Integer.MAX_VALUE));
int realMHz= mHz * 18;
return "Velocidad procesador java virtual: "+
+ mHz / 10
9
+ "."
+ (mHz - (mHz / 10) * 10) //decimal figure
+"MHz\n"
+ "Tan rápido PIII (sin JIT) a "
+ realMHz / 10 + "." + (realMHz - (realMHz / 10) * 10) //decimal
+ "MHz\n"
+ "Num bucles: "
+ nbIter
+ "\nduración:"
+ duration + "ms";
}
}//fin Matriz
Se toma como referencia un Pentium III en cuanto a los números usados.
1.2 Simulación
A continuación se empaqueta el Midlet, llamado CEI en un archivo .jar, y se simula en primer
lugar con el Wireless Toolkit de Sun, habilitando el monitor de memoria en el diálogo de
propiedades. Un Midlet puede tener dentro varias aplicaciones, así que el emulador presenta una
lista. En nuestro caso sólo hay una, CEI, así que sólo hay que pulsar el botón Launch. La
siguiente es una captura de video (DIVX Pro 5.1.1) que empieza una vez se ha cargado e
inicializado la aplicación. La línea verde de consumo de memoria se ha estabilizado tras la carga
de los objetos de inicio. Este video enlaza al archivo correspondiente que acompaña al presente
documento, ya que el archivo de video incrustado en Word no se visualiza bien. Para ver la
captura de 35seg. pinchar dos veces sobre la siguiente figura.
La simulación se ha ejecutado dos veces (dos pulsaciones sobre botón Ejecutar) para ver mejor
el consumo de memoria. También puede verse al principio y casi al final cómo actúa el
recolector de basura.Aunque es difícil de apreciar, al principio se estima la velocidad de trabajo,
10
así que no hay mucho consumo de memoria. Es cuando empieza la segunda prueba, de creación
y multiplicación intensiva de matrices cuando entra en juego la memoria.
En la figura siguiente se puede ver una instantánea casi al final de la simulación anterior.
1.3 PRUEBA REAL SOBRE EL NOKIA 6230
Las pruebas ya realizadas sobre el simulador se harán a continuación sobre un dispositivo real.
En primer lugar sobre un Nokia 6230 y a continuación sobre un Sony Ericsson K300. Las
capturas se han hecho con con la cámara del teléfono no sometido a la prueba. Hemos de
advertir que sólo servirán como testimonio de haber realizado las pruebas, ya que sus
respectivas cámaras son tan pobres de calidad que apenas si se logra distinguir algo.
Esta es la pantalla del Nokia tras cargarse la aplicación CEI.
Se puede ver con esfuerzo la cantidad de memoria total y
libre del aparato. Tras pulsar la tecla Empezar, se ejecuta la
prueba, primero la medida de velocidad de la CPU y a
continuación la prueba con las matrices.
En las captura siguiente, una vez finalizada la ejecución de la
prueba, se aprecia el resultado en cuanto a velocidad. Arriba
puede leerse “Evaluación CEI”.
Trascribimos lo que aparece en el móvil para que sea legible:
11
Mem libre=1007280
Mem total=1024000
Pulse Empezar!
Probando procesador…
Velocidad procesador java virtual: 10.2MHz
Tan rápido PIII (sin JIT) a 183.6MHz
Num bucles: 3103448
Duración: 1819ms
Prueba con matrices
Traza=935273269
Tiempo=117ms (sólo de la prueba de matrices)
1.4 PRUEBA REAL SOBRE EL SONY ERICSSON K3004
En este caso, las capturas de imágenes son aún peores si cabe,
aunque la captura de video de la derecha (formato .3gp pasado a
DivX) puede resultar algo más interesante aunque no se pueda
distinguir detalle..
Mem libre=505848
Mem total=524284
Pulse Empezar!
Probando procesador…
Velocidad procesador java virtual: 29.8MHz
Tan rápido PIII (sin JIT) a 536.4MHz
Num bucles: 9045226
Duración: 1820ms
Prueba con matrices
Traza=935273269
Tiempo=152ms (sólo de la prueba de matrices)
Es curioso comprobar que también en el caso de los teléfonos móviles, los fruteros tendrían las
de perder si sólo se fijaran en la frecuencia. El sony ericsson, casi triplicando la frecuencia del
Nokia, pierde en todas las pruebas de rendimiento. Aun sin datos numéricos se puede
comprobar claramente, tras un rato con el teléfono en la mano, que el Nokia se comporta mucho
mejor que el sony ericsson en términos de rendimiento.
4
No he conseguido información rotunda sobre el procesador de este modelo, pero todo apunta a que es un
hermano gemelo del K500, que lleva un procesador ARM de la familia ARM9E. Especificaciones
técnicas en http://www.arm.com/products/CPUs/families/ARM9EFamily.html
12
1.5 PRUEBA REAL SOBRE UN PORTÁTIL
En concreto se trata de un ordenador portátil Toshiba Satellite SA60-111. Con un Pentium 4
Norwood a 2.80GHz. El resto de características se muestran en las siguientes figuras.
En este caso para ejecutar el test basta con invocar la instrucción java CEI desde usar una
ventana de comandos. Esta vez, la clase CEI sólo ha de contener el método main(), y dentro la
llamada a la función de medida de la velocidad, y el bucle para la multiplicación de matrices.
Además se omiten las referencias a memoria porque no son de interés. El resultado es el
siguiente:
El resultado de la velocidad (la segunda línea no es aplicable aquí) se acerca mucho a los
2.8GHz del portátil sobre el que se ejecuta la prueba.
13
2. ESTRÉS TÉRMICO EN UN INTEL PENTIUM 100
La última prueba, que prometía ser algo más interesante, no dio de si todo lo esperado. El
objetivo es someter a un microprocesador a una dura prueba de estrés térmico hasta llevarlo al
límite físico, aquel que de lugar a su destrucción. Para ello se ejecutarán pruebas sobre el
equipo que hagan uso intensivo del procesador, pero sin contar éste con la ayuda de su disipador
ni el ventilador. En concreto, se ejecutarán el benchmark para la cpu del programa comercial PC
Wizard 2006.
El equipo sobre el que se ejecutará la prueba es un viejo equipo de sobremesa con un procesador
Pentium 100, con 16Mbytes de memoria RAM. La placa base no ofrece información sobre la
temperatura del procesador, por lo que el programa MBProbe para la monitorización de ésta no
es de utilidad. Tras esto, el tiempo que es capaz de aguantar “vivo” el microprocesador, es uno
de los datos interesantes a verificar.
Para la documentación de la prueba se utilizó una webcam para grabar y dejar constancia de la
misma. Los videos son de considerable tamaño y se encuentra en el directorio “TrabajoCEI”
con nombres “CEI_x”.
Se detalla a continuación la cronología de los momentos más interesantes. El único momento
interesante del primer vídeo, CEI_1 es el principio. Se puede ver el sistema, funcionando bajo
Windows 98, una vez ha arrancado y el programa PC Wizard 2006 está listo para comenzar. A
continuación se ofrece una vista de la placa base, deteniéndonos en los módulos de memoria
SIMM, para acabar en un primer plano del procesador alrededor del instante 20seg. Justo a
continuación, se procede a quitar el ventilador y el disipador térmico del lomo del Pentium 100
(previamente desenganchado del mismo). Los más de siete minutos restantes transcurren sin
novedad. Al final puede verse en el monitor cómo el sistema sigue funcionando.
Parece como si las pruebas ni hicieran las más leves cosquillas al microprocesador, pero no es
así. En el vídeo CEI_2, transcurridos 25seg. se vierte una gota de agua sobre el lomo del mismo,
y se puede apreciar como se disuelve casi automáticamente fruto del intenso calor. También al
final de este vídeo puede verse el resultado del benchmark en el monitor.
El tercer vídeo pone de manifiesto dónde se encuentra la zona más activa del procesador. Tras
40seg. se puede ver cómo una gota de agua cae en el centro del chip y se disuelve velozmente,
mientras que si cae sólo unos milímetros más allá tarda casi 30seg. en evaporarse.
El último vídeo intenta mostrar, de forma muy rudimentaria, qué partes del microprocesador
alcanzan mayor temperatura. Para ello, se deja, a partir del instante 2m20seg; y 6m40seg sendas
huellas transversales sobre el lomo del chip.
El equipo estuvo más de 1h sometido sometido a esta prueba, desprovisto de su ventilador y
disipador, sin mostrar el más leve signo de desfallecimiento. Desde luego merece un premio.
14