Duron: el chip económico que la gente overclockeó como un tope de gama

octubre 10, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

Si alguna vez gestionaste un laboratorio de cajas beige, conoces el tipo de fallo que más duele: intermitente. No muerto al llegar, no un fallo limpio—simplemente una máquina que se reinicia una vez al día, corrompe una compilación cada tres ejecuciones y te hace dudar de tu propia cordura.

La era del AMD Duron fue una lección magistral sobre cómo el hardware “barato” puede comportarse como equipo premium—hasta que no lo hace. La gente empujaba estos chips como si fueran piezas tope de gama, y a veces salían bien parados. Otras veces inventaron nuevas definiciones de “inestable.”

Por qué el Duron importaba (y por qué se overclockeaba tan bien)

El Duron no estaba llamado a ser una leyenda. Era la línea de CPU económica de AMD, destinada a superar a las piezas de valor de Intel en precio y rendimiento aceptable. En cambio, se convirtió en un tema recurrente en foros de entusiastas porque a menudo se overclockeaba como una pieza que costaba el doble.

Pero hay una diferencia entre “arranca a una frecuencia más alta” y “ejecuta cargas de producción sin corrupción de datos”. La mayoría aprendió esa diferencia de la forma difícil, normalmente cuando un sistema de archivos empezó a devolver interpretaciones creativas de la realidad.

El Duron encontró un punto óptimo: IPC fuerte para su clase, ecosistemas de placas Socket A inusualmente ajustables para la época y una era de fabricación en la que los bins no siempre eran extremadamente estrictos. A veces realmente conseguías un casi-Athlon bajo una etiqueta más barata. Otras veces te tocaba un chip que pedía clemencia, no abuso del multiplicador.

Datos rápidos y contexto útil

Duron lanzado en 2000 como la respuesta económica de AMD al Celeron de Intel, usando Socket A (la misma familia de socket que muchos Athlon).
Los primeros núcleos “Spitfire” del Duron derivaban de diseños Athlon pero con caché L2 más pequeña, cambiando caché por precio.
Duron usaba un bus frontal DDR de 64 bits conceptualmente similar a la herencia del bus EV6 de Athlon, por lo que la memoria y la calidad del chipset importaban mucho al subir el FSB.
El famoso truco de desbloqueo del puente L1 (lápiz/pintura para desespumar) permitía a los usuarios cambiar multiplicadores en muchas CPUs Socket A, incluyendo Duron, dependiendo del stepping y del soporte de la placa.
Los chipsets VIA KT133/KT133A y posteriores definieron gran parte de la experiencia Duron: geniales para ajustes, pero también excelentes para enseñarte sobre el dolor de los divisores PCI/AGP.
Los Duron “Morgan” llegaron más tarde con mejoras (incluido soporte SSE en algunos steppings), y su comportamiento bajo overclock difería del Spitfire.
Muchos problemas de estabilidad achacados a “la CPU” eran en realidad problemas de entrega de energía: PSUs de gama baja y VRMs calientes fueron villanos recurrentes.
Las interfaces térmicas eran peores entonces: el montaje de disipadores y las pastas térmicas eran irregulares y provocaban gran variabilidad de temperatura entre configuraciones aparentemente “idénticas”.

Arquitectura y las razones reales por las que rendía por encima de su precio

Económico, pero no endeble

El Duron no era una CPU de juguete. Compartía mucho ADN con los diseños de la era Athlon, y eso importa. En la práctica, significaba que un chip económico podía ofrecer un rendimiento real sorprendente—especialmente en cargas intensivas en enteros y uso de escritorio general—si se combinaba con memoria decente y un chipset que no se tropezara.

La gente recuerda la diferencia de tamaño de la caché porque es la separación más limpia en la ficha técnica. Pero los resultados del overclock se moldeaban a menudo más por la plataforma: la calidad del generador de reloj de la placa, las opciones del BIOS, el diseño del VRM y si el bus PCI se volvía caótico al empujar el bus frontal.

Por qué el overclock “funcionaba” tan a menudo

El margen de overclock en esa era era a veces un efecto secundario de bins conservadores y de un mercado que avanzaba rápido. Los vendedores escalaban relojes agresivamente; los rendimientos y los steppings evolucionaban; y el mismo silicio básico podía aparecer en distintas gamas de producto con diferentes marcas y ajustes por defecto.

Los propietarios de Duron tuvieron suerte porque el segmento de valor creó una tubería de volumen. Alto volumen significa muchos puntos de datos para la comunidad. También significa que más “muestras doradas” aparecían en sitios de subastas y en equipos heredados de oficina. La leyenda se construye con las mejores historias, no con la experiencia mediana.

El intercambio oculto: también estabas overclockeando la placa

En Socket A, subir el FSB no solo estresaba la CPU. Estresaba los tiempos de memoria, la estabilidad del northbridge y a menudo los relojes PCI/AGP dependiendo del chipset y del soporte de divisores. Si no sabes qué hace tu chipset con los divisores a 112, 124, 133 MHz FSB y más allá, no estás “overclockeando”, estás jugando a la ruleta con tu controlador de disco.

Broma #1: Overclockear sin comprobar los divisores PCI es como cambiar neumáticos dando una patada al coche. A veces se mueve; no es el resultado que querías.

Cultura del overclock: lo que la gente hacía y lo que se perdían

La escena del overclock del Duron era práctica y caótica. La gente quería resultados con gasto mínimo, así que los rituales tenían sentido: desbloquear multiplicadores, subir FSB, añadir Vcore hasta “estable”, y luego presumir.

La pieza que faltaba era la validación disciplinada. “Estable” a menudo significaba “ejecutó un benchmark una vez”. En términos operativos, eso es como declarar que un servicio es fiable porque las comprobaciones de salud pasaron durante 30 segundos en un periodo tranquilo.

Multiplicador vs FSB: el intercambio que aún ves hoy

Cambiar el multiplicador estresa mayormente el núcleo de la CPU. Cambiar el FSB estresa toda la plataforma—memoria, chipset y a veces controladores de almacenamiento en formas desagradables. A los entusiastas les encantaba el FSB porque mejoraba el rendimiento general del sistema, pero también producía los fallos más confusos.

Si vas a revisar un Duron para construcciones retro o solo quieres entender la lección: prefiere aumentos de multiplicador primero para aislamiento. Luego sube el FSB con cuidado, con timings de memoria conocidos y pruebas explícitas de la estabilidad del bus. Si no puedes explicar por qué tu controlador IDE es estable al FSB objetivo, no has terminado.

Modos de fallo: cómo fallan los overclocks del Duron en el mundo real

1) “Arranca” no es estabilidad

El modo de fallo clásico: la máquina arranca, muestra UI, quizá incluso corre juegos, pero corrompe compilaciones, se bloquea bajo carga sostenida o falla durante I/O de disco intensivo. Eso no es misterioso. Es un timing marginal o entrega de potencia mostrando sus efectos con las peores combinaciones: CPU + memoria + I/O + soak térmico.

2) Soak térmico y deriva del VRM

Puedes pasar un benchmark rápido y aprobar, luego fallar 20 minutos después. Eso es soak térmico. El dado de la CPU se calienta, pero también lo hace el área del socket, los inductores del VRM, los MOSFET y el interior de la PSU. A medida que suben las temperaturas, las características eléctricas cambian. Vcore cae. El ripple aumenta. Los márgenes desaparecen.

3) Errores de memoria disfrazados de CPU

Las comunidades de overclock culpaban a las CPUs de todo porque las CPUs eran el componente llamativo. En realidad, muchos “problemas de CPU” eran inestabilidad en los tiempos de memoria. Módulos SDR/DDR antiguos con CAS/tRCD/tRP agresivos pasaban carga ligera y fallaban con patrones de acceso sostenido.

4) Corrupción PCI/IDE: el asesino silencioso

Si tu chipset no bloquea PCI, los aumentos de FSB pueden sacar a PCI fuera de especificación. Eso puede manifestarse como errores aleatorios de disco, corrupción de sistema de archivos o dispositivos que desaparecen. La parte más peligrosa: el sistema puede no caerse inmediatamente. Simplemente envenena tus datos lentamente.

5) “Más Vcore” y realidades de electromigración

Subir Vcore es un instrumento brusco. Puede estabilizar conmutaciones a frecuencias mayores, pero también aumenta calor y degradación a largo plazo. Con procesos de silicio antiguos, podías salirte con la tuya con algo de abuso—hasta que ya no. La falla aparece como un chip que antes hacía 950 MHz y ahora no sostiene 900 sin errores.

