Мне не пофиг. Эта ошибка может вылезти когда ни-будь в самый неподходящий момент. Я ошибок не допускаю в принципе. Хотя отчасти могу согласится, если пк используется в каких то ограниченных приложениях, то как вариант можно такие ошибки, не приводящие к критическим сбоям системы, пропустить мимо глаз. Но просто мне это в дальнейшем не даст покоя. За других говорить не буду. После просмотра очередного видео каких то блогеров-разгонщиков, которые начитаются инфы и сразу считают себя гуру настройки, практически всегда угораю с какой ни-будь фразы в комментах типа, я настроил курву по данному гайду, везде всё ок, за исключением того что система ребутится в сталкере2 на этапе компиляции шейдеров, но в самой игре всё хорошо. Ну так оставляй, хрен ли, всего то один раз пережить компиляцию.

HertZ Подумаешь одна ошибка всего то через 11 часов. Её ведь может и не быть в повседневе. Ну если к примеру в играх, то там может и видеодрайвер быть виноват и тут уже не Билл а будет Хуанг виноват, прям 100%. Но вот только упс, лично у меня вылеты видеодрайвера практически всегда были связаны с кривой настройкой памяти. Ещё давным давно когда играл в первую The Division, обратил на это внимание.

shuler37, приемлемость и для «игровых» сценариев тоже с оговорками. Эта ошибка вполне может случиться в странице, занимаемой закэшированным файлом реестра или служебной структурой NTFS. Которая позже тихо и мирно уйдет на диск при выключении. А потом утром будет «оно просто перестало загружаться, говно эта ваша винда, взяла и сама сломалась, без причины вообще, я же ничего не делал». Но да, некоторые ещё со времен 95-й винды научились переустановку делать три раза в неделю, на уровне рефлексов, так что им норм.

Добавлено спустя 14 минут 24 секунды:
shuler37, ну тут ничего удивительного, сама архитектура тому располагает. Данные, прежде чем стать доступными для видеочипа, сначала должны пройти оказаться в RAM, чтобы их оттуда можно было скопировать. Равно как и данные в видеопамяти, прежде чем стать доступными для процессора, сначала должны быть скопированы в RAM. Соответственно, процессорное время видеодрайвера большей частью как раз и и есть копирование туда и обратно, это в отдельных случаях вполне себе стресс тест уровня карху. Что бы ни случилось по пути, если из-за ошибки в памяти/кэше/ядрах данные превратятся в мусор, то первым делом будет вылетать именно видеодрайвер. До недавнего времени GPU ещё и не умели выбрасывать исключения аппаратно, так что было ещё веселее. Получение кривых данных приводило к непредсказуемым эффектам уже на стороне GPU, который не понимал что с ними надо делать и что случилось. И выглядело это уже как аппаратная проблема с видеокартой, которая совсем ни при чем.

Помню, была уже тут дискуссия на эту тему. Года 2 назад. Суть в том, что если крутить тесты двое-трое суток, то одна ошибка появится, даже если она будет false positive.
И уж не помню, может быть и с тобой мы тогда спорили, но моё мнение остаётся прежним: если вы не собираетесь запускать на своем компьютере рендер на сутки, или вести многосуточные математические расчеты, то подобные многочасовые тесты — это просто пустая трата времени.

Есть грань, когда нужно остановиться. Люди, которые не используют компьютер по прямому назначению, а сутками гоняют тесты... Ну, мне лично это не понятно.

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

Вообще я такие сообщения видел. И после холодной загрузки и после спящего режима. Но это уже оффтоп.

Phenomenum, в данном случае точно не «false positive», потому что крашится зацикленный 7-zip и VST с -D:3600 оно не может пройти. Зато VT3 замечательно крутит.

HertZ В данном случае да. + ты про PBO писал. Тут явно где-то напряжение проседает.
Видишь, опять же, проблемы выстрее обнаруживаются в прикладных приложениях, даже если тесты показывают ОК.

Phenomenum, про PBO писал о совсем другой памяти и о совсем другом поведении, там нет никаких ошибок ни в каких тестах. Просто что-то не так отрабатывает при очень высоком напряжении на памяти, уверен что PBO там вообще косвенный фактор.

