nForce2 – а пляшут ли частоты?


Эта работа участвует в нашем конкурсе статей.


1. Предисловие

Впервые я столкнулся с этим глюком, когда встретил на форуме www.overclockers.ru упоминание о проблеме скачущих частот на 8RDA(+), и ссылку на программу для выявления этих скачков – thg_clock.exe. Поначалу все было как у всех, на некоторых частотах наблюдалась просто некоторая нестабильность в определенных условиях, но через некоторое время я поймал нечто более странное…

Большинство владельцев материнок на nForce2 сообщают о нестабильности проявления этого глюка, и у меня этот глюк тоже как оказалось, зависит от фаз луны и погоды на Марсе, что позволяет думать об одинаковой природе данной проблемы. Данная статья чуть было не была выкинута в мусорку по той причине, что CPU-Z у меня упорно отказывался узреть скачки частот, хотя многие пользователи использовали именно его. Причина оказалась в том, что новые версии CPU-Z (старше 1.18) используют для вычисления частоты другой алгоритм, нежели старые, а у меня на тот момент была установлена версия 1.18, которая в упор не видела никаких изменений в частоте, что собственно и сбило меня с толку. А беда моя заключалась в следующем – иногда после загрузки частота, выдаваемая thg_clock в левой колонке, равна 2004Mhz (реальная), в а правой ~1740Mhz. В отличие от вышеупомянутых проблем у меня кроме биения частот обнаружилось еще и падение средней частоты аж на 250Mhz! Кроме того, упавшая частота еще и гуляла по показаниям thg_clock в пределах +-20Mhz. Именно это падение позволило мне докопаться до возможной причины "нестабильности частот".

2. Конфигурация тестового компьютера:

  • Материнская плата: Epox 8RDA+ rev 1.1, ревизия чипсета - С1.
  • Процессор: AthlonXP1700+ Thoroughbred-B, разогнан до 200x10
  • Видео: GeForce3 ti200, частоты 260/560
  • HDD: Maxtor D740X,40GB
  • RAM: 256MB в одноканальном режиме, частота 200Mhz, тайминги 3-3-3-8

3. Тестирование в сбойном и нормальном режимах





Ну что, посмотрим, что творится в той или иной ситуации. Частоты, приведенные в рисунках – результат thg_clock, выдаваемый по правой колонке, 2000Mhz – нормальная ситуация, 1740Mhz – сбойная.

Как видно, падения производительности в синтетических тестах нет, результаты примерно соответствуют тем, которые и должны быть при моей конфигурации.

Две фирменные утилиты AMD для определения процессора также упорно утверждают о частоте равной ~1720Mhz, другие говорят о стабильных 2004Mhz В общем, мнения программ диагностики разделились :) Ну ладно… Прогоним бенчмарки в игровых приложениях.

Т-а-а-а-кс. Падение производительности все-таки есть, да и попугаи в 3DMark2001 сильно упали. Но если подумать, производительность процессора и памяти должна сильно влиять только на игровые приложения, почему вдруг упала скорость текстурирования у видеокарты? Частоты видео не менялись, драйвера тоже. Тут я вспомнил, что у меня завалялась моя программка для сравнения текстовых отчетов 3DMark2001, с выдачей разницы по каждому тесту в процентах, берем два отчета, сравниваем, и...

..видим падение по ВСЕМ тестам на 15%

Если дело в материнской плате, то почему изменяются результаты тестирования видеокарты? Закралось в меня подозрение что дело совсем не в производительности.

Далее еще смешнее, берем для тестирования... drive! 1.0.0, который является тестом производительности HDD. И что видим? Аналогичное "падение" скорости на 15% при трансфере с блинов винчестера, и из кэша по IDE интерфейсу.





Будь я суеверным, я бы перекрестился. Решил я до кучи проверить одну свою программу, которая вычисляет частоту процессора, посекундно считывая количество тактов процессора командой RDTSC. И снова получаю 1740Mhz. Выключаю компьютер, включаю снова – стабильные 2004Mhz везде, производительность системы снова пришла в норму.

