anta777, проверил tRFC 432 (с твоих слов "истинный" tRC 54x8), система виснет. При tRC 54, 56, и tRFC 464 система виснет. Что еще попробовать?

Установить tRAS=40, все остальное оставить как у Вас на скриншоте.
У Вити кроме его слов есть только его картинки-скриншоты из его большой практики. Книги он не признает. Его практика выше любой теории.

Верно ли показывает RTC тайминги?

Нет. Значения которые находятся в регистрах sm_bus это то что по сути мы сохранили в биосе при этом они не есть реальными, контроллер памяти корректирует тайминги. Сейчас попадаются биосы отладочные , в которых нет ограничения на тайминги, они могут быть аномально низкие при этом система будет стабильна. Яркий пример это пресеты CJR Reous. Я ему полностью доверяю, но нас тем не менее обманул биос.
По поводу низких значений RTC можно не бодаться, выделить сторону которая права я не смогу.

tRFC с остатком или без

tRFC без остатка греет память на 3-4 градуса больше, удивлением для меня было когда для 3466 trfc был изменен с 277 до 252 (39 против 43 градусов), то-есть утверждение про "время остыть" имеет место быть

tRFC = tRC * 7

Система стабильна

Какое tRAS tRC?

Ваши споры заставили меня взглянуть на картину немного по-иному. А теперь в деталях.

Tras, Active to Precharge - минимальное время активности строки, то есть минимальное время между активацией строки (ее открытием) и подачей команды на предзаряд (начало закрытия строки).



1) активация
2) операции IO (делится на 2 подэтапа: передача данных в глобальные усилители и отправка данных в канал памяти через интерфейс ввода-вывода микросхемы)
3) предварительная зарядка

При этом активация и предварительная зарядка происходят полностью внутри подмассива, тогда как IO происходит в периферийной логике и схемах IO. От сюда возникает вопрос, а как можно оптимизировать этот цикл?

1) уменьшить размер пакета данных (маленький пакет не всегда есть плохо, если вам нужно купить 1 батон не обязательно приобретать тележку чтоб доставить его домой, достаточно маленького пакета)
2) подать команду на предзаряд на этапе отправки данных в канал памяти через интерфейс ввода-вывода микросхемы (параллельное выполнение команд)

в итоге мы получаем, было:

tRC = tRCD (tRCDRD/tRCDWR параллельны, устанавливается значение по tRCDRD) + tCL + tBL + tRP

стало:

tRC(min) = tRCD + tRP + tBL + x
где х, определенное кол-во тактов которое нужно чтоб не допустить «обрыва» передаваемого пакета во время передача данных в глобальные усилители
найти его можно чисто практически

касательно практики я займусь этим вопросом тщательно и опубликую результаты
в качестве тестового пакета хочу опробовать новый ROTTR , там и графики и DX12 и все что хочешь

p.s. я только сегодня изучил что выводит RTC, потому , быть может, заниженный tRAS окажется мифом как и его формула tRCD+tBL+x

p.p.s. примите во внимание, что есть очень умный и известный человек с ником Stilt, если вы обратите внимание на его пресеты https://www.overclock.net/forum/26242714-post24134.html, то у хьюникса AFR tRAS 30 a tRC 38. Я не думаю что он ошибся. В частности я пишу это для камрада anta777.

Это вертушка верхняя передняя и передняя верхняя. 4 планки на 1,55V. Передняя вертушка cpu снята и радиатор отделен от памяти листом бумаги. Да, я пытался её нагреть специально, потому что даже на 1,55 при нормальной работе она едва тёплая. В этом и суть теста.
И ещё раз, рекомендую спросить в ветке интела как работает TREFI, и желательно, уточните перед этим, что 65536 невозможно
Мой тест показывает, что МОЙ комплект(именно мой, не обязательно это будет на другом) вполне хорошо держит заряд конденсаторов даже при очень редком обновлении и при высокой температуре. Ваша теория вновь говорит, что это невозможно. Купите уже себе компьютер, и протестируйте сами. Раньше также свято верили в теорию, что земля плоская, а потом выяснилось, что в итоге любой, у кого z390 и b-die, сидит на 65536 и все отлично.

Тогда пишите формулу корректно. Вы пишете "RAS+RP", но нет команды RP, есть команда "PRE", а "RP"- это тайминг trp, поэтому "ras±rp" мной было воспринято как тайминги

