FAQ на первой странице.
Ликбез: Процессоры intel - глобальный FAQ
Временная ссылка на Ликбез

По ссылке ниже находятся все стресстесты и мониторинг описанные в FAQ.
Комплект утилит для стресс-тестирования и мониторинга системы. (~38mb) обновлено 30.10.2012
Зеркало.

Вот собственно мысль, о которой разговор... Да и смущает еще тот момент что практически на всех скринах с праймом напряжение 1.376 вольт. Как не искал в статье так и не нашел на каком же Vcore реально работал процессор, разница вольтажей при тестировании это результат LLC или просадки ?

alex1974 Отвечу позже. Несмогу заочно сказать. Надо домашний компьютер смотреть.

Добавлено спустя 1 час 22 минуты 16 секунд:
alex1974 Вобщем посмотрел напряжения. Они равны для каждого теста как в 32 так и в х64 ОС. Никаких перекосов в сторону не замечено. Если есть - давайте ссылку.
Далее. Биос 1.344. LLC=on (мне так удобнее - без нагрузки ниже напряжения). Напряжения в нагрузке 1.360 -1.376.
Все замечательно.
Флопсы пока лениво смотреть. Эта тема меня мало интересует.
...
P.S. Только что проверил LinX - все путем. 1.376.
Так что вас еще конкретно смущает? Рассказывайте

Добавлено спустя 24 минуты 23 секунды:
alex1974 Да и я хотел бы услышать от вас ответ на вопрос. Почему у меня при одном и том же напряжении, любимый вами Prime32 и Prime64 работает в обоих ОС? Я еще понимаю вы тут пытаетесь говорить что версия линпака у программ не та. С Prime так-же будете? Где оно ваше повышение напряжения. А между тем вы меня обвиняли уже не раз, что мои результаты - касаются отдельно взятого компьютера...
Также очень интересует, почему при переходе с размера 14000 на 20000 использовалось одно и то же напряжение???
Жду подробного и ясного обьяснения.
Ну да. Тесты ничего не стоят. Касаются отдельно взятого компьютера. Мои старые тесты и вывод из первой статьи также делались на некоем другом компьютере и совсем в другое время (1.5года прошло). И там такой же результат. Цитирую.



Какие две досадные случайности. Но все равно. Это же на моем отдельно взятом компьютере. А у вас Prime x64 обязательно приведет к усилению нагрузки и потребует повышения напряжения. А также обойдет Linpack.
Все чудесно.

Вопрос на засыпку,во время работы прайма запустил распаковщик,в результате на одном ядре количество пройденых проходов отличается от другого. Нормально ли это?
#77

cure72 Конечно нормально. Архиватор по разному нагрузил ядра. Вот и получилось - одна задача выполнилась быстрее другой в прайме.

Ну как бы от флопсы показывают эффективность работы теста, учитывая глюки линпака, от запуска к запуску меняется как нагрев так и флопсы и по последним в принципе удобно смотреть насколько удачно запустился тест. У меня на каком-то линпаке вообще хохмовые 14 гфлопсов получались(иногда, но стоили перезапустить тест, иногда несколько раз и все нормализововалось), хотя обычно 52 в 32 битах 56 в 64х.. Соответственно при 14 нагрев никакой и эффективность проверки тоже.

константин с байконура Да у меня есть нормальный линпак. Корректно работающий с НТ. (как мне кажется)
Если нужно быстродействие сравнивать - скорее по нему буду (т.к. сам использую НТ).
Да и по крайней мере на настоящий момент я не использую Win7 x64. На которой проводил тесты. Мож винда потормознее. Но спорить на тему ОС нехочеться. У вин7 есть одно беспорное преимущество - она симпатичная и гламурная. На одной ХР тоже не 100 лет же сидеть...

Посмотрел на работу разных линпаков в ХР х64. Все по разному. Со новым с HТ получил 50. Что 32 что 64 бита. Со старым другие... Разброс во всем. Незнаю как вам, но мне кажется с производительностью можно забить. Зависит от ОС, от версии линпака. Сейчас уже нет такого стандарта когда он (линпак) тут появился. Я буду пользоваться им только как стресс-тест.

Это все что я хотел услышать. У вас хорошо удалось тестирование LLC на х38-P55 чипсетах с сравнением тестов ничего общего не имеющее. Главное условие сравнения тестов между собой, это равные напряжения, у вас же они регулировались лоадлайном, в довольно широком диапазоне. Ваша статья, количество проблем с переходом на х64 не уменьшит, а линпак не начнет реагировать на катастрофически низкие значения вторичных напруг QPI, VTT, GTL. На сим разрешите откланяться.

