![\"AMD](\"https:\/\/itconnect.lat\/portal\/wp-content\/uploads\/2023\/06\/AMD-EPYC-Rome-e1685896600414.webp\" "\\"\\"")
<\/a>Este hallazgo plantea numerosas preguntas e inquietudes. \u00bfCu\u00e1les son las posibles causas del problema? \u00bfC\u00f3mo afecta a la estabilidad y confiabilidad del sistema en su conjunto? \u00bfQu\u00e9 impacto tiene en las operaciones empresariales y los centros de datos que dependen de estos procesadores de alto rendimiento?<\/p>\n
Adem\u00e1s, es importante considerar las implicaciones a largo plazo de esta decisi\u00f3n de AMD de no abordar el problema. \u00bfSignifica esto que los usuarios tendr\u00e1n que lidiar con un tiempo de actividad limitado en sus sistemas? \u00bfC\u00f3mo afectar\u00e1 esto la reputaci\u00f3n de AMD y su posici\u00f3n en el mercado de servidores?<\/p>\n
El problema identificado en los procesadores EPYC de segunda generaci\u00f3n de AMD se origina en la incapacidad del n\u00facleo para salir del estado de suspensi\u00f3n CC6. Este estado de suspensi\u00f3n tiene como objetivo ahorrar energ\u00eda al reducir la actividad del n\u00facleo cuando no se requiere un rendimiento m\u00e1ximo. Sin embargo, en este caso, el n\u00facleo enfrenta dificultades para salir de este estado y recuperar su funcionamiento normal.<\/p>\n
Seg\u00fan AMD, el momento exacto en el que se produce esta falla puede variar seg\u00fan el espectro ensanchado y la frecuencia REFCLK. El espectro ensanchado es una t\u00e9cnica de modulaci\u00f3n de se\u00f1al utilizada para aumentar la capacidad de transmisi\u00f3n y mejorar la resistencia al ruido en comunicaciones inal\u00e1mbricas. Por otro lado, la frecuencia REFCLK es el reloj de referencia utilizado por el chip para realizar un seguimiento preciso del tiempo.<\/p>\n
Estos factores externos, como el espectro ensanchado y la frecuencia REFCLK, pueden influir en el tiempo exacto en el que se produce la falla del n\u00facleo. Dado que estos elementos pueden variar en diferentes entornos y configuraciones de sistema, resulta complicado predecir con precisi\u00f3n cu\u00e1ndo ocurrir\u00e1 la falla en cada caso espec\u00edfico.<\/p>\n
La explicaci\u00f3n brindada por AMD pone de relieve la complejidad del problema y la dificultad de proporcionar una soluci\u00f3n generalizada.<\/p>\n
Sin embargo, esta declaraci\u00f3n tambi\u00e9n plantea inquietudes sobre la estabilidad a largo plazo de los sistemas que dependen de estos procesadores y c\u00f3mo los usuarios pueden gestionar eficazmente los riesgos asociados con este inconveniente.<\/p>\n
El problema radica en la incapacidad del n\u00facleo para salir del estado de suspensi\u00f3n CC6, y AMD ha se\u00f1alado que el momento de la falla puede variar debido a factores como el espectro ensanchado y la frecuencia REFCLK.<\/p>\n
Esta situaci\u00f3n plantea desaf\u00edos adicionales para los usuarios y subraya la necesidad de abordar cuidadosamente el impacto potencial de esta falla en los sistemas que utilizan los procesadores EPYC de segunda generaci\u00f3n.<\/p>\n La teor\u00eda presentada por el usuario de Reddit acid_migrain plantea un enfoque interesante para determinar el momento exacto en que se produce el bloqueo del n\u00facleo.<\/p>\n Seg\u00fan esta teor\u00eda, el problema en realidad se manifiesta aproximadamente a los 1042 d\u00edas y 12 horas de tiempo de actividad.<\/p>\n El usuario relaciona su teor\u00eda con el funcionamiento del contador de tiempo TSC (Time Stamp Counter), que funciona a una frecuencia de 2800 MHz.<\/p>\n Luego, realiza un c\u00e1lculo multiplicando esta frecuencia por 10^6 y luego por 1042.5 d\u00edas. El resultado obtenido, 0x380000000000000, es una representaci\u00f3n hexadecimal con m\u00faltiples ceros.<\/p>\n El usuario sugiere que esta coincidencia en la cantidad de ceros en el resultado no puede ser simplemente una casualidad, y podr\u00eda estar relacionada con el momento en que se produce el bloqueo del n\u00facleo.<\/p>\n Si bien la teor\u00eda presentada es interesante y puede brindar una posible explicaci\u00f3n, es importante tener en cuenta que es una especulaci\u00f3n basada en observaciones y c\u00e1lculos realizados por un usuario en Reddit.<\/p>\n No hay informaci\u00f3n oficial de AMD que respalde o confirme esta teor\u00eda espec\u00edfica.<\/p>\n Sin embargo, esta teor\u00eda resalta el hecho de que el problema en los chips EPYC de AMD puede tener una relaci\u00f3n compleja con el tiempo de actividad y otros factores internos y externos.<\/p>\n Ilustra c\u00f3mo los entusiastas y la comunidad de usuarios pueden intentar desentra\u00f1ar y comprender mejor las causas detr\u00e1s de este problema.<\/p>\n La soluci\u00f3n propuesta para abordar el problema en los chips EPYC de AMD consiste en dos enfoques principales. El primero es reiniciar el servidor antes de alcanzar los 1044 d\u00edas de tiempo de actividad. Al hacerlo, se reinicia el “temporizador” interno de 1044 d\u00edas de la CPU, lo que supuestamente evitar\u00eda la falla del n\u00facleo relacionada con el estado de suspensi\u00f3n CC6.<\/p>\n El segundo enfoque sugerido es deshabilitar completamente el estado de suspensi\u00f3n CC6 en el sistema. Al hacerlo, se evita que el n\u00facleo entre en este estado de bajo consumo de energ\u00eda, lo que te\u00f3ricamente eliminar\u00eda el riesgo de bloqueo despu\u00e9s de un per\u00edodo prolongado de tiempo de actividad.<\/p>\n Ambas soluciones apuntan a evitar el problema al reiniciar el temporizador interno de la CPU o al evitar por completo el estado de suspensi\u00f3n CC6. Sin embargo, es importante tener en cuenta que estas soluciones pueden tener implicaciones en t\u00e9rminos de rendimiento, consumo de energ\u00eda y funcionalidades relacionadas con el ahorro de energ\u00eda.<\/p>\n Adem\u00e1s, estas soluciones no abordan directamente la ra\u00edz del problema y se basan en enfoques de mitigaci\u00f3n en lugar de una soluci\u00f3n completa y definitiva proporcionada por AMD. Por lo tanto, los usuarios deben considerar cuidadosamente las implicaciones y los compromisos asociados con estas soluciones antes de implementarlas.<\/p>\n En \u00faltima instancia, para obtener orientaci\u00f3n precisa y actualizada sobre este problema espec\u00edfico y las soluciones recomendadas, es recomendable consultar la documentaci\u00f3n oficial y las declaraciones de AMD, as\u00ed como buscar asesoramiento adicional de expertos en la materia.<\/p>\n Si bien el error de bloqueo del n\u00facleo despu\u00e9s de 2,93 a\u00f1os puede parecer un problema con un impacto limitado debido a la necesidad de actualizaciones de seguridad y mantenimiento m\u00e1s frecuentes, sigue siendo un asunto relevante por varias razones.<\/p>\n En primer lugar, aunque las actualizaciones de seguridad y el mantenimiento son esenciales y deben llevarse a cabo en intervalos m\u00e1s cortos, el hecho de que exista un problema que pueda provocar un bloqueo del n\u00facleo despu\u00e9s de un per\u00edodo prolongado de tiempo de actividad plantea interrogantes sobre la confiabilidad y la estabilidad de los sistemas.<\/p>\n Aunque se realicen actualizaciones y mantenimiento peri\u00f3dicos, este error podr\u00eda presentarse en situaciones en las que el tiempo de actividad sea particularmente largo, como en entornos de misi\u00f3n cr\u00edtica o en infraestructuras que operan continuamente.<\/p>\n En segundo lugar, este problema podr\u00eda tener implicaciones en t\u00e9rminos de planificaci\u00f3n y gesti\u00f3n de recursos.<\/p>\n Si se produce un bloqueo del n\u00facleo despu\u00e9s de 2,93 a\u00f1os, podr\u00eda requerir un reinicio del servidor, lo que podr\u00eda interrumpir la continuidad de las operaciones y generar costos adicionales asociados con el tiempo de inactividad no planificado.<\/p>\n Adem\u00e1s, aunque las actualizaciones de seguridad y el mantenimiento deben realizarse con frecuencia, existen casos en los que algunos sistemas, especialmente aquellos en entornos espec\u00edficos o configuraciones personalizadas, pueden requerir per\u00edodos de tiempo de actividad prolongados sin reinicios.<\/p>\n En tales situaciones, el error de bloqueo del n\u00facleo puede plantear un problema real y requerir consideraciones adicionales para garantizar la estabilidad del sistema.<\/p>\n En resumen, aunque las actualizaciones de seguridad y el mantenimiento peri\u00f3dico son fundamentales, el problema de bloqueo del n\u00facleo despu\u00e9s de 2,93 a\u00f1os sigue siendo importante debido a sus implicaciones potenciales en t\u00e9rminos de confiabilidad, estabilidad y gesti\u00f3n de recursos.<\/p>\n Los usuarios y administradores de sistemas deben ser conscientes de este problema y tomar las medidas necesarias para mitigar sus posibles impactos en sus entornos espec\u00edficos.<\/p>\n En un escenario muy realista, se ampl\u00eda a\u00fan m\u00e1s la importancia del problema de bloqueo del n\u00facleo despu\u00e9s de un tiempo prolongado de actividad.<\/p>\n La funci\u00f3n de parcheo en vivo de Linux y la capacidad de actualizar sin reiniciar utilizando kexec son enfoques comunes para aplicar actualizaciones cr\u00edticas del sistema sin interrupciones.<\/p>\n Estas t\u00e9cnicas permiten a los administradores de sistemas mantener el tiempo de actividad de los servidores y minimizar el impacto en las operaciones en entornos de misi\u00f3n cr\u00edtica.<\/p>\n Sin embargo, tambi\u00e9n pueden contribuir a un tiempo de actividad prolongado, lo que podr\u00eda exponer a los sistemas al error de bloqueo del n\u00facleo despu\u00e9s de 2,93 a\u00f1os.<\/p>\n Los servidores de aplicaciones de misi\u00f3n cr\u00edtica, que a menudo requieren un tiempo de actividad continuo y est\u00e1n dise\u00f1ados para manejar cargas de trabajo exigentes, tambi\u00e9n son m\u00e1s propensos a experimentar per\u00edodos prolongados sin reinicios.<\/p>\n Esto los coloca en un mayor riesgo de enfrentar el problema de bloqueo del n\u00facleo.<\/p>\n En consecuencia, es fundamental que los administradores de sistemas y las organizaciones que operan en entornos de alto rendimiento y misi\u00f3n cr\u00edtica est\u00e9n conscientes de este problema y tomen medidas adecuadas para abordarlo.<\/p>\n Esto puede implicar considerar estrategias de reinicio planificado antes de alcanzar los 2,93 a\u00f1os de tiempo de actividad, evaluar el impacto de reinicios en el rendimiento y las operaciones, y tener en cuenta las actualizaciones de seguridad y los procesos de mantenimiento.<\/p>\n En definitiva, en donde se utilizan funciones de parcheo en vivo y se mantienen servidores de aplicaciones de misi\u00f3n cr\u00edtica con un tiempo de actividad prolongado, resalta a\u00fan m\u00e1s la importancia de entender y gestionar adecuadamente el problema de bloqueo del n\u00facleo en los chips EPYC de AMD.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n Los errores o erratas en los chips de CPU no son inusuales y que las CPU modernas son dispositivos extremadamente complejos.<\/p>\n A medida que la tecnolog\u00eda avanza y las demandas de rendimiento y eficiencia aumentan, es com\u00fan que se descubran y documenten erratas en los procesadores incluso despu\u00e9s de su lanzamiento inicial.<\/p>\n Las erratas son errores o problemas en el dise\u00f1o o la implementaci\u00f3n de los chips que pueden afectar su funcionamiento o desempe\u00f1o en ciertas circunstancias.<\/p>\n Estos problemas a menudo se descubren durante las pruebas rigurosas y la validaci\u00f3n realizada por los fabricantes de CPU y los usuarios finales.<\/p>\n Los fabricantes, como AMD, suelen documentar y divulgar estas erratas en gu\u00edas y documentos t\u00e9cnicos para que los usuarios est\u00e9n al tanto de ellas y puedan tomar las medidas necesarias.<\/p>\n Es importante destacar que no todas las erratas tienen un impacto significativo en la funcionalidad o el rendimiento general de los procesadores.<\/p>\n Muchas de ellas pueden estar relacionadas con casos de uso espec\u00edficos o condiciones extremas que pueden no ser comunes para la mayor\u00eda de los usuarios.<\/p>\n Dicho esto, las erratas se toman en serio y los fabricantes, como AMD, trabajan constantemente para mejorar y actualizar sus procesadores para abordar estas cuestiones.<\/p>\n A menudo, se lanzan revisiones y actualizaciones de microc\u00f3digo para corregir o mitigar los problemas identificados.<\/p>\n Los usuarios tambi\u00e9n pueden tomar medidas, como aplicar parches y actualizaciones del sistema operativo, para minimizar los posibles impactos de las erratas.<\/p>\n En general, es importante tener en cuenta que, si bien las erratas en los chips de CPU pueden ser una realidad, los fabricantes y la comunidad de usuarios trabajan en conjunto para gestionar y abordar estas cuestiones a medida que surgen, con el objetivo de brindar una experiencia confiable y de alto rendimiento para los usuarios finales.<\/p>\n Dada la complejidad y el n\u00famero masivo de transistores presentes en los chips modernos, es pr\u00e1cticamente inevitable que se produzcan errores o erratas en su dise\u00f1o y fabricaci\u00f3n.<\/p>\n Estos errores pueden variar en su gravedad y alcance, y pueden abarcar una amplia gama de \u00e1reas, como agujeros de seguridad, problemas de funcionamiento de banderas o etiquetas de cach\u00e9, entre otros.<\/p>\n Los fabricantes de chips invierten mucho tiempo, recursos y esfuerzo en la validaci\u00f3n y prueba exhaustivas de sus productos para identificar y corregir tantos errores como sea posible antes de su lanzamiento al mercado.<\/p>\n Esto incluye revisiones del dise\u00f1o del chip, ajustes de firmware y actualizaciones del microc\u00f3digo, entre otros enfoques.<\/p>\n Adem\u00e1s, los fabricantes suelen tener un proceso de mejora continua y lanzan versiones posteriores de sus chips con correcciones de errores y mejoras adicionales.<\/p>\n Estas versiones posteriores pueden abordar las erratas conocidas y brindar un mejor rendimiento y confiabilidad en comparaci\u00f3n con las versiones anteriores.<\/p>\n Es importante destacar que los fabricantes de chips trabajan en estrecha colaboraci\u00f3n con la comunidad de usuarios, incluidos los desarrolladores de software y los investigadores de seguridad, para identificar y solucionar problemas.<\/p>\n Se fomenta la divulgaci\u00f3n responsable de las erratas, lo que permite una respuesta r\u00e1pida y efectiva por parte de los fabricantes para abordar los problemas identificados.<\/p>\n Los problemas y erratas en los chips de CPU son una realidad dada la complejidad y escala de los dise\u00f1os modernos. Sin embargo, los fabricantes est\u00e1n comprometidos en minimizar estos problemas mediante rigurosos procesos de validaci\u00f3n y pruebas, as\u00ed como mediante la colaboraci\u00f3n con la comunidad de usuarios.<\/p>\n La continua mejora y las actualizaciones peri\u00f3dicas de los chips ayudan a abordar estos errores y ofrecer una experiencia m\u00e1s confiable y de alto rendimiento a los usuarios finales.<\/p>\n Incluso en las versiones de env\u00edo de los chips de CPU, pueden existir erratas que no se han resuelto por completo.<\/p>\n En el caso de la octava generaci\u00f3n de chips Intel, es conocido que se enumeran m\u00e1s de 150 erratas en su documentaci\u00f3n t\u00e9cnica, a pesar de haber sido lanzados en 2017.<\/p>\n Estas erratas pueden variar en su gravedad y alcance, desde problemas menores hasta cuestiones m\u00e1s significativas.<\/p>\n En cuanto a los chips AMD EPYC Rome, aunque la compa\u00f1\u00eda ha eliminado las listas de erratas resueltas, se sabe que todav\u00eda existen al menos 39 erratas en esos chips.<\/p>\n Estas erratas pueden ser diversas y pueden abarcar una variedad de aspectos del dise\u00f1o y funcionamiento de los chips.<\/p>\n Es importante destacar que las erratas que quedan en los chips de CPU no necesariamente significan que los procesadores sean inherentemente defectuosos o inutilizables.<\/p>\n En muchos casos, estas erratas pueden ser mitigadas mediante parches de firmware, actualizaciones del sistema operativo u otras medidas.<\/p>\n Adem\u00e1s, las erratas pueden afectar diferentes casos de uso de manera diferente, y no todos los usuarios pueden verse afectados por todas las erratas.<\/p>\n Los fabricantes de chips, como Intel y AMD, contin\u00faan trabajando activamente para abordar y resolver las erratas en sus productos. Esto puede implicar lanzamientos de nuevas versiones de chips con correcciones, actualizaciones de firmware o microc\u00f3digo, o parches de software.<\/p>\n Adem\u00e1s, la colaboraci\u00f3n con la comunidad de usuarios y la retroalimentaci\u00f3n de los investigadores de seguridad desempe\u00f1an un papel importante en la identificaci\u00f3n y soluci\u00f3n de las erratas existentes.<\/p>\n En \u00faltima instancia, si bien las erratas en los chips de CPU son una realidad, los fabricantes y la comunidad de usuarios trabajan juntos para minimizar su impacto y proporcionar soluciones y actualizaciones para abordarlas.<\/p>\n Los usuarios deben estar atentos a las actualizaciones y parches proporcionados por los fabricantes para asegurarse de que sus sistemas est\u00e9n protegidos y funcionando de manera \u00f3ptima.<\/p>\n Los fabricantes de chips deben evaluar cuidadosamente las erratas y sopesar diversos factores al decidir si corregir o no un error en particular.<\/p>\n La gravedad del problema, la facilidad de soluci\u00f3n y el impacto potencial en el rendimiento son algunos de los aspectos que se consideran.<\/p>\n En algunos casos, las erratas pueden ser benignas y no representar un da\u00f1o significativo para los usuarios.<\/p>\n En tales casos, los fabricantes pueden optar por no solucionar el problema, ya que hacerlo podr\u00eda requerir esfuerzos adicionales y recursos que no est\u00e1n justificados por el impacto real.<\/p>\n Sin embargo, es importante destacar que las erratas cr\u00edticas que podr\u00edan dejar abiertos vectores de ataque o comprometer la seguridad de los sistemas son tratadas como prioridad y generalmente se busca su resoluci\u00f3n lo antes posible.<\/p>\n La seguridad es un factor fundamental en el dise\u00f1o y desarrollo de los chips de CPU, y los fabricantes trabajan en estrecha colaboraci\u00f3n con investigadores de seguridad y la comunidad en general para abordar y mitigar cualquier riesgo de seguridad.<\/p>\n En cuanto a las erratas relacionadas con la funcionalidad que no se corrigen, esto puede deberse a una serie de razones.<\/p>\n Algunas de estas erratas pueden requerir cambios significativos en el dise\u00f1o o arquitectura del chip, lo que puede ser costoso y complejo de implementar.<\/p>\n Adem\u00e1s, las correcciones pueden tener implicaciones en el rendimiento del chip, y los fabricantes deben evaluar cuidadosamente si el beneficio de la correcci\u00f3n justifica cualquier p\u00e9rdida de rendimiento que pueda resultar.<\/p>\n Es importante tener en cuenta que los fabricantes de chips se esfuerzan por ofrecer productos de calidad y alto rendimiento, y buscan equilibrar los diversos factores al abordar las erratas.<\/p>\n La retroalimentaci\u00f3n de los usuarios, la comunidad de investigadores y las actualizaciones regulares de firmware y software siguen siendo esenciales para mantener los sistemas actualizados y protegidos.<\/p>\n En resumen, los fabricantes de chips eval\u00faan las erratas en funci\u00f3n de su gravedad, facilidad de soluci\u00f3n, impacto en el rendimiento y otros factores para determinar si se abordar\u00e1n o no.<\/p>\n La seguridad y la protecci\u00f3n de los usuarios son prioridades, pero tambi\u00e9n se deben considerar otros aspectos, como los recursos necesarios y el impacto en el rendimiento global del chip.<\/p>\n Es importante destacar que la detecci\u00f3n de erratas en los chips de CPU puede ser un desaf\u00edo complejo y no siempre es posible identificar todos los posibles problemas durante las fases de validaci\u00f3n y calificaci\u00f3n. A pesar de los rigurosos procesos de prueba y verificaci\u00f3n que los fabricantes de chips emplean, algunas erratas pueden pasar desapercibidas hasta que los chips se implementen y se utilicen en entornos del mundo real.<\/p>\n En el caso espec\u00edfico del problema que afecta a los chips EPYC Rome de AMD despu\u00e9s de 2,93 a\u00f1os de tiempo de actividad, es posible que las pruebas de envejecimiento acelerado no hayan sido capaces de detectar el problema debido a la duraci\u00f3n y las condiciones espec\u00edficas necesarias para su manifestaci\u00f3n.<\/p>\n Estas pruebas suelen tener l\u00edmites de tiempo y temperatura, y puede haber situaciones en las que las erratas solo se manifiesten despu\u00e9s de un per\u00edodo de tiempo m\u00e1s largo o en condiciones particulares de uso.<\/p>\n Adem\u00e1s, el proceso de validaci\u00f3n y calificaci\u00f3n de los chips generalmente se lleva a cabo dentro de l\u00edmites de tiempo y recursos espec\u00edficos.<\/p>\n Los ciclos de validaci\u00f3n y calificaci\u00f3n pueden no abarcar la totalidad de la vida \u00fatil esperada del chip, ya que esto podr\u00eda requerir un tiempo y recursos significativos.<\/p>\n Es posible que algunos clientes de AMD<\/a> hayan encontrado el problema en la implementaci\u00f3n de los chips EPYC Rome despu\u00e9s de su lanzamiento en 2018.<\/p>\n Los usuarios en entornos del mundo real a menudo pueden experimentar situaciones y cargas de trabajo \u00fanicas que pueden revelar erratas o problemas que no se detectaron durante las fases de validaci\u00f3n previas.<\/p>\n La detecci\u00f3n y resoluci\u00f3n de erratas en los chips de CPU es un proceso complejo y desafiante.<\/p>\n Aunque los fabricantes de chips emplean rigurosos procesos de prueba y verificaci\u00f3n, algunas erratas pueden pasar desapercibidas hasta que los chips se implementen y se utilicen en situaciones reales.<\/p>\n Los ciclos de validaci\u00f3n y calificaci\u00f3n pueden tener limitaciones de tiempo y recursos, y las pruebas de envejecimiento acelerado pueden no ser capaces de identificar todas las posibles erratas.<\/p>\n La retroalimentaci\u00f3n y la experiencia de los usuarios en entornos reales desempe\u00f1an un papel importante en la identificaci\u00f3n y soluci\u00f3n de problemas una vez que se implementan los chips.<\/p>\n Hay entusiastas y comunidades dedicadas a establecer r\u00e9cords de tiempo de actividad en servidores y sistemas inform\u00e1ticos.<\/p>\n Uno de los hitos notables en este sentido es la computadora a bordo de la nave espacial Voyager 2, que ha estado funcionando durante m\u00e1s de 16,735 d\u00edas y contin\u00faa en funcionamiento en el espacio interestelar.<\/p>\n Este logro es impresionante y demuestra la durabilidad y confiabilidad de la tecnolog\u00eda espacial.<\/p>\n En la Tierra, existen registros de tiempo de actividad prolongado en servidores que han superado los 16 a\u00f1os (6014 d\u00edas). Sin embargo, hay debates y discusiones sobre otros sistemas que podr\u00edan contender por el t\u00edtulo de mayor tiempo de actividad.<\/p>\n La comunidad de \/r\/uptimeporn en Reddit es un ejemplo de un grupo dedicado a mostrar ejemplos de tiempos de actividad prolongados y celebrar los logros en este campo.<\/p>\n Estos registros y debates reflejan el inter\u00e9s y la admiraci\u00f3n por los sistemas inform\u00e1ticos que pueden mantenerse en funcionamiento durante largos per\u00edodos de tiempo sin interrupciones.<\/p>\n Establecer r\u00e9cords de tiempo de actividad es un desaf\u00edo interesante y un logro que requiere planificaci\u00f3n, mantenimiento y una combinaci\u00f3n de factores t\u00e9cnicos y operativos.<\/p>\n Sin embargo, es importante tener en cuenta que el tiempo de actividad prolongado no siempre es el objetivo principal para todos los usuarios y organizaciones.<\/p>\n Cada caso tiene sus propias necesidades y prioridades, y el tiempo de actividad prolongado puede ser m\u00e1s relevante en entornos cr\u00edticos o en situaciones donde la continuidad del servicio es esencial.<\/p>\n La errata en los chips EPYC Rome de AMD que causa el bloqueo del n\u00facleo despu\u00e9s de 1044 d\u00edas de tiempo de actividad no ser\u00e1 corregida por la empresa. AMD ha declarado que no solucionar\u00e1 el problema, y existen diversas razones posibles para esta decisi\u00f3n.<\/p>\n Una de las posibles razones podr\u00eda ser el costo asociado con la correcci\u00f3n en el silicio de los chips, lo cual implicar\u00eda cambios en el dise\u00f1o y fabricaci\u00f3n de los procesadores.<\/p>\n Esto podr\u00eda requerir una inversi\u00f3n significativa de recursos y tiempo por parte de AMD. Otra posible raz\u00f3n podr\u00eda ser que una soluci\u00f3n mediante microc\u00f3digo o firmware genere una sobrecarga de rendimiento que no sea aceptable para la empresa o sus clientes.<\/p>\n Es importante tener en cuenta que las decisiones sobre la resoluci\u00f3n de erratas en los chips no se toman a la ligera.<\/p>\n Los fabricantes de chips eval\u00faan cuidadosamente los factores como la gravedad del problema, el impacto en el rendimiento y la cantidad de clientes afectados antes de decidir si vale la pena llevar a cabo una correcci\u00f3n.<\/p>\n Deshabilitar el estado de suspensi\u00f3n CC6 del servidor o reiniciar peri\u00f3dicamente puede ser una estrategia pr\u00e1ctica para evitar que los n\u00facleos se bloqueen despu\u00e9s de 1044 d\u00edas de tiempo de actividad.<\/p>\n Cada usuario y organizaci\u00f3n deber\u00e1 evaluar su situaci\u00f3n y tomar las medidas adecuadas seg\u00fan sus necesidades y prioridades.<\/p>\n En resumen, AMD ha decidido no corregir la errata que causa el bloqueo del n\u00facleo en los chips EPYC Rome despu\u00e9s de 1044 d\u00edas de tiempo de actividad.<\/p>\n Las razones detr\u00e1s de esta decisi\u00f3n pueden incluir consideraciones de costo, rendimiento y el impacto percibido en la base de clientes.<\/p>\n Como alternativa, deshabilitar el estado de suspensi\u00f3n CC6 o reiniciar peri\u00f3dicamente pueden ser enfoques pr\u00e1cticos para mitigar el problema.<\/p>\n <\/p>\n Por Marcelo Lozano – General Publisher IT CONNECT LATAM<\/p>\n <\/p>\n Lea m\u00e1s sobre Aplicaciones Empresariales en;<\/p>\n Seguridad Lateral de VMware, la estrella de la RSA 2023<\/a><\/p>\n RSA D\u00eda 3: Charla Magistral de Scott Raynovich y Chuck Herrin, CTO de Wib<\/a><\/p>\n Oracle revoluci\u00f3n de la nube 2023 al universo de la banca<\/a><\/p>\n VMware Tanzu y VMware Aria: aceleran el desarrollo y entrega de apps 2023<\/a><\/p>\n<\/a><\/a>Chip Errata tan com\u00fan como ineficiente<\/h2>\n
Expulsado del Uptime Club<\/h2>\n