Компьютерный форум OSzone.net  

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)
-   Разгон, охлаждение и моддинг (http://forum.oszone.net/forumdisplay.php?f=52)
-   -   [решено] Непонятная ситуация при тестировании переразогнанного CPU. (http://forum.oszone.net/showthread.php?t=130755)

Oleg_SK 03-02-2009 03:24 1027875

Непонятная ситуация при тестировании переразогнанного CPU.
 
В общем, некоторое время назад, когда я разгонял свой CPU (Core 2 Duo E8400), и искал максимально стабильную частоту для него, возникла непонятная для меня ситуация. Для проверки стабильности работы CPU я использовал утилиту-грелку Prime95. При чрезмерном разгоне процессора, после некоторого времени тестирования (1,5 ч. - 4,5 ч.) тестовая утилита показывала, что на одном из ядер CPU произошла ошибка. Непонятка заключается в том, что ошибка ВСЕГДА происходила на ядре #1, а тест на ядре #0 продолжал нормально крутиться дальше. Более того, даже когда разгон уже упирался не в CPU, а в оперативку (CPU при этом работал на частоте более низкой, чем макс. стабильная для него), ошибки продолжали возникать ТОЛЬКО на ядре #1. Кто-нибудь может объяснить: почему ошибки появлялись только на ядре #1? Почему имеется такой неравномерный разброс ошибок по ядрам CPU?

P.S: Prime95 я запускал раз 20.

DVDshnik 03-02-2009 07:04 1027910

Возможно, второе ядро имеет какой-то производственный дефект, проявляющийся при переразгоне, не не возникающий при номинальных параметрах.

Oleg_SK 03-02-2009 08:21 1027938

DVDshnik, я честно говоря, тоже сперва думал нечто похожее: что у второго ядра разгонный потенциал оказался меньше, чем у первого. Правда, эта версия не выдерживает критики. На то есть две причины:
1) Проц нормально отработал в течении суток на более высокой частоте, под нагрузкой Prime95 (когда тестировался только CPU). Когда же я стал тестировать в режиме CPU+MEM, ошибки стабильно вылетают где-то через 1.5 часа. Причем сам проц при этом работает на чуть меньшей (~50Mhz) частоте, чем тогда, когда он отпахал без проблем сутки;
2) Я буквально вчера узнал, что ядра процессора не имеют жесткой привязки к номерам, т.е. например: сейчас первым является одно ядро, а после включения-выключения компа этот номер вполне может быть присвоен другому ядру. Если я правильно понял, номера ядрам присваиваются в случайном (или псевдослучайном) порядке после включения компа. Прочитал об этом здесь: http://www.rsdn.ru/forum/message/322...t.aspx#3223213 .

SanCho 03-02-2009 11:59 1028136

Oleg_SK, если в система работает, то забей на этот Prime95. Скорее это ошибки возникают из-за особенностей тестирования. Какое бы ядро не было первым в нём всегда возникают ошибки из-за особенностей загрузки, например, второго. Нет ошибок в играх и обычной работе - забей или отключи разгон, если это тебя гложет.

Oleg_SK 03-02-2009 12:24 1028157

SanCho
Это я просто, ради интереса вопрос задал. После того, как я еще немного снизил частоту FSB (до 435Mhz) ошибок в Prime95 больше не возникло (в каждом из имеющихся режимов тестировал в течении суток). Уже почти месяц комп работает в режиме 24/7 и никаких проблем не наблюдается :)

SanCho 03-02-2009 12:53 1028187

Поясню: дело в кеше L2 - он у C2D распределяемый, т.е. при условии использования одного ядра оно может получить в своё распоряжение всю величину кеша L2. При тестировании одного лишь CPU (без памяти) для максимального ускорения выполнения операций, минимизации простоев и соответственно максимального разогрева используются по возможности инструкции, которые помещаются в кеш L1. При этом величина кеша L2 не имеет большого значения и он используется минимально. Поэтому и не было ошибок. При использовании режима CPU+MEM максимальная нагрузка приходится на кеш L2 и саму память. А далее в силу специфики тестирования происходит сбой в кеше L2, выделяемому одному из ядер - какое это ядро физически не имеет значения, а для системы это ядро #1. Т.е. ошибка происходит в кеше L2, который принадлежит ядру #1 - а какое это место на кристалле не суть важно, кристаллы близнецы и думаю у обоих ядер на данной частоте может быть остановка по одинаковым причинам - использование определённого сбойного места в кеше.

Oleg_SK 03-02-2009 13:11 1028199

SanCho, действительно, я что-то упустил из внимания кэш. То что вы сказали, действительно объясняет ситуацию. Большое спасибо!

SanCho 03-02-2009 14:35 1028264

Добавлю также, что сам кеш является наиболее узким местом, а остальные функциональные блоки CPU могут функционировать на гораздо большей частоте. Именно поэтому бюджетные варианты с урезанным кешем лучше разгоняются. Именно поэтому вначале кеш располагался на самой материнкой плате, а позже на дочерней плате с процессором и работал на половинной частоте CPU. И именно процессоры Celeron не имевшие в далёком прошлом кеша L2 вообще достигали гигантской на то время тактовой частоты, но также легко проигрывали скромным своим братьям которые работали на в два раза меньшей частоте, но имели кеш память встроенную в кристалл. Величина кеша - это палка о двух концах и производители CPU постоянно играют со связкой величина_кеша/тактовая_частота.

Oleg_SK 03-02-2009 14:58 1028294

IMHO иногда процессоры хорошо разгоняются благодаря перипетиям маркетинговой политики производителя. Например, мне кажется, что Core 2 Duo E8x00 изначально предназначались для работы на FSB 1600, а не FSB 1333. Возможно Intel искуственно занижает производительность данных CPU, что бы они меньше конкурировали с Core 2 Duo Qxxxx. Как вы думаете?


Время: 16:05.

Время: 16:05.
© OSzone.net 2001-