vid usage что это

What is FB and VID usage in Asus GPU tweak

I’m currently ironing out the kinks on a new system build, and trying to work out the best settings for various games I run. I’m running an Asus GTX 660, and it comes with a piece of software called GPU Tweak, which amongst other things, gives me a live, view of GPU usage, and a reading on what was the highest value reached in a session.

What is VID usage and FB usage? The values don’t seem to go very high so, when would these be important?

2 Answers 2

In case anyone finds this again and is still wondering, FB usage is the frame buffer usage. Put simply, this is the percentage of the GPU memory which is being used. It’s not really anything to worry about unless you are running very close to 100%, at which point your GPU starts to have memory bottlenecks.

VID is essentially the voltage being supplied to the GPU, and is probably being shown as a percentage of the stock voltage (typically around 1.2V).

The other answer is incorrect regarding VID. VID has nothing to do with the voltage on the card.

VID usage is tied to the built-in hardware H.264 encoder found on GTX6xx and higher cards. (I am not sure if AMD cards have a hardware encoder on-die)

A way to show this is by setting the video format under «Video Capture» in Afterburner to NVENC (Nvidia cards) and then pressing the benchmark button under the «Encoder» drop down OR by video-capturing within a game.

This will show usage since NVENC directly uses the hardware encoder on-die.

Источник

Выделение памяти под встроенную видеокарту: как увеличить видеопамять у интегрированных IntelHD, Intel Iris Xe и AMD Ryzen Vega (UMA Frame Buffer Size)

Доброго времени!

В последнее время снискали большую популярность интегрированные (их еще называют встроенными ) видеокарты IntelHD, Intel Iris Xe, и AMD Ryzen Vega. Последних версий уже с лихвой хватает для многих не слишком требовательных игр (что, конечно, радует — т.к. получается хорошая такая экономия на покупке внешней видеокарты)!

Однако, есть один нюанс : видеопамять для этих карт выделяется из ОЗУ (RAM). По умолчанию эта операция «выделения» происходит автоматически (без вашего участия), что не во всех случаях оптимально (например, вы можете столкнуться с ошибками во время запуска игр. ).

Разумеется, было бы не плохо вручную отрегулировать выделение памяти под интегрированную карту (в большинстве случаев стоит вопрос ее увеличения ).

И так, перейдем ближе к теме.

Можно ли разогнать встроенные видеокарты Intel HD и AMD Radeon? За счет чего поднять их производительность

Как увеличить видеопамять: по шагам

ШАГ 1: зачем это нужно

Вообще, если у вас все корректно работает, нет притормаживаний, ничего не зависает и не вылетает с ошибками — то вам, скорее всего, это и не нужно.

Однако, есть ситуации, когда без этого никак:

3DMark Sky Driver (8GB Ram, dual) — производительность в зависимости от выделенной памяти для интегрированной видеокарты AMD Ryzen Vega 11 (Ryzen 5 2400G)

Примечание!

👉 Если у вас количество ОЗУ 8 ГБ (и более) — то большинство современных материнских плат по умолчанию устанавливают для встроенной видеокарты номинальные 1024 МБ (которых пока достаточно для норм. работы).

👉 Не могу не отметить, что если у вас на борту меньше 6 ГБ ОЗУ — то выставлять для интегрированной карты больше 1 ГБ памяти крайне не рекомендуется! Это отрицательно сказывается на общей производительности ПК/ноутбука.

ШАГ 2: как узнать текущий объем видеопамяти

👉 Вариант 1

Это универсальный вариант, работающий во всех популярных версиях Windows 7/8/10.

Сначала необходимо нажать сочетание кнопок Win+R — в окне «Выполнить» ввести команду dxdiag и кликнуть по OK.

Далее откроется средство диагностики DirectX — во вкладке «Экран» среди прочих характеристик устройства вы найдете размер видеопамяти (👇).

Видеопамять 1009 МБ

👉 Вариант 2

Доп. параметры дисплея

👉 Вариант 3

Этот вариант также актуален для ОС Windows 10.

ШАГ 3: как вручную установить размер выделения памяти под встроенную видеокарту

Через BIOS/UEFI

Только через настройки BIOS (в принципе) и можно изменить размер выделяемой памяти для интегрированной карты (в редких случаях можно попытаться «обмануть» игры через реестр).

И так, сначала необходимо 👉 войти в BIOS (ссылка на инструкцию в помощь).

