настройка remotefx windows 10
Windows 10 Hyper-V: RemoteFX 3D
С чем связаны мои восторги от отличного гипервизора Hyper-V восьмого поколения (считаем: Windows Server 2008 — 1.0, Windows Server 2008 SP1 — 2.0, Windows Server 2008 R2 — 3.0, Windows Server 2012 — 4.0, Windows Server 2012 R2 — 5.0, Windows 10 builds earlier than 10565 — 6.2, Windows 10 build 10565 or later — 7.0, Windows Server 2016 Technical Preview — 7.1, Windows 10 Anniversary Update/Windows Server 2016 — 8.0)?
Конструкторы и технологи используют тяжелые CAD-системы, требующие высокой производительности для отрисовки моделей изделий. Зачастую им приходится работать в разных средах — промышленной и опытной, а также с разными версиями ПО. Для исключения конфликтов доходит до использования 2 компьютеров на одном рабочем месте.
В связи с вышесказанным возникла потребность рассмотреть запуск тестового ПО CAD в виртуальной машине на Hyper-V.
Попытка протестировать на пятилетнем домашнем ноутбуке оказалась неудачной: 
Зато определился первый самый простой тест — запустить dxdiag для определения версии WDDM и уровня поддержки DirectX:
Для нашей задачи должны выполняться следующие требования, ключевое — DX 11.0 совместимый GPU с драйвером WDDM 1.2.
Так как нам нужен OpenGL, то из гостевых подходят только Windows 10/Windows Server 2016. Чтобы не вставать на разнообразные грабли, а их есть миллион у MS, я выбрал мой любимый Microsoft Windows 10 Enterprise LTSB 1607 в качестве хостовой и клиентской ОСей. Более смелым рекомендую таблицу «совместимости» ОС(раздел Support for GPU Acceleration with Hyper-V).
Переходим к тестированию на инженерной рабочей станции. Первым шагом запускаем dxdiag:
Результат нас устраивает — WDDM 2.1/DirectX11_0. Это подтверждается в консоли Hyper-V:
Для тестирования запускаем классический российский/международный тест Unigine Heaven, чтобы 3 раза не вставать решил протестировать DirectX 9,11 и OpenGL одновременно:
Конечным результатом тестов является запуск NX в Hyper-V: 
Развертывание графических устройств с помощью vGPU RemoteFX
применимо к: Windows server 2022, Windows server 2019, Windows Server 2016, Microsoft Hyper-V Server 2016
Из соображений безопасности процессор RemoteFX vGPU по умолчанию отключен для всех версий Windows, начиная с обновления для системы безопасности за 14 июля 2020 г., и удален, начиная с обновления для системы безопасности за 13 апреля 2021 г. См. KB 4570006.
функция gpu для RemoteFX позволяет нескольким виртуальным машинам совместно использовать физический GPU. визуализация и вычисление ресурсов совместно используются виртуальными машинами, что делает RemoteFXные виртуальные машины подходящими для высокопроизводительных рабочих нагрузок, когда выделенные ресурсы GPU не требуются. например, в службе VDI RemoteFX виртуальный графический процессор можно использовать для разгрузки затрат на визуализацию приложений в GPU, что приводит к снижению нагрузки на цп и улучшению масштабируемости служб.
Требования к RemoteFX vGPU
Требования к системе узла:
Требования к гостевым виртуальным машинам:
Дополнительные рекомендации для гостевых виртуальных машин:
включение RemoteFXного видеопроцессора
чтобы настроить RemoteFXный виртуальный жесткий процессор на узле Windows Server 2016:
по умолчанию RemoteFX виртуальный графический процессор будет использовать все доступные и поддерживаемые gpu. чтобы ограничить количество gpu, используемых RemoteFXным виртуальным графическим процессором, выполните следующие действия.
Настройка трехмерного адаптера vGPU RemoteFX
Вы можете использовать пользовательский интерфейс диспетчера Hyper-V или командлеты PowerShell, чтобы настроить трехмерный графический адаптер vGPU RemoteFX.
настройка RemoteFX виртуального устройства с помощью диспетчера Hyper-V
Останавливает виртуальную машину, если она выполняется в данный момент.
откройте диспетчер Hyper-V, перейдите к Параметры вм, а затем выберите добавить оборудование.
выберите RemoteFX трехмерная графическая плата, а затем нажмите кнопку добавить.
Задайте максимальное число мониторов, максимальное разрешение монитора и используемой видеопамяти, либо оставьте значения по умолчанию.
настройка RemoteFXного gpu с помощью командлетов PowerShell
Используйте следующие командлеты PowerShell для добавления, проверки и настройки адаптера:
Мониторинг производительности
производительность и масштабирование RemoteFX службы с поддержкой виртуальных gpu определяется различными факторами, такими как количество gpu в системе, общая память gpu, объем системной памяти и скорость памяти, число ядер цп и тактовая частота цп, скорость хранения и реализация NUMA.
Память системы узла
для каждой виртуальной машины, поддерживающей виртуальный графический процессор, RemoteFX использует системную память как в гостевой операционной системе, так и на сервере узла. Гипервизор гарантирует доступность системной памяти для гостевой операционной системы. На узле каждому виртуальному рабочему столу с поддержкой виртуальных рабочих столов необходимо объявить требования к системной памяти гипервизору. Когда запускается виртуальный рабочий стол с поддержкой виртуальных рабочих столов, гипервизор резервирует дополнительный объем системной памяти на узле.
требования к памяти для сервера с поддержкой RemoteFX являются динамическими, так как объем памяти, потребляемой на сервере с поддержкой RemoteFX, зависит от числа мониторов, связанных с виртуальными рабочими столами с поддержкой виртуальных рабочих столов, и максимального разрешения этих мониторов.
Видеопамять основного GPU узла
Каждый виртуальный рабочий стол с поддержкой виртуальных рабочих столов использует аппаратную видеопамять GPU на сервере узла для подготовки к просмотру рабочего стола. Кроме того, кодек использует видео-память для сжатия отображаемого экрана. Объем памяти, необходимый для отрисовки и сжатия, непосредственно зависит от количества мониторов, подготовленных для виртуальной машины. Объем зарезервированной видеопамяти зависит от разрешения экрана системы и количества мониторов. Некоторым пользователям требуется более высокое разрешение экрана для определенных задач, но существует большая масштабируемость с более низкими параметрами разрешения, если все остальные параметры остаются постоянными.
ЦП узла
Гипервизор планирует размещение и виртуальные машины на ЦП. дополнительная нагрузка на узел с поддержкой RemoteFX увеличивается, так как система запускает дополнительный процесс (rdvgm.exe) на виртуальном рабочем столе с поддержкой виртуальных рабочих столов. Этот процесс использует драйвер графического устройства для выполнения команд GPU. Кодек также использует ЦП для сжатия данных экрана, которые необходимо отправить обратно клиенту.
Большее число виртуальных процессоров означает лучшее взаимодействие с пользователем. Мы рекомендуем выделить не менее двух виртуальных процессоров на виртуальный рабочий стол с поддержкой виртуальных рабочих столов. Мы также советуем использовать архитектуру x64 для виртуальных рабочих столов с поддержкой GPU, так как производительность виртуальных машин x64 лучше по сравнению с виртуальными машинами x86.
Вычислительная мощность процессора
У каждого виртуального рабочего стола с поддержкой виртуальных рабочих столов есть соответствующий процесс DirectX, выполняемый на сервере узла. этот процесс воспроизводит все команды графики, полученные от RemoteFX виртуального рабочего стола, на физический графический процессор. Это аналогично одновременному запуску нескольких приложений DirectX на одном физическом GPU.
как правило, графические устройства и драйверы настроены на выполнение только нескольких приложений на рабочем столе, но RemoteFX растягивает графические процессоры, чтобы продолжить работу. вгпус поставляются со счетчиками производительности, которые измеряют ответ GPU на запросы RemoteFX и позволяют убедиться, что gpu не растягиваются слишком далеко.
Когда GPU не хватает ресурсов, операции чтения и записи выполняются длительное время. Администраторы могут использовать счетчики производительности, чтобы выяснить, когда следует настраивать ресурсы и предотвращать время простоя для пользователей.
дополнительные сведения о счетчиках производительности для мониторинга RemoteFX поведения виртуальных gpu см. в статье диагностика проблем производительности графики в удаленный рабочий стол.
Deploy graphics devices using RemoteFX vGPU
Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Microsoft Hyper-V Server 2016
Because of security concerns, RemoteFX vGPU is disabled by default on all versions of Windows starting with the July 14, 2020 Security Update and removed starting with the April 13, 2021 Security Update. To learn more, see KB 4570006.
The vGPU feature for RemoteFX makes it possible for multiple virtual machines to share a physical GPU. Rendering and compute resources are shared dynamically among virtual machines, making RemoteFX vGPU appropriate for high-burst workloads where dedicated GPU resources are not required. For example, in a VDI service, RemoteFX vGPU can be used to offload app rendering costs to the GPU, with the effect of decreasing CPU load and improving service scalability.
RemoteFX vGPU requirements
Host system requirements:
Guest VM requirements:
Additional considerations for guest VMs:
Enable RemoteFX vGPU
To configure RemoteFX vGPU on your Windows Server 2016 host:
By default, RemoteFX vGPU will use all available and supported GPUs. To limit which GPUs the RemoteFX vGPU uses, follow these steps:
Configure the RemoteFX vGPU 3D adapter
You can use either the Hyper-V Manager UI or PowerShell cmdlets to configure the RemoteFX vGPU 3D graphics adapter.
Configure RemoteFX vGPU with Hyper-V Manager
Stop the VM if it’s currently running.
Open Hyper-V Manager, navigate to VM Settings, then select Add Hardware.
Select RemoteFX 3D Graphics Adapter, then select Add.
Set the maximum number of monitors, maximum monitor resolution, and dedicated video memory, or leave the default values.
Select OK to finish the configuration.
Configure RemoteFX vGPU with PowerShell cmdlets
Use the following PowerShell cmdlets to add, review, and configure the adapter:
Monitor performance
The performance and scale of a RemoteFX vGPU-enabled service are determined by a variety of factors such as number of GPUs on your system, total GPU memory, amount of system memory and memory speed, number of CPU cores and CPU clock frequency, storage speed, and NUMA implementation.
Host system memory
For every VM enabled with a vGPU, RemoteFX uses system memory both in the guest operating system and in the host server. The hypervisor guarantees the availability of system memory for a guest operating system. On the host, each vGPU-enabled virtual desktop needs to advertise its system memory requirement to the hypervisor. When the vGPU-enabled virtual desktop starts, the hypervisor reserves additional system memory in the host.
The memory requirement for the RemoteFX-enabled server is dynamic because the amount of memory consumed on the RemoteFX-enabled server is dependent on the number of monitors that are associated with the vGPU-enabled virtual desktops and the maximum resolution for those monitors.
Host GPU video memory
Every vGPU-enabled virtual desktop uses the GPU hardware video memory on the host server to render the desktop. In addition, a codec uses the video memory to compress the rendered screen. The amount of memory needed for rendering and compression is directly based on the number of monitors provisioned to the virtual machine. The amount of reserved video memory varies based on the system screen resolution and how many monitors there are. Some users require a higher screen resolution for specific tasks, but there’s greater scalability with lower resolution settings if all other settings remain constant.
Host CPU
The hypervisor schedules the host and VMs on the CPU. The overhead is increased on a RemoteFX-enabled host because the system runs an additional process (rdvgm.exe) per vGPU-enabled virtual desktop. This process uses the graphics device driver to run commands on the GPU. The codec also uses the CPU to compress screen data that needs to be sent back to the client.
More virtual processors mean a better user experience. We recommend allocating at least two virtual CPUs per vGPU-enabled virtual desktop. We also recommend using the x64 architecture for vGPU-enabled virtual desktops because the performance on x64 virtual machines is better compared to x86 virtual machines.
GPU processing power
Every vGPU-enabled virtual desktop has a corresponding DirectX process that runs on the host server. This process replays all graphics commands it receives from the RemoteFX virtual desktop onto the physical GPU. This is like running multiple DirectX applications at the same time on the same physical GPU.
Usually, graphics devices and drivers are tuned to run only a few applications on the desktop at a time, but RemoteFX stretches the GPUs to go even further. vGPUs come with performance counters that measure the GPU response to RemoteFX requests and help you make sure the GPUs aren’t stretched too far.
When a GPU is low on resources, read and write operations take a long time to complete. Administrators can use performance counters to know when to adjust resources and prevent downtime for users.
Learn more about performance counters for monitoring RemoteFX vGPU behavior at Diagnose graphics performance issues in Remote Desktop.
How to use Windows 10 RemoteFX with GPU acceleration and sound in Hyper-v
I was looking for a way to pass through GPU acceleration to virtual machines for some processing tasks. However, most methods (such as DDA or VMware ESXi) requires specific server hardware, server hypervisor OS, support CPU & motherboard firmware. Sadly, I don’t have matching specification to use those methods.
Then I come across RemoteFX. While it’s not a full feature GPU pass through, it serves my current needs with my limited availability for other methods. Unfortunately Microsoft is disabling (updates after July 14, 2020) and removing RemoteFX support by February 9, 2021.
Based on your Windows 10 version and your updates, you may find that RemoteFX is disabled. But there’s still ways to make it work.
Moreover, if you have trouble with sound or connecting using remote desktop, I have a solution for you.
RemoteFX for Windows 10 version 1803 or earlier
RemoteFX is supported in these versions:
That is. Start the virtual machine and you should have RemoteFX working for your VM.
RemoteFX for Windows 10 version after 1803 without Windows update after July 14, 2020
In this case, RemoteFX still works if your virtual machine already have RemoteFX adapter added. But you don’t have the option to add new RemoteFX adapter from the Hyper-V Manager:
It’s dimmed and you won’t be able to add RemoteFX. Moreover, The Physical GPUs option is no longer shown in Hyper-V Settings.
But you can still add RemoteFX adapter using PowerShell:
Now check your virtual machine settings at Hyper-V manager and you should see RemoteFX adapter added.
RemoteFX for Windows 10 version with Windows update after July 14, 2020
You will start to receive the following error if you try to start a virtual machine with RemoteFX adapter:
This is because Microsoft’s updates after July 14, 2020 would disable RemoteFX due to a vulnerability.
All hope is not lost. You can re-enable it using Powershell:
Now try again and your virtual machine with RemoteFX adapter should be starting ok.
If you want to add new RemoteFX adapter, check out powershell command Add-VMRemoteFx3dVideoAdapter discussed in last section.
Troubleshooting
Video remoting was disconnected
If you have this error, you need to update a setting in your virtual machine using Group Policy Editor.
You should now be able to connect using Enhanced Session Mode.
RDP failed to connect
If you receive this error, you need to disable Use WDDM graphics display driver for Remote in your virtual machine as discussed in the last troubleshooting section.
Disable Windows Automatic Update
Microsoft has scheduled to remove RemoteFX by February 2021. If you want to continue to use RemoteFX after that, you would need to avoid Windows Update at that time.
One way is to disable Windows Automatic Update.
IMPORTANT: continue using Windows without security updates pose security risk to your system. Do not disable unless necessary.
To disable Windows Automatic Update, follow the steps below:
Security Risk
RemoteFX has a remote code execution vulnerability (CVE-2020-1036) that has no patch to fix. As a result, Microsoft decides to remove the RemoteFX feature to eliminate the risk.
IMPORTANT: continue using RemoteFX poses security risk to your system. Use it at your own risk or stop using RemoteFX to avoid the risk.
Производительность RemoteFX, часть 1
О технологии RemoteFX от Майкрософт, которая повышает качество работы в режиме удалённого рабочего стола, известно давно. В интернете хватает материалов, демонстрирующих её эффективность. Но большинство оценок носят качественный характер: «вот играем в %game_name%, fps в норме», «вот запустили 3D софт, как будто локально работает! Скриншот здесь, видео там».
В данном исследовании мы разберёмся, как перейти от «попугаев» к конкретным метрикам, чтобы количественно оценить эффективность технологии и объективно сравнить её использование с обычным режимом RDP.
Конфигурация тестовой среды
Выбор показателей для измерений
Тест #1: ввод текста
Тест #2: ввод текста + 3D BenchMark
Тест #3: ввод текста + просмотр локальных видеофайлов
Тест #4: ввод текста + просмотр youtube-ролика
Обработка данных и построение графиков
Анализ результатов и наиболее интересные графики
Задержки при обработке ввода от пользователя
Общие сетевые метрики
Загрузка центрального процессора
Переопределение групп сбора данных: _1_task_define.cmd
Принудительная остановка записи данных: _1_task_breake.cmd
Конвертация двоичных данных в CSV: blg2csv.cmd
Нормализация заголовков CSV: blg2csv.ps1
Jupiter Notebook: импорт данных
Jupiter Notebook: отрисовка одной метрики на диаграмму
Jupiter Notebook: отрисовка всех метрик на одной диаграмме
Диаграмма со всеми графиками
Кратко о RemoteFX
Традиционный RDP работает так, чтобы как можно больше работы по отрисовке окна удалённого рабочего стола переложить на клиента: по сети передаются графические примитивы и инструкции, которые должна выполнить клиентская видеокарта. Такой подход, в случае показа видео или использования интерфейса Windows Aero, требует поддержки со стороны клиента. Иначе вместо Aero будет использована упрощённая схема, а обработанный CPU сервера видеопоток передан клиенту в виде растровой графики, производительность отрисовки при этом может оказаться просто неприемлемой. Поэтому приходилось выбирать: либо использовать традиционный RDP только в связке с достаточно производительным клиентским железом, либо отказываться от сложной графики.
При включении RemoteFX клиенту по сети по прежнему передаются растровые кадры. Но есть два существенных отличия от традиционного RDP. Во-первых, вся подготовка и обработка графики перекладывается на GPU сервера, это происходит намного быстрее и разгружает CPU. А во-вторых, используется сжатие кадра, которое выполняет кодек RemoteFX. Это существенно снижает объём передаваемых по сети данных, тем самым разгружая канал связи. Это существенно снижает требования к клиентскому железу, но сохраняет достаточный уровень отрисовки и отзывчивости удалённого рабочего стола.
Конфигурация тестовой среды
Сервер
2 vCPU Intel(R) Xeon(R) CPU E5-2696 v4 @ 2.20GHz
GPU NVIDIA GRID M60-1Qб, Dedicated Memory 929 MB, Shared Memory 4095 MB
гостевая ОС Windows Server 2019 Standart x64 1809 (Version 10.0.17763.1577), DirectX 12
network in/out rate limit 50 Mbps
Клиент
Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz, 3801 МГц, ядер: 4, логических процессоров: 4
network in/out rate limit 100 Mbps
OS Windows 10 Pro 2004 (Version 10.0.19041.685), DirectX 12
1920 x 1080 (32 bit) (32Hz)
на вкладке «Взаимодействие» выбрано «Локальная сеть (10 Мбит/с и выше)»
Выбор показателей для измерений
Качество и производительность удалённого рабочего стола нужно оценить с точки зрения как пользователя, так и потребления облачных ресурсов. Будем собирать данные о частоте кадров отрисовки, задержках отклика на ввод данных, сетевом трафике и загрузке CPU/GPU/RAM. Метрики выбраны с учётом официальных рекомендаций по диагностике.
\Графика RemoteFX(*)\Качество кадра
\Графика RemoteFX(*)\Исходящих кадров в секунду
\Графика RemoteFX(*)\Входящих кадров в секунду
\Графика RemoteFX(*)\Среднее время кодирования
\Графика RemoteFX(*)\Коэффициент сжатия графических данных
\Графика RemoteFX(*)\Пропущено кадров в секунду — у сервера недостаточно ресурсов
\Графика RemoteFX(*)\Пропущено кадров в секунду — недостаточно сетевых ресурсов
\Графика RemoteFX(*)\Пропущено кадров в секунду — у клиента недостаточно ресурсов
\Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода
\Сведения о процессоре(_Total)\% загруженности процессора
\NVIDIA GPU(*)\% Video Decoder Usage
\NVIDIA GPU(*)\% Video Encoder Usage
\NVIDIA GPU(*)\% GPU Memory Usage
\NVIDIA GPU(*)\% GPU Usage
\NVIDIA GPU(*)\% FB Usage
\Сеть RemoteFX(*)\Общая скорость отправки
\Сеть RemoteFX(*)\Общая скорость приема
\Сеть RemoteFX(*)\Скорость отправки TCP-данных
\Сеть RemoteFX(*)\Скорость отправки UDP-данных
\Сеть RemoteFX(*)\Общая скорость приема
\Сеть RemoteFX(*)\Скорость получения TCP-данных
\Сеть RemoteFX(*)\Скорость получения UDP-данных
\Сеть RemoteFX(*)\Пропускная способность текущего TCP-подключения
\Сеть RemoteFX(*)\Пропускная способность текущего UDP-подключения
\Память\% использования выделенной памяти
PS. По непонятной причине данные по оперативной памяти не сохранялись в журнал при выполнении задания группы сбора, хотя «вживую» Системный монитор нормально строил графики по обоим показателям. Сброс кэша счётчиков не помог.
Методика тестирования
Чтобы оценить эффективность использования выделенной видеокарты на облачным сервере, нужно провести две серии одинаковых тестов: до и после включения отрисовки удалённого рабочего стола на GPU.
В каждой серии выполним следующие тесты:
ввод текста + 3D BenchMark
ввод текста + просмотр локальных видеофайлов
ввод текста + просмотр youtube-ролика
Для оценки влияния теста на задержку обработки ввода от пользователя поверх основной программы открывается стандартный Блокнот и зажимается произвольная клавиша. Окно редактора на протяжении теста будет постоянной частью всех кадров, поэтому исказит результат в лучшую сторону. Чтобы снизить эффект, размер окна уменьшим до 122*156% 99% кадра будут меняться и визуально будет видно, что имитация активности пользователя работает.
Тест #1: ввод текста
В качестве тестов рекомендуется «использовать любые приложения, которые плотно работают с графикой (например, потоковое видео), приложения, использующие DirectX». Результаты первого теста, с точки зрения пользователя (частота кадров и задержка ввода), практически одинаковые. Поэтому строить графики и анализировать их нет особого смысла. Такой тест больше пригодится для диагностики RemoteFX.
Тест #2: ввод текста + 3D BenchMark
Выполнялся при помощи FurMark в полноэкранном режиме.
Тест #3: ввод текста + просмотр локальных видеофайлов
Локальные видеофайлы воспроизводились в Windows Media Player, равёрнутом на весь экран, без установки каких-либо дополнительных кодеков, по кругу в следущем порядке:
«Ants carrying dead spider»: 1920 x 1080, 10667 кбит/с, 19 секунд, 29.97 fps
«Flying Through Forest 1»: 1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps
Единственным критерием отбора была динамичность ролика: видеоряд должен был как можно сильнее нагрузить кодек RemoteFX. Но ролик «Flying Through Forest 1» оказался в этом плане интересной находкой: выходной FPS заметно проседал, а входной от запуска к запуску был сильно выше или ниже среднего! Его влияние на различные метрики будет заметно на графиках, которые будут ниже.
Тест #4: ввод текста + просмотр youtube-ролика
В качестве youtube-теста был выбран чудесный ролик «Коста-Рика», который проигрывался в качестве 1080p60 в браузере Firefox, режим «киоск».
Обработка данных и построение графиков
Сначала конвертируем двоичные файлы в csv (см. Приложение) с помощью стандартной утилиты reglog и очистим их заголовки (см. Приложение).
Анализ результатов и наиболее интересные графики
Задержки при обработке ввода от пользователя
До включения групповых политик сильнее всего на обработке ввода сказалось проигрывание локальных видеофайлов: в среднем 45 мс при рекомендованных 33 мс.
Включение отрисовки через GPU в групповых политиках стабилизировало этот показатель во всех сценариях.
Частота кадров
После включения GPU ускорения ситуация явно становится лучше, особенно в 3D тесте. Результаты двух других тестов хоть и демонстрируют улучшение, но недостаточно: провалы на графиках соответствуют визуальным «рывкам» при просмотре.
Воспроизведение «Flying Through Forest 1» (1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps): от запуска к запуску на вход кодека RеmoteFX поступало либо повышенное либо пониженное количество кадров. Возможно, причина в перекодировке из формата QuickTime, «лишних» 8 пикселях ширины кадра или битрейте.
«Коста-Рика» также вызвал «проседание» FPS у RemoteFX: его проигрывание в браузере в 1080p60 ложилось на центральный процессор. Возможно, он просто не успевал перекодировать из 60fps и подготовить нужный кадр для RemoteFX.
Общие сетевые метрики
При включении GPU ускорения происходит рост сетевого трафика, который зависит от сценария теста.
Загрузка центрального процессора
Включение GPU ускорения практически вдвое разгружает центральный процессор, за исключением youtube-теста. И даже здесь удалось уйти от периодической 100% загрузки.
Загрузка видеокарты
Возможно, разгадка странного поведения второго ролика кроется в графике 17: входящих для RemoteFX кадров было больше, когда видеокарта была больше загружена кодированием.
Выводы
В RDP протоколе частота кадров ограничена 30-ю кадрами в секунду. Со стороны сервера увеличить лимит FPS можно, но бессмысленно: на практике терминальная сессия перестала отрисовывать окно и реагировать на действия как раз при проигрывании «того самого» видеофайла :).
Итоги в цифрах:
Частота кадров стабилизируется почти на максимально возможном для протокола уровне: 29-30 FPS в среднем вместо 25 или даже 15 FPS
Отзывчивость удалённого рабочего стола также стабилизируется, при этом возрастая в несколько раз
Заметно, на 20-50 %, разгружается центральный процессор
Немного возрастает утилизация канала связи, на 3-6 Мбит/сек
Утилизация GPU составила до 20%
Результат действительно очень хороший: RemoteFX значительно увеличивает качество работы в терминальной сессии — плавность отрисовки окна и отклик на действия пользователя сравнимы с локальным режимом. Даже «тяжёлые» сценарии показывают в этом плане заметный прирост.
Тесты, конечно, носят искусственный характер: выбором способа нагрузки на кодек RemoteFX можно как «завалить» так и «подтянуть» его результаты. Возможно, более релевантным было бы проведение чего-то вроде «конфетти-теста», например, такого.
Что дальше
Так как на этом этапе тесты проводились для одной сессии и при включении лишь рекомендованных настроек, то далее имеет смысл протестировать производительность:
при одновременной работе нескольких пользователей
при включении в групповых политиках различных дополнительных настроек кодека
Рекомендация по тестированию взята из хоть и старого, но очень подробного описания RemoteFX
Как сделать работу с Microsoft Remote Desktop лучше. Ветка комментариев про UDP, TCP, потери и т.д. В самой статье есть ссылки на спецификации мультитранспортного расширения для протокола RDP
Приложения
Заголовки столбцов содержат различные уникальные данные (id терминальной сессии или оборудования), которые будут несовпадать из-за применения групповых политик и выхода-входа на терминальный сервер. Приводим к единому виду с помощью PowerShell-скрипта:
Продолжение истории будет на следующей неделе. Спасибо за внимание!
Что ещё интересного есть в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.