HW vs SW: ¿por qué pierde rendimiento un equipo con el paso del tiempo?

Seguro que alguna vez te has preguntado el porqué de las bajadas de rendimiento progresivas con el paso del tiempo. Si es el mismo equipo, con el mismo sistema operativo, con el mismo hardware que el día que compraste tu equipo, y prácticamente con los mismos programas, etc. ¿a qué se debe? ¿por qué mi PC se vuelve lento?

¿Es el software el que se vuelve más lento con los años? ¿O tal vez el culpable es el hardware? ¿Quizás ambos? ¿Tal vez es un problema de mantenimiento? Esto es lo que intentaré aclarar en este artículo, ya que es una pregunta que me hacen a veces cuando algún familiar/amigo me han traído sus equipos para que los repare…

Introducción

Aunque la electrónica programable no sería nada sin los programas (HW y SW son inseparables), algunos culpan a una u otra parte. Probablemente ambos tengan parte de razón como intentaré explicar. Pero quizás unos tienen algo más de razón, por eso me gusta abrir este apartado con una frase que me gusta mucho recordar:

«El hardware es lo que hace a una máquina rápida; el software es lo que hace que una máquina rápida se vuelva lenta.«.

Craig Bruce

Seguro que no es la primera vez que compras tu flamante computador, lo enciendes por primera vez, y sientes esa sensación de rendimiento en comparación con tu viejo equipo. Pero, conforme pasa el tiempo, el sistema comienza a ser cada vez más lento, hasta tal punto que llega un momento en el que parece que no es el mismo equipo que compraste.

¿Es mi hardware el que pierde rendimiento con la edad? ¿Tal vez el software? ¿Es el momento de comprar un nuevo equipo? ¿Ha llegado la obsolescencia programada a tu equipo? No es tan sencillo contestar rápidamente a estas preguntas que seguro que te has hecho. Hay que ser cuidadoso y analizar cada caso particular, pero intentaré darte algunas pistas.

Desde el lado del SW

Siempre lo digo, es importante contar con un hardware potente, pero no lo es menos contar con un software optimizado. A lo largo del tiempo he visto casos muy escandalosos donde un software consume unos recursos realmente elevados frente a otro equivalente que, aparentemente, hace exactamente lo mismo.

Con esto quiero decir que no se puede dejar en manos de los consumidores la responsabilidad de mantener un rendimiento adecuado en sus sistemas. Los proveedores de software también deberían comprometerse a no vender código que no consume recursos, sino que los derrocha. Algunos parecen más los departamentos de ventas de las compañías de hardware (te incitan a comprar equipos más y más potentes), que desarrolladores responsables.

Además, no solo afecta la optimización de los binarios que se emplean, también tenemos el problema de los parches. Esas actualizaciones constantes que muchas veces agregan más y más líneas de código, y que necesitarán recursos de hardware. Si alguna vez te has fijado, y que es algo que confirma lo que digo, aquellos sistemas que se actualizan con menor frecuencia, la pérdida de rendimiento no es tan evidente como, por ejemplo, ciertos sistemas embebidos…

Peor aún es cuando compruebas que tras instalar un sistema operativo desde cero en tu mismo hardware, no vuelve a ser tan rápido como el primer día. Esto también tiene que ver con esas actualizaciones, muy probablemente, la ISO del sistema operativo que has descargado ya incluye toda esa batería de actualizaciones, por lo que no será el mismo sistema exacto.

O en el peor de los casos, esos parches para ciertas vulnerabilidades que pasan por dinamitar en gran metida el rendimiento al tener que hacer las cosas diferente a la óptima, o que implican pasos adicionales para evitar que dicha vulnerabilidad sea explotada.

Véase los casos como Spectre, Meltdown,… que han supuesto pérdidas de rendimiento considerables. En este caso, no hay que culpar al lado del SW, ya que es un problema con el que han tenido que lidiar los desarrolladores, pero que viene heredado de malas prácticas desde el lado del HW.

Desgraciadamente, las actualizaciones son inevitables para garantizar el buen funcionamiento de los sistemas y la seguridad. A eso se le agregan otras problemáticas, otras fuentes de ralentización del sistema como la fragmentación de los datos almacenados en los medios de almacenamiento, procesos en segundo plano que se van agregando debido a la instalación de nuevos programas, registros y «suciedad» acumulada por el uso, etc.

Afortunadamente, todas esas fuentes se pueden corregir realizando un buen mantenimiento del sistema. Esto sí que está en manos del administrador de sistemas o usuario. Por ejemplo:

• Es probable que procesos no acabados estén ocupando recursos de hardware que no se liberan, lo que empeora con el paso del tiempo si llevas mucho sin reiniciar el sistema. En un PC doméstico se puede simplemente reiniciar para solucionar este caso, pero no es así en un sistema de alta disponibilidad, como un servidor. En esos casos, existen procedimientos para hacerlo sin reiniciar. Aquí también entraría el bloatware/crapware…
• El software y archivos han ocupado gran parte de la unidad de almacenamiento. Cuando están al 85-90%, o más, pueden verse afectadas en cuanto a rendimiento. Bastaría con ampliar la capacidad o hacer una limpieza (desinstalar programas que no uses, eliminar temporales y otros residuos,…). En ciertos sistemas de archivos, la fragmentación de datos también puede ser una causa, por tanto, desfragmenta la unidad. Esto es más acusado en algunos tipos de FS como FAT y NTFS (especialmente el primero), que en otros como EXT4, ZFS, etc., de los sistemas *nix.
• Factores inherentes del propio sistema operativo o software. Por ejemplo, en sistemas Unix/Linux esto no es un problema, pero en Windows, su registro lo es.
• El malware también puede causar pérdidas de rendimiento, al estar usando recursos en un segundo plano. Bastaría con tener una buena política de prevención, y en caso de infección, analizar el sistema y eliminar la amenaza.
• Usar software mal optimizado. Busca aquel programa que consume la menor cantidad de recursos, es decir, aquel que esté más optimizado.
• Drivers o firmware desactualizado. En ocasiones, algunas actualizaciones no vienen a reducir el rendimiento, sino a aumentarlo. Es el caso de estos parches que suelen optimizar mejor el uso que se hace del hardware al controlan.
• Cuida también de no tener políticas de ahorro energético activas, o gobernadores de la CPU muy agresivos.
• Idioteces varias… Podía haberlo llamado miscelania, pero lo cierto es que en ocasiones algunos desarrolladores de software parecen tener complejo de decoradores. Por eso, cargan sus programas de multitud de adornos y efectos visuales que no hacen más que consumir recursos innecesarios…

Más información – Software aging

Desde el lado del HW

Ahora que he enfadado un poco a algunos ingenieros o desarrolladores de software, vamos a comenzar a quitarle la razón a Craig Bruce, y enfadar a los diseñadores de hardware… ¿o tal vez no? Bueno, ahora toca meterse en una zona más pantanosa, y es determinar si el hardware pierde rendimiento con el tiempo.

No me gustaría entrar en temas de obsolescencia programada, ya que eso sería otra cuestión. Es verdad que relacionada, pero no quiero ser mal pensado y ceñirme a suponer que los sistemas de hardware que nos venden están pensados para durar todo lo posible.

La cuestión aquí es, si el envejecimiento del hardware afecta a su rendimiento. Para eso, intentaré ir por partes. Bien, la parte que más afecta al rendimiento es la CPU, aunque lo que voy a especificar es aplicable a otros chips.

Xtal

De hecho, el oscilador de cristal (Xtal) que hay en la placa base, es el que marcará el ritmo del bus principal, y éste alimentará de frecuencia a las ranuras de expansión (GPU…), a la CPU, a la RAM, etc. Todas ellas tienen sus propios multiplicadores o divisores de frecuencia para trabajar a las frecuencias para las que han sido diseñadas. Pero se basan en la frecuencia base aportada por ese Xtal.

Es decir, si ese Xtal baja su frecuencia, también lo hará la de esos dispositivos. Por ejemplo, si el Xtal es de 25Mhz, se multiplicará por un factor X para generar la frecuencia del bus, y éste a su vez se multiplicará por otro valor en función de la frecuencia a la que trabaja la CPU, GPU, RAM, PCI/PCIe, SATA, etc.  Es como el corazón de un sistema circulatorio del equipo, llevando la sangre (frecuencia) a cada una de las partes acopladas a la placa base para que trabajen a cierto ritmo y con un determinado nivel de latencia cuando se habla de las interconexiones entre dispositivos.

Si eres electrónico, sabrás que el oscilador de cristal es un dispositivo piezoeléctrico que sufre de envejecimiento. Es un cambio gradual y lento, pero existe. Eso no quiere decir que suponga un serio problema, de hecho, probablemente sea casi despreciable. De hecho, la deriva con la edad es de unos 4 ppm (parts per million) durante el primer año, y de aprox. 2 ppm por cada año durante la vida útil del Xtal en adelante (varía según el modelo de oscilador). Eso indica una deriva de la frecuencia nominal mínima.

Para que te hagas una idea, 4 ppm representa una pérdida de 4/1000000 = 0,000004, es decir, la frecuencia perdida en el primer año será del 0.0004% con respecto a la nominal de ese cristal. Por tanto, no es una causa a la que atribuir esas pérdidas de rendimiento tan notables. Por ejemplo, para uno de 25Mhz supondría 0.0001004 Mhz de pérdida, o lo que es lo mismo 100,4 Hz.

Va a afectar más la tolerancia (± ppm) del propio Xtal que las pérdidas que se producen…

Otros problemas de los semiconductores

Mientras los dispositivos semiconductores del sustrato de un chip, y las interconexiones que hay sobre ellos, sigan en condiciones de funcionar, el chip seguirá adelante con su trabajo. En el momento que alguno de esos dispositivos se deteriore (movimientos de los portadores dentro del cristal, perforaciones en el aislante de la puerta, fusiones por temperaturas altas,…), o una de las interconexiones falle (se genere un cortocircuito al traspasar capas de pasivación, se corte generando un circuito abierto, estrechamientos debidos a la electromigración que dificulten el paso de los electrones,…), el chip dejará de funcionar. Pero ¿hasta entonces su funcionamiento será óptimo?

Bueno, durante los 15 años que pasé investigando y aprendiendo sobre esta temática, para crear la enciclopedia sobre microprocesadores que publiqué. Para ello, leí muchos libros, trabajos de investigación de multitud de universidades de todo el mundo (TFGs, Tesis Doctorales, TFMs), documentos publicados en el IEEE, etc. Recuerdo un artículo de Brandon Castellano publicado en el IEEE, en el que se detallaban multitud de problemas de envejecimiento de los semiconductores (p.e.: la electromigración) y su impacto.

Un chip debería durar cientos de años. Pero en la práctica no es así. A parte de los problemas citados, también suelen afectar otros factores como las roturas debidas a las tensiones mecánicas, como la vibración, la dilatación por lo cambios de temperatura (especialmente cuando se enciende o apaga el sistema), etc. Eso puede hacer que un chip se destruya en tanto solo unas décadas o unos años.

Aunque no sean notables, es probable que los chips semiconductores puedan verse afectados con el tiempo, aunque teóricamente no debería hacer que el rendimiento de la CPU caiga de forma notable para el usuario. Pero, en la práctica, es complicado determinar por varios factores:

• Los cambios son tan despreciables que resultan complicados de medir. Además, se necesita cierta instrumentación cara para realizar algunas inspecciones más a fondo.
• No hay dos chips idénticos, incluso a pesar de ser del mismo stepping y wafer, no serán idénticos en ningún caso. Puede haber pequeñas variaciones durante los procesos de fabricación que los puede hacer más o menos sensibles a fallas, que sean inestables a ciertos voltajes/frecuencias, etc. Por eso, aunque tuvieras dos chips aparentemente idénticos, no lo son.

Pero, teóricamente, si se pudiera clonar una CPU y almacenar una de las copias exactas mientras se usa la otra, pasado un lapso de tiempo (1-20 años), al comparar el rendimiento de ambas, no debería haber variado según los estudios de Brandon.

¿Y la memoria?

Se tiene que tener en cuenta también que ese deterioro citado anteriormente, también podría llevar a que ciertos unidades fallen. Si se depende de memorias ECC, esos sistemas podrían seguir funcionando, pero implicará una pérdida de rendimiento debido a las correcciones que se deben hacer.

Otros circuitos de memoria también dependen de ciertos circuitos analógicos, como la RAM para calibrar sus pines de entrada y salida. Esos circuitos tienen una degradación más acusada con el tiempo, generando un cierto retraso.

Throttling

Los actuales sistemas tienen técnicas de throttling, es decir, escalada dinámica de frecuencia, así como otros parámetros que pueden modificar el rendimiento en función de factores como la temperatura. ¿A dónde quiero llegar? Pues bien, si tienes un sistema con un mantenimiento nulo, o pésimo, se pueden dar los siguientes casos:

• Se acumula polvo/pelusa en los sistemas de refrigeración (filtros, disipadores y ventiladores), reduciendo su eficacia.
• La pasta térmica (TIM) se deteriora con el tiempo (degradación o evaporación) o es de mala calidad.
• Rodamientos del ventilador dañados, pérdidas de presión en el flujo de los sistemas de refrigeración líquida.
• Temperatura ambiental elevada por un cambio en la climatología de la zona.

Todo esos casos llevan a un incremento de la temperatura del sistema, lo que hará que ese throttling sea más acusado. Es decir, los mecanismos de protección de la CPU/GPU, bajarán la frecuencia de reloj para contrarrestar el aumento de temperatura, y eso implica una reducción considerable del rendimiento.