6) Comportamiento de PSU barata bajo cargas transitorias

Las fuentes de alimentación baratas de entonces a menudo tenían regulación débil y ripple alto, especialmente cuando el rail de 5V se usaba intensamente (común en placas antiguas). La inestabilidad de la era Duron está llena de historias donde reemplazar la PSU “arregló la CPU”. No arregló la CPU. Arregló la física.

Cita (paráfrasis de la idea): Gene Kim ha enfatizado repetidamente que la fiabilidad viene de sistemas disciplinados y bucles de retroalimentación, no de heroísmos.

Guía de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando un sistema clase Duron overclockeado es inestable, no “pruebas ajustes aleatorios del BIOS.” Aíslalo. Prueba. Cambia una variable a la vez. Aquí está la guía que ejecutaría si esto fuera un incidente de producción y quisiera la causa raíz, no buenas vibras.

Primero: clasifica la falla

Reinicio duro / reinicio instantáneo: entrega de energía, sobrecalentamiento del VRM, Vcore demasiado bajo, caída de la PSU.
Congelación bajo carga: térmica, inestabilidad del chipset, tiempos de memoria, relojes de bus.
Corrupción silenciosa (compilaciones malas, desajustes de checksum): errores de memoria, PCI/IDE fuera de especificación, estabilidad marginal de la CPU.
No hace POST: FSB/multiplicador demasiado agresivo, BIOS no aplica divisores, RAM no puede entrenarse, o mod de desbloqueo fallido.

Segundo: vuelve a una línea base conocida

Restablece el BIOS a valores por defecto.
Ejecuta con frecuencia y voltaje de CPU de stock.
Configura la memoria con timings conservadores.
Verifica la estabilidad con pruebas de estrés y comprobaciones tipo memtest.

Tercero: aísla dominios

Estrés solo CPU: mantén el FSB en stock, sube multiplicador si es posible.
Estrés de memoria: mantén la CPU cerca del stock, sube frecuencia/timings de memoria.
Estrés I/O: golpea disco y dispositivos PCI; vigila los logs.

Cuarto: haz un cambio y valida como si lo tomaras en serio

Validar significa horas, no minutos. Significa soak térmico. Significa ejecutar comprobaciones que detecten corrupción, no solo caídas.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas asumen un entorno Linux live o un Linux instalado en la caja retro. Si usas herramientas solo de Windows, el principio sigue siendo: medir, interpretar, decidir.

Task 1: Identify CPU, stepping, and current frequency

cr0x@server:~$ lscpu | sed -n '1,18p'
Architecture:            i686
CPU op-mode(s):          32-bit
Byte Order:              Little Endian
CPU(s):                  1
Model name:              AMD Duron(tm) Processor
CPU family:              6
Model:                   3
Stepping:                1
CPU MHz:                 900.000
BogoMIPS:                1795.68
L1d cache:               64K
L1i cache:               64K
L2 cache:                64K
Flags:                   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse

Qué significa: Confirma que realmente estás en una CPU clase Duron y muestra el stepping y los MHz reportados. Los flags pueden insinuar si se trata de un núcleo posterior (por ejemplo, presencia de SSE).

Decisión: Usa el stepping para fijar expectativas; trata los steppings tempranos como de menor margen. Si los MHz no coinciden con los ajustes del BIOS, tienes un problema de reporte de reloj o ajustes no aplicados.

Task 2: Verify kernel saw any machine check events

cr0x@server:~$ dmesg -T | egrep -i 'mce|machine check|cpu.*error' | tail -n 20
[Mon Jan  8 10:12:33 2026] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 4: b200000000070005
[Mon Jan  8 10:12:33 2026] mce: [Hardware Error]: TSC 0 ADDR fef1a000 MISC d012000100000000

Qué significa: Se detectaron errores de hardware. No todas las placas antiguas reportan MCE limpiamente, pero cuando lo ves, créelo.

Decisión: Retrocede el overclock o aumenta el margen de estabilidad (refrigeración/voltaje) antes de culpar al software.

Task 3: Check thermal sensors (if available)

cr0x@server:~$ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:     +62.0°C