alex1974 Жаль что я не услышал ответов на свои вопросы. Ну да ладно. Не первый год на форумах. Одному не нравится одно другому другое. Но предпочитаю при наличии каких-то обвинений - аргументированный все-таки разговор. Четкие и понятные ответы.
...
Справедливости ради напишу (это не по i7 выводы). Для процессоров поколения кенсфилд, линпак действительно грел сильнее в х64 ОС чем в х32. Я сам это отписывал (и помню) еще на первых страницах ветки по нему. Сейчас ситуация изменилась. И я не увидел сколько нибудь заметной разницы. Или возможно та старая версия линпака этим и отличалась? Незнаю. q6600 уже нет и никогда небудет. Да и не нужно вобщем-то.
...
Для выяснения как на других платформах себя ведут стресс-тесты было создано голосование. А найти с десяток тестеров которые бы провели каждый у себя такие тесты - нереально. Например мне тестировали АМД. У человека проходит прайм и линпак. А ОССТ делает перезагрузку. Он утверждает что не по причине мат. платы и памяти. Но я не могу относить такую перезагрузку на счет процессора. И ни один из этих тестов так и не включил в статью. А может так и есть? На AMD OCCT лучше? Да кто-ж его знает. Чего он моргает. Второй овер, который обещал провести тест на своей платформе AMD - также не смог. Оказался занят. Вопрос так и остался в воздухе. Разве что информацию о пользе стресс тестов можно получить из голосования. Жаль только статистику первого голосования не сохранили. Я просил. Но администрация решила так.

Вы их задали исходя из того, что я, якобы сравнивал х64-х86 версии прайма. Я никогда не говорил, что прайм как то реагирует на изменение разрядности, и всегда утверждал, что эта проблема имеет место в линпаке. Каких либо пристрастий к определенным тестам у меня нет. По прайму нельзя настроить vcore, по линпаку нельзя подобрать QPI/VTT, GTL- вот моя позиция о которой я вам говорил миллион раз в этой ветке. Или с этим вы тоже не согласны и опять мне будете доказывать что я предпочитаю прайм??? Вторичные напряжения вы и вовсе проигнорировали в своем тестировании. Такое впечатление, что разгон процессора на вашей системе сведен к подбору Vcore.

По этому пункту я так и не услышал вразумительного ответа о производительности в 35 гигафлопс. Что могу ответить я в этой ситуации, если вы сами этот феномен объяснить не можете и тупо игнорируете??? По кол-ву гигафлопс легко судить и о уровне нагрузки, результат в х64 линпаке был ниже чем в х32 но вы все равно сделали вывод о том что все работает одинаково... при том что у меня к примеру ни разу в 32-х битном линпаке не было большего результата чем в х64.

Ситуация не изменилась, а с выходом новых чипсетов появилась фича интеллектуального управления питанием (load line calibration), которая вполне способна компенсировать недостаточный vcore на многих матерях. Кстати реализация LLC зависит от конкретной матери и не везде работает одинаково. На счет того что больше греет, вопрос меня и вовсе никогда не интересовал, я всегда говорил исключительно о стабильности, а не о степени нагрева.

Про аргументы... вы их просто проигнорировали. И сейчас пытаетесь отстоять свою позицию любой ценой.

Нет слов. Цитирую свои ответы. Раз уж в упор не видите.


Если на разных ОС разная производительность одного и того же линпака вам это не о чем не говорит?
Поясняю. Дело в ОС и ее работе с этой программой.
Работал в ХР х64 на частоте 394х. Подвтержденной в х32. Если бы ваша теория о соразмерности производительности с нагрузкой была хоть сколько то верна, то получив на 50% больше флопс - комп бы быстро вылетел в ошибку.
У меня на той ОС вобще производительность почти не изменилась при смене битности. И что? У вас возникнет теория что это уже не 64 бита?
...
Так же я писал
...

Остальное не вижу смысла обсуждать. Может вам обратиться к автору LinX, затем на сайт Microsoft о проблеме подсчета с использованием HT? Или любите только диструктив вносить?

Добавлено спустя 6 минут 32 секунды:
Эх жаль. Дуалист ушел. Я и не знал. Я бы сам с ним переговорил.

