vorvort, что в биосе подрубил для включения PBO? Только XFR2 настройки и OC Mode с оффсетом на напруге цп? У меня не работает оффсет совсем. Руками я гоню куда лучше. Либо что-то делаю не так.
update: разобрался, причина не работающего оффсета была смешная - при выборе авторазгона, мать зачем-то выбирала разгон через p-state, не сразу допёр туда глянуть. Хотя я туда на новом биосе не лез вообще... Удивительно. p-state в авто и всё заработало через оффсет -0.1. Пока полёт нормальный. Руками, кажись, было лучше. В простое цп бустит до 4.3-4.325

Выбрал Core Voltage, затем Offset, выставил - 0.1 В. Система теперь меньше вольтаж на ядра подает при бусте.

Она-просто лишний "буфер", добавляющий задержку. Я думаю, что с ее разгоном задержку на ней мы меняем в пределах погрешности, так как её тайминги скорее всего считаются в секундах, а не тактах.
Иначе я не могу объяснить почему между 3000-3733 с одинаковыми таймингами прирост чисто для галочки, а стоит тайминги ужать, так сразу все летает.
В zen+ эту задержку чуть сократили.

Жаль, что на амд не раскрыта тема "третичных" таймингов до конца, чтобы все тайминги с суффиксами DD,Dr,SD,Sr,SG,DG..тогда бы можно было точно их зафиксировать и измерить

Не знаю даже, с чего все обзорщики начали обвинять шину в тормозах - проблема не в ней, а в том, что райзены - процессоры типа NUCA (non-uniform cache access) по аналогией с нумой. Все задержки появляются из-за того, что винда/линукс/полуось и т.п. постоянно перебрасывают потоки между ядрами, перебрасывая и их данные из L3. Если программа написана с учетом этой особенности райзена (два сегмента кэша), то проблем нет (редко кому нужен доступ к кэшу абсолютно всех ядер), а в играх с этим никто не заморачивается (а если заморачивается, то в 99% случаев получается 32 поточное жрущее чудо класса Monster Hunter:World, тратящее весомую часть ресурсов на синхронизацию бесполезных потоков, и в 1% случаев - движок дума)

Я бы так не сказал, по крайней мере по тестам в играх. У меня есть 4 планки SR, и с ними такой же фпс в бенчмарке, как и с двумя на одинаковой частоте и таймингах. Разница между ними в пользу четырех есть только тогда, когда первички выставлены руками, а вторички в авто. Но стоит ужать вторички у всех одинаково, разницы нет от слова вообще, по крайней мере у меня так. А вот увеличение частоты на двух планках сразу заметны по минимальному фпс. Так что 4 планки для игр явно не подходят, тоже по началу повелся на все эти утверждения.

Остановился на таком результате, больше ковырять банально лень/устал ) Тестмем (пресет куратора) несколько раз + после холодных пауз - без ошибок. В играх вылетов вроде как нет. Хороший результат на samsung oem? И скажите пожалуйста, почему у некоторых L3 параметр больше 400, это от памяти тоже зависет?

Снижение напряжения SoC и правда положительно сказалось. Изначально 3666 получил из пресета кулькулятора, а потом докрутил напряжения вверх и tfaw 18 что-ли. На памяти 1,47 В. Попробовал скинуть SoC до 1 В с 1,075 В и без проблем получилось повысить частоту на шаг из пресета 3600. Ну как без проблем, 30 минут TM5 без ошибок, а до этого единичные ошибки стабильно сыпались после десятой минуты. Линкс пока стабильно крутит уже 6 проход. Даже цифры немного подросли.

ivanvatnikov RTC можно?

Добавил.

Какие тайминги имеют самое большое влияние на фпс?

https://docs.google.com/spreadsheets/d/ ... sp=sharing

В таблице приведен средний фпс в тесте, для каждого случая (клетки с результатом) было проведено по 3 прогона и взято среднее арифметическое. Погрешность 1фпс.
Я думаю догадаются все, что каждый столбец это изменения относительно XMP профиля, жирным выделены тайминги которые были изменены. С первым изменением тайминга был отключен PDM (PowerDown mode) и он присутствовал до конца тестирования дабы исключить бутылочное горлышко (вдруг энергосбережение ограничит производительность).
Порядок для тестирования таймингов я выбирал сам , опираясь на знания и опыт.

Тайминги которые имеют косвенное положительное влияние на фпс:
1) tRC (насколько можно снизить я сейчас выясняю, скорее всего будет формула-постулат)
2) tWRWR SCL + tRDRD SCL , но как показали результаты, ниже 4 смысла крайне мало, ПСП с избытком
3) комплекс из tRRDS + tRRDL + tFAW имеют незначительное влияние на производительность
4) tRFC , ниже чем 260ns ( это 416 для 3200 ) лишено особого смысла
5) tRTP полезный тайминг для оптимизаций, ниже 8ки - лишено смысла
6) tRDWR tWRRD 7 3 или 8 3 , снижение ухудшает производительность

