Прошло достаточно много времени с момента написания основного материала. За это время вышли новые версии программ, предназначенных для стресс тестирований. Компьютерная индустрия также не стояла на месте. Intel выпустила новую линейку процессоров i7, а AMD — Phenom II. Применимы ли к ним ранее протестированные программы или они требуют переоценки? Конечно, можно с определенной степенью уверенности предположить, что да. Но будет совсем не лишним провести ряд дополнительных, отдельных тестов на новых платформах. Было проведено подробное тестирование процессора i7 860. Phenom в наличии нет, поэтому данные по его работе смогу получить только при помощи других источников. Пока они в статью не вошли. И по поступлении будут выведены в отдельный абзац.

КОНФИГУРАЦИЯ КОМПЬЮТЕРА

Процессор i7 860
Память 4x Samsung original 1333
Материнская плата Gigabyte P55 UD3R
Видеокарта ASUS 250GTS 1Gb @ 760/1836/2200(1100)MHz
Винчестеры:
4х640Гб Western Digital (собраны в Raid 0)
2х1Тб Samsung
Звук Creative Audigy SE
Монитор Samsung 2693HM
Охлаждение — водянное.
Корпус Thermaltake Armor. Модифицированный.

СПИСОК ПРОТЕСТИРОВАННЫХ ПРОГРАММ.

1.) IntelBurnTest v 2.4
2.) OCCT v 3.1.0
3.) LinX v 0.6.4
4.) Prime95 v 25.9 build 4
5.) CPU Stress Test v 0.14b

НАСТРОЙКИ. МЕТОДИКА.

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

Имеющаяся у меня материнская плата Gigabyte P55 UD3R способна на стабильную работу на частотах до ~205Мгц BCLK(FSB), память Samsung 1333 – нормально функционирует на частотах 2000Мгц (и даже выше, но значительное повышение таймингов делает такое повышение бесмысленным).

Скрин системы. 2 часа Prime95, на минимальных оборотах вентиляторов
Частота процессора 4000Мгц, QPI=3600Мгц, память 2000Мгц 9,11,11,31

С целью исключения возможного влияния на результаты тестов — их частоты будут понижены. С сохранением настроек по напряжению. Изменение частоты будет задаваться с шагом 21Мгц (21 – фиксируем множитель процессора, х1 – шаг увеличения тактового генератора BCLK).

Система охлаждения – 5х120мм радиаторы на аллюминивой основе. Конденсаторного типа. Медные ватеры. Помпа Laing DDC. Вобщем как уже написал, не преследуется задач для установок разного рода рекордов. Обороты вентиляторов на время тестов с помощью регулятора установлены на среднее значение (в обычной повседневной работе – они всегда минимальные). Нагрев системы ожидается значительный. Все программы-участники делают это весьма неплохо.

Операционная система – Windows XP. На этот раз я решил не устанавливать для теста чистую (“сферическую”) ОС. Логика простая. Компьютеры проверяемые на стабильность и работоспособность – это по большей части настроенные системы с установленным софтом. И именно в рабочем режиме они и должны быть готовы на все 100%. К тому же весьма неудобно нагружать компьютер многочасовыми тестированиями без возможности хотя бы просмотра видеофайлов и интернета. Поэтому параллельно тестированию проводилась другая работа за компьютером. Насколько это вообще было возможно сделать

Для каждой платформы будут приведены по 2 скриншота. Скрин прохождения теста и скрин экрана с выявленной ошибкой. Конечно было много и промежуточных результатов. Приводить их всех нет необходимости (по началу вообще прогонял тесты с частотами памяти 2000мгц и QPI 3600Мгц т.к. использую в разгоне именно такие настройки). Могу сказать одно. Полученные результаты характеризуются неплохой повторяемостью. Во всех тестах процессора I7, технология Hyper Threading будет включена.

1.) IntelBurnTest v 2.4.

Интерфейс программы претерпел изменения в лучшую сторону. Теперь из основного окна можно легко выставить требуемое количество проходов, уровень нагрузки и количество потоков. Но такие изменения можно назвать только косметическими. Нет выбора между х32 и х64 режимами. К недостаткам также можно отнести “мгновенный благополучный проход” (к тому же Intelburn не корректно работает из каталогов имеющих в названии русские буквы). Для теста в х32 среде доступно не более 2Гб памяти.

Касательно непосредственно итогов работы – тут претензий нет. Тестирует жестко и хорошо.

Прохождение на частотах свыше 3990 приводило к ошибке. В одном из тестов удалось даже наблюдать синий экран (что не было ни с одной из других программ)

50 проходов, 8 потоков. Остальные настройки по дефолту.

Скрин прохождения на частоте 3969Мгц.

Частота 3990Мгц. Ошибка на 6 минуте

Максимально достигнутая температура во время теста – 86гр.

2). OCCT v 3.1.0

Программа ОССТ начиная с третьих версий, стала представлять собой комплексный набор для нагрузки не только на процессор, но и на оперативную память, видеокарту, блок питания.
Будут запущены подтесты для проверки непосредственно CPU. Время прохождения 1час.

Тест CPU OCCT. Пройден на частоте 3990Мгц в режиме Auto 1час (скрин подтверждения ошибки на больших частотах к сожалению затерялся). В работе тест CPU OCCT значительно перегружал компьютер (что наблюдалось в первых версиях программы). Это заметно затрудняет использование компьютера во время тестов.