Далее нужно перейти в раздел «Configuration» (в некоторых BIOS за это отвечает раздел «Advanced» ).

Затем нам нужно найти один из следующих параметров (прим.: в разных версиях BIOS он называется по-своему) :

На скриншоте ниже приведен параметр «iGPU Configuration» — необходимо отключить авто-режим!

Отключаем Auto режим

А после вручную задать параметр «UMA Frame Buffer Size» — это и есть размер выделяемой видеопамяти (в моем примере можно выбрать от 256 МБ до 2 ГБ 👇).

UMA Frame Buffer Size — ставим 2 GB

Advanced / настройки BIOS / American Megatrends

DVMT ставим на Maximum

Еще один пример для более старой версии American Megatrends см. ниже. 👇

Через настройки реестра (опционально для IntelHD)

Этот способ поможет только «перехитрить» некоторые игры, которые могут вылетать с ошибками после запуска (т.к. у вас якобы недостаточно видеопамяти). Т.е. игра будет «считать», что размер памяти видеокарты у вас больше, чем есть на самом деле.

Причем, хочу отметить, что срабатывает он не всегда (но всё же, вдруг. ).

И так, для начала нужно 👉 открыть редактор реестра — нажать Win+R, и использовать команду regedit.

regedit — открыть редактор реестра

Далее в редакторе нужно создать раздел «GMM» в нижеприведенной ветке:

Создать раздел GMM

После, в разделе «GMM» создать строковый параметр с именем «DedicatedSegmentSize» (без кавычек).

Создать строковый параметр

Далее открыть его и задать значение выделяемой памяти (судя по тестам, способ актуален и работает для значений от 0 до 512).

Источник

core vid что это

Название опции:

CPU VID

Описание:

Данная опция отображает или номинальное напряжение питания ядра процессора в вольтах, или числовой идентификатор этого напряжения (VID — Voltage IDentification).

Номинальное напряжение питания ядра процессора зависит от типа и модификации центрального процессора. Более того, даже два процессора одной модели, работающие на одной и той же частоте, могут иметь разные номинальные напряжения питания ядра. Штатное значение можно уточнить на упаковке процессора, его отображают многие информационные утилиты. Оно как раз и задается идентификатором VID.

К сожалению, однозначно сопоставить числовой идентификатор и напряжение питания ядра процессора не так просто: необходимо обратится к документации на данное семейство процессоров.

Опция CPU VID отображает информацию о текущем напряжении питания ядра процессора или идентификатор напряжения питания ядра процессора (а идентификатор напряжения питания ядра процессора в свою очередь содержит информацию о напряжении питания ядра ЦП).

Страница 11: 990FX: значения напряжений

Если вы будете разгонять процессор «Vishera», то в UEFI/BIOS получите набор разных параметров. Хотя по сравнению с платформой Intel их не так много. Ниже мы привели наиболее важные из них.

Напряжения «Vishera»

Напряжение процессорного ядра – отличается от одного CPU к другому в зависимости от VID/качества процессора. На это напряжение следует обращать внимание большинству оверклокеров.

Напряжение северного моста в CPU (не следует путать с напряжением чипсета); данная часть CPU работает в собственном домене частоты и напряжения. Частота CPU-NB определяет скорость работы контроллера памяти и кэша L3. Компонент CPU-NB довольно существенно влияет на общую производительность системы. На высоких частотах рекомендуется поднимать напряжение CPU-NB для повышения стабильности системы.

Большинство материнских плат позволяют задать напряжение смещения, позволяющее увеличить напряжение выше диапазона напряжений CPU V >

Напряжение чипсета. При разгоне через увеличение множителя повышать не требуется.

Если вы хотите разогнать процессор AMD ещё и через интерфейс HT, то может потребоваться увеличение данного напряжения.

Напряжение памяти. Зависит от используемых планок памяти.

LLC/Loadline Calibration:

Предотвращает эффект Vdroop (падение напряжения под нагрузкой). К сожалению, эта настройка встречается далеко не у каждой материнской платы AMD.

Источник

Анализ производительности ВМ в VMware vSphere. Часть 2: Memory

В этой статье поговорим про счетчики производительности оперативной памяти (RAM) в vSphere.
Вроде бы с памятью все более однозначно, чем с процессором: если на ВМ возникают проблемы с производительностью, их сложно не заметить. Зато если они появляются, справиться с ними гораздо сложнее. Но обо всем по порядку.

Немного теории

Оперативная память виртуальных машин берется из памяти сервера, на которых работают ВМ. Это вполне очевидно:). Если оперативной памяти сервера не хватает для всех желающих, ESXi начинает применять техники оптимизации потребления оперативной памяти (memory reclamation techniques). В противном случае операционные системы ВМ падали бы с ошибками доступа к ОЗУ.

Какие техники применять ESXi решает в зависимости от загруженности оперативной памяти:

minFree — это оперативная память, необходимая для работы гипервизора.

До ESXi 4.1 включительно minFree по умолчанию было фиксированным — 6% от объема оперативной памяти сервера (процент можно было поменять через опцию Mem.MinFreePct на ESXi). В более поздних версиях из-за роста объемов памяти на серверах minFree стало рассчитываться исходя из объема памяти хоста, а не как фиксированное процентное значение.

Значение minFree (по умолчанию) считается следующим образом:

Например, для сервера со 128 Гбайт RAM значение MinFree будет таким:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Мбайт = 1,88 Гбайт
Фактическое значение может отличаться на пару сотен МБайт, это зависит от сервера и оперативной памяти.

Обычно для продуктивных стендов нормальным можно считать только состояние High. Для стендов для тестирования и разработки приемлемыми могут быть состояния Clear/Soft. Если оперативной памяти на хосте осталось менее 64% MinFree, то у ВМ, работающих на нем, точно наблюдаются проблемы с производительностью.

В каждом состоянии применяются определенные memory reclamation techniques начиная с TPS, практически не влияющего на производительность ВМ, заканчивая Swapping’ом. Расскажу про них подробнее.

Transparent Page Sharing (TPS). TPS — это, грубо говоря, дедупликация страниц оперативной памяти виртуальных машин на сервере.

ESXi ищет одинаковые страницы оперативной памяти виртуальных машин, считая и сравнивая hash-сумму страниц, и удаляет дубликаты страниц, заменяя их ссылками на одну и ту же страницу в физической памяти сервера. В результате потребление физической памяти снижается и можно добиться некоторой переподписки по памяти практически без снижения производительности.

Источник

Данный механизм работает только для страниц памяти размером 4 Кбайт (small pages). Страницы размером 2 МБайт (large pages) гипервизор дедуплицировать даже не пытается: шанс найти одинаковые страницы такого размера не велик.

По умолчанию ESXi выделяет память большим страницам. Разбивание больших страниц на маленькие начинается при достижении порога состояния High и происходит принудительно, когда достигается состояние Clear (см. таблицу состояний гипервизора).

Если же вы хотите, чтобы TPS начинал работу, не дожидаясь заполнения оперативной памяти хоста, в Advanced Options ESXi нужно установить значение “Mem.AllocGuestLargePage” в 0 (по умолчанию 1). Тогда выделение больших страниц памяти для виртуальных машин будет отключено.

С декабря 2014 во всех релизах ESXi TPS между ВМ по умолчанию отключен, так как была найдена уязвимость, теоретически позволяющая получить из одной ВМ доступ к оперативной памяти другой ВМ. Подробности тут. Информация про практическую реализацию эксплуатации уязвимости TPS мне не встречалось.

Политика TPS контролируется через advanced option “Mem.ShareForceSalting” на ESXi:
0 — Inter-VM TPS. TPS работает для страниц разных ВМ;
1 – TPS для ВМ с одинаковым значением “sched.mem.pshare.salt” в VMX;
2 (по умолчанию) – Intra-VM TPS. TPS работает для страниц внутри ВМ.

Однозначно имеет смысл выключать большие страницы и включать Inter-VM TPS на тестовых стендах. Также это можно использовать для стендов с большим количеством однотипных ВМ. Например, на стендах с VDI экономия физической памяти может достигать десятков процентов.

Memory Ballooning. Ballooning уже не такая безобидная и прозрачная для операционной системы ВМ техника, как TPS. Но при грамотном применении с Ballooning’ом можно жить и даже работать.

Вместе с Vmware Tools на ВМ устанавливается специальный драйвер, называемый Balloon Driver (он же vmmemctl). Когда гипервизору начинает не хватать физической памяти и он переходит в состояние Soft, ESXi просит ВМ вернуть неиспользуемую оперативную память через этот Balloon Driver. Драйвер в свою очередь работает на уровне операционной системы и запрашивает свободную память у нее. Гипервизор видит, какие страницы физической памяти занял Balloon Driver, забирает память у виртуальной машины и возвращает хосту. Проблем с работой ОС не возникает, так как на уровне ОС память занята Balloon Driver’ом. По умолчанию Balloon Driver может забрать до 65% памяти ВМ.