Тайминги которые имеют негативное влияние на фпс:
1) tWTRS 3 - падение фпс
2) tRRDL 4 - падение фпс
3) tWTRL ниже 10 лишено смысла как собственно и снижение tWR ниже 12
4) снижение tWRWRSD tWRWRDD tRDRDSD tRDRDSD - отсутствие влияния , но есть информация что занижение вызывает фризы

а что же tRAS ? я не увидел толк от снижения

P.s. Еще в планах аналогичный разбор полета на 3466
P.p.s. Любые идеи я охотно выслушаю, самые интересные будут разобраны на практике

от частоты проца,от кол-ва ядер


csodtsetup ckesetup addrcmasetup что означает 1/31?

1usmus
Вот бы на главную обзор с графиками вместо лайт-порно и "обзоров" экселя

tsaMolotoff
Это набросок , графики я планировал

Добавлено спустя 7 минут 13 секунд:
Remarc
Означает 1 выставлено , а 31 максимум . На некоторых платах 63 максимум

У меня тоже зеленые планки самсунга, сравни с моим результатом. На нем сижу уже 3 месяц) Проблем нет) Агеса старая 1.0.0.2

MarWood
tRTP 10 или 8 не берут?

1usmus
Я честно не пробовал. От этого сильно что то поменяется?

Судя по шапке, результаты плавают в пределах одного процента.

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


судя по профилю райзена у тебя нет...что ты тут забыл?

1usmus
RAS это тайминг отвечающий за минимальное время до ЗАКРЫТИЯ строки (максимальное REFi*9). Положительное влияние на производительность можно увидеть там где крайне плохо отрабатывает планировщики (вплоть до планировщика непосредственно кп). Например КП открывает строку - работает с данными, в планах пока ничего больше делать нет - закрывает, внезапно появляется задача с доступом опять в эту же строку и тут снижение RAS может сыграть положительную роль.

Стоит также учитывать, что RAS+RP идёт параллельно с таймингами RC, и RCD+CL. То есть КП посылает команду на закрытую ранее строку то одновременно и параллельно пойдут эти три группы таймингов. На доступ к уже открытым строкам он вообще никак не повлияет. Соответственно если у вас RAS+RP меньше RCD+CL(что-то мне подсказывает ещё сюда минимум надо накинуть такты непосредственно передачи данных). То варианта два, он либо ничего не делает, либо память не работает вообще. Недопустимый RAS на DDR4 достигнуть можно разве, что подняв сильно тайминги непосредственно доступа к памяти, да и то кп или мать может проигнорировать "глупые" значения, в основном упор идёт в физическую невозможность текущих чипов так быстро открывать и закрывать строки.
Короче этот тайминг непосредственно на задержку доступа к данным влияет косвенно и его влияние на производительность зависит как от остальных таймингов, так и от "оптимизации"(бесполезно искать его влияние когда всё идёт "по плану").
Увеличение RAS+RP также может позволить снизить RC если он сильно задран. Хотя это скорее следствие переразгона связки RAS+RP или слишком агрессивного RCD.
Также во время RFC у вас по факту идёт цикл RAS+RP (и RC естественно). Поэтому допускаю, что манипуляции с RAS+RP и RC теоретически могут повлиять на RFC. Например, имеем RFC=321, RAS=39, RP=15, RC=54. За время RFC у нас влезает 321/54 =5 целых циклов RC и RAS+RP и остаток 51 такт, во время этого остатка память по сути совсем ничего со строками не делает("остывает"). Пороговыми значениями RFC очевидно является количество целых тактов соответствующих таймингов, пауза "сверх" целых очевидно тоже оказывает влияние, но всё же думаю, что основным является именно количество целых циклов. Допускаю сценарий, что при разгоне может возникнуть ситуация где вы выставите RFC 216(54*4) и оно работать не будет, а RFC 215 внезапно заведётся 54*3+ 53 такта "остывания". Короче влияние здесь есть, но искать конкретную формулу мне кажется бесполезно, так как слишком индивидуально.

А ещё вероятно миф о том, что он значительно влияет на производительность пошёл от того что на многих интел связка RAS+RP=RC без возможности крутить RC. Соответственно чтобы снизить RC там по-умолчанию надо скручивать RAS+RP. А RC как известно влияет очень даже значительно.

coolio
понятное дело, идеально цифра в цифру не получится

Remarc
я ссылку на тест кинул в ветку озу, так что могут заходить в гости и обладатели интела

Добавлено спустя 9 минут 26 секунд:
Agiliter
я понял о чем ты говоришь, параллельность есть (предзарядка не дожидаясь начала закрытия строки)
у меня уже сил сегодня нет тестировать , я завтра проверю что происходит при trfc = 252 (42*6)
и что будет если tRAS 34 tRC 36 (проверял раньше , оно работало без нареканий но без цифр)

а по поводу простоя это под вопросом, tBL может быть и 4 и 2 , может КП и дробить данные, чтоб максимально загружать конвейер