Что-то замедляет мой процессор Haswell - не EIST, не PROCHOT, не ClockMod... что еще?

Примечание. Этот вопрос является дубликатом предыдущего вопроса, на который был получен довольно подробный ответ.

=========

Дорогие коллеги-суперпользователи,

Возможно, вы помните мой неуместно широкий вопрос некоторое время назад... это продолжение. На этот раз у меня достаточно данных, чтобы быть более конкретным. Поймали одного преступника в поле, и на этот раз мы были в некоторой степени подготовлены. Но первые результаты меня озадачивают. Это не EIST, это не PROCHOT, это не CLOCKMOD. После сегодняшнего дня мне интересно: «Что Windows знает такого, чего не знаю я»? Должно быть, я упускаю какой-то сладкий секрет - еще один MSR или механизм рулевого управления часами...

Проблема: на паре десятков ПК под управлением Windows Server 2012 R2 «то и дело» случайно какая-нибудь случайная машина начинает «сочится, как патока». Процессор субъективно становится очень медленным. Диспетчер задач Windows в 2012 году твердо сообщает, что тактовая частота процессора составляет «0,22 ГГц», что является странным значением. Проблема исчезает после выключения и включения питания.

Эффективное среднее время безотказной работы до сих пор составляло около 20 лет, т.е. его невозможно воспроизвести в лаборатории. Машины работают прохладно, вдали от порогов теплового регулирования. Проверено путем создания 100% загрузки ЦП в течение нескольких дней с записью датчика температуры ядра. В производстве машины фактически простаивают в течение нескольких месяцев, что подтверждается некоторыми соответствующими сообщениями в журнале событий, в которых говорится, что ЦП работал на самой низкой тактовой частоте EIST еще один день - это более 100 дней подряд, до выключения и включения питания. Нет никаких местных факторов окружающей среды или других обстоятельств, с которыми можно было бы связать такое поведение.

Процессор — Haswell Core i7 Core i7-4650U: двухъядерный с HT, TDP 15 Вт, фактически потребляющий менее 5 Вт в режиме ожидания. Номинально "мобильный" процессор - машина хоть и не ноутбук, но без батареи. Имеет встроенный контроллер.

Номинальная тактовая частота процессора (та, что указана на банке) составляет 1,7 ГГц. Максимальная частота EIST составляет 2,3 ГГц. Turbo может повысить частоту одного ядра до 3,3 ГГц и всех ядер до 2,9 ГГц. Эталонная частота, по-видимому, составляет 100 МГц от встроенного синтезатора (на самом деле, по-видимому, больше похоже на 98 МГц). При нормальных обстоятельствах, в Windows или Linux при типичной рабочей нагрузке = простое, частота ЦП остается на уровне 800 МГц (сообщается о 790 МГц), т.е. множитель = 8.

Теперь о тех 0,22 ГГц. Это единое значение, усредненное по всем четырем ядрам. Кроме того, это не физическая тактовая частота - скорее, она выводится Windows на основе некоторой номинальной тактовой частоты и некоторых аппаратных «измерителей производительности», вероятно, регистров MSR, где значение предположительно представляет собой процент от максимальной производительности.

      Effective clock = Nominal max clock * "frequency percentage gage" * "throttling percentage gage"

или, на языке счетчиков производительности Windows:

      Effective clock = Nominal max clock * "% Processor Performance" 

Это в среднем по всем четырем ядрам графического интерфейса диспетчера задач. Счетчики производительности Windows (API/UI ОС на программном уровне) делают счетчики доступными для каждого ядра, агрегированными для каждого пакета ЦП и общими для каждой системы.

Эта формула работала у меня в лаборатории, то есть на здоровой системе. Я не нашел счетчика производительности Windows, содержащего «EIST Max» = нашу фактическую «систему отсчета» для «% производительности процессора», но неважно… Самое близкое, что я мог получить, возясь с ClockMod на исправной машине, работающей на холостом ходу. на частоте 800 МГц было дросселирование двух ядер до 4/16 и двух до 5/16 через IA32_CLOCK_MODULATION MSR. Выполнено с помощью инструмента MSR от uclewebb — «эффективная тактовая частота процессора», о которой сообщает диспетчер задач Windows, продолжала колебаться между 0,23 и 0,25 ГГц.