Если на ВМ не установлены VMware Tools или отключен Ballooning (не рекомендую, но есть KB:), гипервизор сразу переходит к более жестким техникам отъема памяти. Вывод: следите, чтобы VMware Tools на ВМ были.

Работу Balloon Driver’а можно проверить из ОС через VMware Tools.

Memory Compression. Данная техника применяется, когда ESXi доходит до состояния Hard. Как следует из названия, ESXi пытается сжать 4 Кбайт страницы оперативной памяти до 2 Кбайт и таким образом освободить немного места в физической памяти сервера. Данная техника значительно увеличивает время доступа к содержимому страниц оперативной памяти ВМ, так как страницу надо предварительно разжать. Иногда не все страницы удается сжать и сам процесс занимает некоторое время. Поэтому данная техника на практике не очень эффективна.

Memory Swapping. После недолгой фазы Memory Compression ESXi практически неизбежно (если ВМ не уехали на другие хосты или не выключились) переходит к Swapping’у. А если памяти осталось совсем мало (состояние Low), то гипервизор также перестает выделять ВМ страницы памяти, что может вызвать проблемы в гостевых ОС ВМ.

В отличие от Ballooning’а, когда у ВМ отбираются неиспользуемые страницы, при Swapping’e на диск могут переехать страницы, которые активно используются ОС или приложениями внутри ВМ. В результате производительность ВМ падает вплоть до подвисания. ВМ формально работает и ее как минимум можно правильно отключить из ОС. Если вы будете терпеливы 😉

Если ВМ ушли в Swap — это нештатная ситуация, которую по возможности лучше не допускать.

Основные счетчики производительности памяти виртуальной машины

Вот мы и добрались до главного. Для мониторинга состояния памяти в ВМ есть следующие счетчики:

Active — показывает объем оперативной памяти (Кбайт), к которому ВМ получила доступ в предыдущий период измерения.

Usage — то же, что Active, но в процентах от сконфигурированной оперативной памяти ВМ. Рассчитывается по следующей формуле: active ÷ virtual machine configured memory size.
Высокий Usage и Active, соответственно, не всегда является показателем проблем производительности ВМ. Если ВМ агрессивно использует память (как минимум, получает к ней доступ), это не значит, что памяти не хватает. Скорее это повод посмотреть, что происходит в ОС.
Есть стандартный Alarm по Memory Usage для ВМ:

Shared — объем оперативной памяти ВМ, дедуплицированной с помощью TPS (внутри ВМ или между ВМ).

Granted — объем физической памяти хоста (Кбайт), который был отдан ВМ. Включает Shared.

Consumed (Granted — Shared) — объем физической памяти (Кбайт), которую ВМ потребляет с хоста. Не включает Shared.

Если часть памяти ВМ отдается не из физической памяти хоста, а из swap-файла или память отобрана у ВМ через Balloon Driver, данный объем не учитывается в Granted и Consumed.
Высокие значения Granted и Consumed — это совершенно нормально. Операционная система постепенно забирает память у гипервизора и не отдает обратно. Со временем у активно работающей ВМ значения данных счетчиков приближается к объему сконфигурированной памяти, и там остаются.

Zero — объем оперативной памяти ВМ (Кбайт), который содержит нули. Такая память считается гипервизором свободной и может быть отдана другим виртуальным машинам. После того, как гостевая ОС получила записала что-либо в зануленную память, она переходит в Consumed и обратно уже не возвращается.

Reserved Overhead — объем оперативной памяти ВМ, (Кбайт) зарезервированный гипервизором для работы ВМ. Это небольшой объем, но он обязательно должен быть в наличии на хосте, иначе ВМ не запустится.

Balloon — объем оперативной памяти (Кбайт), изъятой у ВМ с помощью Balloon Driver.

Compressed — объем оперативной памяти (Кбайт), которую удалось сжать.

Swapped — объем оперативной памяти (Кбайт), которая за неимением физической памяти на сервере переехала на диск.
Balloon и остальные счетчики memory reclamation techniques равны нулю.

Вот так выглядит график со счетчиками Memory нормально работающей ВМ со 150 ГБ оперативной памяти.

На графике ниже у ВМ явные проблемы. Под графиком видно, что для данной ВМ были использованы все описанные техники работы с оперативной памятью. Balloon для данной ВМ сильно больше, чем Consumed. По факту ВМ скорее мертва, чем жива.

