Исходное сообщение
"Для ядра Linux предложена возможность отслеживания переохлаж..." Отправлено Аноним, 18-Дек-23 16:12
> сколько текста - и никакой конкретики смысл было столько пейсать ? А какую конкретику надо было? В большой сложной системе очень много чего может пойти не так - все failure modes даже производитель не знает. В общем случае - проц при выходе за спеки может начать глючить, от ухода параметров за design margins. Их обещали только от сих до сих. А сверх того - вот и узнаете как именно он заглючит, если заметите. Ну или когда все факапнется, только вы с вашим ником - на свою криворукость подумаете. А это 50/50 было. Ни один адекватный инженер не будет гонять сложную систему за пределами ее спеков, понимая вот этот момент. Относительно простые вещи, типа несложных МК, еще можно попытаться провалидировать "за рамками" спеков на предмет корректности работы самому. Но даже просто проверить что ALU всегда считает правильно - целый отдельный квест. А на борту еще память всякая есть и много чего еще. А в миллиардах транзисторов есть где развернуться, удачи в валидации! Извините, сейчас у АМД с их нанометрами - набортное фирмваре в серсисном мк (на том же кристалле) трекает, даже, цуко, AGING своего кремния! И вооон там в шедулер ядра хотят впилить логику запуска задач на "наименее заюзаных" ядрах, соответственно (они оптимальнее по рабочим точкам DVFS). И интел наверняка не лучше в своей гонке выжать из технологи максимум, любой ценой. Вы там правда хотите стресстестануть ЭТО вне условий заявленных производителем, в управляющей системе?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: