Принятые в теме сокращения (и заодно необходимые утилиты для отладки и тестирования памяти)
TM5 - TestMem5
ATC=Asrock Timing Configurator 4.0.4 for z370/390
Asrock Timing Configurator 4.0.13
Asrock Timing Configurator 4.0.12 for z690
Asrock Timing Configurator 4.0.10 for z590
Asrock Timing Configurator 4.0.9 for z490
Asrock Timing Configurator 4.0.8
Asrock Timing Configurator 4.0.3 for z170/270/490

Asrock Timing Configurator 4.0.16
https://drive.google.com/file/d/1-PdgLkCf-5cA3b1kqO2CmFyhXtz-tiS3

AMT - Asus MemTweakit Asus MemTweakIt 2.02.44
При настройке памяти в BIOS ставим ОБЯЗАТЕЛЬНО MRC Fast boot=disable (включаем при этом режим тонкой тренировки, если же выставим enable, то включаем режим грубой тренировки).
Оптимально при разгоне памяти использовать в биосе множитель памяти 133, а не авто или 100, что даст возможность создать комфортные условия для контроллера памяти в процессоре и снизить напряжения ио и са ! Недаром в Jedec шаг между спидбинами именно 133, а не 100!
Для плат с Alder Lake напряжения VDD и VDDQ на память могут отличаться не больше, чем на 300 мВ.
Для плат на основе логики z690 и b660:
VDD>VDDQ
VDDQ>=VDD-300mV(0.3V)
Лучше на VDDQ не превышать 1.25V. Вполне возможно 1.30V. MSI дает зазор до 1.40V.
Для таймингов должно выполняться требование:
_dr=_dd

Разгон памяти у современной DDR4 (16 банков,RRDS=4,FAW=16,BL=8) эффективен только при tRC<=64,если каждый новый блок чтения происходит с разных банков памяти.
Для 4-х слотовых плат при разгоне желательно в биосе отключить неиспользуемые слоты.
Предположительно для максимальной производительности памяти значение tRFC в тактах для 8-Гбитных чипов должно быть кратно 8,а для 16-Гбитных чипов - 16. Если это правило не соблюдать, то будут вставлены лишние такты при каждом цикле обновления памяти.
Для желающих максимально снизить tRFC.
Делим tRFC на сумму tRCD,tRTP и tRP.
Если результат ближе к 4, то снижать tRFC можно по 4 такта.
Если результат ближе к 2, то снижать tRFC можно по 2 такта.
Это связано с тем, что обновление происходит субмассивами, которые обязательно кратны 2.

Новая информация по tRAS


Напряжения на процессоре при разгоне памяти






МЕГАпост про RTL и настройку






Расшифровка коротких наименований таймингов часть 1 и часть 2

Предварительная настройка параметров разгона в BIOS платы (на примере плат ASUS)

Пресет для поиска максимальной частоты DDR4 и расчета таймингов от Agiliter (может пригодиться тем у кого плата автоматом выставляет какую-то дичь при автоматической частоте)
Необходимо дополнительное тестирование и ваши предложения что там добавить или поменять.

Кстати, на нашем форуме есть еще и другая Таблица по расчёту таймингов









Программы для тестирования памяти

Поставить XMP или частоту 3200 - все тайминги на авто. Протестировать.

Maks_Gailish, Вы меня конечно простите но я вообще не нашел в биосе все эти параметры. Или я реально туплю! Просто биосы разный и написано может по-другому.

Я на 3200 ужался по таймингам насколько только возможно. Но задержку все равно уложил в 60 только впритык. CL ниже 15 не идет.

SunRise777 ,

Так - должно работать.
VTT у тебя на скриншоте HWInfo это ошибка программы или МП, это твой VCCSA на самом деле.
VCCIN_AUX я бы приподнял немного, до 1,82 В для стабилизации.
1,36-1,37В по VDRAM (VDD) должно хватать.
tFAW может быть и больше чем tRRDS*4, тем самым ты немного разгрузишь КП.
tREFI можно и не менять, если проходит тесты норм после изменения всех остальных таймингов.
А вообще мы уже по кругу ходим, ты почему-то не реализуешь, то что тебе советуют...

