jueves, 1 de noviembre de 2012

AMD Vishera FX 8350. Primeras impresiones – ProfessionalSAT

Siendo sincero debo admitir que me ha sorprendido gratamente el nivel de prestaciones de la nueva serie de CPUs FX de AMD basadas en el nuevo stepping dotado de cores Piledriver.

En un artículo de LowLevelHardware exploré detalladamente las mejoras que aportaba este core refinado, este nuevo stepping a la conocida micro arquitectura Bulldozer de AMD.

PiledriverCORE_640Piledriver module con sus 2 MB de caché L2.

Podríamos sintetizar las mejoras en dos fundamentales:

- Por un lado una menor disipación térmica por core y un menor voltaje mínimo estable a una frecuencia dada. A igual frecuencia menor consumo y temperatura.

- Por otro lado un aumento IPC de un 5 a 30% en función de la carga de trabajo (enteros, branches, coma flotante, SSE, AVX,…) A igual frecuencia más rendimiento.

Gracias a estas dos mejoras AMD ha conseguido incrementar la frecuencia base del FX 8350 en 400 MHz.

PDvsBSAMD FX8150 vs. FX8350. Bulldozer vs. Piledriver.

En modo Turbo Core Vishera aplica el Turbo máximo en todas las situaciones, es decir, en carga máxima de un thread (ST, single threaded) o de varios threads e incluso 8 threads simultáneos (MT, multi threaded):

BD_TurboTurbo Core en FX8150 Bulldozer.

Podemos decir, para simplificar, que en Vishera el estadio intermedio Turbo Core desaparece.

En la práctica, medido por mí mismo, un Vishera FX8350 a 4 GHz en Prime95 Blend 4 GB consume exactamente lo mismo a un Bulldozer FX8150 a 3.6 GHz a voltajes nominales.

PiledriveModule_640Bulldozer module 32 nm SOI HKMG.

Como deduciréis fácilmente, Vishera aportará un 11% más de frecuencia en cargas paralelas y en cambio no incrementa nada en cargas single threaded. Por ello en cargas ST el rendimiento solo aumentará por el incremento de IPC y en cambio en cargas MT se sumará el 11% de frecuencia nominal al incremento IPC.

Undervolting

A esto debo añadir que tanto en los antiguos FX Bulldozer como en los nuevos Vishera AMD ha sido bastante exagerado en cuanto a los voltajes a los que vende sus CPUs. Normalmente son absolutamente estables a voltajes 0.100 – 1.150 V inferiores a los nominales. Con ello además ganamos unos 20 – 30 W en consumo y 10 – 15 ºC de temperatura. Merece la pena hacerlo aunque con ello perdamos horas o incluso a veces algunos días.

AMD debería hacer este proceso en fábrica pero resulta laborioso y por ello caro. De este modo saca al mercado las CPUs a un voltaje excesivamente prudente para asegurar su estabilidad sin probar individualmente en exceso cada uno de los chips para ajustar individualmente su voltaje.

Piledriver. Mejoras micro arquitecturales respecto a Bulldozer.

AMD ha mejorado Bulldozer en muchos aspectos aunque sin cambiar nada importante del diseño, de hecho Piledriver no es más que un stepping más avanzado del mismo core.

piledriver_enhancements_640

Se ha mejorado el Branch Prediction, algo crítico en este diseño debido a su larguísimo pipeline. Esto mejorará el rendimiento sobretodo en cargas de enteros.

Se ha activado la unidad de división de enteros (INT Div, iDiv) que estaba deshabilitada en Bulldozer por un fallo de diseño, como comenté en Abril de 2011 en mi artículo:

AMD AGLUs, Bulldozer INT cores. Actualizado – LowLevelHardware

“ EX0 contiene una unidad de división de enteros parcialmente pipelinizada y con latencia y capacidad de proceso variable en función de la precisión. Aunque examinando detenidamente la documentación parece que más bien se trata de una unidad “virtual” ya que la instrucción IDIV se decodifica en el Microcode Engine y se secuencia en instrucciones sencillas ALU que se ejecutan en EX0. Además incluye una unidad para LZCNT y POPCNT.

Efectivamente, en Bulldozer, la unidad iDiv no estaba habilitada y por ello la latencia y velocidad de las divisiones de enteros eran tan decepcionantes. Por fin, en Piledriver se encuentra habilitada.