ESXTOP

Как и с CPU, если хотим оперативно оценить ситуацию на хосте, а также ее динамику с интервалом до 2 секунд, стоит воспользоваться ESXTOP.

Экран ESXTOP по Memory вызывается клавишей «m» и выглядит следующим образом (выбраны поля B,D,H,J,K,L,O):

Интересными для нас будут следующие параметры:

Mem overcommit avg — среднее значение переподписки по памяти на хосте за 1, 5 и 15 минут. Если выше нуля, то это повод посмотреть, что происходит, но не всегда показатель наличия проблем.

В строках PMEM/MB и VMKMEM/MB — информация о физической памяти сервера и памяти доступной VMkernel. Из интересного здесь можно увидеть значение minfree (в МБайт), состояние хоста по памяти (в нашем случае, high).

В строке NUMA/MB можно увидеть распределение оперативной памяти по NUMA-нодам (сокетам). В данном примере распределение неравномерное, что в принципе не очень хорошо.

Далее идет общая статистика по серверу по memory reclamation techniques:

PSHARE/MB — это статистика TPS;

SWAP/MB — статистика использования Swap;

ZIP/MB — статистика компрессии страниц памяти;

MEMCTL/MB — статистика использования Balloon Driver.

По отдельным ВМ нас может заинтересовать следующая информация. Имена ВМ я скрыл, чтобы не смущать аудиторию:). Если метрика ESXTOP аналогична счетчику в vSphere, привожу соответствующий счетчик.

MEMSZ — объем памяти, сконфигурированный на ВМ (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — Granted в МБайт.

TCHD — Active в МБайт.

MCTL? — установлен ли на ВМ Balloon Driver.

MCTLSZ — Balloon в МБайт.

MCTLGT — объем оперативной памяти (МБайт), который ESXi хочет изъять у ВМ через Balloon Driver (Memctl Target).

MCTLMAX — максимальный объем оперативной памяти (МБайт), который ESXi может изъять у ВМ через Balloon Driver.

SWCUR — текущий объем оперативной памяти (МБайт), отданный ВМ из Swap-файла.

SWGT — объем оперативной памяти (МБайт), который ESXi хочет отдавать ВМ из Swap-файла (Swap Target).

Также через ESXTOP можно посмотреть более подробную информацию про NUMA-топологию ВМ. Для этого нужно выбрать поля D,G:

NHN – NUMA узлы, на которых расположена ВМ. Здесь можно сразу заметить wide vm, которые не помещаются на один NUMA узел.

NRMEM – сколько мегабайт памяти ВМ берет с удаленного NUMA узла.

NLMEM – сколько мегабайт памяти ВМ берет с локального NUMA узла.

N%L – процент памяти ВМ на локальном NUMA узле (если меньше 80% — могут возникнуть проблемы с производительностью).

Memory на гипервизоре

Если счетчики CPU по гипервизору обычно не представляют особого интереса, то с памятью ситуация обратная. Высокий Memory Usage на ВМ не всегда говорит о наличие проблемы с производительностью, а вот высокий Memory Usage на гипервизоре, как раз запускает работу техник управления памятью и вызывает проблемы с производительностью ВМ. За алармами Host Memory Usage надо следить и не допускать попадания ВМ в Swap.

Unswap

Если ВМ попала в Swap, ее производительность сильно снижается. Следы Ballooning’а и компрессии быстро исчезают после появления свободной оперативной памяти на хосте, а вот возвращаться из Swap в оперативную память сервера виртуальная машина совсем не торопится.
До версии ESXi 6.0 единственным надежным и быстрым способ вывода ВМ из Swap была перезагрузка (если точнее выключение/включение контейнера). Начиная с ESXi 6.0 появился хотя и не совсем официальный, но рабочий и надежный способ вывести ВМ из Swap. На одной из конференций мне удалось пообщаться с одним из инженеров VMware, отвечающим за CPU Scheduler. Он подтвердил, что способ вполне рабочий и безопасный. В нашем опыте проблем с ним также замечено не было.

Собственно команды для вывода ВМ из Swap описал Duncan Epping. Не буду повторять подробное описание, просто приведу пример ее использования. Как видно на скриншоте, через некоторое время после выполнения указанной команд Swap на ВМ исчезает.

Советы по управлению оперативной памятью на ESXi

Напоследок приведу несколько советов, которые помогут вам избежать проблем с производительностью ВМ из-за оперативной памяти:

Источник