Neibot , по моему ты уже выжал максимум от H610. На нем всегда будет выше задержка, чем на более старших чипсетах.
Не вижу VDD...
Но тайминги я бы все же чуть подправил. И тестировать надо не только в TM5.
tRRDS=tRRDL - плохая идея, но если проходит OCCT СPU+RAM - можно и оставить равными.

А чего еще на нем делать. Только и остается душить тайминги на досуге )
Память эта у меня так то оттестирована давно уже в таком виде (еще на прошлом 12400), везде где можно (включая OCCT СPU+RAM).
Просто результат закинул уж коли тут обсуждают конкретно 3200 и задержки.


КП по идее в проце, от матери при прочих равных зависит разве что RTL, не? Тут 65 она выставляет ровно и стабильно.
Ты выкладывал свой i7-14700kf, там 58 при 4000 CL17.
Мои 60 на 3200 CL15 - ну врядли дело в чипсете. Кроме ограничения 3200


Стоковый 1.2, там есть на скрине.


Ваши диалоги по tRAS с anta777 выше видел, попробовал 37 тоже - в принципе латенси становится чуть выше, но меньше разброс от прохода к проходу.
По tWRRD_dg - там вообще говоря мать изначально в безопасном режиме ставит 23, и этим таймингом сам выставляется (у меня в авто стоит) tWTR_S.
Работает стабильно на 20/0, есть какие-то подводные, из-за которых стоит перелезть на 24/4?
Чипы если что - самсунг d-die, скорее всего изначально серверные, перепаянные китайцами и проданные задешево (за тот ценник я вообще не в обиде ) под видом новых.

У меня есть еще такие же плашки на бидаях. В отличие от первых - эти односторонние. Но при этом двухранговые, с чипами 2-в-1.
Первый раз такое на десктопе вижу, но как есть. Если тайфун не врет конечно.

Работают на ровно тех же самых всех таймингах, на такой же мамке и частоте.
Но вот tWRRD_dg 20 не берут ) Минимум 21.

Ну и да, поскольку это бидай (хоть и особенный) - дает выставить трфс поменьше, 400.
Но взамен - работает исключительно на CR2, даже на своих стоковых XMP-таймингах, с остальными в авто.
Какого-то выигрыша по задержкам/псп итого не дает.
15-15-15 стартует, но стабильность там надо искать за пределами 1.4в, на повседнев такое себе..

Дело не в том что я не реализую то что вы мне советуете, а в том что много параметров (даже по вольтажу) которые вы рекомендуете изменить я их тупо не нахожу в биосе. Или они как-то совсем по другому называются именно в моём биосе.
Я даже вот этот параметр найти у себя не могу.

Нет.
1. На бюджетных МП, количество слоев PCB - редко бывает выше 4. И твоя МП - не исключение. Это плохо влияет на стабильность по памяти.
2. На бюджетных МП, гораздо хуже оптимизированы дорожки ЦП-ОЗУ (трассировка), что напрямую влияет на общую задержку ЦП-ОЗУ, из-за влияния паразитной емкости. И твоя МП - не исключение.
3. Схема питания бюджетных МП - не больше 8 фаз (на твоей 6+1+1). Питание идет и на тот самый КП в т.ч. И чем больше фаз - тем точнее подается напряжение, и тем меньше ЭМ помех, и тем лучше для PHY-интерфейса и SA в целом, качество питания которого влияет на RTL в т.ч.

VDDQ TX (оно же IVR Transmitter VDDQ, оно же VccDDQ, оно же CPU VDDQ, питает интерфейс IO для КП) это ни разу не VDD (VDRAM). Само напряжение физически формируется из VccIN_AUX в ЦП и подается через FIVR [в данном случае он же IVR (Integrated Voltage Regulator)]. VDDQ отвечает за целостность сигнала, который ЦП посылает в сторону ОЗУ. Потому что со стороны модулей памяти еще есть просто VDDQ (без TX). Невозможность на H610 поднять эти напряжения - никак не влияет на стабильность при 3200 МГц, но влияет на Latency в худшую сторону. Потому что по JEDEC на 3200 совсем другие тайминги (не как у тебя). Ну и VDDQ TX соответственно, заблокировано на уровне 1,2 В и рассчитано на расслабленный JEDEC. Далее КП будет компенсировать ЭМ наводки по шинам DQ и CA, путем добавления дополнительной задержки (при тренировке памяти), раз тайминги у нас ужаты, а VDDQ TX осталось на уровне JEDEC. Иными словами, у тебя будут красивые циферки в виде tCL = 14...15, а в реальности это не совсем так. И все из-за бюджетной МП на H610.

В целом, tWTR_S и должен выставляться по tWRRD_dg. Но алгоритм работает не на всех МП одинаково. У меня, если я ставлю верный (подходящий с т.з. биос) tWTR_S, то tWRRD_dg будет ставиться автоматически по нему. Если я ставлю tWTR_S, который не соответствует физическим возможностям подсистемы памяти, то tWTR_S будет рассчитан по tWRRD_dg. Если у тебя не так - сочувствую -)
Теоретически минимально: tWRRD_SG = tCWL+6+tWTR_L; tWRRD_DG = tCWL+6+tWTR_S; но у тебя эти формулы могут и не работать, из-за того самого "не соответствия".
У тебя получается tWTR_S=tWRRD_dg(20) - tCWL(14) - 6 = 0. А такого быть не может ну никак. Это означает что тайминг "схлопнулся", и КП все равно будет ставить значение не 20 и не 0. У КП есть 3 пути "неповиновения": 1) Hard Fail (Цикличный ребут); 2) Safe Fallback (Скрытое завышение, возможно твой случай); 3) Auto-Correction (Что у тебя и происходит, и ты видишь красивые циферки но высокую Latency);
Значение, которые записаны в блок регистров КП [базовый адрес MCHBAR (Memory Controller Hub Base Address Register) + смещение регистра; и откуда читает их ATC] до передачи управления загрузчику ОС - могут и не примениться, потому что есть механизмы коррекции (та самая тренировка памяти). Реальные тайминги - это те, которые применяются в планировщике КП (через механизм Memory-Mapped I/O, он же MMIO). Так вот с помощью MMIO, КП "сдвигает" задержки (если конечно он сможет это сделать на своем уровне) и перезаписывает в свои регистры уже реальные значения. Но есть нюанс... у КП есть механизмы динамической коррекции (прямо во время работы)... Так что реальное tWTRS у тебя явно не 0. А ATC явно глючит из-за чего-то. Советую перепроверить тайминги и в другом ПО (в HWInfo есть тоже).

Есть. Эти подводные камни спрятаны в механизмах динамической коррекции некоторых таймингов, планировщиком КП. И появлением дополнительных задержек, что неминуемо отражается на общей Latency.

Как я уже говорил ранее, уставка tRAS и реальное tRAS - разные вещи. Динамическая корректировка таймингов (не путать с Real timing уставкой в биосе), в принципе - тратит ресурсы внутренней логики КП (перестроение расписания планировщика). От этого может падать производительность подсистемы памяти. Ничего не бывает даром и бесследно. Но лишние такты нам тоже не нужны. Поскольку тест AIDA64 - короткий по времени, протестировать изменения производительности у таких таймингов как tRAS и tRFC - нормально не получится. А третичные тайминги - это вообще тайминги внутренней логики DRAM (tWTR_S к ним и относится), тут вообще больше про стабильность, а не про производительность на коротких дистанциях. Но третички - почва для отсутствия "палок в колесах" при разгоне.
Давай попробуем твою память в y-cruncher VT3 протестировать? Тут будут два варианта: либо ошибка, либо КП справляется (и только потому, что частота памяти низкая для 14gen), но вносит доп. задержки.

Ну а что мешает пройтись по каждому и найти инфу (способов - море). Учись добывать инфо и сам...
Я же вроде половину настроек нашел в твоем биос и выделил их, недавно...

Всё гораздо проще и прозаичнее - "Кто хочет, ищет возможность, кто не хочет - причину."

Вот так уже красивее ) Если не лень будет - поставь 3200 15-17-17, чисто глянуть влияние мамки и доп настроек на задержку.


Не, это всё понятно, не спорю.
Я прост думал что где-то что-то пропустил, если помимо качества текстолита/питальника - еще и чипсет может как-то влиять напрямую, кроме как на доступность настроек
Так то маманя ничем не отличается от аналогичных 8-фазовых на b-чипсетах .. кроме собсно чипсета (и ценника в далеком 2022, когда оно покупалось под 12400).


Давай попробуем.

Из изменений - я тут вспомнил что плашки вообще говоря держат tRP 15, и поставил для разнообразия. Заодно выясним, как оно влияет.
Ну и почитав тему до февраля - выкрутил еще трефи в небеса, если падать не будет - пусть так останется.

К сути - прогон на изначальном tRAS = 34 и tWRRD_dg/tWTR_S = 20/0:

Выставляем tRAS = 37 + tWRRD_dg/tWTR_S = 24/4:

Вроде стало пошустрее и меньше разброса. Но что из этого повлияло больше? Если tWTR_S выставить ну пусть не в ноль, но в 1 например:

Стало еще быстрее. А если все же вернуть ноль (в hwInfo отображается кста как просто пустое поле):

То стало еще быстрее )

Добавлено спустя 5 минут 27 секунд:
Далее контрольные прогоны.

Возвращаем tRAS 34 обратно, как рекомендует шапка темы - просаживаемся:



Откатываем на tRAS 37, ставим tRP 17 как было изначально - просаживаемся:



Откатываем на tRP 15, и прогоняем еще разок - тоже просаживаемся, но меньше всего:



Оставлю так наверно.
Bigsun напомни пжл принцип по которому ты этот tRAS 37 рассчитал?

Это будет некорректное сравнение, у меня чипы DRAM другие. Вот если мои чипы протестировать на H610 - да, будет понятно влияние МП (и то, разные бренды дадут некоторый разброс). А со своими - ты как сравнишь? Я такие тайминги не могу поставить, на DJR тайминги tRCD tRP - дубовые. А вот вторичные и третичные - наоборот, получше будут.

Похвально, что стремишься разобраться -)
Ты считал по эмпирической формуле tRAS (от ACT до PRE) = tRCD (от ACT до READ) + tRTP (от READ до PRE) + 12 = 17 + 5 + 12 = 34;
В данном случае, я просто добавил tAL к твоему 34. Но получилось по расчетной минималке -)
При операции чтения минимальный tRAS ≥ tRCD + tRTP + tAL (additive latency, но это КП решает какой она будет, может быть и 0 в некоторых сценариях) = 17 + 5 + 4 = 26; Это самый оптимистичный сценарий для чтения. Который не применяется всегда. Если tRAS слишком мал, контроллер может начать вставлять пустые циклы ожидания (Wait States), чтобы дождаться физической готовности ячеек. Ну, либо поползут ошибки -)
При операции записи [наихудший сценарий + когда КП не использует chopped burst (BC4)] минимальный tRAS ≥ tRCDWR (от ACT до WRITE) + tCWL (от WRITE до факт. передачи данных) + BL/2 (длительность передачи пакета данных) + tWR (от завершения передачи данных до PRE) = 15 + 14 + 4 (иногда 2 при BC) + 10 = 41..43; tRCD ≥ tRCDRW ≥ tCL. tRCDWR (он же tRCDW) часто может быть ниже tRCD на 2-4 такта [благодаря ChargeCache и NUAT (Non‑Uniform Access Timing)] - механизмам, которые обеспечивают низкую задержку при частичном восстановлении ячеек и при доступе к достаточно заряженным ячейкам DRAM (недавно заряженных, к которым доступ быстрее).

Поэтому, минимальный tRAS при записи = (17-4=13) + 14 + 2 + 10 = 39, а учитывая, что на твоих чипах tRCD при tRP = 15 тоже вполне может быть 15 (на 3200 МГц), то самый минимальный tRAS= (15-4=11) + 14 + 2 + 10 = 37. Это самый оптимистичный сценарий при операции записи, с учетом оптимизаций.

