Esta última semana he estado centrado en el montaje y ahora mismo en la fase de validación final, ya realizando los controles de temperaturas con ejecuciones de tests superiores a las 24h en carga 100%.
La primera prueba que ejecuto en un sistema nuevo es Memtest86+ durante al menos 24h en condiciones reales de funcionamiento, es decir con la torre cerrada y todos los componentes conectados.
Si el resultado es satisfactorio procedo a la instalación desde cero del sistema operativo, en este caso un Windows Vista 64 y sus correspondientes drivers. Es en este punto cuando copio un extenso conjunto de tests y pruebas portables e instalo dos o tres que no existen en versión portable.
La primera prueba ya en el escritorio de Windows siempre es Memtest for Windows, ejecuto una instancia por núcleo / core del procesador asignando la afinidad manualmente en el administrador de tareas.
Como vemos, no queda memoria libre y el uso de los ocho procesadores lógicos es plano del 100%, consiguiendo así carga máxima. Esta prueba es recomendable que dure al menos unas 12 horas.
Ahora llega el turno de los tests de procesador, tests de cálculo puro. El primero y más importante es Prime95.
Prime95 es un excelente programa para poner a prueba la estabilidad de un sistema y más si opera fuera de especificación. Tiene tres modos de funcionamiento, que como explique en un artículo de SATSoftware son los siguientes:
- Small FFTs. Fast Fourier Transformations (FFTs) de pequeño tamaño, de 8 a 64 KB. Máximo stress de las unidades de coma flotante, los datos caben en caché L2 y prácticamente no testea memoria. Este modo prueba únicamente el procesador y en menor medida la caché L2 y poco más. Uso de memoria cero. Es el mejor test de cálculo puro.
- In-place large FFTs. FFTs de 128 a 1024 KB, en CPUs actuales (Core2Duo, Core2Quad, AMD Phenom.) los datos caben también en L2 o en su caso L3. Testea algo de memoria principal, uso de memoria 8 MB. Según los desarrolladores del software aquí se produce la mayor disipación térmica. Según mis pruebas no siempre es así.
- Blend. Prueba concienzudamente la memoria puesto que utiliza FFTs de 8 a 4096 KB. En equipos con 2 GB utiliza unos 1750 MB de RAM. El modo de mayor disipación térmica en Athlon 64 X2 altos de gama (6000+ y 6400+).
Personalmente ejecuto sobre 24h cada test, ya que más de una vez me ha fallado a las 10 o 15h… Hay que ser estricto. Y recordar que es necesario activar la opción round off checking.
Cuando estos han concluido empiezo con las pruebas de carga combinada. Normalmente utilizo combinaciones de Prime95 con RTHDRIBL y Unigine Tropics a la vez que ejecuto desfragmentaciones de disco o escaneos del antivirus.
En la captura, se ven todas las ventanas, pero la forma correcta de generar carga máxima es maximizar la ventana de RTHDRIBL. Como vemos la temperatura del core más caliente son 60ºC y la del núcleo de la ATI HD4890 58ºC con 63ºC en las controladoras de memoria GDDR5, unos excelentes resultados.
RTHDRIBL, como explico en un artículo que le dediqué, es un test de DirectX 9.0C. Como sabéis la HD4890 de este sistema es una gráfica adherida a la especificación DirectX 10.1, para probar esta característica utilizo Unigine Tropics.
Como en el caso anterior hay que maximizar Unigine Tropics para obtener la carga máxima.
En estas pruebas de carga combinada máxima es importante que Prime95 esté configurado en el modo SFFT (así se ejecuta con código de las cachés L1), pues de otro modo la carga (medida como IPC) sería muy inferior debido a cache trashing en L2 y L3 y con ello también las temperaturas.
En resumen, no es tarea sencilla el asegurar la estabilidad de un sistema de esta características. Es necesario mucho tiempo, muchas horas de trabajo y dedicación y sobretodo un espíritu de investigación y mejora constante para descubrir el nuevo hardware y los nuevos métodos de validación y stress.
Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes. Gracias de antemano.
El que tenga dudas o aportaciones tiene para ello la sección de comentarios, intentaré responder a todos y con la máxima claridad. Los Blogs deben de ser lugares de intercambio y agradezco vuestro feedback.
dime y que haces si luego ejemplo 18 horas encuentras errores en alguna prueba, como comienza tu diagnostico
ResponderEliminarPues muy sencillo Juan, hago exáctamente lo mismo que si diese un fallo a los diez minutos de test:
ResponderEliminarAveriguar la causa del fallo, que tras muchos años de experiencia se intuye en función del tipo de error, y cambiar la configuración para solucionarlos.
En sistemas de estas características normalmente es un tema de timings o voltajes, piense que siempre hay que buscar los timings más rápidos con el voltaje más bajo. Es un compromiso.
Por esta razón la validación tan exhaustiva, son sistemas fuera de especificación.
Saludos.
tus articulos exceden con mucho mis conocimientos de tecnico en pc autodidacta con 20 años de experiencia, pero quiero agradecerte compartirlos y enseñarme nuevas forma de pensar. encontre todos muy utiles y mas que interesantes, un saludo cordial desde bs-as
ResponderEliminarDesde mi experiencia de más de 20 años de overclocker te puedo decir que esos programas que usas para testar no valen un pimiento :D
ResponderEliminarUsa LinX ( la últimisima version ) y verás que los equipos petan mucho más rápido.
Otro bueno es el OCCT ( la ultimísima versión también ) en Power Supply mode.
Verás que de tiempo ganas :D
Anónimo,
ResponderEliminarSería absurdo, y no va con mi carácter y mi formación, el empezar aquí una discusión sobre este tema. Para empezar me parece un sin sentido por tu parte irrumpir así en uno de mis Blogs...
Solo te diré que he usado LinX y el muy superior y excelente IBT (ambos utilizan binarios Linpack de Intel vectorizados y compilados específicamente para cada arquitectura) y empíricamente he visto que no son, ni de lejos, tan sensibles como Prime95 para detectar errores sutiles de procesamiento.
Partiendo de la basa de que todas mis máquinas tienen ajustes iniciales presuntamente estables, obtenidos por mi profundo conocimiento de la arquitectura subyacente tanto en procesadores, chipsets, memoria, GPUs,... (es mi trabajo y mi obligación saberlo todo del tema y es lo que justifica en última instancia mis honorarios) ejecuto siempre rutinas de validación de una duración de dos a tres semanas de media por sistema.
En algunos casos he llegado a las seis semanas, no es algo trivial y mis clientes entienden la complejidad del proceso.
Debo decir que mis clientes son especiales en sus necesidades, llevo años diseñando máquinas para utilizaciones críticas para universidades. Normalmente para simulaciones numéricas en las que un solo fallo es catastrófico y no puede contemplarse.
Mis Sistemas de Altas Prestaciones están avalados por su nula tasa de fallos debidos a ajustes inapropiados en frecuencia, voltaje o timings de memoria y otros ajustes así como su superior velocidad de cálculo o proceso a cualquier otra máquina del mercado estable. Y digo estable en términos absolutos.
Todo ello debido al largo y exhaustivo método de validación.
Te diré, para terminar, el porqué LinX no es un buen método de detección de errores sutiles (sí es bueno y rápido para errores de bulto; errores no permisibles en mis sistemas): las rutinas Linpack ejecutan un mix de instrucciones MUY reducido intentando siempre dar un pico en GFlops gracias a una excelente tasa de aciertos de caché.
Simplemente hablando y para que todos lo entiendan, ejecuta repetidamente pocas instrucciones y siempre del mismo modo, por ello no prueba todas las demás instrucciones X86 y además no activa muchas unidades de la CPU.
En síntesis, un sistema que no falla LinX durante un año, puede fallar otro test diferente (que utilice otro mix de instrucciones distinto y no busque un resultado pico en GFlops FPU) un minuto después.
Un saludo,
Carlos Yus Valero.
PD. También a mí me encantaría descubrir el Santo Grial de los programas de testing y conseguir uno que en diez minutos me asegurase la estabilidad absoluta de una máquina...
Hola, Carlos:
ResponderEliminarMe encantan tus artículos. Este, por ejemplo, lo encuentro interesantísimo.
Veo que hace meses que no publicas; imagino que debes tener otras obligaciones que te lo impiden. Si en algún momento te resulta posible sacar unos minutos para escribir por aquí, me encantaría que comentases si a día de hoy sigues usando los mismos programas para validar tus sistemas o si, por el contrario, has introducido algún cambio, ya que este artículo lo publicaste en 2009 y pienso que podría ser posible que algo de lo publicado en él ya no sea vigente.
Un cordial saludo,
Juan Carlos
Juan Carlos,
ResponderEliminarAgradezco tus felicitaciones, y sí, voy muy atareado con el trabajo y la familia... pero al fin he sacado algo de tiempo para publicar un nuevo artículo en ProfessionalSAT sobre los nuevos AMD Vishera FX:
http://professionalsat.blogspot.com.es/2012/11/amd-vishera-fx-8350-primeras.html
Un saludo,
Carlos Yus Valero.