Se ha doblado el tamaño del L1 dTLB (TLB de datos de nivel 1). Para el que quiera amplia información sobre para que sirve un TLB le remito a algunos artículos pasados.

piledriver_enhancements2_640

En total todas estas mejoras aumentan el IPC de un 5 a 30%, en general sobre un 10%. En el caso del 30% es más por un rendimiento terrible de Bulldozer en algunas tareas que por méritos de Piledriver.

En cualquier caso podríamos caracterizar las prestaciones de Piledriver en el AMD FX8350 del siguiente modo:

- Cargas de trabajo de enteros con excelente paralelización y con carga máxima en los 8 INT cores. Ejemplo: compresión de datos en WinRAR o 7zip LZMA2. Prestaciones generalmente muy superiores al Core i5 3570K y superiores al Intel Core i7 3770K.

- Cargas de trabajo de coma flotante con excelente paralelización y con carga máxima en las 4 FPUs FMACs con 8 threads.

  Ejemplo 1: Rendering, cálculo matemático. Prestaciones generalmente bastante superiores al Core i5 3570K y ligeramente inferiores al Core i7 3770K. En PovRay en cambio el más rápido y por buen margen es el FX8350.

   Ejemplo 2: Edición y codificación de video x264 / H264. Prestaciones generalmente superiores al Core i7 3770K y muy superiores al Core i5 3570K.

- Cargas de trabajo principalmente de enteros con baja paralelización y raras veces con carga máxima en 4 INT. Ejemplo: SysMark 2012, compilación y usos multitarea de la máquina en Windows con varias aplicaciones a la vez. Prestaciones muy similares o algo inferiores al Core i5 3570K (como mucho un 10%).

- Cargas de trabajo de enteros single thread o con paralelización muy leve. Ejemplo: instalaciones de software, instalación de sistema operativo, javascript. Prestaciones inferiores a Core i5 3570K hasta un 40% en proceso javascript.

Si hacemos la media el FX8350 nos da un rendimiento superior en un 5% al Core i5 más alto de gama, el i5 3570K que está situado por encima en precio (unos 20 – 30@ más).

El Core i7 3770K se sitúa en un nivel de prestaciones superior gracias al Hyper Threading como atestiguan sus más de 150€ extras de coste.

Conclusiones

Lo más positivo que puedo sacar de Vishera es su notable aumento de velocidad de trabajo en aplicaciones ofimáticas respecto a Bulldozer (ha mejorado más de un 20%) y el hecho de haberse convertido en el rey en prestaciones en temas de video, sobretodo en coding x264. En estos casos supera incluso al excelente y mucho más caro Core i7 3770K.

FX8350_640El die completo del procesador AMD FX 8350 32 nm.

Vishera mantiene exactamente los niveles de consumo y disipación térmica de los anteriores AMD FX con un rendimiento medio en cargas multithread de un 20% (ayudado por los 400 MHz extras) superior y un 5 – 10% en cargas single thread (con igual frecuencia).

Post Scriptum

Animo a los posibles compradores de estas CPUs a cambiar el funcionamiento nominal de Turbo Core. AMD ha dejado invariado el Turbo Core con carga single threaded o dual threaded a 4.2 GHz respecto a Bulldozer.

En Bulldozer FX8150 la disipación térmica y consumo era prácticamente igual con cargas MT de 8 threads (3.6 GHz) que en single o dual threaded (4.2 GHz) e igual a 125W.

En Vishera, en cambio, con cargas de 8 threads (4.0 GHz) llega a los declarados 125W en Prime95 pero con cargas single o dual threaded (4.2 GHz) se queda corto marcando unos 100 – 105W.

Los samples que he probado del AMD FX8350 son absolutamente estables en cargas single o dual threaded a voltaje nominal a 4.6 GHz y manteniendo siempre la disipación térmica por debajo de los 125W nominales. Para ello, en BIOS, cambio manualmente el funcionamiento de Turbo Core aumentando el multiplicador máximo a 46X.

En este caso conseguimos otro 9 – 10 % adicional de velocidad en casos ST (single threaded), el talón de Aquiles de esta micro arquitectura.

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.

miércoles, 4 de abril de 2012

Degradación física de la memoria DDR3 en cargas de trabajo de saturación – ProfessionalSAT