Тест CPU LINPАCK. Это все тот же линпак, который благодаря своей нагрузке, вышел в лидеры среди всех других программ для стресс тестирований. Видимо в виду его большой популярности – разработчики ОССТ решили включить его наряду со своим, как они пишут “знаменитым” тестом СPU.
Настройки. Выбираю режим Auto. Отсутствует свободный ввод размера вычислений. Хотя имеющихся вариантов нагрузки в ручном режиме custom, для большинства должно быть достаточно.
Запуски на частотах 3990, 3969, 3948Мгц легко выявляли ошибки.

3990Мгц

И лишь частоту 3927Мгц удалось подтвердить часовым проходом

Максимальная температура – 81гр.

3). LinX v 0.6.4.

Программа появилась немного позднее IntelBurnTest’а, однако по популярности значительно ее опередила (во всяком случае в нашей стране). По нескольким причинам. Она изначально имела русский язык, имела более удобный ввод и отображение данных. Благодаря постоянной доработке и добавлении полезных опций в интерфейс, тестировать в LinX просто и удобно.

Настройки. 50 проходов, 8 потоков. Размер вычислений – 14000.
Тестирование показало нестабильность на частотах свыше 3948Мгц

3969Мгц. Ошибка нашлась сразу.

3948Мгц. Тест пройден.

Максимальная температура во время теста – 88гр.

4.) Prime95 v 25.9 build 4.

Настройки — Подтест Small FFTs, 8 потоков.
Прайм без проблем определил частоту 3990Мгц как полностью стабильную в течении 2-х часов

На частоте 4011Мгц спустя 6мин — ошибка.

Нагрузка на процессор во время тестирования (как и в большинстве других тестов) была 100%. Однако нагрузка нагрузке рознь. Если при тестировании CPU OCCT я с трудом мог переключаться между окнами и прокручивать текст для чтения, то при работе с Prime95 оказалось возможным даже запускать игру King’s Bounty. И играть без явных признаков торможения.
Максимальная температура – 84градуса.

С целью увеличения нагрузки праймом, было проведено дополнительное тестирование в режиме in-place large FFT. Проверка действительно подтвердила увеличение нагрузки процессора этим подтестом по сравнению со small FFTs. Однако на общую расстановку сил это повлиять не смогло.
Настройки — Подтест in-place large FFT, 8 потоков.

Частота 3990. Ошибка спустя 20мин.

Частота 3969. 2-х часовой проход. Ошибок не найдено.

Максимальная температура не изменилась – 84градуса.

5.) CPU Stress Test v 0.14b (имеются более поздние версии)

Новый тест от serj. Подробнее о нем можно прочесть здесь http://testmem.tz.ru/cst.htm

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

Настройки тестирования по умолчанию. Единственное сделанное изменение – увеличено время прохождения теста. С 10 до 40 циклов.
Полученная нагрузка во время тестирования – 50% говорит о том, что технология HT для I7 незадействованна и программа тестирует только физические ядра. Опции для изменения числа активных ядер либо включения HT найти не удалось.
Результат полностью совпал с полученным по Prime95.

Частоты 3969 и 3990Мгц – ошибок нет.

3969Мгц 3990Мгц

Частота 4011Мгц – 26 цикл (58мин.) – ошибка найдена.

Максимальная температура – 82градуса.

ТЕСТИРОВАНИЕ CPU В EVEREST, 3DMARK.

Кроме рассмотренных в статье, существует множество других программ, создающих нагрузку на CPU. К сожалению стресс тесты не могут гарантировать 100% стабильной работы. Хотя и максимально снижают вероятность появления ошибок. Компьютеры настроенные по стресс тестам обычно требуют проверки своей работоспособности временем. Любое дополнительное прохождение тем или иным тестом может быть полезным. Everest и 3Dmark также имеют подтесты создающие нагрузку на CPU. Могут ли они составить конкуренцию специализированным тестам? С ходу выставяю заведомо нестабильную (по результатам всех тестов) частоту 4011Мгц.

Everest. Прохождение 1час. Температуры до 75гр. Никаких проблем.

3Dmar05. 30 проходов обоих CPU тестов. Долгое и как оказалось совершенно бесполезное тестирование. Также пройдено.

Максимальная температура CPU — 63гр.

Дальнейшее выяснение частот этими программами не представляло никакого смысла. Определить стабильную частоту процессора они не могут. Компьютер настроенный по ним может быть подвержен сбою в любой момент. Тестирование в 3dmark неудобно еще тем, что исключает любую параллельную работу. Что очень неудобно.

ИТОГИ ТЕСТИРОВАНИЯ ДЛЯ ПЛАТФОРМЫ I7.

Результаты проведенного тестирования не преподнесли никаких сюрпризов. Программы, в основе своей использующие библиотеку Linpack — по прежнему лидируют. Ими достигаются как самые высокие температуры, так и минимальные стабильные частоты.

Первая тройка выглядит так:

На самом деле полученная разница по частоте 42Мгц, совершенно нивелируется несколько разными начальными условиями тестирования.

Несмотря на то, что установленная у меня 32бит ОС Win XP без проблем видит и использует 3.6Гб оперативной памяти, только ОССТ Linpack смог расспределить под тест >2Гб (если точнее, то 2.7Гб). В этом, очевидно, причина наилучшего результата (поскольку нагрузка на процессор при тестировании под линпак прямо пропорциональна величине использования оперативной памяти). За это программе можно поставить большой плюс. Да. Во время тестирования была отмечена более низкая температура в нагрузке. Обьяснить не возьмусь, но скорее всего причина кроется в изменившейся комнатной температуре.

LinX использовался с настройкой 14000х14000. Это достаточно большой обьем матрицы. Использует около 1.6Гб оперативной памяти. Такой размер вычислений пределен для компьютеров с 2Гб памяти. Наиболее распространенной сейчас конфигурации.