w83627hf-isa-0290
Adapter: ISA adapter
Vcore:          +1.78 V  (min =  +1.60 V, max =  +1.85 V)
+5V:            +4.86 V  (min =  +4.75 V, max =  +5.25 V)
+12V:          +11.52 V  (min = +11.40 V, max = +12.60 V)
fan1:          4200 RPM  (min = 3000 RPM)

Qué significa: Temperatura y rieles plausibles pero nota Vcore cerca del límite superior y 5V ligeramente bajo.

Decisión: Si las temperaturas exceden lo cómodo (especialmente bajo carga), mejora la refrigeración antes de empujar la frecuencia. Si los rieles caen bajo carga, sospecha de la PSU/VRM.

Task 4: Watch Vcore and rails during load

cr0x@server:~$ watch -n 1 "sensors | egrep 'Vcore|\+5V|\+12V|Temp'"
Every 1.0s: sensors | egrep 'Vcore|\+5V|\+12V|Temp'

Core0 Temp:     +67.0°C
Vcore:          +1.74 V  (min =  +1.60 V, max =  +1.85 V)
+5V:            +4.78 V  (min =  +4.75 V, max =  +5.25 V)
+12V:          +11.44 V  (min = +11.40 V, max = +12.60 V)

Qué significa: Bajo carga, Vcore cae y el rail de 5V se acerca al mínimo.

Decisión: Si la caída se correlaciona con fallos, reduce el overclock o reemplaza la PSU / mejora la refrigeración del VRM. No sigas añadiendo Vcore a ciegas.

Task 5: Measure CPU throttling or frequency drift

cr0x@server:~$ grep -iE 'cpu mhz|bogomips' /proc/cpuinfo | head
cpu MHz		: 900.000
bogomips	: 1795.68

Qué significa: Confirma reporte de frecuencia estable (dentro de lo que esta plataforma puede exponer).

Decisión: Si los MHz fluctúan o el reporte es inconsistente, sospecha de mala configuración del BIOS o problemas de sensor/reloj; no confíes en números de benchmark.

Task 6: Stress CPU and watch for errors

cr0x@server:~$ stress-ng --cpu 1 --cpu-method fft --verify --timeout 10m
stress-ng: info:  [2217] setting to a 10 mins run per stressor
stress-ng: info:  [2217] dispatching hogs: 1 cpu
stress-ng: fail:  [2218] cpu:fft: verification failed on worker 0
stress-ng: info:  [2217] successful run completed in 46.12s

Qué significa: Fallo de verificación es una gran señal de alarma: errores de cálculo, no solo un crash.

Decisión: Retrocede frecuencia o aumenta margen de estabilidad (refrigeración, leve Vcore) y vuelve a probar. No uses sistemas de archivos importantes con esto.

Task 7: Stress memory and detect corruption patterns

cr0x@server:~$ stress-ng --vm 1 --vm-bytes 256M --vm-method all --verify --timeout 10m
stress-ng: info:  [2301] setting to a 10 mins run per stressor
stress-ng: info:  [2301] dispatching hogs: 1 vm
stress-ng: fail:  [2303] vm: verification failed: 0x00000000 != 0xffffffff
stress-ng: info:  [2301] successful run completed in 2m11.49s

Qué significa: El path de memoria es inestable (timings/frecuencia de RAM, northbridge o alimentación).

Decisión: Relaja timings de memoria, baja FSB o aumenta voltaje del chipset/IO si está disponible—con cautela. No eches la culpa a la CPU primero.

Task 8: Check kernel logs for IDE/ATA errors (PCI/FSB side effects)

cr0x@server:~$ dmesg -T | egrep -i 'ata|ide|dma|reset|I/O error|EXT4-fs error' | tail -n 30
[Mon Jan  8 10:26:41 2026] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[Mon Jan  8 10:26:41 2026] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[Mon Jan  8 10:26:41 2026] end_request: I/O error, dev hda, sector 128032

Qué significa: Errores CRC y DMA suelen mostrar problemas de timing del bus, problemas de cable o inestabilidad del controlador—clásicos cuando PCI está fuera de especificación.

Decisión: Reduce FSB, asegúrate del divisor PCI correcto, reemplaza el cable IDE y deja de escribir datos importantes hasta tener limpieza.