En mi vida profesional mi dedicación principal consiste en garantizar la estabilidad y exactitud en cálculo de las máquinas que diseño: mis Sistemas de Altas Prestaciones.

Por ello siempre me encuentro en una constante búsqueda de mejores y más perfectos métodos de validación de sistemas (de lo que hablo en SATSoftware) y en el estudio de todos los procesos que influyen en su tasa de fallos, entre ellos la electromigración.

Una gran parte de los errores de cálculo que aparecen en un sistema tras un largo periodo de uso intensivo se deben a la degradación eléctrica de los chips de DRAM DDR3 de los módulos DIMM de la máquina.

Samsung_DDR3 (2)Uno de los chips DDR3, un  Samsung, presente en alguno de mis sistemas.

En mis Sistemas de Altas Prestaciones suelo utilizar módulos de 2 GB y 4 GB de DDR3 1333 o 1600 normalmente de marca Kingston (módulos Kingston, los chips son de varios fabricantes: Elpida, Hynix, Samsung, Kinston…)

Valoro especialmente un voltaje de operación bajo, normalmente 1.50V, por encima de timings extraordinarios (por su limitadísimo efecto sobre el tiempo de cálculo).

3DIMM_4GB_DDR3_1333_thumb[1]12 GB de DDR3 Kingston a 1333 MHz.

En todas mis máquinas utilizo 6 o 12 GB en triple channel DDR3 a frecuencias que oscilan entre los 1450 y los 1600 MHz con latencias típicas de 8-8-8-24-1N y como he comentado a 1.50V.

Parámetros que influyen en la degradación de los chips DRAM DDR3

Son varios los aspectos que marcan la velocidad de deterioro de las constantes eléctricas de los semiconductores, para alargar su vida en lo posible hay que tenerlos en cuenta y trabajar sobre cada uno de ellos para limitar los daños.

Primer factor: El voltaje. Cuanto más bajo es el voltaje menor degradación eléctrica se producirá en los chips DDR3 debido al proceso de electromigración.

Los electrones golpean (literalmente) a los átomos metálicos de cobre o aluminio y los desplazan de sus posiciones originales, degradando las características eléctricas de los data paths (aumentando la resistencia de los conductores eléctricos, así como la disipación térmica y produciendo errores de datos).

Además, a mayor voltaje, mayor consumo y disipación térmica lo que causa un aumento de temperatura.

Segundo factor: La temperatura. A menor temperatura menor degeneración física de los chips DDR3. Se produce menos leakage en los transistores y menor disipación térmica y consumo eléctrico. En todos mis sistemas intento conseguir temperaturas sobre los 30ºC en los DIMM en carga 100% sostenida.

A mayor temperatura, más vibraciones de los átomos metálicos de los conductores en las celdas DRAM y con ello mayor intensidad de electromigración.

Tercer factor: La carga de trabajo. Partamos de la base de un software de cálculo matemático FPU que utilice al 100% los todos los threads disponibles en la máquina, es decir, cargas de saturación 100% en CPU.

Lógicamente no será lo mismo un software de cálculo que acceda a la RAM, digamos cada cien millones de ciclos de CPU porque obtenga tasas de aciertos de caché L1, L2 y L3 combinadas del 99.999% (por ejemplo) que otro algoritmo de cálculo que por su set de trabajo enorme de tasas de fallo de cachés de un 15%.

Sinus_8X_2min_2_thumb[3]Carga de trabajo de saturación conjunta CPU y DRAM DDR3.

Este último caso presentará tasas de acceso a RAM que saturarán todas las controladoras DDR3 presentes y con ello una muy intensa carga en los DIMM DDR3. Ningún problema si no fuese porque estas cargas, yo y muchos de mis clientes, las aplicamos durante años seguidos (sin pausas ni reinicios) sobre nuestras máquinas, mis ya habituales Sistemas de Altas Prestaciones.

Mis observaciones

En un conjunto formado por 36 máquinas Core i7 de la serie 900 pertenecientes al stepping D0 de Nehalem 45 nm configuradas todas ellas con 3 módulos DDR3 de 2 GB (total 6 GB) o de 4 GB (total 12 GB) he observado lo siguiente:

En ocho de estos sistemas han fallado simultáneamente 15 módulos DDR3 de 2 GB y 4 GB tras unos tiempos de cálculo acumulados de 12 a 21 meses (cálculo continuo sin pausas ni reinicios, estos sistemas sólo se apagan para tareas de mantenimiento cuando hay algún fallo hardware).