Цель tRAS - дать время на выполнение операций чтения/записи, пока строка не закроется. При tRAS происходит частичное восстановление заряда, достаточное для корректного чтения или записи в открытой строке, а при tRFC - полное восстановление заряда для всего банка (даже если строки не открывались, чтобы предотвратить потерю данных из-за утечки). В этом разница.
КП, как правило, не может изменить первичные тайминги (но для tRAS может добавить Wait States). А вот что касается остальных - слегка подкорректировать (но не все тайминги, опять-таки) - может. Плюс как работают его оптимизации - нам не видно, но можно что-то протестировать.
Ошибка по tRAS может и не проявиться сразу: например, при сценариях с низкой нагрузкой, где оптимизации КП работают "в полную силу".

Нюансы про "предохранители".
1) tRTP.
Если КП использует политику "закрывать как можно быстрее" (эффективна для случайных доступов), то он ориентируется на tRAS для принятия решения о закрытии строки. В этом случае строка закроется, если прошло время tRAS, независимо от значения tRTP.
Если КП использует адаптивную политику (когда КП переключается между стратегиями в зависимости от нагрузки, паттерна доступа, истории попаданий страниц и других факторов), то tRTP может (а не обязан) повлиять на закрытие строки (в общем случае, tRTP влияет только на переход от чтения к закрытию, но не на общую длительность активности строки).
Единственный случай, когда tRTP будет "предохранителем" - это если после операции чтения сразу требуется закрыть строку, а время с момента чтения до команды PRECHARGE меньше tRTP. Тогда КП будет вынужден ждать истечения tRTP, прежде чем закрыть строку командой PRECHARGE.
2) tWR контролирует временной зазор между завершением записи и закрытием строки (командой PRE), но не влияет на само значение tRAS. Поэтому, tWR тоже не может быть "предохранителем" [только команда PRE (PRECHARGE) может закрыть строку, tWR строку не закрывает (но сообщает что "можно закрыть")].
Даже при использовании команд с автоматической предварительной зарядкой [RDA (Read with Auto-Precharge) и WRA (Write with Auto-Precharge)], длительность процесса восстановления заряда все равно ограничена tRAS.
Так что нет там никаких "предохранителей". Просто КП может "спасти", но его возможности не безграничны. Тайминги строки не закрывают. Закрывают команды, а их формирует КП.

Пусть будет ИМХО -)
А tWTR_S = 0 не бывает, никак и никогда. У тебя баг какой-то с доступом в регистры. Думаю, 2 может поехать вполне. tWTRL может поехать 4-5 при этом. Но следует помнить, что КП на это может отреагировать по-своему. А может и будет все ОК.
tRCD - меньше не едет? Хотя бы на -1.

Оптимальный tRAS равен минимальному tRC-tRP при политике закрытых страниц.
На интеле (исключение некоторые платы гигабайт) нельзя отдельно выставить tRC, поэтому оптимальный
tRAS=X*CCDS, где X от 1 до 16, так как на DDR4 у нас 16 банков.
Если контроллер вернется в нашу открытую строку после чтения нескольких банков, то , оставив ее открытой, мы можем выиграть.
Но у контроллера есть еще 15 банков и смысла держать открытой нашу строку нет, лучше ее закрыть максимально быстро, так как не исключено вообще обращение к другой строке в нашем банке, а не к открытой.
tRAS для записи не существует, он у нас для чтения.

Короче, я за минимальный tRAS.

Нелегко расставаться с догмами?
Команда ACT подается до того, как КП решит, будет он читать (READ) или записывать (WRITE). Поэтому, тайминг tRAS является единым (универсальным) параметром для любого цикла активации строки, независимо от того, следует ли за ней операция чтения (Read) или записи (Write).
Т.е. время удержания строки открытой (tRAS) накладывается на сам факт активации строки, а не на тип последующей операции.