Task 9: Verify PCI devices and chipset identification

cr0x@server:~$ lspci -nn | sed -n '1,18p'
00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] [1106:0305]
00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT82C598/698 [Apollo MVP3/Pro133x AGP] [1106:8598]
00:07.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B IDE [1106:0571]
00:09.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139]

Qué significa: Confirma que estás en una plataforma clase KT133, que tiene comportamiento conocido de divisores y peculiaridades conocidas.

Decisión: Ajusta expectativas: empujar FSB puede arrastrar PCI/IDE. Prefiere ajuste por multiplicador si te importa la integridad del disco.

Task 10: Check filesystem for corruption after a crash

cr0x@server:~$ sudo dmesg -T | egrep -i 'EXT4-fs|XFS|BTRFS|JBD2|I/O error' | tail -n 20
[Mon Jan  8 10:29:03 2026] EXT4-fs warning (device sda1): ext4_end_bio:345: I/O error 10 writing to inode 262401 starting block 912345

Qué significa: El SO vio fallos reales de escritura (o mentiras del controlador). Esto no es “problema de benchmark”.

Decisión: Para las pruebas, revierte relojes, ejecuta un fsck offline y asume que los datos recientes pueden no ser fiables.

Task 11: Confirm disk health indicators (where supported)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'reallocated|pending|crc|overall|error'
SMART overall-health self-assessment test result: PASSED
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Pre-fail  Always       -       27

Qué significa: Los errores UDMA CRC indican problemas de enlace: cable, ruido eléctrico o bus fuera de especificación. No necesariamente medio fallando.

Decisión: Reemplaza cables y reduce FSB/estrés PCI. No hagas RMA del disco hasta que la plataforma esté en condiciones.

Task 12: Benchmark memory bandwidth changes from FSB tuning

cr0x@server:~$ sysbench memory --memory-block-size=1K --memory-total-size=2G run
Total operations: 2097152 (567843.12 per second)

2048.00 MiB transferred (554.53 MiB/sec)
General statistics:
    total time:                          3.6921s

Qué significa: Una cifra base de ancho de banda para comparar tras cambiar FSB/timings.

Decisión: Si ganaste 5% de ancho de banda pero introdujiste 0.1% de riesgo de corrupción, perdiste. Prioriza la corrección.

Task 13: Detect flaky RAM with a repeatable checksum loop

cr0x@server:~$ dd if=/dev/urandom of=/tmp/blob bs=1M count=256 status=none
cr0x@server:~$ sha256sum /tmp/blob
b3c9c1d0b1e6fbff4b3aa5f0f71e4a5c3f0a2b6b0fbd17f1d6efb9f1c1a3d4e5  /tmp/blob
cr0x@server:~$ sha256sum /tmp/blob
b3c9c1d0b1e6fbff4b3aa5f0f71e4a5c3f0a2b6b0fbd17f1d6efb9f1c1a3d4e5  /tmp/blob

Qué significa: Los checksums repetidos deben coincidir. Si no lo hacen, observas corrupción en memoria, disco o ruta del controlador.

Decisión: Si el desajuste ocurre con overclock pero no en stock, tu overclock no es “casi estable”. Está roto.

Task 14: Validate I/O under load (CPU + disk together)

cr0x@server:~$ sudo fio --name=burn --filename=/tmp/fiofile --size=512M --rw=randwrite --bs=4k --ioengine=sync --direct=1 --runtime=120 --time_based
burn: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1
fio-3.33
burn: (groupid=0, jobs=1): err= 0: pid=3122: Mon Jan  8 10:40:18 2026
  write: IOPS=823, BW=3292KiB/s (3371kB/s)(386MiB/120001msec)
Run status group 0 (all jobs):
  WRITE: bw=3292KiB/s (3371kB/s), 3292KiB/s-3292KiB/s (3371kB/s-3371kB/s), io=386MiB (405MB), run=120001-120001msec

Qué significa: No tener errores de I/O es bueno, pero esta prueba cobra sentido cuando se repite tras soak térmico y con estrés CPU en paralelo.

Decisión: Si aparecen errores solo bajo carga combinada, sospecha de caída del VRM/PSU o inestabilidad PCI/IDE—reduce FSB primero.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una asunción errónea