De estos 36 equipos únicamente dos de ellos se han apagado para sustituir dos discos duros averiados (de los 72 discos totales) y dos más por avería en la fuente de alimentación.

Para la limpieza periódica de radiadores y ventiladores se mantienen los sistemas encendidos en cálculo y se efectúa el mantenimiento con aire comprimido, normalmente cada mes.

En resumen, tras una media de 11500 horas de cálculo continuo han dado errores de cálculo 8 de las 36 máquinas.

Tras exhaustivos tests, que han durado 3 semanas, se ha localizado la avería limitada a 15 DIMMs DDR3. Ningún otro componentes de las máquinas ha sufrido daños.

Uno de ellos, el que daba el error más grave, fallaba Memtest en el test 0, no duraba ni un segundo.

P95B2048_Fallo_18h30A las 7:35AM falló esta máquina tras 18h 30 min de tests.

El que daba el error más rebelde falló en Prime 95 tras 18h de test Blend con set de trabajo de 2048 MB y Round off checking y SUM(INPUTS) error checking activados.

P95X64

En todos ellos he sustituido los 3 DIMMs por nuevos (24 DIMMs en total) y tras 120h de testeo se han incorporado de nuevo a sus tareas de cálculo sin presentar nuevos fallos.

P95B2048_121h42minPrime95: 121h y 42 minutos de test. 2832 tests por thread sin errores.

Tras unos 20000 tests de cálculo por sistema en Prime 95 X64 ejecutados en unas 120 horas por equipo he dado por estables las máquinas y ya están de nuevo desempeñando su trabajo.

Conclusiones

En las próximas semanas o meses preveo el fallo de más DIMMs DDR3 hasta llegar al total de la población de estos sistemas (108 DIMMs, 3 DIMMs por 36 máquinas).

Consulta mi nuevo artículo sobre electromigración en LowLevelHardware.

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.

jueves, 16 de febrero de 2012

Memoria Transaccional en Intel Haswell 22 nm – ProfessionalSAT

Intel ha confirmado la inclusión en su nueva micro arquitectura Haswell 22 nm (disponible en 2013) de extensiones de aceleración (Transactional Synchronization o Intel TSX) hardware para acceso a memoria transaccional, un avance significativo y que posibilitará un mejor aprovechamiento del acceso simultáneo a RAM de varios threads o cores.

TSX_Haswell_01Los primeros estudios de Intel en memoria transaccional datan de 2005.

En este artículo de perfil bastante técnico explico en que consiste el concepto de memoria transaccional y las variaciones respecto al manejo actual de la memoria y hago una introducción de la implementación de Intel en sus nuevos cores Haswell 22 nm.

Intel_HaswellIntel Haswell 22 nm.

El modelo actual

Durante años, y en la actualidad, el acceso a memoria concurrente por varios procesos o threads se resolvía mediante locks o bloqueos (Lock-based synchronization of shared data access) de la página de RAM.

Una dirección de memoria a la que un proceso (un thread) accede se bloquea hasta que el thread daba señal de que había acabado su trabajo. Esto se hace para proteger contra colisiones en acceso a memoria: un thread puede intentar escribir (cambiar el valor) en una dirección de memoria mientras otro thread está procesando instrucciones con el valor pasado (el anterior a la escritura) de esa posición.

En este caso podría darse corrupción de datos y un fallo de ejecución en el software. De ahí el lock pues debe siempre respetarse el orden temporal de los accesos a memoria que colisionen. Gracias a Memory disambiguation, sólo el de los que colisiones. Anteriormente todo el proceso de acceso a RAM era en orden (in order).

Digamos que este mecanismo lock-based es altamente pesimista, por algunas veces que pueden haber problemas en el acceso concurrente se prohíbe siempre el acceso simultáneo y se serializa el acceso a memoria. Esto tiene en muchos algoritmos graves consideraciones prestacionales pues limita la ejecución multithread.

La memoria transaccional, de la que hay numerosas implementaciones por software (aquejadas de graves problemas de velocidad), propone un mecanismo para evitar estos locks y con ello conseguir accesos concurrentes a paginas o estructuras en RAM cuando no haya conflictos (colisiones de memoria).