JESD79-4B.pdf, стр. 97 файла, 4.23 Precharge Command. Явно сказано:
Команда PRECHARGE (предзаряд) используется для деактивации открытой строки в конкретном банке или во всех банках сразу. Исключением является параллельный авто-предзаряд (concurrent auto precharge), при котором допускаются команды READ или WRITE к другому банку. Если при подаче команды Read или Write сигнал на линии A10 имеет высокий уровень, задействуется функция авто-предзаряда (Auto-Precharge). "The precharge operation engaged by the Auto precharge command will not begin until the last data of the burst write sequence is properly stored in the memory array." "Операция предварительной зарядки, активируемая командой автоматической предварительной зарядки, не начнется до тех пор, пока
последние данные последовательности пакетной записи правильно не сохранятся в массиве памяти." [А10 - физическая адресная линия; A10 = Low (0): Обычная команда READ или WRITE; A10 = High (1): Команда READ или WRITE с авто-предзарядом (Auto-Precharge)]
JESD79-4B.pdf, стр. 136 файла, "The write recovery time (tWR) is referenced from the first rising clock edge after the last write data shown at T13. tWR specifies the last burst write cycle until the precharge command can be issued to the same bank."Время восстановления записи (tWR) отсчитывается от первого нарастающего фронта тактовой частоты после последних данных записи, отображаемых в T13. tWR определяет последний цикл пакетной записи, до тех пор пока команда предварительной зарядки может быть выдана в тот же банк."
"Once a bank has been precharged, it is in the idle state and must be activated prior to any READ or WRITE commands being issued to that bank." "После предзаряда банк переходит в состояние ожидания (idle) и требует новой активации перед подачей команд READ или WRITE."
Матрица ячеек физически одна и та же для чтения и записи, и время, необходимое для удержания строки открытой (чтобы заряд в конденсаторах стабилизировался через Sense Amplifiers), одинаково действует на обе операции.

Параметр tRAS в JEDEC - это минимальный порог. При записи, КП заставит держать строку открытой дольше, чем требует минимальный tRAS. И "эффективный" tRC (время между активациями одного банка) в операциях записи будет больше, чем в операциях чтения [tRCэфф. = tRAS (запись) + tRP вместо tRC = tRAS + tRP]. Опять-таки потому, что tRC - минимальное (а не реальное) время. tRC (Row Cycle Time) в DDR4 - минимальное время от активации строки до следующей активации строки или ее автоматического обновления (ACTIVE to ACTIVE/Refresh Command Period) для одного и того же банка (от активации до предварительной зарядки и обратно к активации или авто-рефреш). tRP - время предварительной зарядки строки перед активацией следующей строки, в том же банке.

Потому что есть разница между спецификацией (теоретическим минимальным пределом) и реальным поведением контроллера (эффективным циклом). Если КП использует Auto-Precharge (а точнее WRITE с Auto-Precharge).
Auto-Precharge - "стратегическое" решение планировщика КП (руководствуясь политикой управления страницами, состоянием очереди запросов, типом нагрузки, конфликтами банков и т.д.). Например, при случайном доступе, КП использует Auto-Precharge очень часто, поскольку вероятность того, что следующий запрос попадет в ту же строку, крайне низка. Невозможно закрыть строку, если идет запись.

При Read: tRAS нужен, чтобы вернуть "старое" на место. потому что операция чтения - деструктивная (разрушает заряд) для ячеек.
При Write: tRAS (точнее, время до предзаряда) нужен, чтобы успеть впихнуть новые данные и дать заряду стабилизироваться.
Процесс один и тот же: конденсаторы должны успеть зарядиться до того, как закроется строка [закроются транзисторы доступа строки (Wordline)].

tRAS, что мы устанавливаем в биосе, это tRAS для чтения, а не для чтения и записи, так как для записи ограничивающим фактором выступает tWR , а точнее tWRPRE.
Никакого tRAS на запись нет.
Ты хоть почитай стандарты по джедек, очень удивишься, ведь tRAS=32 ns.

Хотя я очень сомневаюсь, что ты сможешь верно подсчитать tRAS на запись по стандарту.

Доказать можешь? Подтвердить свои слова? Не своим не всегда верным мнением, а ссылкой на конкретику? Я нигде не нашел в стандарте, что tRAS - только для чтения. Я думаю, это твое мнение, не более того. При WRA (WRITE с Auto-Precharge), tRAS будет больше минимального.
Речь идет о минимальном tRAS. В стандарте нет разделения на "tRAS для чтения" и "tRAS для записи". Это единый временной барьер для состояния банка.
Тайминг в биос - это не всегда то, что будет реально применяться. tRAS = 32 ns - стандартное значение, а не реально применяемое (эффективное). По JEDEC, много чего является завышенным (с умыслом конечно).
С т.з. таймингов в биос, настройка tRAS универсальна. Где доказательство того, что биос будет работать именно так, как ты говоришь? А уж КП так тем более.