Un pequeño equipo de herramientas internas heredó un lote de sobremesas envejecidos reconvertidos en trabajadores de compilación. No eran críticos—hasta que lo fueron. El sistema de builds empezó a fallar de formas que parecían regresiones de software: fallos aleatorios de tests unitarios, segfaults ocasionales en código determinista y tarballs con checksums malos.

La asunción errónea fue simple y costosa: “Si la máquina arranca y funciona durante una hora, es estable.” Alguien había activado un overclock moderado años antes para acelerar compilaciones. Parecía inofensivo. Incluso parecía justificado: builds más rápidas, ingenieros más contentos, menos quejas.

Con temperaturas ambientales más altas, la tasa de fallos subió. El equipo persiguió fantasmas en compiladores y librerías. Congelaron paquetes, revirtieron cambios y construyeron reproducciones elaboradas. Los fallos se negaban a reproducirse de forma fiable en portátiles de desarrolladores, que es exactamente lo que la inestabilidad de hardware hace a tu presupuesto de depuración.

La solución fue humillantemente básica: volver a relojes de stock, ejecutar una verificación de memoria durante la noche, reemplazar dos PSUs que caían bajo carga y dejar de tratar “arrancó” como certificación.

La lección no fue “nunca overclockear.” Fue: nunca ocultes riesgo de hardware tras síntomas de software. Si vas a overclockear, documentalo como un cambio de producción, valídalo como si protegieras datos y móntoréalo como si esperases que te falle.

Micro-historia 2: La optimización que salió mal

Un grupo de ingeniería quería más rendimiento de una flota de máquinas retrofiteadas que hacían conversiones por lotes de medios. La carga era CPU-intensiva, pero también escribía salidas grandes. Tenían una teoría: subir el FSB para obtener mejor ancho de banda de memoria y una sensación general del sistema más ágil.

La optimización funcionó en el benchmark que les importaba. Los tiempos de conversión mejoraron un poco. La CPU fue más caliente pero dentro de lecturas “aceptables” de sensores. Difundieron el cambio por la flota porque parecía rendimiento gratis. A nadie le gusta decirle a dirección “decidimos ser más lentos por seguridad.”

Dos semanas después, la verificación de salidas empezó a fallar. No constantemente. Lo suficiente para doler. Los archivos ocasionalmente tenían corrupción sutil—frames equivocados, bloques de audio malos—cosas que pasaban por alto en comprobaciones superficiales. La tubería gastó más tiempo reprocesando de lo que ahorraba con el overclock.

Causa raíz: el aumento del FSB empujó el comportamiento PCI/IDE a una zona marginal en ciertas revisiones de placa. La ruta de almacenamiento corrompía escrituras de forma intermitente bajo soak térmico y I/O sostenido. La CPU estaba bien. La plataforma no.

Revirtieron a un ajuste solo por multiplicador en los pocos sistemas que lo soportaban, mantuvieron el FSB conservador y añadieron verificación obligatoria por checksum en la canalización. El rendimiento bajó ligeramente, pero el rendimiento efectivo subió porque el reprocesado se desplomó.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo distinto gestionaba un servicio on-prem para almacenamiento interno de artefactos. Tenían un par de cajas Socket A antiguas como espejos secundarios—nada glamuroso, pero útiles durante problemas de red. Una caja era conocida como “ajustada” porque el propietario anterior le gustaba exprimir performance de todo.

La práctica del equipo era dolorosamente aburrida: cada trimestre hacían una ventana de mantenimiento que incluía verificar backups, ejecutar comprobaciones de sistema de archivos, revisar contadores SMART y hacer una prueba de carga controlada. No porque algo estuviera mal, sino porque así mantienes que “nada está mal” sea verdad.

Durante una de estas ventanas, notaron un aumento en UDMA_CRC_Error_Count en un disco y algunas entradas en el kernel que olían a inestabilidad del bus. El servicio aún no había fallado. Los usuarios estaban contentos. Las métricas estaban tranquilas. La caja sonreía mientras afilaba un cuchillo.

Reemplazaron el cable IDE, bajaron el FSB a stock y revalidaron el espejo. Un mes después llegó una ola de calor y la refrigeración del edificio se degradó. La caja que habría corrompido datos en su lugar siguió funcionando. Sin incidente, sin drama, sin fin de semana perdido.

