halt

> Вся эта информация есть в статье, которую вы видели.

Ну вот и читайте сами эту статью. Я повторяю: вас уже неоднократно ловили на вранье (неумышленном, конечно - профессионализма не хватало). Самый дикий случай - это когда вы не смогли справиться с простым 7-битным алгоритмом деления на 10. После этого на веру никакие ваши утверждения подобного типа никогда приниматься не будут. Они априорно ошибочные (даже если некоторые из них на поверку окажутся правильными). Если хотите отчиститься от такой репутации, то приложите минимальные усилия. Ответьте на заданные вопросы или дайте точную ссылку. Я - человек добрый, войду в положение. И если какое-то из ваших утверждений окажется правильным (например, про те самые 3 процента), сразу же об этом доложу

> Разница между 22 и 21 - это дисбаланс между отдельными слайсами. Его можно посчитать в процентах: 22 / 21 = 1.05 (5%).

Вы можете изобрести сколько угодно дурацких "дисбалансов". Они никак не влияют на производительность, и никому до них нет никакого дела

mrzet

Дурак ты, братец. И психуешь потому, что дурак. Тебе лично эти графики никто не обещал. Ну а что я с ними сделал, когда нарисовал - это уже моё личное дело

bess_temporary
Самый дикий случай - это когда вы не смогли справиться с простым 7-битным алгоритмом деления на 10.

Деление на 2 выполняется элементарно. Например, другие процессоры со степенью двойки делают это, и не нужно дополнительно пояснять это.
Понимать нужно только действительно сложную операцию: деление на 5.
А деление на 5 там заменяется простым делением на 16 и умножением на 3.
3/16 = 3/4 / 4
для 10 слайсов: 3 / 4 / 4 / 2 = 3 / 32 = 0.09375
так один слайс получает 9.375% вместо среднего 10%.
Вот так это работает на простых понятиях с умножением на 3 и делением на 2 без вникания в двоичную логику.

halt

> А деление на 5 там заменяется простым делением на 16 и умножением на 3.

Там - это где ?

> для 10 слайсов: 3 / 4 / 4 / 2 = 3 / 32 = 0.09375
так один слайс получает 9.375% вместо среднего 10%.

Очередная выдуманная хрень ?

Всех приветствую! Подскажите, напряжение vr vout (vcore), в стресс-тестах держится на уровне 1.5v. В режиме простоя тоже может надолго подзадерживаться на 1.4+. Насколько это нормально? Процессор в стоке. DLVRIN стоит в авто (1.329V), по hwinfo ~ 1.35v. Проц ultra 5 245k, мать Gigabyte z890m aorus elite. БИОС крайний

это нормально, на выходе VR OUT должно быть напряжение с запасом, чтобы DLVR работал без провалов при скачках нагрузки.

Добавление от 25.03.2025 22:05:

---

обзор
Core Ultra 5 235 6P + 8E - 5,0 GHz 4,4 GHz 4 65 W 121 W 280 Euro
Core Ultra 5 225 6P + 4E - 4,9 GHz 4,4 GHz 4 65 W 121 W 270 Euro

https://www.hardwareluxx.de/index.php/artikel/hardwa…225f-im-test.html

caesar88

Всех приветствую! Подскажите, напряжение vr vout (vcore), в стресс-тестах держится на уровне 1.5v.

У SkatterBencher для 245K было около 1.3V:
https://skatterbencher.com/2025/01/15/skatterbencher…cked-to-5633-mhz/

Можно еще посмотреть напряжение и частоту каждого отдельного P-ядра, E-кластера и Ring под нагрузкой на все ядра. Наибольшее напряжение из всех работающих P-ядер должно влиять и на общее напряжение.

Завышенные напряжения должны приводить к повышенному расходу энергии в теории.
Например, если vrm vout = 1.5V, а p-ядра получают только 1.10V, тогда вся эта разница 0.4V уйдет в тепло, если я правильно понимаю. Это может быть существенная величина излишнего потребления под нагрузкой. Поэтому можно еще посмотреть потребление под нагрузкой, которое показывают на разных уровнях: на плате и в процессоре.

Если нагрузить одно ядро через CPU Affinity, тогда частота будет выше - 5.2 GHz. И тогда напряжение может быть выше, чем в случае нагрузки на все ядра для 5.0 GHz.


Если хотите проверить латентность памяти и латентность кэша L3, есть бенчмарк от сайта chipsandcheese.com, который скомпилировал mrzet:

Микроархитектура Lion Cove. Мобильные процессоры Intel Lunar Lake / десктопные LGA 1851 Arrow Lake , #3396

Этот тест лучше запускать с CPU Affinity на первое P-ядро (core 0).
Кэш L3 в 245K меньше кэша в 285K/265K, но поэтому кэш в 245K может быть немного лучше по характеристикам латентности. Хотя это зависит от того какие конкретно ядра и какие сегменты кэша они отключили в процессоре 245K. И пока было мало надежных результатов латентности памяти для Arrow Lake. Везде есть только тесты Aida. А Aida могла соврать.
В Arrow Lake много непонятных моментов с высокой латентностью памяти. И тесты латентности памяти с бенчмарком chipsandcheese на 245K помогут улучшить понимание насчет производительности Arrow Lake.

