Ну вот, прошел нормативные 2 часа в Кранчере:

Теперь по идее подобрать первички с VDD/VDDQ под них и что-то такое "хоть какое" будет. Или отсутствие 3:2 UCLK:FCLK руинит?
Лезть сейчас в 7600 моральных сил нет, это начнется подбор вольтажей, перегревы, обдув городить, вторички-третички какие-то не поедут, в такое с хорошим настроением надо, а сейчас оно поганое.

X870E Taichi. Ну должна же она блин 6000 то брать? Хотя я уже ни в чем не уверен.

7600 в 1:2 все же нужно запустить, да и 8000 я бы попробовал на вашем месте с этими планками. Не важно что они не шли раньше выше 7600.. Тайминги на авто, напруги vsoc 1.15-1.2 vddp 1.05, vddio 1.25-1.3 vdd 1.45 vddq 1.40 и пробуем бут 8000. Nitro только в авто либо 2/3/1x8x8

Да на ней и 8200+ без особых проблем должны работать.

Когда работает вообще как попало все можно выставлять и оно в целом работает Задержка конечно хуже чем в синхроне, но у вас там на 9800x3d и так с ней непонятки, если по aide смотреть по крайней мере.

Спасибо большое за поддержку. Обязательно буду пробовать, но попозже.

Т.е. эти пресловутые 3:2 не нечто прям сильно важное? Просто я вообще первый раз на АМД за 30 лет сидения за компом, не говоря уже о Райзенах с их фабриками.

Да костыль это обыкновенный. КП нам достался еще со времен DDR4, т.к. нового у AMD не было, а новую платформу с DDR5 выпускать надо, поэтому пришлось адаптировать старый контроллер к DDR5. Так как частоты новой памяти он держать не мог, ему приделали дополнительный тактовый генератор UCLK через который частота режется до перевариваемых старым КП значений. Эдакий CUDIMM от Amd встроенный в процессор. Ну а по факту основным лимитирующим производительность является частота IF. Это очень поверхностное объяснение, но суть происходящего я думаю оно отражает, надеюсь знатоки не закидают помидорами

PDM для ускорения запуска пк и подбора напряжений еще с частоты 6400 остался включен) rfc изменю

Я могу ошибаться но при быстрой загрузке работает дефолтная тренировка, а не Nitro.(В зентайм при отключении Nitro все равно показывает что Nitro 1/2/0)

Это полагаю влияет только на показатель задержки? Буду отключать!

И на стабильность. Мое личное мнение: для начала нужно вырубать GDM, PDM, Restore Contex Memory(MRC) и включать Nitro в 1/2/0. Делитель КП 1:1 естественно. Таким образом мы по максимуму отключаем все "душилки-оптимизаторы" подсистемы памяти, и выходим на "чистую" производительность от конфигурации нашей памяти, т.е. имеем нормальную корреляцию конфиг-производительность. Далее в таком режиме ищем пределы возможностей нашей памяти и КПЦП, а попутно видим какую реальную максимальную производительность на нашей системе они выдают. Уже потом, отталкиваясь от этих результатов можно пытаться выжать дополнительную производительность с использованием "ухищрений" в виде Nitro в режимах "углубленной" тренировки и прочих перечисленных выше функций.


Заинтересовала меня эта тема, 2 последних дня погонял Аиду в режимах
tRAS=tRCD
tRAS=tRCD+tRTP
tRAS=tRCD+tRTP+8
tRAS=tRCD+tRTP+24
По задержкам, между первыми 3мя вариантами, в действительности разницы нет. А вот +24, показались чуть более тугими, хотя минимальная задержка как и везде ~58.6ns, но это не повторяющийся минимум, в отличии от других вариантов... Повышение tRC начинает давать о себе знать? Или все погрешность?
В каждом режиме делал по 25 проходов латенси+ 25фото, поочереди, и с одним проходом Julia каждые 10проходов фото+лат, затем перезагрузка, и повторение процедуры. В трее всегда только один Fan controll. БИОС из Аида "твиков" только Spread Spectrum off.
А вот где разница все же просматривается, это photoworxx:

tRAS=tRCD - 53841 max. lat 58.7ns повторяющийся минимум(58.6 абсолютный)
tRAS=tRCD+tRTP - 53756 max. lat 58.7ns повторяющийся минимум(58.7 абс.)
tRAS=tRCD+tRTP+8 - 53636 max. lat 58.7ns повторяющийся минимум(58.6 абс.)
tRAS=tRCD+tRTP+24 - 53512 max. lat 58.9ns повторяющийся минимум(58.7 абс.)

Поэтому, пробую совсем не стандартный вариант, зажимаю tRC при +24tRAC, а именно tRC=tRAS=tRCD+tRTP+24, и вижу говорящий о чем то результат 53775 max. lat 59.2ns повторяющийся минимум (58.9 абс.)

Хотел еще проверить "anta777-Я вообще встречал информацию, что tRC оптимально выставлять равным тому, что заложено в родном профиле памяти, так как реально он и используется." Но так как по всем текущим ощущениям tRC работает, я решил пойти в обратном направлении - зажать максимально tRC, с поджатым tRAS, тем более что имеется принципиальная возможность работы в tRC=tRAS, получил такие результаты(задержку больше не указываю, т.к. далее везде без изменений 58.7):
Все результаты с tRC<tRAS+tRCD воспринимать с двойным недоверием - полноценное тестирование на стабильность они не проходили!
tRC+18=tRAS=tRCD 53858 max
tRC=tRAS=tRCD 53883 max
Места для скриншотов в посте не осталось, поэтому выкладываю только последнюю конфигурацию