Aunque algunos no lo saben, en la GPU también se producen estos mismos mecanismos de ahorro de energía controlando la frecuencia de reloj, TDP, y se llegan a apagar unidades funcionales para ahorrar energía. Es decir, exactamente igual. De hecho, AMD usa tecnologías como AMD PowerTune, AMD ZeroCore Power, Duty Cycle Scaling (DCS), etc. Por ejemplo, en el caso de DCS, se monitoriza la corriente, la potencia, y temperatura de la GPU, y cuando algo excede el límite bajo una alta carga de trabajo, los núcleos se apagan durante una fracción de tiempo (tras renderizar un fotograma o frame) y, una vez los valores vuelven a estar dentro de los límites, se vuelven a encender. El tiempo lo determinará el firmware en función de los criterios de energía acumulada.

Es cierto que los portadores de carga de los semiconductores se pueden ver afectados también por la temperatura. En principio, esto no debería afectar a la conmutación, mucho menos bajo los rangos en los que se suelen usar (si no se tienen en cuenta temperaturas extremas).

Los portadores de carga (electrones y huecos) se vuelven más lentos con temperatura baja mientras que, a temperaturas más altas, mejora su número. Eso no significa que a mayor temperatura, mejor rendimiento. De hecho, aunque el número de los portadores mayoritarios crece con la temperatura, en un semiconductor extrínseco (dopado, como el usado en los chips), la movilidad de estos portadores disminuye, lo que causa que la conductividad decrezca.

Esa «pereza» de los portadores mayoritarios en las zonas P (huecos) y N (electrones), hará aumentar la resistividad, que es la inversa de la conductividad. Por tanto, gracias a las fórmulas de la Ley de Ohm y de potencia, no hay que ser muy avispado para saber que eso contribuye a aumentar la temperatura. Eso nuevamente afecta al throttling, a la electromigración, y se convierte en un círculo vicioso poco recomendable…

Chips longevos

Si el chip ha sobrevivido durante años, es probable que debido a cierto envejecimiento o deterioro con el tiempo, se genere cierta inestabilidad en el sistema. Ya sea debido a la degradación en la velocidad de conmutación, o por otros problemas citados anteriormente, esa inestabilidad podría «curarse» a golpe de underclocking/overvolting (¡ojo! aumentar el voltaje implicará hacer que los transistores envejezcan más rápidamente).

Ten en cuenta que una CPU es un circuito digital síncrono que necesita que se respete un cierto timing para dar los resultados esperados. Por tanto, reduciendo un poco el ritmo, se puede recuperar esa estabilidad perdida. Es decir, el underclocking pretende reducir la velocidad para darle más tiempo a esas unidades funcionales «seniles» de hacer su trabajo a tiempo.

En el caso del overvolting consistiría en darles un «chute» de «adrenalina» a los transistores para que puedan conmutar más rápido. Así, la velocidad de conmutación de los transistores del chip subiría, por lo que a igual frecuencia, no se estaría trabajando tan cerca del límite de la velocidad lógica, y no se generaría inestabilidad.

¿Chips autocorrectivos?

No tengo constancia de que esto se esté haciendo en los actuales chips, pero sí que he leído trabajos donde se insinuaban ciertas acciones interesantes que ahora detallaré. Y es que, con el crecimiento de las unidades funcionales, y núcleos, que se pueden integrar en un mismo chip monolítico, es posible que se pueda (o se haga en un futuro) desactivar algunas que dejan de funcionar adecuadamente.

Esto sí se hace de fábrica, desactivando ciertas zonas de memoria caché, o algunos núcleos que tienen algún defecto. Pero me estoy refiriendo a una vez se han comercializado, cuando ya están funcionando. Es decir, si los chips tienen capacidad de «auto-corregirse» sobre la marcha si alguna de sus unidades deja de funcionar.

Tampoco lo confundas con el apagado que se hace de forma temporal de algunas zonas o núcleos que no se están usando, como ya expliqué en el artículo sobre ACPI. No me refiero a eso, sino a dejar esas unidades que fallan apagadas de forma permanente. Es decir, que si una unidad funcional deja de funcionar, o un core, se marque como inutilizable y se deje sin usar.

Esto que digo también representaría una pérdida de rendimiento. Y no es tan descabellado, hay algunos estudios. Aunque, repito, no tengo constancia de que se haga.

Conclusión

Si con el deterioro se genera mayor resistencia en ciertas zonas del chip (más temperatura) debido al deterioro debido al envejecimiento, es probable que también el throttling comience a «hacer de las suyas» antes, y por tanto, el rendimiento se vea afectado. Pero eso no debería suceder en los primeros años, y en todo caso, no sería demasiado evidente como para que un usuario lo note demasiado (a excepción de los efectos de throttling, que sí se notan bastante).

Además, esos incrementos de temperatura debidos al envejecimiento son probablemente paliados por el aumento de la velocidad (RPM) de los sistemas de ventilación. Por tanto, no implicarán una bajada de rendimiento evidente para el usuario.

En definitiva, lo siento, pero la culpa la tiene el software…