Esta es la verdadera habilidad del overclock: saber cuándo “aburrido y correcto” vence a “rápido y frágil.”

Errores comunes: síntoma → causa raíz → solución

Síntoma: Reinicios aleatorios durante juegos o compilaciones
Causa raíz: Caída de Vcore bajo soak térmico; sobrecalentamiento del VRM; problemas de regulación de la PSU
Solución: Mejora flujo de aire del VRM, reemplaza la PSU, reduce la combinación Vcore/frecuencia; valida con carga mientras observas los rieles.
Síntoma: Fallos tipo memtest o desajustes de checksum solo cuando está overclockeado
Causa raíz: Timings de RAM demasiado agresivos; FSB demasiado alto para el northbridge; voltaje de memoria insuficiente (si ajustable)
Solución: Relaja CAS/tRCD/tRP, baja FSB, añade VDIMM modesto si está disponible, retesta durante la noche.
Síntoma: Errores de I/O de disco, errores CRC, advertencias de sistema de archivos tras subir FSB
Causa raíz: Reloj PCI fuera de especificación; timing marginal del controlador IDE; cable malo amplificado por ruido
Solución: Asegura divisor PCI/bloqueo correcto, reduce FSB, reemplaza el cable, detén escrituras hasta comprobar limpieza.
Síntoma: El sistema pasa pruebas cortas pero se cae tras 30–60 minutos
Causa raíz: Soak térmico que afecta CPU, chipset, VRM; curva de ventilador insuficiente; mal montaje del disipador
Solución: Remonta el disipador, renueva la pasta térmica, prueba con ejecuciones largas, añade flujo de aire en caja.
Síntoma: No hace POST tras cambio de multiplicador/intento de desbloqueo
Causa raíz: Mala conexión del puente; BIOS sin soporte de control de multiplicador; multiplicador demasiado alto al arrancar
Solución: Borra CMOS, revierte el mod físico, arranca en stock y luego aumenta de forma incremental.
Síntoma: “Estable” pero el rendimiento es peor de lo esperado
Causa raíz: Memoria funcionando asíncrona o en timings de fallback conservadores; comportamiento tipo thermal throttling; BIOS aplicó mal ajustes
Solución: Verifica frecuencia/timings de memoria, retesta ancho de banda, confirma relojes reales y temperaturas.
Síntoma: El overclock se degrada con los meses (necesita más Vcore para la misma frecuencia)
Causa raíz: Electromigración acelerada por voltaje y calor; estrés del VRM; ciclos térmicos a largo plazo
Solución: Reduce Vcore, mejora la refrigeración, acepta un reloj estable más bajo; deja de tratar la degradación como “mala suerte.”

Broma #2: El Duron enseñó a una generación que “rendimiento gratis” es un servicio por suscripción facturado en horas de resolución de problemas.

Listas de verificación / plan paso a paso

Paso a paso: un overclock sensato para Duron (estabilidad primero)

Línea base stock: Restablece BIOS, ejecuta relojes/voltajes de stock, timings RAM conservadores. Ejecuta estrés de CPU + memoria al menos 1–2 horas.
Instrumenta: Asegúrate de poder leer temperaturas y rieles (aunque sea aproximado). Si no puedes medirlo, no puedes gestionarlo.
Prefiere multiplicador primero: Aumenta el multiplicador en pasos pequeños manteniendo el FSB stock. Valida cada paso con pruebas verificadas de estrés.
Solo entonces toca el FSB: Sube el FSB en incrementos pequeños. Tras cada cambio, revisa errores PCI/IDE en logs.
Mantén la RAM honesta: Si sube el FSB, relaja timings proactivamente. No esperes a que la corrupción te lo enseñe.
Disciplina de voltaje: Añade Vcore solo cuando sea necesario y después de verificar térmicas y comportamiento de droop. Anota lo que cambiaste.
Validación de soak térmico: Ejecuta pruebas lo suficiente para calentar todo (CPU, VRM, PSU). Las ejecuciones cortas engañan.
Comprobaciones de integridad de datos: Usa bucles de checksum y estrés de I/O. Si puedes corromper un archivo, puedes arruinarte la vida.
Documenta: Anota ajustes del BIOS, stepping, disipador, temperatura ambiente. El tú del futuro olvidará y culpará al tú del pasado.
Detente en “aburridamente estable”: El último 3–5% de reloj es donde los fallos resultan caros.