Что за высшая сила, способная замедлить все устройства в компьютере? Что нужно для того, чтобы их все разом замедлить на 15%? Я пришел к выводу, что причина этой проблемы... системный таймер. Cамый простой способ замедлить тесты на 15% - ускорить время на 15% :) Нормальные результаты Sandra2004 в этом случае становятся объяснимы, возможно она просто считывает при запуске частоту процессора (из BIOS?), которую позже использует для проведения диагностики, ориентируясь на нее и внутрипроцессорный счетчик тактов (TSC), и обходя при этом стороной ошизевший системный таймер, что позволяет получать более точные и стабильные результаты в тестах производительности. В пользу этой теории (а их уже скоро будет не меньше, чем версий падения Тунгусского Метеорита), говорит и то, что многие пользователи материнских плат Epox 8RDA(+) жалуются на убегающие часы, но впоследствии сообщают о том, что они вдруг сами по себе стабилизируются.

Для подтверждения этой версии была написана программа, считывающая показания двух таймеров, один – таймер из CMOS, который энергонезависим, и второй – системный, показания которого зависят от частоты вызова IRQ0. Как выяснилось, WindowsXP использует именно этот таймер для отображения времени, но после перезагрузки снова синхронизируется по таймеру CMOS. Снова ребутаемся до тех пор, пока показания thg_clock не падают до 1740Mhz, начиная при этом скакать, и запускаю самописанный тест:

Как видно из этого рисунка, представления о времени у таймеров разошлись, и разрыв увеличивается до тех пор, пока не будет произведена перезагрузка. Из этих экспериментов можно сделать следующие выводы:

  1. С некоторой уверенностью можно утверждать, что частота процессора всегда остается стабильной, меняется лишь точность таймера.
  2. Влияние таймера обнаруживается только в программах, использующих для проведения измерений системный таймер Windows. Влияние на программы, использующие другие методы измерения производительности, отсутствует (SiSoft Sandra2004, версии CPU-Z до 1.19). Более поздние версии CPU-Z 1.19 и старше уже подвержены влиянию таймера.
  3. Глюк не зависит от каких-либо опций BIOS, достаточно просто несколько раз выключить компьютер, запуская после каждой загрузки thg_clock.

4. Выводы и параноидальные мысли :)

Исходя из вышесказанного, пожалуй в одном можно быть спокойным – реальные частоты на самом деле стабильны, скачки обусловлены нестабильностью таймера, а не генератора частот, и порча оборудования вследствие этого маловероятна. Но опять же закрадывается сомнение, если так легко надуть тестовые приложения, не дурят ли нас производители материнских плат, демонстрируя прирост в сравнении с конкурентами, чуток замедляя таймер, улучшая таким образом результаты тестов? Всегда ведь можно свалить на погрешность... Настораживает, к примеру, превосходство nForce2 над KT400/600 в играх, при отсутствии аналогичного превосходства в Sandra (как вы помните, она не реагирует на изменение скорости таймера).

Причиной подобного глюка вполне может быть драйвер чипсета, либо BIOS. Но если это так, то этот глюк вполне может быть проявлением какой-нибудь динамической системы обмана бенчмарков. Если, допустим, притормаживать таймер при 100% загрузке процессора, и в момент снижения нагрузки до цифры близкой к нулю – восстанавливать "упущенное" время, то пользователь может и не заметить никаких отклонений часов. В свете последних скандалов с выявлением читерства nVidia, я бы наверное этому уже не удивился... но пока предположим, что эта проблема чисто программная, и возможно будет исправлена в будущих драйверах nForce2, либо в новых версиях BIOS.

Telegram-канал @overclockers_news - это удобный способ следить за новыми материалами на сайте. С картинками, расширенными описаниями и без рекламы.
Страницы материала
Страница 1 из 0
Оценитe материал
рейтинг: 3.8 из 5
голосов: 9


Возможно вас заинтересует

Популярные новости

Сейчас обсуждают