viernes, 29 de octubre de 2010

Sistemas de Altas Prestaciones: Core i7 930 a 4 GHz. Actualizado – ProfessionalSAT

Estoy estos días ocupado en la preparación de varios Sistemas de Altas Prestaciones basados en el actual sweet spot en procesadores: el Intel Core i7 930 para LGA1366.

DSCF0262Core i7 920 y Core i7 930, ambos stepping D0.

La configuración consta de un triple canal DDR3 de 6 GB y una tarjeta gráfica nVidia 8400GS. De las especificaciones deduciréis que el cliente no es precisamente un gamer… Realmente su utilización es en cálculo matemático continuo con ejecutables vectorizados con la última versión del Intel Fortran Compiler optimizados para arquitectura Nehalem.

DSCF0524El sistema sufriendo los primeros tests en Windows 7 Ultimate X64.

Un condicionante de las máquinas diseñadas para este cliente es que debo moderar en lo posible la emisión térmica debido a que son sistemas que nunca están en reposo. En realidad están continuamente realizando cálculos vectorizados en coma flotante.

Frecuencias objetivo

En todos mis Sistemas de Altas Prestaciones lo que persigo es el máximo rendimiento, eso sí sin renunciar a una estabilidad absoluta y en cualquier circunstancia.

En este caso el procesador ha sido configurado a 4 GHz gracias a un multiplicador 22 y a un Bclock de 181 MHz. 4 GHz es una frecuencia perfectamente asumible para un procesador Core i7 D0 seleccionado y se logra a un voltaje moderado, en este caso a 1.325 V.

DSCF0525El Asus Triton 88 es un buen conjunto para estos requerimientos.

Tras realizar numerosas pruebas y hablando de placas y BIOS actuales he comprobado que es bastante poco útil superar los 3.266 GHz en el Uncore: es necesario aumentar considerablemente su voltaje para conseguir un bajo retorno en rendimiento (menos de un 2%).

Configuración final:

XR11

La frecuencia del Uncore
 
Al aumentar la frecuencia del Uncore en un procesador Core i7 llegamos a un punto de no retorno en cuanto a temperatura. El Uncore de la serie Nehalem está diseñado con transistores optimizados para bajo consumo (bajo leakage) pero no para altas frecuencias.
 

Es por ello que necesitamos aumentar demasiado el voltaje del Uncore para subir por encima de los 3.266 GHz de modo estable. Yo considero ya excesivo superar los 1.30 V, aunque sé que sin peligro para el procesador se puede ir más allá, pero a costa de un aumento no lineal (exponencial) de la disipación térmica y la temperatura.

 
DSCF0525_2
A estas frecuencias se debe evacuar el calor rápidamente.
 
Tened en cuenta que estas máquinas tardan unos 20 días en ejecutar un ciclo de cálculo y en ese tiempo el uso de CPU se sitúa en un 100% en los ocho threads, es absolutamente crítico no superar los 80ºC.
 
Cuando acaban un cálculo, empiezan otro y así durante su vida útil, estimada en algo más de un año (en ese momento serán sustituidos por sistemas Sandy Bridge), a los 6 meses aproximadamente realizamos una “parada técnica” de una semana en el que se chequea lo siguiente:
  • Revisar estrictamente los sistemas
  • Efectuar una limpieza intensiva
  • Cambio de la interfaz térmica del procesador (a veces también del chipset o la GPU)
  • Control de temperaturas mediante monitorización software
  • Control de voltajes mediante monitorización software
  • Comparación con los valores iniciales
  • Control en video HD1080 y fotográfico de los componentes y nivel de ruido
  • Control térmico con termómetro infrarrojo de los Hot Spots
Por otro lado hay que contar con que actualmente este cliente posee ya 10 sistemas idénticos a este en lo esencial (con frecuencias de 3.8 a 4 GHz, todos ellos con 6 GB y W7 X64) y están todos ellos en un despacho de la facultad en utilización continua. Como os imaginareis también debo cuidar el aspecto del ruido en reposo y en carga máxima y el consumo…
 
PIC04358
También hay que prestar atención a las fases de regulación de voltaje.
 
No solo hay que mimar al procesador, pues hay otros componentes sometidos a stress no nominal, entre ellos destaca el chipset X58.
 
El chipset X58 cuenta con un bus QPI que comunica con el procesador a 4.8 GHz nominalmente, en este caso su frecuencia es de 6.51 GHz al tratarse de un sistema fuera de especificación. Este hecho, junto con el incremento del BCLK de 133 a 181 MHz obliga a adecuar la refrigeración de este chip.
 
Para ello en estos sistemas siempre monto sobre el chipset un ventilador adicional de revoluciones variables controlado por temperatura.

PIC04359El radiador del X58 visto a través de su ventilador.

Cuando acabe con esta primera etapa de validación inicial, procederé al montaje del sistema y por último a la validación final junto con los ajustes de refrigeración y minimización de voltajes.

DSCF0269Experimentos en uno de mis sistemas personales con otro Asus Triton 88 y un Noctua.

10 comentarios:

  1. Hola de nuevo Carlos. Voy a seguir de cerca este nuevo trabajo tuyo, tengo el mismo micro y memorias (quiero decir DDR3 triple canal) y seguro me valen para mis propios fines. Yo también estoy en la línea de los 4 ghz. Aunque mis voltajes sobre el micro son bastante menores, cosa que me resulta rara puesto que de primeras, ya los pones a 1.32V. Evidentemente cada vez he ido subiendo más el listón y ahora empieza el verdadero reto. Prime95 blend con "Round checking on" activo, me tira un error a las horas (8 o así) en determinados núcleos en los que figura este texto: "rounding was 0.5 espected less than 0.4" He leído de todo sobre este error con opiniones a veces demasiado dispares. Qué voltaje o voltajes influyen en ese tipo de fallos? He leído que puede ser fallo de memoria, pero le hice 11 pasadas antes de memtest86 y todo normal, y claro con el micro a 4ghz.
    No quiero nada mascado, pero se agradecería por lo menos tener una hoja de ruta y no dar palos de ciego. El sistema está configurado de la siguiente manera, 4.0 Ghz 200x20 Ram 8x 1600 Mhz, por consiguiente uncore x16 3200 Mhz y el Qpi a 7.2 Ghz.

    Podría ser tema de temperaturas, aunque el micro no pasa de 62º, podría ser falta de V, Vcore 1.25 (1.248 real) V uncore 1.235 las memos de fábrica a 1.6V

    No espero que me digas haz esto o lo otro, no. Pero a ser posible y desde tu experiencia, ¿A qué e puede deber?

    Sintiendo mucho la gran parrafada;
    Gracias y un saludo.

    ResponderEliminar
  2. Como siempre Carlos, brillante trabajo, de paso de las preguntas de PS3RO, vienen las mias :P.
    ¿Por alguna razón el Intel compiler?, que tal el de PGI. Lo pregunto porque...ya sabes lo que hace intel en su compilador de C, yo para alguna cosa puntual lo usé pero desde que vi la zancadilla que hace en el código....que les dén.
    Otra cosa, estos maquinones que montas, a la hora de limpiar el polvo ¿se dejan limpiar?

    Un saludo....y a seguir publicando más posts!

    ResponderEliminar
  3. ¿Por qué tus clientes no usan CUDA?

    Tratándose de cálculos paralelos en coma flotante creo que la diferencia puede ser muy grande.

    CPU sin ocear, respetando la vida útil de chipset, memoria y procesador, una placa con abundantes PCI Express 16x como las Asus WS, 4 baratitas 460 GTX que ya cambiarás el año que viene y refrigeración por agua, apuesto a que hace menos ruido, consume menos y es más barato. Y si la potencia es la que dice Nvidia, estamos hablando de 50 veces más capacidad de cálculo...

    ResponderEliminar
  4. Ya siento el spameo, no puedo editar el mensaje.

    He leído que algunos de tus clientes llegan a tardar 20 días en obtener resultados ¿no les interesaría usar memoria ECC?

    Según Google Research un 8% de las memorias dan un fallo en un año de trabajo contínuo (24/7), no sé si tirar dos semanas de cálculo por ahorrar unos cientos de euros merece la pena. Por cierto, Tesla tiene memorias ECC por si te animas con lo de CUDA.

    ResponderEliminar
  5. PS3RO,

    Sí, creo que es falta de voltaje. Ten además en cuenta el Vdroop.

    A 4 GHz, para ser absolutamente estable se suele necesitar sobre 1.30 a 1.33 V efectivos, es decir, en carga máxima 100% en los 8 threads.

    En BIOS, según la placa base y la fuente de aliemntación puede ser necesario ajustar en Vcore a algo más por la pérdida de voltaje debida al altísimo (más de 200W) de una CPU configurada de este modo en carga máxima.

    Sobre el Uncore, a 3.2 GHz sobre 1.25 V suele estar OK, aunque algunos micros algo lentos necesitan hasta 1.30 - 1.325 V para estabilidad total.

    Un saludo,

    Carlos Yus.

    ResponderEliminar
  6. Christian,

    El Intel compiler da código óptimo (dentro de la tecnología actual) para los procesadores Intel y por eso lo utilizamos.

    El día que AMD produzca un procesador más rápido en estos cálculos paralelos y vectorizados, probablemente debamos de cambiar de compilador.

    Ten además en cuenta que tenemos la licencia original del IFC.

    Sobre el polvo y la limpieza:

    Periódicamente, sobre cada 6 meses de uso ininterrumpido hacemos una "parada técnica" que incluye limpieza total, cambio de interfaz térmica y control de temperaturas y voltajes comparándolos con los originales.

    Saludos,

    Carlos Yus.

    ResponderEliminar
  7. Diego,

    Primero, a día de doy y para cálculos de esta índole CUDA no provée una plataforma suficiente a nivel de precisión.

    Segunda cuestión, CUDA solamente rinde realmente en sistemas TESLA y no con SVGAs standard como las que apuntas en las que por BIOS y hardware se limita su potencia de proceso FPU de 64 bit muy importantemente.

    Por cierto, cichas tarjetas TESLA no son baratas...

    Sobre consumir menos, obviamente no es cierto y de lejos. Un sistema CUDA como el que comentas (con CPU "de seie") serían unos 300W - 350 W más efectivos y requeriría una fuente bastante "especial" por su ingente consumo en las fases de 12V.

    Tercera cuestión, CUDA no es 50X más rápido con código optimizado en ambos sistemas... Claro, nVidia tiene interés en publicitarlo de ese modo.

    Las GPUs actules TESLA son muchísimo más rápidas que un Core i7 en cálculo PERFECTAMENTE paralelizable que requiera una precisión de 32 bit y no tanto en 64 bit de precisión.

    Las CPUs actuales (y no las GPUs) pueden calcular con 128 bit de precisión.

    Sobre la memoria ECC y los soft y hard errors, conozco el excelente estudio estadístico del White Paper de Google, aunque si te interesa conocer en profundidad el tema los mejores y más profundos estudios son de IBM. Si te interesa te puedo dar enlaces... aunque son de nivel post universitario y requieren conocimientos avanzados de física.

    Yo mismo hice un brevísimo esbozo en 2008 en este artículo:

    http://satsoftware.blogspot.com/2008/03/memtest86-y-memtest86.html

    El tema es relamente apasionate y he profundizado mucho en ello en los últimos años.

    Resumiendo, el ECC aporta:

    - Muy inferior velocidad de proceso debido a mayor saturación en los buses de memoria y a la imposibilidad páctica de configurara estos sistemas fuera de especificación.
    - Detección y corrección de algunos tipos de errores de memoria a nivel de chip o de bus.
    - Detección de otros errores sin corrección posible, el sistema lo soluciona repitiendo la transacción.
    - Un importantísimo incremento del coste del sistema.

    Estos errores se pueden dividir en Soft y Hard errors, siendo Hard los provocados por un módulo de memoria o placa base (chipset, cableado hasta el DIMM, socket DIMM...) defectuoso y soft errors los producidos por perturbaciones externas (fluctuacíones eléctricas, temperatura, rayos cósmicos, radiación ionizante...

    La gran mayoría de hard errors se diagnostican en unas semanas de tests de stress intensivos y diseñados al efecto y los soft errors disminuyen enormemente con el voltaje aplicado y cuidando al máximo la alimentación (fuente, cableado, ferritas, filtrajes previos, fases eléctricas dedicadas, SAIs...) y teniendo los equipos a nivel del mar (como aquí en Tarragona) por el mayor apantallaje atmosfécrico contra las partículas ionizantes extraterrestres.

    Algún día quizás ... escribiré una serie de artículos al efecto.

    Un saludo,

    Carlos Yus.

    ResponderEliminar
  8. Entonces, la ECC no sale a cuenta porque es muy cara (bueno, es cara la placa y la CPU) y no se puede subir de velocidad.

    Y Tesla es una pasta y las gráficas no dan la precisión necesaria. Vaya :( Es una pena porque me encantaría verte montar un equipo con 4 Teslas en una EVGA SR-2.

    PD: Comentaba lo del gasto energético porque si realmente es tan potente como dice Nvidia se ahorraría en tiempo de ejecución. Ya veo que no.

    ResponderEliminar
  9. Hola. He bajado el bclk a 190 y he subido el multiplicador a 21. He incrementado el voltaje del "uncore" en 0.150. Vcore 1.250 (igual). 30 pasadas linx 24 horas blend 18 horas small (no pude más) 30 pasadas linx y 0 problemas. De todas formas subiré un poco más el voltaje y comprobaré temperaturas. Gracias por la respuesta anterior.

    Saludos.

    ResponderEliminar
  10. Diego,

    CUDA no es que sea "malo" sino que las GPUs calculan a 64 bit.

    De todos modos todo está en cambio constante. Próximamente, con AVX habrá 256 bit de precisión FPU en los procesadores Intel y AMD, Sandy Bridge y Bulldozer.

    PS3RO,

    Me alegro de que ahora parece que ya es estable, aunque personalmente no me gusta LINX Linpack.

    Pasa también P95 InPlace con Round off Checking activado 24h, vigilando temperaturas...

    Cautela con la subida de voltaje, sé muy estricto en el control térmico.

    Un saludo,

    Carlos Yus.

    ResponderEliminar