Нет не говорит. У меня такого не наблюдается. Разбирайтесь с ПО. Разница между х32 и х64 составляет 2-5 гигафлопс, но она всегда есть и всегда в пользу х64. Разрыв в производительности между версиями ОС одной разрядности, легко убирается повышением приоритета теста, в диспетчере задач - это позволяет избежать влияния фоновых процессов или служб. Но опять же если этот разрыв более 5 гигафлопс, то чо-то не в порядке с системой.

Я прослезился... FLOPS (или flops или flop/s)(акроним от англ. Floating point Operations Per Second (операций с плавающей точкой в секунду), произносится как флопс) — величина, используемая для измерения производительности компьютеров, показывающая, сколько операций с плавающей запятой в секунду выполняет данная вычислительная система. - для справки. Последние версии линпака ошибки на i7 находят быстрее...
но я полагаю что сей факт вы тоже будете отрицать как и остальные очевидные вещи.

Xmast писал(а):

Эх жаль. Дуалист ушел. Я и не знал. Я бы сам с ним переговорил.

всмысле "ушел"?

Добавлено спустя 14 минут 38 секунд:
Кстати по поводу линейного роста эффективности линпака с ростом размера матрицы... Я в этом вопросе солидарен с Xmast - после какого-то определенного порога, по логике вещей, размер матрицы должен перестать влиять на качество тестирования... иначе это бред... но вполне возможно что этот порог находится за границей в 20-ть тысяч ... Помнится даже Кронос (автор одной из тем по линпаку) говорил о том что рост результата замедляется после определенной границы "problem sizes".
Т.е по логике процессор тогда достигает пика своей производительности когда размер матрицы больше не увеличивает колличество "операций с плавающей точкой в секунду" (с) Википедия Соответственно с этой же границы и нагрузка на CPU достигает пика.


а собственно, в чем смысл этой цитаты из википедии?

Разумеется на каком-то этапе это произойдет. Но разговор не о том. Камрад Xmast несколько перефразировал мои слова, вот исходник. Разговор шел о достаточности объема в 14000 тысяч непонятно откуда взятом. О том что есть определенный порог после которого не имеет смысла поднимать объем матрицы я не спорил.

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

Я думаю говорить о достаточности какого-то размера матрицы нужно с привязкой к определенной архитектуре (или даже семейству CPU - предполагается что более скоростные CPU могут проявить себя лучше с большим размером матрицы).

Насколько я помню в случае с моим P4 2.4C изменение размера матрицы с 8 до 10К (памяти 1280Mb поэтому 10000 - максимум) не приносило абсолютно никакого роста производительности. (линпак 10.0.2 без оболочки). А если "теория о соразмерности производительности с нагрузкой" имеет подтверждение на практике (в чем лично я на данный момент уверен) то и роста качества тестирования подобные действия НЕ вызвали бы.

Вобщем тему мы с alex1974 обсудили в личке и закрыли.
14000 - это не официально рекомендуемый размер. Я назвал его из опыта тестирований. Большинство тестировали линпак в диапазоне до 14000-15000. Видимо по причине большей расспространенности 2Гб. Которая эти границы и определяет. Поэтому указал именно эти границы. Результатов в лучшем отлове ошибок при переходе на большие размеры я также не встретил. А временные потери при этом очень значительные...


И тут должен сделать сноску. Говоря о теории=практике отношений нагрузки и производительности, я имел в виду не то что они не взаимосвязаны. Тут я к сожалению неправильно выразился. Думал о другом сказать. Если один линпак показывает 35 а другой 50, и оба работают, то значит полученная частота тем не менее подтверждается.
Разбег конечно сам по себе не радует. Черт его знает.

Проведу несколько последних тестов в х64 средах. Посмотрю. Может найду ниточки

Добавлено спустя 2 часа 32 минуты:
Я нашел причину низкой производительности LinX в Win7 х64. На самом деле он выдает 45. Но есть одна тонкость. Параллельно у меня работали другие программы, в том числе видеоплейер. Ну так вот. Если в течении первого цикла расчетов активно работать на компе (я грузил видеофайлы), то производительность можно обвалить. Казалось бы все понятно. Процессов много вот и скорость пониже. Но не совсем. При закрытии всех этих процессов - скорость может оставаться как и до закрытия! Я таким путем обвалил скорость LinX с 45 до 28 (только загрузкой видеофайлов), затем вышел из плейера и наблюдал те же самые 28-29 флопс. Температуры до троттлинга не доходят. И еверест то-же говорит. Почему производительность не восстанавливается (или восстанавливается не полностью) после таких манипуляций - я не знаю. И даже не буду пытаться гадать. Но у меня происходит так.
Таким образом, запустив линх и запустив одновременно просмотр видео, у меня и снизились флопсы с 45 до ~35.
Интересно, что со второго цикла такого эффекта не заметил.
...
Все с тестами. Устал от них