Добавлено спустя 5 минут 54 секунды:

А как же GDM, который исправляет ряд таймингов на четные, и это отражается в RTC? или с GDM коррекция происходит ДО?

Victor91rus
эта коррекция происходит в оболочке еще, то-есть контроллер памяти не имеет к нему отношения

Витя, это ты не знал как работает tREFI, про что я тебе написал с подробными объяснениями. 65535 (не 65536) возможно, но с ошибками, это уже понял даже xyligano, а куратор темы занижает tREFI еще больше.
Мой же совет, основанный на исследованиях мировых институтов, допускает стабильную работу при значениях tREFI рассчитаному по стандарту и умноженному на 3, что даст 192 мс. В опытах заметили падение стабильности при значениях выше 200 мс.
Твоя так называемая стабильность ничем не подкреплена кроме твоих слов, это не доказательство.

Зачем? Я ухудшаю важнейший рабочий первичный тайминг ничего не улучшая.

vorvort
ты попробуй эти 40, мне тоже нужно понимать происходящее
чтоб найти виновных и наказать жестоко

_____________________

для всех

а вообще это конечно глупость трактовать теорию не проверяя на практике
если б все так было как на бумажке не было б этих тем по райзену с тоннами сообщений

Так ведь совсем скоро AMD откроет свою документацию по контроллеру памяти, до февраля осталось совсем чуть-чуть, тогда должно будет многое стать ясным.

anta777
если опубликует, они далеко не все делают что говорят или обещают

Очень жаль.
А thaiphoon burner показывает тоже неистинные значения таймингов в своей вкладке - контроллер АМД? Или истинные?

В Аиде хуже не стало, в TM5 короткий тест не прошла - 1 ошибка.

Очень интересно, ошибка в каком тесте?
А если поставить tRAS=42, то система запустится?

Я не смотрел операцию, после 3 -х минут.
Сейчас 42 проверю.

Спасибо!

В Аиде латентность снизилась на 0.2 - 0.3 нс (три теста), остальные результаты в том же коридоре, что и при tRAS 36, в TM5 ошибок нет.

А вы много у кого видите память, стабильно работающую на tcl=7,7ns и умеющую в 7,5ns?
Я это к тому, что опыт куратора и института безусловно важен и интересен, однако не надо сравнивать разные комплекты памяти и их возможности, подгоняя это под одну линейку. У некоторых память кипяток на 1,36в, а в меня на 1,55 без намеренной изоляции не прогреть. TREFI по jedec, как и другие задержки, разработаны не случайно, однако они, как и почти любое, что изобретено человечеством, имеют буферный запас по всем возможным параметрам. Если tcl по jedec 14ns, то это не противоречит тому, что хорошие комплекты могут в 2 раза лучше. То же самое касается и TREFI. В исследовании наверняка не участвовал белый отборный HOF или какой-нибудь gskill 4400c19, а участвовали там какие-нибудь зеленки от крушиала, причём на самых древних чипах. А то, как сильно отличаются возможности древних ревизий дешевой памяти и новых ревизий отборной-есть куча материала. Тайминги отличаются в разы.

Согласен, как раз изменениям таймингов и посвящена диссертация доктора Ли.
Но зачем ты писал, что любая память B-die на z390 тянет максимальный tREFI ?
И тут есть еще один очень важный нюанс:
твой tREFI 65535 при 4400 - это совсем не то же, что 65535 при 3200 или 3400.
И свои тайминги ты улучшил всего в 2 раза, tREFI я предлагаю улучшить аж в 3 раза, а тебе этого мало. Сохраняй тогда пропорции.

А по теории плата даже не должна была запуститься.
Что-то делает контроллер памяти, но что конкретно, знает только Stilt.
А тайфун бернер показывает те же тайминги, что и RTC?
Смотреть вкладку контроллера 17-го поколения.

Преувеличил, ничего страшного. Не любой, но у многих 65535. И почти в каждом гайде про TREFI пишут что-то типа "я не знаю шо это, но бахаем в потолок и тестируем"
Соответственно, почти любой скриншот с разгоном памяти содержит максимально возможный TREFI.
Конечно за чужую стабильность я не отвечу, однако никто не жалуется.
Я проходил тест при 3200 с 65535. Как минимум, 5 циклов тм5@1usmus он держит.

Отличная у тебя память!