чета невеликая разница
слева трефи 65024 справа 262143

Выигрыш считай
tRFC/tREFI - это время обновления в процентах
Допустим tRFC=480
480/65024=0,74%
Стало
480/262143=0.18%

Выиграл 0,56%.

Здесь вопрос уже не в толковании документации, а в принципиальной возможности получить такую "раскладку" сопротивлений.
Если бы это был ноутбук с распаянными на плате чипами памяти, то разработчику ничего (кроме здравого смысла) не могло бы помешать подключить контакты ZQ чипов к шине питания не через стандартное сопротивление на 240 ом, а через какие-нибудь управляемые делители. И тогда, хитроумно управляя этими делителями при изменении настроек в биосе, можно было бы получить любую зависимость реального сопротивления RTT от значения в соответствующем MR. Или вообще зафиксировать это значение и управлять только делителями.
Но мы имеем дело со стандартными модулями DIMM в стандартных слотах. В этих слотах нет контактов, как-либо связанных с контактами ZQ чипов. Следовательно, изменить RZQ извне модуля невозможно. Поэтому, я с ходу вижу только вот эти три варианта объяснения "парадокса Gigabyte":

1. Чипы памяти имеют какой-то волшебный, недокументированный регистр, изменением значения в котором можно изменить формулу соответствия значений сопротивлений числам в соответствующих MR - с гиперболической RZQ/n на линейную RZQ*(8-n)/12 .

2. Все присутствующие на рынке модули DDR5 имеют недокументированные цепи, включенные параллельно штатным сопротивлениями на 240 ом на линиях ZQ. SPD-хаб, в свою очередь, имеет недокументированную же функциональность для управления суммарными сопротивлениями на этих линиях. Ну а биос Gigabyte, используя все эти замечательные возможности, реализует необходимую "раскладку" сопротивлений.

3. Авторы биоса Gigabyte ошиблись, и написали некорректные числа в этом списке. Возможно, изначально скопировали этот список из какого-то другого раздела, а потом забыли исправить строки. То есть на самом деле 160,140,120,100,80,60,40,20 в списке - это обычные ∞,240,120,80,60,48,40,34.

Мне представляется наиболее вероятным последний вариант.

Это так только для показанной на картинке установки, для RttWr? Или для всех остальных сопротивлений там такая же "раскладка"?

нее...на вольтаж попал...эт не профит....итак 1.485v

да, для всех ток наоборот(cмотря как воспринять конечно ): (незапускающиеся)160,140,120,100,80,60,40,20<=>∞,34,40,48,60,80,120,240(незапускающиеся)Z690 AORUS TACHYON c биосом от Z790 AORUS TACHYON X
но, там вроде у всех гиг так.

Не наоборот, но со сдвигом по отношению к тому, что я раньше предположил.

То есть, слева здесь получается 240*(9-n)/12, справа - 240/n, где n=8...1.
Но n=8 (RZQ/8=30) - это неподдерживаемое в рамках известной архитектуры DDR5 значение. Там 3 бита для него зарезервировано, и из 8 получается 0. То есть, если туда при выборе значения 20 действительно записывается 0, то получается RZQ/0 = ∞.

А какая у Вас модель платы?

Вот так получается все в авто.

SH@RK
Для получения правильных значений AC/DC LL (в миллиомах) нужно те числа, которые сейчас показываются в pyhwinfo, умножить на 10^5=100000 и разделить на 2^20=1048576.
Или, другими словами, в коде _read_vr_info (файл msrbox.py) вместо divisor = 100.0 должно быть divisor = 1048.576 .

На моём asrock именно 100 должно быть.
Да и на asus z790 hero тоже 100.
А вот на arrow lake уже 2^10.

Тут видимо может зависить от микрокода биос. Вы бы написали на какой плате и на каком биосе у вас возникла эта трабла.
Хотя, наверняка, модель проца тоже важна.

То есть, у Вас в pyhwinfo получаются те же самые значения, что Вы задаёте в биосе и которые потом отображаются, например, в HWiNFO?

Вряд ли зависит. У меня из подходящих платформ сейчас только 14700K на Asrock Z790i Lightning WiFi. Но хорошо помню, что в начале года читал эти значения на 12700K/MSI Z790i Edge WiFi, и формат данных там был точно такой же.
Опять же, в комментариях к коду Вашего любимого ICE_TEA_BIOS (см. функцию InitCpuVrConfig() в Intel/AlderLake/AlderLakePlatSamplePkg/Setup/CpuSetup.c) об этом деле пишут так:

Здесь индусы немного запутались. Само действие (умножить на 2^20, поделить на 10^5), относится к обратной операции - записи значения в регистр. A "to convert to Ohms" намекает на операцию преобразования числа после чтения из регистра.
Авторы, похоже, "не глядя" скопировали этот комментарий из кода функции с той самой обратной операцией - UpdateVrOverrides() из Intel/AlderLake/ClientOneSiliconPkg/IpBlock/VoltageRegulator/LibraryPrivate/PeiVrLib/PeiVrLib.c.

Помимо этого, сами они там, перед тем как поделить на 2^20, добавляют к прочитанному из регистра и умноженному на 100000 значению половину делителя, 2^19=524288. Якобы, для учёта ошибок округления при манипуляции числами с плавающей точкой в целочисленной арифметике:

Какая-то немного странная идея в данном контексте. Но лично я нигде больше не встречал её реализацию, кроме этого кода. То есть, современные биосы должны писать значения LL без этой, с позволения сказать, "коррекции".

В любом случае, учитывая используемый здесь двоичный формат (U-4.20), Ваш divisor никак не может быть точно равным степени 10. В расчётах обязательно должен присутствовать делитель 2^20 в том или ином виде.

Так и кто из двоих прав?

Оба варианта подозрительны

SH@RK в биос фиксированное напряжение, не знаю какому значению AC/DC_LL это соответствует. AC/DC_LL в авто.

Это не лучший выбор для проверки таких расчётов - минимально возможное значение LL, да ещё и степень 10.
Попробуйте, например, с 0,05 или 0,09 мОм.

Как в авто? А что же Вы тогда проверяете?
Задайте значения LL в биосе вручную (на платах MSI в биосе пишется число в единицах 1/100 миллиом, т.е. 0,05 мОм - это число 5; 0,1 мОм - число 10; 1,1 мОм - число 110 и т.д.), и смотрите, что показывают программы.

Вот я не зря сказал что подозрительные циферки.
В Auto режиме плата ну никак не выставит меньше 0,2 мОм.

Так проверьте сами на своём оборудовании. Меняйте в биосе вручную значения LL и смотрите показания pyhwinfo c divisor = 1000.0 и divisor = 1048.576. Какие показания будут ближе к заданным для некоторого набора тестовых значений (не равных степени 10), те и правильные.
divisor = 100 вообще не имеет смысла, т.к. величина получается в десятых долях миллиома - ни туда (сотые доли, как у Интела в регистрах и в некоторых биосах), ни сюда (реальные миллиомы).
Да, и если это число отображать всё-таки в реальных миллиомах, то его правильно будет округлить до двух знаков после запятой.

У меня 13700KF и 32гб DDR5 6000мгц Corsair Vengeance,включил XMP полет нормальный

Тут я оказался не прав. Меня немного заглючило


А вот тут вы правы!
Я уже исправил.
Спасибо!

даже если напряжение fixed?

Да, теперь всё правильно и красиво.

Ещё было бы неплохо поправить "средства запуска" приложения. Сейчас для запуска необходимо наличие в системе powershell. А это бывает не всегда - особенно, на live-сборках винды.