Lista operativa: si esta máquina contiene algo que te importa

Mantén backups que realmente hayas restaurado.
Ejecuta comprobaciones periódicas de sistema de archivos y SMART.
Monitorea errores CRC y advertencias de I/O del kernel.
Mantén flujo de aire sobre los VRMs; añade un pequeño ventilador si hace falta.
Prefiere ligera sub-frecuencia y estabilidad sobre ajustes heroicos.

Preguntas frecuentes

1) ¿Por qué el Duron se overclockeaba tan bien comparado con otros chips económicos?: Porque no era un diseño recortado simplista; compartía linaje arquitectónico con piezas AMD de gama superior y a menudo tenía margen real. La capacidad de ajuste de la plataforma ayudó también.
2) ¿Es más seguro overclockear por multiplicador que por FSB en Socket A?: Normalmente, sí. Cambios en el multiplicador estresan mayormente la CPU. Cambios en el FSB estresan memoria, chipset y a veces relojes PCI/IDE—donde vive la corrupción.
3) ¿Cuál es la señal más peligrosa de inestabilidad?: La corrupción silenciosa: desajustes de checksum, archivos dañados, fallos de tests aleatorios. Un crash limpio es molesto; la corrupción es traición.
4) ¿Necesito subir Vcore para overclockear un Duron?: No siempre. Prueba la frecuencia con buena refrigeración primero. Si debes subir Vcore, hazlo al mínimo y vigila térmicas y droop bajo carga.
5) Mi sistema se cae solo después de 30 minutos. ¿Por qué?: Soak térmico. Eres estable en frío e inestable cuando el VRM/PSU/chipset se calientan. Valida con pruebas largas y mejora el flujo de aire.
6) ¿Cómo sé si la corrupción de disco se debe al overclock?: Busca errores IDE/ATA, errores CRC y advertencias de sistema de archivos correlacionadas con cambios en FSB. Si revertir FSB lo arregla, esa es la respuesta.
7) ¿Puede una PSU mala imitar inestabilidad de CPU?: Absolutamente. La caída de rieles y el ripple bajo cargas transitorias pueden provocar reinicios, errores de cálculo e I/O inestable. Reemplaza la PSU antes de perseguir fantasmas.
8) ¿Cuál es un objetivo responsable para un “retro overclock”?: El reloj más alto que pase estrés largo y verificado de CPU+memoria y no muestre errores de I/O, con temperaturas cómodas. No el MHz más alto que arranque.
9) ¿Debería overclockear si la máquina funciona como servidor de archivos?: No, a menos que disfrutes aprender cómo huele la corrupción. Si debes hacerlo, mantén el FSB conservador, valida I/O intensivamente y guarda backups.
10) ¿Por qué dos Duron “mismo modelo” se comportan distinto?: Diferentes steppings, variación en el silicio, calidad del VRM de la placa, diferencias en el montaje del disipador y calidad de la PSU. La plataforma es parte de la CPU.

Conclusión: qué hacer a continuación

El Duron se ganó su reputación porque entregó rendimiento desproporcionado por el dinero y porque Socket A invitaba a la experimentación. Pero la lección real no es “overclockea todo.” Es que la estabilidad es una propiedad del sistema. CPU, memoria, chipset, VRM, PSU, refrigeración, buses—si cualquiera de ellos es marginal, no tienes una máquina rápida. Tienes una máquina que miente.

Pasos prácticos siguientes:

Vuelve a stock y establece una línea base limpia con pruebas largas y verificadas de CPU y memoria.
Decide si tu objetivo es velocidad o confiabilidad; no finjas que puedes optimizar ambos sin prestar atención.
Prefiere aumentos de multiplicador sobre FSB cuando sea posible; trata cambios de FSB como un cambio de plataforma, no de CPU.
Valida con cargas que detecten corrupción (checksums, estrés verificado, I/O bajo carga), no solo “no se cayó”.
Arregla la alimentación y la refrigeración antes de perseguir MHz. La mejora de rendimiento más barata suele ser una PSU competente y flujo de aire sobre el VRM.