Проверил все же разгон своего процессора (IC2D E6300 1,86Ghz@3,33Ghz) в 32-битной Windows XP Professional SP3 посредством утилиты LinX при объеме задачи 14000. Вот, что из этого вышло...

Перед тестированием в биосе были выставлены следующие значения напряжений:
CPU VCore Voltage - 1,4500V (по данным CPU-Z: 1,432-1,440V);
Memory Voltage - 2,10V (напряжение, рекомендуемое для профильной памяти ее производителем);
FSB Termination Voltage - 1,300V (+1 шаг от доступного к выбору минимума);
NB VCore - 1,40V (+1 шаг от доступного к выбору минимума);
SB VCore - 1,50V (минимум);
ICH Chipset Voltage - Auto.
Значения частот основной шины и памяти:
CPU Frequency - 476;
DRAM Frequency - DDR2 - 952Mhz.
Опция Memory Remap Feature была отключена (с тем, чтобы 32-разрядная WinXP увидела 2,93Gb оперативной памяти, а не 2,00 - как это происходит, если включить данную "фичу").

Указанные настройки позволяют моей системе пройти 300 "кругов" линпака при объеме задачи 10000. Ну, а если их сравниватьс условиями разгона процессора и проверки его стабильности в 64-битной Win7Макс, то в случае с WinXP "биосных" отличий два.
Во-первых, перед проверкой на х86 WinXP в биосе было установлено более низкое процессорное напряжением, чем в случае с х64 Win7Макс.
Во-вторых, была отключена Memory Remap Feature.

Итак, загрузив х86 WinXP при указанных выше настройках биоса, я запустил мониторинговые утилиты и включил тест. Все было ОК, кроме "поведения" HWMonitor, который в ходе теста демонстрировал просто удивительные показания вольтажей. Обнуление настроек мониторингового окна в этой утилите ни к чему не приводило - через некоторые время значения вольтажей приобретали нереальный вид. С учетом этого я остановил тестирование:
~307,49kb#77
После этого скачал последнюю версию HWMonitor для 32-разрядных систем и вновь запустил тест. Однако мои надежды на новую версию этого самого монитора не оправдались. Утилита продолжала "пугать" очень низкими показателями основных +напряжений и сверхвысоким CPU VCore. Решив не обращать на это внимание, я на ночь вновь запустил LinX на 300 проходов/размере матрицы 14000 и указанных выше настройках разгона. Утром же я увидел лишь... рабочий стол "оси", посреди которого нагло красовалась табличка Kaspersky Anti-Hacker c утверждением о том, что лицензия закончилась! Изучение журнала событий Windows, поиск дампов "синего экрана" при помощи утилиты BlueScreenView ни к чему не привели - внятной причины происшедшего я так и не вычислил. Такое впечатление, что в ходе теста, компьютер выключился, а затем, некоторое время спустя, включился. Иными словами, возможно, отрубилось электричество.
Как бы там ни было, я решил считать подобное завершение теста как его провал. Вечером удалил Kaspersky Anti-Hacker, установил другой файерволл, перегрузил ОС, повысил в биосе CPU VCore на один шаг - до 1,4625V (по данным CPU-Z: 1,448V). Далее: F10 - загрузка x86 WinXP - запуск мониторинговых утилит - включение теста. На сей раз система прошла 300 "кругов" LinX при объеме задачи 14000 и указанном процессорном напряжении:
~316kb#77
_______________________
Выводы?..
1. Я был поражен тем "разрывом напряжений", которые требуются для подтверждения стабильной частоты разогнанного процессора в одной утилите, с одними условиями тестирования, но в разных ОС. Для того, чтобы пройти 300 раз линпак в оболочке LinX при объеме задачи 14000 в среде х64 Win7Макс потребовалось подымать в биосе напряжение до 1,5000V. Это на три шага/позиции больше, чем для прохождения этого теста, но в операционной системе х32 WinXP Prof. SP3.
Чем это объяснять: разной разрядностью "осей", относительной "свежестью" Win7 или особенностями утилиты LinX, не знаю. Конечно, для большей уверенности следовало бы осуществить подобное тестирование, но с применением другой оболочки для линпака - InTelBurn Test или OCCT-Linpack. Как, впрочем, и включить в тестировании иные версии Windows - х64 и х86... Однако в ближайшее время заниматься этим точно не буду. Пока же на основании результатов своего сравнительного тестирования буду считать, что для стабилизации разгонной частоты в х64 Windows действительно необходимо подавать в биосе большее процессорное напряжение, нежели в случае с х86-разновидностями этих ОС.