В свою очередь работать с IntelburnTest было затруднительно. Он часто не вполне адекватно откликался на изменение настроек (например простое изменение количества активных потоков-ядер с режима auto – приводило к сообщению об успешном прохождении теста). Поэтому запускался со стандартными настройками для памяти – 1Гб. Дабы не мучать себя “капризами программы”.

Следом за первой тройкой “синхронно” финишируют Prime95 и CPU Stress Test и делят между собой четвертое место.

Надо сказать, что применение этих программ с целью поиска ошибок, требует значительно больших затрат времени. Если CPU Stress Test – тест пока новый и малораспространенный (к тому же он еще находится в процессе доработки автором), то прайм известен давно. Теперь уже можно c уверенностью говорить, что Prime95 уступает в стресс тестировании процессоров core2duo, core2quad, i7, программам, использующим линпак. Полученные результаты не оставляют в этом никаких сомнений. Времени затрачивается больше. Ошибки находит хуже.

Но не все так плохо. Prime по прежнему интенсивно нагружает современные процессоры. Разгон компьютеров, настроенный по нему, обладает очень высокой степенью стабильности (что также подтвердило это тестирование). Напомню. При запущенном прайме одновременно в течении нескольких часов была запущена игра King’s Bounty).

Кроме того, в конференции иногда можно встретить отзывы, об отсутствии ошибок в Linpack и наличии их в Prime95. Были даже отзывы о более низком прогреве в Linpack’e (что согласитесь необычно). Однако все они касались бюджетных процессоров. С уменьшенным размером кэша L2. Что видимо не случайно и связано с нагрузкой создаваемой программами именно на кэш процессоров.
Однако эти достаточно редкие случаи и могут считаться исключением из правил.

И последнее. Интересно, что при внимательном анализе полученных температур можно увидеть — былая разница в ~20гр между Prime и Linpack практически полностью сошла на нет и составила максимум 2-3гр. С одной стороны Prime работал дольше, но ведь хорошо известно, что линпаку для прогрева системы много времени и не требуется…
Опять же из полученных температур возникает новый вопрос. Существует мнение (и оно не беспочвенно), что высокие показатели линпака в определении нестабильности процессора обусловленны не только написанным алгоритмом, но и по причине тестирования на высоких температурах. Проще говоря, высокие температуры снижают разгонный потенциал сами по себе. И вот тут то и начинается самое интересное. В приведенном в начале статьи скриншоте, Prime отработал на температурах уж точно не меньших. И все равно подтвердил стабильность частоты 4000Мгц…

ЭПИЛОГ. РАЗЛИЧИЯ МЕЖДУ ТЕСТИРОВАНИЕМ 32 И 64 БИТ

Некоторые пользователи на основании использования 64 битных версий программ утверждают, что эти версии сильнее нагружают процессор и позволяют лучше выявлять ошибки.
Я провел полный ретест программ с поддержкой 64бит на Win7 x64 для того чтобы проверить это утверждение. Приведу полученные результаты.

1.) IntelBurn.

50 проходов, 8 потоков. 64бит. Размер задачи=20000.
Прохождения на частотах 3990Мгц и 3969Мгц заканчивались ошибкой

3990Мгц 3969Мгц

Частота 3948Мгц. Без ошибок.

2.) LinX.

50 проходов, 8 потоков. 64бит. Размер задачи=20000.

3969Мгц. Ошибка 3948Мгц. Пройдено

3.) OCCT.

Подтест Linpack. 90% использование памяти. 64бит. 1час.

3969Мгц. Ошибка 3948Мгц. Пройдено

3.) Prime ver. 25.9 x64.
Настройки — In-place large FFT, 8 потоков.

3990Мгц. Ошибка 3969Мгц. Пройдено

Полученные результаты совпадают с тестированием на 32бит ОС. В ОС х64 мы уже не ограничены 2Гб памяти. Что позволило привести все тесты использующие линпак к одному знаменателю. 2.7-3Гб. Благодаря этому как и предполагалось были получены практически одни и те же результаты. 3948мгц.
Отмечу разве что то, что intelburn подтвердил эту частоту только со второй попытки. От запуска к запуску в нем значительно отличалась итоговая производительность. Проблемы с ним присутствовали и в х32 версии. Prime95x64 подтвердил именно те частоты, которые были в х32 версиях.

Таким образом ясно, что для современного стресс тестирования нет никакой необходимости в х64 версиях программ. Использовать их конечно можно. Но реального улучшения они не дают. Для создания максимальной нагрузки существующих х64 процессоров вполне достаточно 32бит стресс-программ.

Пожеланиям и критике буду рад в старой теме.
https://forums.overclockers.ru/viewtopic.php?p=5326821#5326821

Для голосования за тот или иной тест создана тема
https://forums.overclockers.ru/viewtopic.php?f=2&t=349077

Другие статьи
http://cp.people.overclockers.ru/cgi-bin/admin.pl?action=records

Спасибо.

Xmast

Лучшие инструменты для стресс-теста вашего ПК (CPU & Ram)

Стресс-тестирование не только для новых систем; это также может быть отличным способом проверить старую систему. Ваша система может быть разогнана, поэтому тестирование компонентов поможет вам понять, насколько они стабильны и откуда может возникнуть потенциальная проблема.

В этом руководстве мы рассмотрим различные инструменты, которые можно использовать для стресс-тестирования вашего процессора и оперативной памяти . Мы подробно рассмотрим, почему мы считаем, что каждый инструмент может быть полезен, и как их использовать. В эту статью мы также включим некоторые инструменты мониторинга оборудования, чтобы вы могли отслеживать поведение вашей системы. Если вам нужен совет о том, как провести стресс-тестирование вашего GPU, вы можете прочитать нашу отдельную статью, посвященную этому.

Что такое стресс-тест?

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

Стресс-тестирование ЦП проводится для проверки производительности компонента во время его работы на полной скорости и при максимальной температуре.

Стресс-тестирование ОЗУ — это первое, что вы должны выполнить, если столкнетесь с какими-либо проблемами, такими как синий экран или случайные перезагрузки системы. Тестирование ОЗУ может помочь выявить дефекты памяти и поведенческие сбои

Инструменты для мониторинга вашей системы

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

CPUID HWMonitor

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

Хотя каждый компонент имеет различные максимальные температуры; всегда хорошо держать ваш процессор ниже 75 ° C.

HWiNFO64

Этот инструмент довольно продвинутый по сравнению с двумя другими. С HWiNFO64 вы можете контролировать многоядерные компоненты в удобной для пользователя форме. При запуске этого инструмента вы можете отслеживать температуру на вашем процессоре, графическом процессоре, оперативной памяти и материнской плате, а также отслеживать скорость вращения вентиляторов и время загрузки.

Core Temp

Core temp — относительно простой инструмент, но он делает именно то, что написано на жестяной банке. Вы получаете временные показания в реальном времени, и вы можете легко увидеть процент загрузки вашего процессора. Core Tempsнемного более продвинут для пользователей процессоров Intel, так как вы можете видеть информацию для каждого ядра вашего процессора, однако с AMD вы можете видеть только общую температуру.

Этот инструмент также позволяет увидеть немного больше информации о установленном процессоре и отображает напряжение и частоту.

Стресс-тест CPU

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

Prime95

Когда дело доходит до нагрузочного тестирования процессора, самым надежным и широко распространенным является Prime95. Этот инструмент находит простое число Мерсенна с помощью процессора и создает большую рабочую нагрузку. Если вы можете запускать этот инструмент в течение 5–6 часов без перерыва, это дает вам хороший признак того, что процессор работает нормально.

Есть несколько разных тестов, которые вы можете запустить, когда хотите нагрузить свой процессор. Вы можете запустить небольшие БПФ, чтобы выявить потенциальные проблемы на ранней стадии. Смешанный тест может быть очень полезен, поскольку он будет одновременно нагружать ваш процессор и оперативную память.

IntelBurn Test

IntelBurn Test — еще один бесплатный инструмент для стресс-тестирования, который позволит вам довести ваш процессор до предела. Вы можете использовать этот инструмент, чтобы проверить, насколько стабилен ваш компонент, однако, он получил отрицательную обратную связь, аналогичную инструменту Prim95, возможно, немного продвинув его.

Adia64

Aid64 — единственный инструмент стресс-тестирования для вашего процессора в списке, который будет стоить вам денег. Стоимость пакета составляет около 39,95 долларов, что не так уж и дорого, но для большинства из них совершенно не нужно, так как бесплатных инструментов достаточно. При этом Aida64 позволит вашему процессору проходить более реалистичные темпы, а не мучать его, как Prime95.

Aida64 должна быть заплачена за вас, чтобы получить полную утилиту диагностики системы по сравнению с бесплатными. Этот тип комплекта больше ориентирован на компьютерных инженеров, специалистов в области ИТ и энтузиастов.

RAM Stress Testing

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

Prime95 (тест смешивания)

Prime95 лучше всего подходит для тестирования процессора; однако его смешанный тест может быть полезен для стресс-тестирования оперативной памяти и проверки стабильности при разгоне. При тестировании пытки внутри программы вы увидите опцию Blend, но стоит отметить, что этот инструмент не будет проверять вашу оперативную память на наличие потенциальных ошибок. Если вы ищете лучший диагностический инструмент для вашей оперативной памяти, то приведенные ниже являются гораздо лучшим решением.

MemTest86 +

Лучший инструмент для проверки стабильности ОЗУ и возможных проблем с ОЗУ — MemTest86 +. После загрузки MemTest он автоматически начнет стресс-тестирование вашей оперативной памяти и четко покажет, есть ли у вас какие-либо текущие аппаратные проблемы или ваша оперативная память нестабильна из-за недавнего разгона.

MemTest 64+
MemTest86 + всегда рекомендуется для стресс-тестирования оперативной памяти, поскольку он просто лучший; однако MemTest64 + предлагает более удобное решение. MemTest64 + работает в Windows, что делает его более привлекательным для некоторых.

Прощальные слова

Реальность такова, что все эти инструменты будут работать для вас; все сводится к выбору того, что лучше для вас. Прежде чем начать, убедитесь, что вы скачали один из инструментов мониторинга, чтобы дать вам представление о текущем состоянии ваших систем и посмотреть, что стресс-тестирование делает с вашими компонентами.

Эти инструменты пригодятся всем, кто хочет разогнать и максимально повысить производительность своей системы. Вы сможете толкать эти компоненты до тех пор, пока они не станут нестабильными, не беспокоясь о том, что вы можете что-то сломать. Эти инструменты часто могут дать хорошее представление о состоянии ваших компонентов и помочь вам диагностировать проблему.

Если у вас есть какие-либо вопросы или проблемы с ПК, не стесняйтесь комментировать ниже, и мы сделаем все возможное, чтобы помочь вам.

Стресс тест процессора в Linux

Прогнал я тест Linpack и задумался: а не пора ли мне поменять термопасту на своём ноутбуке?

Да, по результатам нескольких тестов подряд (не буду захломлять статью картинками) видно, что процессор уходит в троттлинг (пропуск тактов и сброс частоты при нагреве), но вот, как быстро он начинает это делать?

Стресстест процессора в терминале Linux

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

Начал я с sysbench:

sudo apt install sysbench

sysbench --num-threads=4 --test=cpu --cpu-max-prime=100000 run

где:

• —num-threads=4 — это количество потоков, у меня двухъядерный четырёхпотоковый Intel® Core™ i7-640M, поэтому 4;
• —cpu-max-prime=100000 — это максимальное количество выполненных операций, я выставил в 100000, т.к. по умолчанию — 10000, слишком быстро завершают тест.

Потом я перешёл на Linpack. Так как процессор у меня от Intel и я имею некоторую долю лени (лень — двигатель прогресса), то я взял, скачал и распаковал готовый Intel-овский Linpack, предварительно создав в домашнем каталоге директорию linpack:

mkdir ./linpack
cd ./linpack
wget http://registrationcenter-download.intel.com/akdlm/irc_nas/9752/l_mklb_p_2018.3.011.tgz
tar -xvzf ./l_mklb_p_2018.3.011.tgz

Для AMD процессоров такой вариант я бы не стал пробовать, так как компилятор от Intel вставляет закладки, проверяющие процессор и если он не Intel…ну, подумаешь сотню-другую лишних инструкций процессор выполнит и заведомо проиграет в производительности. Для AMD лучше собрать Linpack из исходников, например, из этих. В данной статье сборку из исходников рассматривать не буду — читайте README в source code.

Вернёмся к Intel-овскому Linpack-у. Там много чего лишнего и мне не нужного, а то, что нужно рассмотрю относительно версии 2018.3.011. Сразу же перейду в нужную директорию, чтоб потом не набирать длинные команды:

cd ./l_mklb_p_2018.3.011/benchmarks_2018/linux/mkl/benchmarks/linpack

Так как по умолчанию Intel-овский Linpack заточен под тестирование серверных Xeon-ов, создадим свой файл, который будет использоваться в качестве входных опций — просто уменьшим количество тестов, иначе устанем «пару-тройку дней» ждать завершения теста. У меня Linux Mint LMDE 3, поэтому я использую текстовый редактор xed, да и нравится он мне бОльшим функционалом, особенно, когда из-под root-а его запускать — он цвет на красный меняет. И так, создаём в этой же директории, в которую перешли, файл, например, my_test:

xed ./my_test

И в созданный файл копируем следующее содержимое:

Shared-memory version of Intel(R) Distribution for LINPACK* Benchmark. *Other names and brands may be claimed as the property of others.
Sample data file lininput_xeon64.
5 # number of tests
1000 2000 5000 10000 20000 # problem sizes
1000 2000 5008 10000 20000 # leading dimensions
4 2 2 2 1 # times to run a test
4 4 4 4 4 # alignment values (in KBytes)

Ну, и собственно запуск Linpack с созданным файлом:

./xlinpack_xeon64 -i ./my_test

Или:

./xlinpack_xeon64 ./my_test

Можно ещё заюзать stress-ng или stress, но поставленной мной задачи это всё-равно не решает. Вывода температуры, частот и времени от начала старта эти утилиты мне не показывают.

Температуру может показать sensors — подробнее про установку этой утилиты здесь. И эта утилита понадобится в дальнейшем рассмотрении моего вопроса. Линукс — велик и могуч: одна и та же задача может решаться по-разному. За Си мне лень было браться и я написал недостающую мне часть на BASH, ибо строк получилось не так уж и много. Без установленной sensors мой скрипт работать не будет. Фиксацию троттлинга естесственно не стал писать — его и так будет видно по сбросу частоты и температуре. Вот сам скрипт:

#!/bin/bash
out=0 # переменная контроля за тестовым процессом
pid_test='tty' # PID тестового процесса (сделан существующей директорией, чтоб запускать без аргументов)
cpus_num=$(cat /proc/cpuinfo | grep -ci 'processor') # количество процессоров/ядер/потоков
echo -en "\033[?25l" 1>&2 # скрыть курсор
echo -en "\033[1m" 1>&2 # жирный шрифт
cat /proc/cpuinfo | sed '/model name/!d;s/^[^:][^:]*: //g' | sort -u # вывод модели процессора
echo -en "\033[0m" 1>&2 # сброс параметров цвета
trap out=1 SIGINT # инициализация выхода по ctrl+c
trap out=2 SIGABRT # инициализация выхода по незапуску теста
for ((i=0; i<$cpus_num; i++)) # предварительная инициализация массива переменных
do
cpu_crit_temp[$i]=$(sensors | sed '/Core '"$i"'/!d;s/.*crit = +\(.*\)[.][0-9]°C).*/\1/')
if [ -n "${cpu_crit_temp[i]}" ]
then
let cpu_red_temp[i]=cpu_crit_temp[i]-10
let cpu_yel_temp[i]=cpu_crit_temp[i]-30
cpu_min_temp[$i]=1000
cpu_max_temp[$i]=0
fi
done
start_time=$(cat /proc/uptime | sed 's/[.][0-9][0-9] .*$//') # время запуска
if [ -n "$1" ]
then
script_pid="$$"
(if ! $@ > "$0_out" 2>&1 # запуск тестового файла
then
kill -s SIGABRT $script_pid # послать сигнал основному скрипту об отказе запуска
fi 2>/dev/null)&
pid_test="$!" # PID тестового процесса
fi
while (true) # контроль температуры
do
for ((i=0; i<$cpus_num; i++))
do
cpu_freq[$i]=$(cat /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_cur_freq | sed 's/...$//')
cpu_temp[$i]=$(sensors | sed '/Core '"$i"'/!d;s/.*+\(.*\)[.][0-9]°C[ \t]*(.*/\1/')
if [ -n "${cpu_temp[i]}" ]
then
(( ${cpu_temp[i]} < ${cpu_min_temp[i]} )) && cpu_min_temp[$i]=${cpu_temp[i]}
if (( ${cpu_temp[i]} > ${cpu_max_temp[i]} ))
then
cpu_max_temp[$i]=${cpu_temp[i]}
time_max[$i]=$(cat /proc/uptime | sed 's/[.][0-9][0-9] .*$//')
let time_max[i]=time_max[i]-start_time
fi
if (( ${cpu_temp[i]} > ${cpu_red_temp[i]} ))
then
echo -en "cpu${i}:\t"
echo -en "\033[1m" 1>&2 # жирный шрифт
echo -n "${cpu_freq[i]} "
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo -en "MHz \t"
echo -en "\033[31;1m" 1>&2 # жирный красный шрифт
echo -n "${cpu_temp[i]}"
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo -en "°C \t(min: ${cpu_min_temp[i]}°C; max: "
echo -en "\033[31;1m" 1>&2 # жирный красный шрифт
echo -n "${cpu_max_temp[i]}"
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo "°C/${time_max[i]}sec) "
elif (( ${cpu_temp[i]} > ${cpu_yel_temp[i]} ))
then
echo -en "cpu${i}:\t"
echo -en "\033[1m" 1>&2 # жирный шрифт
echo -n "${cpu_freq[i]} "
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo -en "MHz \t"
echo -en "\033[33;1m" 1>&2 # жирный жёлтый шрифт
echo -n "${cpu_temp[i]}"
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo -en "°C \t(min: ${cpu_min_temp[i]}°C; max: "
echo -en "\033[31;1m" 1>&2 # жирный красный шрифт
echo -n "${cpu_max_temp[i]}"
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo "°C/${time_max[i]}sec) "
else
echo -en "cpu${i}:\t"
echo -en "\033[1m" 1>&2 # жирный шрифт
echo -n "${cpu_freq[i]} "
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo -en "MHz \t"
echo -en "\033[32;1m" 1>&2 # жирный зелёный шрифт
echo -n "${cpu_temp[i]}"
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo -en "°C \t(min: ${cpu_min_temp[i]}°C; max: "
echo -en "\033[31;1m" 1>&2 # жирный красный шрифт
echo -n "${cpu_max_temp[i]}"
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo "°C/${time_max[i]}sec) "
fi
else
echo -en "cpu${i}:\t"
echo -en "\033[1m" 1>&2 # жирный шрифт
echo -n "${cpu_freq[i]} "
echo -en "\033[0m" 1>&2 # сброс параметров цвета
echo -e "MHz \t "
fi
done
time=$(cat /proc/uptime | sed 's/[.][0-9][0-9] .*$//')
let time=time-start_time
echo -en "Time:\t$time sec. "
[ ! -d "/proc/${pid_test}" ] && break # выход по окончании теста (лучший способ контроля по comm и cmdline, но...лень)
[ "$out" != '0' ] && break # выход при ошибке теста
echo -en "\033[${i}A\r" 1>&2 # перенос курсора вверх на $i строк и на начало строки
sleep 0.1 # пауза, чтоб вывод частот сильно не скакал
done
echo ''
echo -en "\033[?25h" 1>&2 # включение курсора
if [[ "$out" == '0' && -n "$1" ]]
then
cat "$0_out" | sed '/^$/d;/Sample data/d;/CPU frequency/d;/Parameters are set/,/Data alignment value/d'
rm -fR "$0_out"
exit 0
elif [[ "$out" == '1' && -n "$1" ]]
then
kill -9 "$pid_test" 1>/dev/null 2>/dev/null
cat "$0_out" | sed '/^$/d;/Sample data/d;/CPU frequency/d;/Parameters are set/,/Data alignment value/d'
rm -fR "$0_out"
exit 1
elif [ "$out" == '1' ]
then exit 1
elif [ "$out" == '2' ]
then
echo -en "\033[31;1m" 1>&2
echo 'Error arg!'
echo -en "\033[0m" 1>&2
exit 2
fi
exit 0

Сильно не ругайте за скидывание управляющих символов в stderr (1>&2), но это дело привычки, если вдруг потом вывод скрипта в файл отправлять, а там все эти ESC-апе последовательности точно не нужны, вот так и будет терминал цветным, а файл чистым. Что-то я отвлёкся.

Я создал файл chk в директории с linpack-ом и записал скрипт в него, Вы можете сделать тоже самое, за исключением xed, если у Вас его нет:

xed ./chk

И собственно то, ради чего всё затевалось — тест Linpack cо скриптом:

./chk ./xlinpack_xeon64 -i ./my_test

Да, я вижу, одно ядро нагрелось до критического TDP в 105°C за 86 секунд, но это мне ни о чём не говорит, а вот то, что с 50°C до 80°C процессор нагревается за 2 секунды — это уже показатель: термопасту точно пора менять — два года не менял, а вот с системой охлаждения останется вопрос, который проявят тесты после замены термопасты и термопроводящих прокладок на моём ноутбуке.

Почему именно 80°C я взял за отправную точку? Да просто потому, что именно эта температура заложена в BIOS, как температуры начала скидывания частот, да ещё и начало включения кулера выставлена в 55°C в угоду энергосбережению, но BIOS — Insydeh30, да ещё и с проверкой своей хэш-суммы и белым списком девайсов — та ещё головная боль…будет программатор — займусь им вплотную.

Скрипт писал на скорую руку и с ориентиром на Linpack, но он так же свободно работает и с другими консольными утилитами. Вот запуск с вышеизложенным sysbench:

./chk sysbench --num-threads=4 --test=cpu --cpu-max-prime=100000 run

Как видно из скриншота sysbench не даёт полную нагрузку на процессор, в отличии от Linpack-а…

Вот запуск с утилитой stress (подробнее про stress — здесь):

./chk stress --cpu 16

Естественно выход/окончание теста с утилитой stress осуществляется вручную по CTRL+C, отсюда и Error: 1 выведенная моей переменной PS1 из-за подобной реализации выхода из скрипта через exit 1.

Скрипт можно запустить и без опций, но тогда он только температуру и частоты в почти реальном времени показывает:

./chk

В любом случае выход из скрипта осуществляется автоматически, по окончании теста или можно выйти, нажав CTRL + C:

В общем: поставленную для себя задачу я решил и даже лучше — появилась целая надстройка над тестовыми утилитами. Осталось ноутбук разобрать и поменять таки термопасту с прокладками: как вспомню — аж страшно становится…

Стресс-тестирование систем в Linux – утилита stress-ng

Для организации и проведения нагрузочного стресс-тестирования в Linux-системах существует утилита stress-ng. С помощью неё несложно сгенерировать реальную рабочую нагрузку на тестируемые подсистемы и, соответственно, оценить её возможности. Утилита, традиционно для Linux, предоставляет для работы интерфейс командной строки. Однако, это ни в коей мере не делает её неудобной. Со своими задачами она справляется на «отлично». В данной статье приведены инструкции, отражающие основы работы с утилитой stress-ng для некоторых самых распространённых ситуаций в стресс-тестировании систем на основе Linux.

Основные особенности и возможности stress-ng

Возможности, которыми обладает утилита stress-ng, довольно широки. Об этом свидетельствует огромное количество всевозможных опций, которыми её наделили разработчики.
Но ключевой особенностью stress-ng является то, что это полноценный инструмент со встроенными тестами. В отличие от многих других аналогов, при выполнении теста не производится обращений к сторонним и/или внешним ресурсам. Таким образом, stress-ng абсолютно самодостаточна. Практически в любом дистрибутиве Linux она доступна в стандартном репозитории и устанавливается с помощью системы управления пакетами (СУП) дистрибутива. Например, в Ubuntu:

$ sudo apt-get install stress-ng

Кроме всего прочего, stress-ng в своём составе очень качественные тесты для тестирования процессоров, в совокупности позволяющие наиболее полно сгенерировать нагрузку на CPU, используя такие методы как целочисленные и с плавающей запятой, битовые операции, комплексные вычисления и т. д.

Синтаксис stress-ng

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

stress-ng [OPTION [ARG]] . . .

Задаёт конкретный метод тестирования виртуальной памяти. По-умолчанию выполняются все доступные для данной категории тесты, последовательно друг за другом. Подробнее в официальном руководстве по команде man stress-ng.

—vm-method mЗадаёт конкретный метод тестирования виртуальной памяти. По-умолчанию выполняются все доступные для данной категории тесты, последовательно друг за другом. Подробнее в официальном руководстве по команде man stress-ng.

Основные опции stress-ng

В таблице ниже указаны основные опции утилиты

Для удобства и быстрого составления необходимых тестов рекомендуется пользоваться также некоторыми вспомогательными опциями, например:

• что бы запустить несколько экземпляров каждого стресс-теста используется опция —all N, где N – необходимое количество экземпляров;
• для установки таймаута, т. е. времени продолжительности стресс-теста используется опция —timeout.

Тестирование процессора

Для подавляющего большинства ситуаций классическим примером стресс-теста можно использовать тест, выполняемый следующей командой:

$ stress-ng --cpu 16 --cpu-method matrixprod --metrics --timeout 60

В данном тесте задействованы 16 потоков для тестирования 16-поточного процессора. Вывод результатов может быть следующим:

Естественно количество потоков следует задавать в соответствии со спецификацией используемого процессора.

Тестирование дисковой подсистемы

Для проведения стресс-тестирования накопителей, таких как жёсткие диски можно для начала провести низкоуровневый тест ввода вывода

$ stress-ng --sequential 0 --class io --timeout 60s --metrics-brief

Вывод команды будет следующим

Еще один стресс-тест дисков можно выполнить командой

$ stress-ng --hdd 5 --hdd-ops 100000

В данном случае будет запущено 5 стрессоров для жёстких дисков, которые будут остановлены по завершении 100 тыс. bogo-операций.

Во время тестирования можно смотреть загрузку командой iostat

Тестирование памяти

Что бы провести стресс-тест памяти используйте команду

$ stress-ng --sequential 0 --class memory --timeout 60s --metrics-brief

После окончания мы получим результат проверки приблизительно следующего вида

Комплексное тестирование

Если необходимо провести комплексное стресс-тестирование, можно задействовать работу нескольких основных подсистем вместе одной командой:

$ stress-ng --cpu 4 --io 4 --vm 1 --vm-bytes 1G --timeout 60s --metrics-brief

Эта команда запустит тест для CPU в 8 потоков, тест виртуальной памяти с размещением в ней одного гигабайта данных, а также 4 стрессора для тестирования операций ввода/вывода.

Что бы запустить тестирование всего «железа», используется команда

$ stress-ng --sequential 0 --timeout 60s --metrics-brief

Эта команда запустит все тесты. После выполнения результат будет выведен в консоль. Во время выполнения команды лучше компьютер не трогать

Заключение

В заключение стоит ещё раз отметить, что утилита stress-ng по своим возможностям очень универсальна и позволяет качественно протестировать любую систему. Приведенные выше примеры охватывают наиболее распространённые ситуации по нагрузочному тестированию Linux-систем. Для проведения специфичных или более сложных тестов рекомендуется обращаться к официальному руководству по использованию утилиты, доступному по команде man stress-ng.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Стресс-тестирование процессора с помощью программы AIDA64

Одной из распространённых причин поломки ПК и ноутбуков является перегрев процессора. Такое редко когда происходит внезапно, обычно этому событию предшествует масса, так сказать, клинических проявлений – частые зависания, долгая обработка даже простейших операций, синий экран смерти и т.п. В большинстве случаев для решения проблемы достаточно провести уборку внутри корпуса компьютера и заменить термопасту.

Но иногда дела могут обстоять сложнее: в лучшем случае, возможно, придётся менять систему охлаждения, в худшем – покупать новый процессор.

Зачем проводить стресс-тестирование?

Узнать, помогла ли чистка внутри корпуса устройства и замена термопасты, можно сразу же по завершении проведения этих мероприятий. Не нервничая в ожидании внезапного повторения проявлений перегрева. Для этих целей существует специальный тип ПО, на борту которого реализована функция стресс-тестирования ЦПУ на предмет стабильности его работы. В рамках проведения этой операции система компьютера подвергается максимальным нагрузкам с отслеживанием температуры значимых комплектующих, в частности, процессора. Задача проводящего тестирование – сопоставлять значения отображаемой температуры с её критическим порогом.

Стресс-тестирование базовых компьютерных комплектующих – обязательная операция при их покупке на вторичном рынке. Не втюхивают ли нам проблемный процессор, не идёт ли с ним в комплекте кулер, не соответствующий уровню тепловыделения – эти и прочие нюансы можно будет выявить сразу, не дожидаясь их проявления после покупки. Искусственно вызванный режим максимальной нагрузки покажет, как будет вести себя ЦПУ в реальных условиях при обработке ресурсоёмких операций пользователя – не поднимется ли температура до критического порога, не будет ли операционная система подвергаться сбою.

Как провести стресс-тестирование процессора? Для этих целей прибегнем к помощи одной из популярнейших программ для диагностики компьютеров на базе Windows — AIDA64. В нашем случае будет использована базовая редакция программы Extreme.

Максимальная температура

Перед проведением стресс-теста необходимо выяснить критическую температуру процессора – максимально возможный показатель, превышение которого может привести к сгоранию. Сопоставление последнего с показателями, выдаваемыми по ходу тестирования, и является сутью проведения этой операции.

Усреднёнными показателями допустимой нормы температуры ЦПУ являются:

• До 45С° в условиях простоя, при работе только фоновых служб операционной системы.
• До 65С° при активной нагрузке, когда обрабатываются сложные пользовательские задачи.
• Температура в 70С° считается критической.

При достижении критического порога по идее должна срабатывать защита, вследствие чего компьютер сам либо выключается, либо перезагружается. Однако у каждого процессора свой показатель максимально допустимой температуры. Узнать его можно на сайте производителя, на конкретной страничке технических характеристик модели. И в этом поможет AIDA64. Запускаем программу, идём в раздел «Системная плата», далее – «ЦП». В окошке справа ищем графу «Информация о продукте». Здесь обычно размещается ссылка, ведущая на нужную страницу сайта компаний Intel и AMD. Кликаем её.

В окне браузера откроются характеристики модели процессора. В нашем случае AIDA64 перебросила на страницу веб-ресурса Intel, где выложены краткие сведения. Чтобы получить детальные характеристики, нужно сделать клик на названии модели.

В графе «Tcase» для процессоров Intel отображается их критическая температура. Как видим на скриншоте ниже, в нашем случае это чуть ниже общепринятой нормы — 69,1С°.

Значению 69,1С° и будем сопоставлять температуру, отслеживаемую в процессе стресс-тестирования.

Стресс-тестирование

Для запуска стресс-теста в окне AIDA64 раскрываем меню «Сервис» и выбираем пункт «Тест стабильности системы».

В состав тестируемых областей компьютера по умолчанию входят ЦПУ и оперативная память. Если нужно проверить стабильность работы других устройств компьютера – видеокарты и жёстких дисков, нужно выставить их галочки в верхнем левом углу окна утилиты тестирования. Для запуска процесса жмём кнопку «Start». Чтобы на визуальном блоке температуры проще было отслеживать показатели каждого из ядер процессора, можно убрать галочки отображения показателей материнской платы и диска.

Визуальная шкала удобна для отслеживания динамики нагрева, но по факту больше пользы будет от статистических данных тестирования. Во вкладке «Statistics» по каждому из ядер можем отслеживать показатели температуры:

• текущие (Current),
• минимальные (Minimum),
• максимальные (Maximum),
• средние (Average).

Хотя и здесь, по сути, особо интересовать нас должен только максимальный показатель — насколько он разнится с критическим порогом нагрева конкретно этой модели процессора.

Стресс-тестирование нужно останавливать вручную кнопкой «Stop».

Проводить эту процедуру рекомендуется от 30 минут до 1 часа, не отходя далеко от компьютера и периодически поглядывая на значения температуры. Если критический порог превышен, необходимо прекратить стресс-тестирование. Защита от перегрева, увы, срабатывает не всегда, и процессор может просто сгореть.

Признаки наличия проблем

О наличии проблем с процессором может говорить не только достижение критического порога нагрева, но также существенное отличие показателей температуры на разных ядрах. В норме разница не должна превышать 10С°.

Источник скачивания AIDA64:
https://www.aida64.com/downloads