Ну ты же смог, смог и я (формула выше). tWRPRE (Write to Precharge) - суммарный интервал от команды WRITE до команды PRE, т.е. tCWL + BL/2 + tWR (именно то, что у меня и написано). tWRPRE = tWR + tCWL + 4 - оно же и есть.

Еще раз, сколько tRAS в нс на запись по джедек?
И сколько равен tRAS в нс по джедек?
Ты не видишь очевидного и споришь, не о чем с тобой говорить.

По JEDEC, много чего является завышенным. Это не аксиома. При 3200 МГц у ТС tRAS = 34 и все ОК. Даже при моем 37, получается 23,1 нс. И где твои 32 нс?

Ну так ты ничем конкретным не обосновал, так почему бы не спорить? или низззяя?

Ты так ничего не понял.
Это же ты продолжаешь писать простыни и выдирать текст из контекста.
Кто процитировал на полстраницы стандарт?
Поэтому и продолжай по стандарту.
Или ты на него смотришь только тогда, когда тебе это выгодно?
Чему равен tRAS на запись по джедек.
И чему равен tRAS в джедек?
Где я пишу про завышение или занижение.
Дай мне просто два числа - и то, и то по джедек.
Потом их сравни и подумай.

Про работу биоса.
Процессору нужно прочесть или записать какие-то данные по какому-то адресу.
Первым делом после преобразования адреса в банки и строки КП смотрит активирована ли нужная строка.
Тут возможны 3 варианта.
Строка активна.
Строка неактивна.
Активна другая строка в этом банке.

Тогда перед командой чтения срабатывают задержки.
1. tCL
2. tRCD+tCL
3. tRP+tRCD+tCL

Перед командой записи срабатывают те же задержки, только иногда в биосе есть tRCDWR на запись.

После чтения/записи КП нужно деактивировать строку.
Перед деактивацией строки после чтения КП проверяет прошло ли время tRAS , что задано в биосе от момента подачи команды ACT (на активацию строки).
И КП проверяет прошло ли время tRTP от момента подачи последней команды на чтение в этой строке.
Если эти два условия выполнены, то строка деактивируется.

При записи КП проверяет прошло ли время tWRPRE от момента последней команды на запись, так как tRAS не является лимитирующем фактором.

Чтобы tRAS стал лимитирующим фактором его надо выставить больше, чем
tRCDWR+tCWL+BL/2(у нас 4)+tWR.

Только не надо экзамен на IQ проводить, мы тут не для этого. Что-то знаешь лучше - напиши, обоснуй. То что твое мнение не всегда верное, мы уже знаем.
У меня tRAS = 20,8 нс работает без ошибок на DDR4-5000 при таймингах 21-28-28-52. И где тут 32 нс? При tRFC = 720 (288 нс против прописанного в спецификации на мою память tRFCmin = 350 нс). Даже на 5000.

Третий раз спрашиваю - чему равен tRAS на запись в нс по стандарту джедек и чему равен tRAS в стандарте джедек?
Зачем мне твои тайминги?
Ответь про стандарт.

Мое мнение всегда имело основу.
И для амд ам4 tRAS оптимальный всегда равен tRC-tRP.
Выставить с запасом tRC и tRAS, а затем их снижать по 1 такту до минимума.
При минимально возможном tRC оптимальный tRAS всегда будет максимально возможным, то есть равным tRC-tRP.
Но моя методика неприменима для интела, так как интел не дает выставить и применить tRC.

Ты хочешь сказать, что tRAS (32 нс) формально всегда больше, чем цикл записи (даже с учетом задержек), и поэтому tRASmin является якобы ограничителем? Стандарты JEDEC писались с огромным запасом, для работы в серверных фермах. Твои 32 нс из JEDEC - это требование к стабильности для худших чипов в мире, а не физический закон.

Нет такого отдельного или я не нашел. КП сформирует итоговое tRASзапись, с учетом наших таймингов и многого чего еще.

32 нс. И?

tCL не основа для мнения о tRAS. Не будь таким самоуверенным. У тебя нет специального образования или глубокого опыта работы, в этой сфере. По твоим же сведениям