Следуя советам нескольких людей, что это может быть связано с сигналом PROCHOT или регулированием по требованию, собрал ли я свои собственные инструменты для доступа к MSR_POWER_CTL, IA32_PACKAGE_THERM_STATUS, IA32_THERM_STATUS и IA32_CLOCK_MODULATION - чтобы при расследовании иметь что-то маленькое, простое и по делу следующий преступник на свободе.

И этот преступник сегодня пришел, и... я в некотором шоке. Никакие источники PROCHOT не активны, по-видимому, PROCHOT никогда не случался с момента последнего включения, и «регулирование по требованию» (также известное как CLOCKMOD) также отключено.

...то же самое для ядер ЦП 1,2 и 3.

Пробовали отключать BD-PROCHOT - флаг отключенного висит в MSR, но проблема не уходит. Что неудивительно. Мы попробовали поиграться с битами CLOCKMOD, используя другой инструмент, который выполняет чтение + запись + обратное чтение. Инструмент работает, но не приносит никаких улучшений (опять же неудивительно).

Я также взглянул на некоторые счетчики производительности Windows, используя программу командной строки perf32 из SnmpTools Эрвана Л. Вот результат:

      "Processor Information\% Processor Performance\_Total" 
9.49953814259068

"Processor Information\% Processor Performance\0,0" 
9.99836227595223

"Processor Information\% Processor Performance\0,1" 
9.00490682886555

"Processor Information\% Processor Performance\0,2" 
9.95220023870093

"Processor Information\% Processor Performance\0,3" 
8.99923060510645

"Processor Information\% Processor Utility\_Total" 
9.15043821293382

"Processor Information\% of Maximum Frequency\_Total" 
73

"Processor Information\Processor Frequency\_Total" 
1700

"Processor Information\Processor Frequency\0,0" 
1700
# the same for CPU core 1,2 and 3

"Processor Information\Processor State Flags\0,0" 
1
# the same for CPU core 1,2 and 3

"Processor Information\Parking Status\_Total" 
0

"Processor\Interrupts/sec\0" 
1979.5905212033

"Processor\% Interrupt Time\_Total" 
0.777807192025936

Итак... ядра ЦП застряли на своей номинальной «жестяной» частоте 1,7 ГГц, что составляет 75% от 2,3 ГГц (максимум EIST). Регулирование по требованию отключено. Но что-то заставляет Windows поверить, что общий «процент производительности процессора» составляет всего 9 или 10 процентов. Два ядра по 9%, два ядра по 10%, в результате чего совокупный процент по всей системе составляет 9,5%. 0,095*2300 МГц = 218 МГц.

Обратите внимание на эти проценты, на их степень детализации: 9 и 10 процентов, довольно точно.

• Как это согласуется с целочисленным множителем EIST (который, по-видимому, зафиксирован на значении 17) и рабочим циклом 1/16 CLOCKMOD, который, по-видимому, изначально отключен?

• Какой еще фактор учитывает Windows, рассчитывая процент производительности процессора? Или это просто дословно считывается с оборудования? Какие MSR мне следует проверить в оборудовании, чтобы проверить/понять цифры, которые сообщает Windows?

• возможно, Turbo (преемник EIST) делает контроль производительности более детальным, «свободным от ограничений EIST», и привносит ли он какие-то соответствующие новые MSR?

• эти проценты на самом деле могут быть неправильными... виновная система в неисправном состоянии на самом деле может работать даже медленнее, чем предполагают проценты. Просто путем субъективного сравнения с моими лабораторными экспериментами с регулированием CLOCKMOD при аналогичной «эффективной тактовой частоте» около 0,25 МГц.

Спасибо за ваше время. Любые идеи приветствуются.

РЕДАКТИРОВАТЬ: черт возьми, да, есть несколько MSR. Я бы хотел, чтобы Turbostat был доступен для Windows.

РЕДАКТИРОВАТЬ: я написал инструмент для выполнения необработанного дампа заданного диапазона MSR на экране и в файл CSV. Оказывается, пространство MSR довольно скудно... Этот инструмент позволит мне получить дамп некоторого значимого диапазона на виновнике/пациенте и на здоровом ящике для сравнения. Сравнение также может быть в некоторой степени автоматизировано. Затем я могу просмотреть данные, имея под рукой руководство Intel, сосредоточиться на различиях и т. д.

Я также пробовал использовать сборку acpidump AcpiCA для Windows и т. д. Еще не пробовал на виновной машине, но на моем старом ноутбуке (модель Lenovo 2015 года с UEFI) он не смог найти объект _PSS... Я могу попробуйте еще раз на проблемной коробке.