Memoria transaccional en Intel Haswell 22 nm

Intel integra en Haswell una implementación de Intel TSX de dos vías (HLE y RTM) para la memoria transaccional, ambas con soporte de aceleración hardware.

TSX_Haswell_02

En la imagen anterior las cinco operaciones se deben ejecutar de manera secuencial, en orden temporal. Con memoria transaccional pueden ejecutarse simultáneamente por varios threads con la condición de que no se altere el resultado final.

Intel-Tick-Tock

En esencia la memoria transaccional permite un acceso paralelo a RAM por varios threads aunque accedan a la vez a las mismas estructuras o páginas. Y en caso de conflicto proporciona un mecanismo para deshacer los procesos y volver a una ejecución serializada de los accesos a RAM.

HLE (Hardware Lock Elision)

HLE funciona del siguiente modo: mediante prefijos modifican la función normal de las instrucciones de acceso a memoria que bloquean y desbloquean la estructura de datos en RAM.

Para realizar un lock se utiliza el prefijo XACQUIRE, para deshacerlo XRELEASE. Para el thread que utiliza el prefijo XACQUIRE el lock se ejecuta con normalidad (el thread cree que la estructura de datos en RAM está bloqueada para toda la máquina), en realidad no es así y el resto de threads pueden procesar con acceso a dicha estructura.

Cualquier thread puede entonces acceder al lock (con XACQUIRE) y operar, con lo que puede obtenerse un incremento tangible de concurrencia y velocidad.

HLE es un modo en el que el procesador miente a los threads y les concede el lock incondicionalmente y simultáneamente, pero la CPU tiene un mecanismo de resolución de conflictos por si el thread escribe en el lock. De hecho el procesador monitoriza por hardware todas las direcciones RAM que el thread lee o escribe desde el momento en que accede al lock.

En este caso todas las operaciones ejecutadas posteriormente sobre el lock son inválidas y la CPU debe cancelarlas (se aborta la transacción) y precargar los datos anteriores conocidos como correctos antes de realizarse el lock.

En caso (XRELEASE) de ausencia de conflictos todas las operaciones en RAM se ejecutan atómicamente en una sola transacción actualizando así el contenido de la RAM para que el resto de threads puedan acceder a estos datos actualizados.

Lo verdaderamente interesante de HLE es que es compatible con hardware anterior, las CPUs anteriores a Haswell simplemente ignoran los prefijos XACQUIRE y XRELEASE porque para ellas no significan nada y ejecutan el código con el antiguo modelo lock-based.

RTM: Restricted Transactional Memory

RTM es incompatible con procesadores actuales. Los programadores de un software deberán desarrollar dos versiones del código (una con RTM y una lock based). En CPUs Haswell y compatibles se ejecutará la versión optimizada RTM.

A día de hoy RTM tiene un menor interés, sólo comentaré que cuenta con nuevas instrucciones (XBEGIN, XEND, ABORT) que el código utilizará explícitamente. Es decir, es totalmente incompatible con hardware actual y llevará años llegar a ver implementaciones significativas de RTM.

Conclusiones

Intel TSX es otra extensión al juego de instrucciones X86 y ya van… rondamos ya las 1000 instrucciones. La utilidad de TSx se hará evidente en software multi-threaded que compartan datos activamente. Por ejemplo programas que accedan en paralelo a matrices de datos…

Las-CPUs-Intel-Haswell-llegan-en-2013

Habrá que ver aplicación por aplicación los beneficios que aportará, será interesante en bases de datos, en cálculos de simulaciones físicas, incluso en determinadas aplicaciones de Excel.

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.

domingo, 12 de febrero de 2012

Core i7 2600K 4.6 GHz Liquid Cooling nVidia 580 GTX – ProfessionalSAT

En este periodo he tenidos los Blogs bastante abandonados, ha sido no por dejadez o aburrimiento sino por exceso de trabajo y falta de tiempo. Confío poder retomar a la actividad con una cadencia suficiente en los próximos meses y como aperitivo os dejo este artículo.

Para esta máquina se seleccionaron los componentes pensando, además de en una estabilidad absoluta en cualquier condición, en unas temperaturas y niveles de ruido reducidos.

DSCF5193