Не был до конца уверен что эти варианты заработают, но они работают и даже продолжают показывать похожее на прирост по фотоворксу. Тем не менее, осторожный вывод который мне позволили сделать эти наблюдения: Оптимальный вариант это общепринятые tRAS=tRCD+tRTP и tRC=tRAS+tRP. Но вариант tRAS=tRCD достоин дальнейшего изучения как потенциально чуть более быстрый, ввиду наиболее низкого tRC.

Можно пояснение для тех кто школу прогуливал? "Минимальный блок сейчас составляет 64 байта", имеется ввиду минимальный блок хранения информации в памяти, или минимально возможный размер блока для считывания? "может считываться как с одного банка, так и с разных." - Значит один блок может быть записан в разных банках? И допустим мы может считать один блок либо с одного банка порцией 64б, либо с нескольких, например с двух, но уже порциями 32б и это будет в два раза быстрее? Или все мимо?
Мне это интересно по той причине, что если применять стандартную количественную логику к написанному, то получается что оптимальным должен быть вариант tRAS=tRCD+tRTP+24(при считывании 64 байт с одного банка), так как минимальный размер считываемых блоков у нас 64б. Но на практике, он(субьективно) не оптимальный.
По этой логике зажатие ниже tRAS=tRCD+tRTP+8, должно либо вообще ничего не давать, либо ухудшать производительность. А в действительности есть рост... Возможно один лишь tRC влияет в даном случае, и им можно обьяснить рост по фотоворксу? Тогда есть смысл прогнать tRC=tRAS=tRCD+tRTP+24 что бы это проверить? Или так вообще не может работать?

upd Добавил недостающий скрин, и продолжение теста.

У DDR5 минимальный блок считывается не с одного банка.
64 байта - минимальный блок для считывания на сегодня для современных процессоров.

Если 64 байта считываются с 8-ми банков, то лучший вариант tRAS=tRCD+tRTP, так как тогда минимальный tRC.

Что то проясняется, а со скольки банков одновременно может считываться блок?

Спасибо, это более менее обьясняет все кроме того почему тогда фотоворкс фиксирует линейный рост при tRAS=tRCD. Тем более я так понимаю там все равно по факту остается +tRTP. Но рост есть точно. Я в конце специально еще раз перетестировал tRAS=tRCD и tRAS=tRCD+tRTP+8, и сколько я не гонял +8 - 53636 это рекорд. А при tRAS=tRCD 53700+ вообще стабильно повторяется, с рекордом 53841... Я понимаю что заложенные формулы не обманешь, но тогда получается tRC сам по себе может быть меньше tRAS+tRP и давать профит?

Зависит от настроек в биосе, хэша.
Умно , если сделали так, что с 8-ми банков считывается.
Просто фотовокс использует , видимо, другие банки (их же теперь 32), и не доходит до чтения с той же самой банки. Но тогда фотовокс вообще не должен зависеть от значений tRAS и tRCD.
Думаю, что тут просто проблемы биоса.
При tRAS=tRCD начинает реально использоваться минимально возможный tRAS.

Добавлено спустя 5 минут 42 секунды:
Я вообще встречал информацию, что tRC оптимально выставлять равным тому, что заложено в родном профиле памяти, так как реально он и используется.
Недаром tRC в родных профилях всегда стоит конский.

Еще момент, вдруг будет интересно. Когда я все это дело крутил я дошел до минимума tRAS=30 tRC=66(При tRCD=36), система работала, VT3 полтора часа удачно прошел без фоновой активности, но когда я в след. раз. после старта теста подключал на фон 4k видео(С Ютуба), на экране начинали мерцать черные кадры, сначала с частотой 1 раз в ~10сек и далее по нарастающей, пока экран не начинал уже ошутимо мерцать черным цветом с хаотичной частотой. TM5 ex3d при этом наконец выплюнул ошибку. Ни разу до, я подобного не наблюдал на этой сборке. Как только я выключал видео, мерцания прекращались, прямо во время тестов, и тест шел дальше. Когда останавливал тест так же все мерцания пропадали. Я на встройке сижу... И да в итоге tRAS=tRCD память осталась стабильной. Все тесты во всех порядках и с фоновой нагрузкой прошла без ошибок..

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

Это интересно, спасибо. Попробую прогнать и в таком режиме.

Какие тут чипы могут быть?

x014 это M-die

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

Все три.

Привет! Имеется система 7700x + Asrock B650 Pro RS (8 слоев). Стоит 32гб Kingbank 2x16 в режиме 6400 CL30 c ужатыми таймингами.
Понадобилось минимум 96 Гб. Вопрос - как лучше сделать: докупить 2х32 того же кингбанка - заработают ли вообще 4 планки в такой конфиге или это дохлый номер? Или все такие единственный нормальный вариант - продать этот комплект и взять 2х48?

Для 7700х(один чиплет) ограничение скорости находится в IF.
Для 2000 оно = 64 Гб/с, что полностью перекрывается памятью с частотой 4000.
Если IF=2200, то память нужна с частотой 4400.

это будет полнейшее безумие и ужасающе низкие частоты, если вообще запустится

В продолжении своего вопроса хотел бы поделиться успехами и задать вопрос дошел ли я до предела? Напряжение попробовал поднять до 1.48 (дальше стремно хоть и хинукс говорит о1.5)
При повышенном напряжении комп стартует но мем тест не проходит ни при cl28 ни при rcd36. Rfc так же ниже 580 не идет