Этот же скрин с интела, и на нем нет PBO. И проблема точно в памяти, ей просто не суждено работать на 8000 с 4-х слотовой материнкой. Смысл же поста в том, что можно настроить систему под конкретный тест и она будет его крутить по полдня, но при этом будет валиться на совсем простых вещах. Так что 40 минут это смех в любом случае. Даже под игрульки.

Добавлено спустя 4 минуты 30 секунд:
Phenomenum, ну и ещё один момент. То, что называют «false positive», на самом деле вовсе не «false», а просто неконтролируемые события. Космические лучи то есть. Майкрософт публиковал исследование на эту тему, с ростом высоты над уровнем моря количество «случайных программных ошибок» растет по закону обратных квадратов. Так что в какой-то момент любая система выдаст ошибку, если нет механизмов корректирования, и уже эти неконтролируемые ошибки будет никак не убрать. Переехать в шахту разве что. Но DDR5 этому явлению уже менее подвержена, она может прозрачно корректировать ошибки в хранимых данных.

Phenomenum Поэтому я и говорю, каждому своё. Естественно не каждый вынесет многочасовые тесты. Но как тут было сказано, ошибок быть не должно. А уж как тут кто интерпретирует понятие ошибка, это его личное дело. Для меня ошибка это уже потенциальная нестабильность. Хотя я и не приверженец гонять тесты по десятку часов. Я делаю по другому, максимальный комплекс различных тестов, на час-два каждый. И потом многочасовые игровые тесты. Так как компьютер использую как медиа станцию, инет, фильмы, игры, музыка. Пока ни одного сбоя. Везде стабильно. Как только появятся, если появятся, буду решать. Но по опыту сборки с 2000г компьютерных систем и настройки кучи разнообразного железа, это вряд ли случится.

dmitrij31 и ashap88 спасибо, протестирую ещё эти в играх и отпишу о результатах и тестах на ошибки на своих планках и своей сборке на своих настройках биос со скриншотами настроек из биос и иных настроек.

У меня игры крашились от одной ошибки за 6 часов карху
Но если тебе ок винду раз в неделю переустанавливать - как хош. Ток другим своё садо-мазо не советуй - это 3.1
Вот тут соглашусь. Нет проблем - гонять сутками не обязательно, достаточно 2-3 часа тестов. Есть проблемы - тогда уже углубляемся.
Но и точно не надо делать так, как выше советует spellcraft - 1 ошибка за 40 минут теста это очень нестабильно, и проблемы будут 100%

Добавлено спустя 7 минут 26 секунд:
К тому же непонятна цель "терпеть" ошибки. Ради чего? 100МГц по памяти? Это смешно

npa4ka, «проблема» - это субъективное понятие. Ошибка же является объективным фактом. Она просто есть и её наличие никак не зависит от тонкой душевной организации наблюдателя. Человек может глазами смотреть на «проблему» и не замечать её. Поэтому многие баги в трекерах висят неисправленными по 9-10 лет. Разработчик отвечает фразой УМВР («у меня всё работает»), и так продолжается до бесконечности Ошибку же в тесте можно проигнорировать, приняв на себя ответственность за такое решение, но её нельзя не заметить. Поэтому юнит-тесты и стали индустриальным стандартом. Ведь игнорировать тикеты в трекере можно, а за игнорирование ошибки в тестах могут уволить.

Со стресс-тестами рационален точно такой же подход. Тестируем, не дожидаясь «проблем», чтобы не думать и не париться впоследствии. И не тратить время на размышления о том, есть ли «проблема».

HertZ только если твой код падает и юзеры жалуются, а ты такой "у меня юнит-тесты ОК" - то тебя тож уволят нахрен

npa4ka, это уже вопрос к тому, кто написал тесты с неполным покрытием. Или вообще откровенно натупил с логикой. Но тут чаще включается УМВР уже.

ТМ5 (или что там) 40 минут - это однозначно не полное покрытие

Добавлено спустя 1 минуту 40 секунд:
Между делом, настроил свой комплект так
Как время будет ещё напруги поуменьшать и ок

И ещё, подскажите пожалуйста dmitrij31 и ashap88 или кто-то из знатоков.
Что лучше в итоге будет именно для игр в плане улучшения FPS...

