[DVDshnik]

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

[Oleg_SK]

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

[SanCho]

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

[Oleg_SK]

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

[SanCho]

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

[Oleg_SK]

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

[SanCho]

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

[Oleg_SK]

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