halt

> И тесты латентности памяти с бенчмарком chipsandcheese на 245K помогут улучшить понимание насчет производительности Arrow Lake.

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

Питер опубликовал патчи для шедулера, учитывающий качество кеша https://www.phoronix.com/news/Linux-Cache-Aware-Load-Balance

halt
Например, если vrm vout = 1.5V, а p-ядра получают только 1.10V, тогда вся эта разница 0.4V уйдет в тепло
Если снять лимиты, то так примерно и получается. Vout = 1.57, а на ядрах ~ 1.15-1.2v. В итоге потребление за 200w улетает. Пока ограничил вручную dlvr на 1.3v, для стока этого за глаза. Vout тоже в таком случае фиксируется на этом напряжении. На выходных доберусь до разгона. С биосом Гигабайта потихоньку разбираюсь. Есть конечно некоторые отличия от Асуса, который я видел у scatterbencher. Буду экспериментировать

китайцы распродают ненужные(никому) уже инженерники ES2 MTL-S 6+8 14C\14T, HT off, на которых шла отладка MB для ARL-S, на серийных MB\BIOS для ARL-S они конечно не работают...

https://videocardz.com/newz/unreleased-intel-core-ul…no-hyperthreading
https://www.ithome.com/0/840/178.htm

Добавление от 26.03.2025 20:41:

Александр Федотов

>опубликовал патчи для шедулера, учитывающий качество кеша

это скорее к AMD Epyc с несколько CCX\L3 смогут приспособить, чем для ARL, пока поддержки выбора best CPU для L2+L3 кластеров там нет. Но движение в сторону универсального cache-aware шедулера в кернеле Линуха это хорошо.

caesar88
Изначальный вопрос, что ваша плата по умолчанию выставила vrm vout на 0.2V больше, чем ASUS ROG Strix Z890-I у ScatterBencher. Хотя может быть это для большей надежности.
Ручная настройка большого числа параметров - это слишком сложно. И можно где-то очень легко ошибиться так, что случится сбой в случайный момент. Поэтому от установок по умолчанию хотелось бы сразу получать оптимальные параметры, если сам процессор не требует разгона. А 245K уже хорошо сбалансирован сам по себе по стоковым частотам (p: 5.0 / e: 4.6). И поэтому дополнительный разгон ядер большую прибавку уже не даст.
Разгон для памяти легче и потенциально даст больше. Хотя там тоже много параметров. Но есть самый простой - это проверить, что режим Gear 2, а не Gear 4. Gear 2 лучше для получения низкой латентности памяти.

По потреблению и по напряжению ядер там могут быть еще важны какие конкретно значения напряжения прописаны для каждого ядра для точек 5.0 GHz и 5.2 GHz. Косвенно можно посмотреть эти напряжения под нагрузкой на одно ядро и на все ядра.
Если есть хотя бы одно ядро с высоким напряжением, то по цепочке придется завышать напряжение dlvr и vrm vout для всех ядер в нагрузке на все ядра.
Например, вот на гистограмме одно ядро немного хуже других:
5.0 GHz - 1.126 V
5.2 GHz - 1.203 V

Исправлено: halt, 26.03.2025 21:50

утечки-слухи по ARL-Refreshвыйдут только K\KF SKU, для нынешнего ARL и рефреша в BIOS появятся покрываемые гарантией Intel новые пресеты с повышением частот\вольтажа. https://www.youtube.com/watch?v=vXrt9eDwLYg
https://www.bilibili.com/video/BV15fXyYdEPJ/

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

Omega
это скорее к AMD Epyc с несколько CCX\L3 смогут приспособить, чем для ARL, пока поддержки выбора best CPU для L2+L3 кластеров там нет. Но движение в сторону универсального cache-aware шедулера в кернеле Линуха это хорошо.
Это патч для Intel процессоров. Причём тут amd вообще... там же написано may apply for amd...

Исправлено: Александр Федотов, 27.03.2025 01:24

Александр Федотов

там патч пока только ограничивает\запрещает миграцию активного треда между несколькими L3\LLC кэшами, для Intel это сокетные NUMA и subNUMA на др. die. Да, предложенные правила можно применять и для ограничения миграций между L2 в ADL\RPL\ARL, если кто-то его доведет до ума в плане выявления активности таких тередов, учета нагрузки на L2 кэши E-ядер. Насколько я помню, такое уже было в Линухе, был патч шедулера для Intel all-Atom процов, но он особой популярности не имел, ибо проигрывал простой привязке, и его тоже пробовали приспособить для Epyc Zen1\2 c четырьмя ядрами в ССX.

там, кстати, есть бенчмарки попыток его применить

https://lore.kernel.org/lkml/78508c06-e552-4022-8a4e…5c7a90@intel.com/

Исправлено: Omega, 27.03.2025 02:11