Эти настройки под Hynix M-die c 6000 CL28 = 160ns?
Ссылка на настройки от dmitrij31 https://forums.overclockers.ru/viewtopic.php?p=18629993&sid=8ea56671bf7decac1c0e0b85a72b999c#p18629993
Ссылка на настройки от ashap88 https://forums.overclockers.ru/viewtopic.php?p=18629993&sid=8ea56671bf7decac1c0e0b85a72b999c#p18629993

Или же мои эти ниже настройки под Hynix M-die c 5800 CL28 = 157.2414ns?




tREFI пока тестирую 65024, но думаю на этих таймингах протестировать на стабильность ещё 65535.
Вольтажи все в биос пока в Auto для 5800 CL28 на моих планках ADATA XPG Lancer DDR5 6000 МГц 2x16 ГБ (AX5U6000C3016G-DCLABK) Hynix M-die и поэтому биос сам выставил такие вольтажи.
А вот VSOC поставил 1.200 в bios, но по итогу в ZenTimings смотрю автоматически накинуто ....50V, то есть на VSOC можно не смотреть, так как пытаюсь подобрать минимально стабильный VSOC под Hynix M-die c 5800 CL28 на этих планках AX5U6000C3016G-DCLABK и по сути 1.200 понимаю это итак с переизбытком под Hynix M-die c 5800 CL28 на этих планках. Ставил для 5800 CL28 VSOC 1.1250, но иногда очень редко были странности с ПК, поэтому решил начать тесты для 5800 CL28 с VSOC 1.200 и далее после тестов понижать планкам AX5U6000C3016G-DCLABK VSOC под 5800 CL28.

То есть есть ли смысл для ИГР под Hynix M-die на этих планках гнаться за 6000 CL28 и повышать tRFC до 480 и выходит 160ns или же логично для именно игр использовать тогда 5800 CL28 с tRFC 456 с 157.2414ns и при этом тогда не придётся задирать вольтажи на более высокие значения, чтобы не дегродить чипы у планок памяти и у контроллера памяти процессора?

Вопрос связан только из-за буста FPS в играх (особенно редкие 1% и оч. редкие кадры 0.1%) и чтобы тайминги не крашили игру или не дропали бы интернет, так как думал обновить планки с Hynix M-die на Hynix A-die для выставления более низкого tFC на 5800 CL28 или 6000 CL28, но что-то припозднился, а когда очнулся, то Hynix A-die уже стоят целое состояние и это ещё не предел, поэтому придётся пока дальше сидеть на грёбанных M-die-)))

Не оффтоп, на самом деле, а насущная тема, ибо с напряжениями не всё всегда бывает просто.


Тут соглашусь. Это уже на тоненького.

Хотя, у меня была хохма, ещё с райзеном 1600 с DDR4 3333 Cl16 (там калеченная ОЗУ была, не суть). Прогнал все тесты, Ок, пользовался 3 года, всё ОК. Перед тем как отнести на работу в 2023-м, решил прогнать тесты. ТМ5 ошибка через 4 минуты. Я ещё раз. Так же.
В итоге, не стал сильно копаться, снизил частоту до 3200, и забил. До сего дня в офисной работе ни одного нарекания, работает как часы.

Вопрос: интересно, сколько я её юзал с такой нестабильностью?

pateritum, для tREFI разница между 65535 и 65024 это не разница. Если на 65535 глючит, то на 65024 тоже будет глючить.

Касательно tRFC, тут уже всё определяется здравым смыслом. tRFC 640 с tREFI 65535 и tREFI 4000 - это немного разные вещи, скажем так. Если при низком tREFI от уменьшения tRFC будет заметная разница, то при расжатом tREFI разницы от кручения tRFC с гулькин нос, просто потому что регенерация происходит реже и занимает меньшую долю циклов в целом. По большому счету, если у тебя tREFI 65k+, то tRFC можно не трогать вообще. Если где-то какая-то разница и будет, то на неё можно будет с чистой совестью плюнуть.

Ничего себе 3D-кэш так в PyPrime роляет...

На tREFI 65535 у меня не глючит, просто некоторые техноблогеры советуют для M-die ставить 65024 вместо 65535, так как у некоторых в тестах на 65535 были нестабильности, но я на своих планках не заметил разницы в стабильности или нестабильности при 65024 или 65535.

Спасибо за полезную информацию, как раз будет полезна для тестов и анализа тестов.
Ну раз так, тогда пойду верну tREFI на 65535.