2. Напомню, что в среде х64 Win7Макс при увеличении объема задачи в LinX с 12000 до 14000 для прохождения 300 "кругов" теста на моей системе потребовалось поднять процессорное напряжение в биосе на два шага - с 1,4750V до 1,5000V - с тем, чтобы подтвердить стабильный разгон IC2D E6300 на частоте 3330 Mhz. Для х86 WinXP_Prof_SP3 увеличение размера матрицы в указанном тесте было более существенным - с 10000 до 14000. Однако напряжение пришлось повышать всего на один шаг (и то с некоторыми оговорками) - с 1,4500V до 1,4625V. Объяснить такую "непропорцию повышений" ничем иным, кроме разной разрядности используемых в тестировании "осей", я пока также не могу...

3. Мысль о том, что многочисленные BSOD`ы (с ошибкой 0x00000124 и ссылкой на файл ntoskrnl.exe), неоднократно прерывавшие тестирование в среде х64 Win7Макс, имеют другое объяснение, чем недостаток процессорного напряжения, не давала мне покоя. Поэтому я решил проверить потенциальные причины сбоев - ошибки в работе памяти или матплаты. Вначале была осуществлена проверка оперативной памяти. Трехчасовой прогон утилиты memtest86+ в среде DOS ошибок не обнаружил:
~156,84kb#77
Затем был предпринят такой эксперимент. Загрузив х64 Win7Макс на частоте FSB 500 Mhz (для этого в биосе CPU VCore было повышено до 1,5125V, а NB VCore - до 1,55V; остальные настройки оставались прежними - как для разгона моего процессора до уровня 476Mhz х 7), я запустил все тот же LinX с объемом задачи 14000, но количеством проходов - 10. Секунд через 5-6 после начала теста он был прерван "синим экраном" с ошибкой 0x00000124. Далее - перезагрузка, снижение частоты шины до 495 Mhz, F10 - загрузка "оси" и вновь запуск теста. На сей раз LinX с теми же условиями тестирования вызвал синий экран чуть-чуть позже после старта: секунд через 10-15... Вообщем, дальше я снижал частоту FSB еще на 5 Mhz и вновь повторял тест - с каждым разом время тестирования "до BSOD 0x00000124" увеличивалось - чем ниже была частота, тем дольше система держала тест (проходя уже несколько "кругов"). Наконец, на частоте шины именно 476 Mhz линпак в оболочке LinX с объемом задачи 14000 был пройден все 10 раз...
С одной стороны, это говорит мне о том, что нынешний разгон моего процессора до уровня 476 Mhz х 7, пожалуй, и составляет его потолок стабильности (по крайней мере, в утилите LinX_14000 и при заданном значении VCore 1,5125V по-биосу). С другой же - явная зависимость между снижением частоты FSB и увеличением времени тестирования до появления синего экрана явно же свидетельствует о следующем. В моем случае указанный BSOD следует трактовать скорее не в качестве ошибок в работе памяти или материнской платы, но с большой долей уверенности как реакцию LinX на переразгон/недостаток процессорного напряжения именно в среде х64 Win7Макс. Да, и расписанная выше проверка разгона х32 WinXP Prof. SP3 вполне позволяет доверять этому выводу. Ведь странно же: на одной "оси" матплата нещадно "бсодит", на другой же и намека на это нет...

Хотя прогон системы еще и через Prime95/Blend я несомненно устрою. Но... позже... И для себя... Тоже устал уже от тестов ...

ovix Интересно! Эх жаль мало таких исследований. Но на мой взгляд у вас сказывается ограничение по фсб мат. платы.
Вобще еще пару лет назад я пришел к выводу, что очень нехватает универсального (комплексного) теста. По сути ничего не изменилось. ОССТ разве что. Но и он не совсем то что хочется...

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