El procesador es un Core i7 2600K Sandy Bridge se configuró a su frecuencia límite a un voltaje prudente. En este caso, en Prime95 X64 Blend 4 GB, el voltaje en carga es de 1.36V y la frecuencia a la que es absolutamente estable son 4.6 GHz con temperaturas pico en cargas de saturación 100% de 76ºC en el core más caliente tras 8h de stress.

Aunque a algunos les pueda parecer extraño, como placa base he elegido una AsRock Z68 Pro3. Un excelente modelo con un precio que ronda los 100€ y permite grandes aumentos de frecuencia en cores a voltajes moderados.

El sistema de refrigeración del procesador es un Corsair con bomba integrada en el radiador de CPU y velocidad variable en tres posiciones. Fue elección del cliente, pues yo prefiero sistemas por aire como el excelente Scythe Mugen 2 B.

DSCF5195

la configuración de memoria consiste en un dual channel de 4 DIMMs DDR3 de 4 GB para un total de 16 GB a 1600 MHz con timings 8-8-8-24 2N a 1.50V. En este caso opté por un voltaje muy reducido a costa de unos timings no muy brillantes para favorecer un consumo reducido de las controladoras de memoria integradas en CPU.

El objetivo era la mayor velocidad de proceso y en este caso, el margen de consumo y temperatura obtenido con este sacrificio en rendimiento de la RAM es aprovechado por el gran consumo de los 4 cores procesando 8 threads simultáneos a 4.6 GHz sostenidos.

DSCF5192

La tarjeta gráfica elegido es una Gigabyte GF 5800 GTX con un sistema de ventilación triple que demostró ser extremadamente eficaz, manteniendo unas temperaturas realmente excelentes, sobretodo teniendo en cuanta el verdadero monstruo de chip que tienen que refrigerar.

DSCF5197

Es importante señalar que el nivel de ruido del sistema en carga máxima es realmente bajo, el mayor ruido proviene de la GTX 580 y no llega a resultar nada molesto incluso en una habitación en silencio.

Se debe a mi aplicación desde hace años del principio de refrigeración por exceso de presión o presión positiva. Consiste en introducir mediante ventiladores más aire en la torre que el que evacuamos activamente produciendo así mayor presión interna que la atmosférica y haciendo que el calor “salga solo”.

DSCF5199

El calor producido por la CPU y la GTX 580 (unos 500W en pico) es expulsado naturalmente y en silencio y con muy pocos ventiladores.

DSCF5200

La fuente de alimentación es, como es costumbre en muchos de mis sistemas, una Corsair de la serie AX. En este caso el modelo de 850W, sobrada potencia y sobretodo un rendimiento eléctrico excelente que arroja muy bajos consumos en el enchufe.

DSCF5201

Tenía curiosidad por probar si las rpm de la bomba influían en la temperatura de los cores en carga máxima, pero en este sistema, con su excelente ventilación, no noté diferencia alguna.

Mención especial merecen los dos ventiladores que Corsair adjunta con el sistema de refrigeración líquida. Son toscos, ruidosos y de diseño de antes de la guerra… suerte que el control de velocidad de la BIOS de la placa AsRock Z68 Pro3 me permitió un fino control de rpm con la carga de CPU y un nivel de ruido inaudible.

Si no tenéis una placa con estas cualidades o no tenéis los conocimientos necesarios para regular estos ventiladores os recomiendo sustituirlos por algo de más calidad.

DSCF5198

Por las ranuras traseras visibles en la foto anterior se evacúa casi todo el calor de la GTX580.

DSCF5202

El sistema operativo, Windows 7 X64, se instaló en un SSD OCZ Agility 120 GB con la última versión Firmware de SandForce.

Es un modelo de reducido precio y muy buenas prestaciones.

DSCF5190

A la hora de elegir una GPU de altas prestaciones, en primer lugar se debe decidir el procesador necesario, en este caso una GTX 580. La mejor disponible cuando se montó la máquina (hoy día tenemos las AMD HD7970).

DSCF5189

Pero es muy importante después elegir que marca y modelo comprar, sobretodo comparando el sistema de refrigeración. En este caso fue un absoluto acierto, sorprendente teniendo en cuenta la bestia escondida bajo el chip de la GTX580 y su enorme consumo.

DSCF5182

Hasta la próxima.

Y echad un vistazo a la preview en LowLevelHardware (mi Blog de micro arquitectura) de los nuevos cores Piledriver de AMD.

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.