Удаленный рабочий стол remotefx что это
RDP vs RemoteFX
В группе предприятий «Х» используют терминальные сервера.
Начался новый сезон и в одном из представительств загрузка cpu начала достигать 100 процентов, что есть плохо, особенно после того, как пользователи начали жаловаться на скорость работы.
Причина возникновения проблемы была не понятна, количество сотрудников не менялось, софт не менялся… Все представительства в одинаковых условиях.
Собрал тестовый стенд и начал искать решение…
Долго перебирал разные настройки сервера и клиентских мест, это отдельная тема.
В творческом поиске сравнил протоколы RDP и RemoteFX, результаты решил опубликовать.
Сервер:
HP ML350 G6, 1*Xeon5620, 42gb RAM.
DirectX аппаратная видеокарта отсутствует.
СХД:
HP MSA P2000 G3 SAS, из 4х дисков SAS собран массив R5.
ПО:
На сервера установлен ESXi 5.1.
Терминальные сервера представляют из себя VM, выделено 4 vcpu(8000мгц) и 20gb RAM, в качестве гостевой ОС используется Windows Server 2008R2 SP1.
Сравнивалась нагрузка на процессор в трех приложениях: IE11, Adobe PDF Reader 11, 1c8.
Делал 8-10 замеров, в момент замеров на сервере работал только подопытный пользователь и пользователь администратора.
В качестве клиентских мест использовал два ноутбука с Windows XP и Windows 7 SP1, и тонкий клиент HP t510 c установленной ОС HP Smart Zero 4.4.
Результаты
IE11, запускался тестовый ролик, который находился на youtube.
RDP – Нагрузка на процессор 21-23%
RemoteFX – Нагрузка на процессор 11-18%
После замены ноутбуков на тонкий клиент HP.
RDP – Нагрузка на процессор 17-21%
RemoteFX – Нагрузка на процессор 10-12%
В лабораторных условия разница составила 5-10% процесорного времени в пользу RemoteFX.
Добавлю, что RDP по плавности проигрывания видео и рядом не находится с RemoteFX, при включенном RemoteFX, на первый взгляд, разницы в сравнении с обычным ПК не видна.
Все дальнейшие измерения решил проводить на тонком клиенте HP.
Переходим к документу PDF и скроллингу.
RDP – Нагрузка на процессор 16-20%
RemoteFX – Нагрузка на процессор 12-17%
Разница в пользу RemoteFX составила 3-4%.
Настала очередь 1с8, опять будем заниматься скроллингом списка документов.
RDP – Нагрузка на процессор 14-17%
RemoteFX – Нагрузка на процессор 17-18%
Разница в пользу RDP составила 1-3%.
Честно говоря, результат 1с8 мне не понравился. Решил все проверить и сделать дополнительные замеры.
Повторно замерял результаты, вроде все ок, укладываюсь в ошибку при измерениях, примерно 1-2%.
Результаты 1с можно списать на ошибку измерения, в итоге получается, что 1с все равно, как подключается пользователь — по RDP или RemoteFX.
Если подвести предварительные итоги
Думаю что для оценки качества кодека лучше всего подходит видео, остальные тесты я решил провести, поскольку работа с 1с и документами должна занимать большую часть рабочего времени пользователей.
Раньше я пробовал смотреть на PCoIP, результат мне не понравился, может, нужно посмотреть снова, но как не крути, а RemoteFX будет стоить меньше PCoIP, да и концепция VDI мне нравится меньше терминальных серверов.
В случае предприятия «Х» на одном процессоре Xeon5620 с нагрузкой в 40-80% работают 18-24 пользователей, и параллельно с терминальным сервером работает домен контроллер, и еще некоторые мелкие vm.
Как мне видится, внедрение RemoteFX позволит снизить на 20-30% нагрузку на процессор сервера, или позволит добавить примерно 5-7 пользователей.
Интерес к RemoteFX начал расти, и замеры решил продолжить
Сначала будем сравнивать, как влияет увеличение качества передаваемого звука.
В стандартных настройках качество звука подбирается динамически, когда на сервере работает достаточное количество пользователей — это слышно.
Смотрим ролик на ютюбе(RDP), нагрузка на процессор 18-22%, с стандартными настройками результат 17-21%.
Смотрим ролик на ютюбе(RemoteFX), нагрузка на процессор 10-16%, с стандартными настройками результат 10-12%.
Делаю вывод, что разница минимальная и при желании можно смело выставить высокое качество.
Однако прошу обратить внимание на сетевой трафик, я его не измеряю, все пользователи и сервера находятся на расстоянии коммутатора; если работать по узкому каналу, придется учитывать сетевой трафик.
Далее, как RemoteFX будет работать при изменении настроек, частота кадров, качество картинки, оптимизация кодека
Screen capture rate = Lowest
Screen Image Quality = Medium (default)
Ролик на ютюбе:
Нагрузка на процессор 5-8%
PDF и скроллинг:
Нагрузка на процессор 14-18%
1с8 и скроллинг:
Нагрузка на процессор 12-18%.
В случае медиа получаем выигрыш, но сразу заметно, что видео играет не так плавно и видны подергивания, аналогичные как при RDP.
Если задуматься, в этом нет нечего плохого, все зависит от задач, которые должны выполнять пользователи.
Хотя в случае офисной работы смысл теряется, работа с документами потребляет в два раза больше процессорного времени.
Screen capture rate = Medium (default)
Screen Image Quality = Lowest
Ролик на ютюбе
Нагрузка на процессор 5-11%
PDF и скроллинг
Нагрузка на процессор 12-16%
1с8 и скроллинг
Нагрузка на процессор 18-21%.
Получаем результат где для офисных задач выигрыш отсутствует, а для медиа возможно будет виден результат по сетевому трафику.
Screen capture rate = Lowest
Screen Image Quality = Lowest
Ролик на ютюбе
Нагрузка на процессор 5-10%
PDF и скроллинг
Нагрузка на процессор 12-16%
1с8 и скроллинг
Нагрузка на процессор 16-19%.
Screen capture rate = Highest (best quality)
Screen Image Quality = Highest (best quality)
Ролик на ютюбе:
Нагрузка на процессор 9-13%.
Для получения результатов для 1с и PDF, как оказалось, у меня не хватило терпения.
От настроек Highest (best quality) я ожидал другой результат, а полученный можно списать на ошибку измерения.
Далее на очереди ооптимизация кодека, Text vs Rich Multimedia
Стандартная настройка кодека Rich Multimedia.
PDF и скроллинг:
Нагрузка на процессор 13-16%
1с8 и скроллинг:
Нагрузка на процессор 16-19%
Технология RemoteFX и ее роль в работе удаленных пользователей
В цикле статей «Критерии выбора модели тонкого клиента» были подробно рассмотрены предпосылки появления и развития стека технологий, предназначенных для реализации полноценного графического интерфейса при удаленной работе по сети с виртуальными рабочими столами пользователей.
В цикле статей «Критерии выбора модели тонкого клиента» были подробно рассмотрены предпосылки появления и развития стека технологий, предназначенных для реализации полноценного графического интерфейса при удаленной работе по сети с виртуальными рабочими столами пользователей.
Конкретно в случае с протоколом Microsoft RDP, данный стек технологий по расширению графических возможностей получил название RemoteFX (RFX) и относится именно к «надстройке над RDP» (но никак не к замене оного).
Исторически, корни RFX уходят к разработкам фирмы Calista Technologies, которая в свое время была выкуплена Microsoft.
В дальнейшем, эти разработки были продолжены уже в стенах Microsoft и, в результате, первая инкарнация RemoteFX была представлена потребителям в составе Windows Server 2008 R2 SP1 и версии RDP7.1 соответственно.
Более поздняя и более совершенная версия RemoteFX появилась в составе RDP8.0 и Windows Server 2012 соответственно.
Формально, наличие RemoteFX означает поддержку полноценного пользовательского окружения при удаленной работе, включая:
— гибкий проброс USB-портов в удаленные сессии
— двунаправленную синхронизированную передачу аудио и видео потоков (вплоть до FullHD)
— удаленную работу с комплексной 3D-графикой и SilverLight-анимацией
— поддержку DirectX и OpenGL кодеков
— а также Windows Aero и любых 3D-приложений.
Но, на практике, как и всегда прочим, есть свои нюансы, которые следует рассмотреть подробнее.
Аппаратные требования (для хоста виртуализации на основе Windows Server 2012)
— соответствие хоста стандартным требованиям к Hyper-V
— GPU с поддержкой DirectX11.0 и выше, совместимый с унифицированными драйверами WDDM1.2
Программные требования (для хоста виртуализации на основе Windows Server 2012)
— Windows Server 2012 в качестве сервера (предпочтительнее core-инсталляция)
— Windows 8 Enterprise в качестве гостевой ОС на ВМ (и только Enterprise!)
Ключевые возможности (в составе Windows Server 2008 R2 SP1 и выше):
— Усовершенствованный проброс USB-устройств в удаленную сессию
Включая поддержку Смарткарт и USB-токенов
— Оптимизированные кодеки для сжатия и передачи видео (и аудио) потоков по RDP
Однако кодеки применяются НЕ селективно, кодируется весь экран целиком
— Виртуализация аппаратных GPU, разделяемых между несколькими виртуальными машинами
Предоставляет возможность полноценной работы удаленных 3D-приложений, включая и ресурсоемкие программные пакеты
Виртуализация аппаратного GPU и видеопамяти между несколькими ВМ при этом осуществляется следующим образом:
Максимальное разрешение / кол-во выделяемой на ВМ видеопамяти
Тестируем RemoteFX
Желание сделать домашний компьютер бесшумным рано или поздно посещает почти любого владельца настольного компьютера. Если компьютер используется, как печатная машинка, эта задача более менее реализуема. Но если вы пользователь 3D-игр либо других ресурсоемких приложений, то радостного мало. Либо вы приобретаете систему жидкостного охлаждения, либо серьезно вкладываетесь в бесшумные компоненты ПК.
С выходом технологии RemoteFX у вас появилась неплохая альтернатива: где-то далеко стоит мощный сервер, а на вашем рабочем месте тихий бездисковый клиент.
Microsoft анонсировал эту технологию относительно недавно — вместе с первым сервис-паком для Windows 2008 Server R2. Самое вкусное в этой технологии не проброс USB и не VOIP, а возможность виртуализовать графический адаптер.
Причем, если не ошибаюсь, Microsoft чуть ли не единственный вендор, позволяющий «расшарить» графический адаптер, а не отдать его монопольно ресурсоемкой ВМ. Кстати, пару лет назад Миша Михеев писал про RemoteFX.
Есть свежие презентации с Платформы, где демонстрируются возможности RemoteFX по рендерингу 3D-объектов для института МАИ. Впечатляет 🙂
В качестве тестирования я использовал следующий стенд:
— сервер: ПК 1*Core i3-2100/8GBRAM, Windows 2008 R2 SP1 Trial/ NVIDIA SVGA 1GB;
— виртуальная машина: 1vCPU/2GB, Windows 7 SP1 Enterprise Trial;
— клиент: ноутбук Core2Duo
2GHz/2GB RAM, Windows 7 SP1 Home Premium.
Сервер и клиент связаны Wi-Fi роутером D-Link 🙂
Требования к RemoteFX:
Так как сервер по совместительству является домашним ПК, операционная система сервера находится в VHD-файле, любезно предоставленном компанией Microsoft для ознакомления с продуктом 🙂
Лицензирование
Все достаточно радужно: вы можете использовать RemoteFX на бесплатном сервере Hyper-V R2, необходимо будет заплатить только за ОС, установленные в виртуальных машинах. В качестве такой ОС поддерживаются только Windows 7 SP1 Enterprise/Ultimate.
Настройка стенда:
1) Установка сервера Hyper-V R2 SP1/Windows 2008 R2 SP1
Вся установка заключается в том, чтобы подмонтировать VHD-файл с системой в диспетчере дисков и через утилиту BCDEDIT разрешить загрузку с VHD.
2) Поднимаем роль Hyper-V, а также компонент «RDS-RemoteFX», входящий в состав роли Remote Desktop.
3) Создаем ВМ на основе VHD с оценочной Windows 7 SP1 Ultimate в менеджер Hyper-V. Добавляем ей 2 гигабайта ОЗУ. Настраиваем в ВМ компоненты интеграции, брандмауэр, включаем RDP, после чего выключаем ВМ.
4) Добавляем в ВМ адаптер «RemoteFX 3D» и включаем ВМ. В свойствах адаптера можно указать количество мониторов и разрешение — эти настройки влияют на объем видеопамяти RemoteFX. Если у видеоадаптера не будет требуемого количества свободной памяти, ВМ не запустится.
Внимание: после добавления этого видеоадаптера подключиться к ВМ через консоль Hyper-V будет невозможно!
5) Настраиваем профиль подключения к ВМ следующим образом:
6) Подключаемся с ноутбука через RDP и проверяем какой видеоадаптер установлен в системе. Если «Microsoft Remote FX Graphics Device –WDDM», то все получилось.
Тестирование
Для тестирования я воспользовался относительно свежим 3D-шутером Deus Ex 3: Human Revolution.
Первый же блин был комом — на максимальных настройках игра быстро вылетела с ошибкой нехватки памяти. Это и не мудрено: ВМ использовала 220 Мб видеопамяти, а минимальные требования — 512мб. Пришлось достаточно прилично снизить используемые настройки, оставив разрешение 1024х768 (самое адекватное для моего ноутбука).
Ура, игра запустилась и я смотрю без тормозов стартовый трейлер. Потрясающие ощущения.
Как видите, загрузка процессора на уровне 40%, сети — в пике до 20Мбит/с. RemoteFX явно не оптимизирован для WAN.
Затем начинается игра. Что за ужас — при любом движении мышью экран будто сходит с ума. Подвигался с помощью клавиатуры — подтормаживает 🙁
Возможно, это отголоски Wi-Fi и в локальной сети все будет быстрее.
Дальше решил поразбираться, что за ерунда с мышью…
Выяснил, что есть два режима позиционирования мыши: абсолютный и относительный. При абсолютном передаются текущие координаты указателя, при относительном — смещение относительно предыдущей позиции. В RDP передается только абсолютный режим, а в 3D-шутерах используется относительный. Решение есть — геймпад 😉
Постойте, а как же Crisis? Его же «запихивали» в RemoteFX? Все просто — к разработке Crisis приложила руку MS и оставила там возможность абсолютного режима позиционирования мыши.
Выводы
1) Технология уже сейчас вполне применима для того, чтобы виртуализировать 3D приложения (CAD) рендеринга объектов. Правда, налагаемые требования к клиенту (RDP 7.1) несколько осложняют широкое распространение. Разделение видеоадаптера между несколькими ВМ — значительное преимущество, особенно, Nvidia Quadro Plex 7000.
2) Крайне не хватает оптимизации под узкие каналы связи. Впрочем, задержка при маршрутизации будет критична для работы 3D-игр.
3) Невозможно указать большее количество видеопамяти, чем запрограммировано на текущие настройки монитора ВМ. К примеру, нельзя дать ВМ 512МБ видеопамяти.
4) Крайне огорчает отсутствие поддержки относительного режима позиционирование мыши, без которого не поиграть в большинство 3D-шутеров.
Производительность 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
«Low Angle Of Pedestrians Walking In Busy Street, Daytime»: 4096 x 2160, 31721 кбит/с, 13 секунд, 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 можно как «завалить» так и «подтянуть» его результаты. Возможно, более релевантным было бы проведение чего-то вроде «конфетти-теста», например, такого.
Что дальше
Так как на этом этапе тесты проводились для одной сессии и при включении лишь рекомендованных настроек, то далее имеет смысл протестировать производительность:
при одновременной работе нескольких пользователей
при включении в групповых политиках различных дополнительных настроек кодека
Настройка ускорения графического процессора (GPU) для виртуального рабочего стола Windows
Диагностика проблем производительности графики удалённого рабочего стола
Рекомендация по тестированию взята из хоть и старого, но очень подробного описания RemoteFX
Сброс кэша счётчиков
Как сделать работу с Microsoft Remote Desktop лучше. Ветка комментариев про UDP, TCP, потери и т.д. В самой статье есть ссылки на спецификации мультитранспортного расширения для протокола RDP
Приложения
Заголовки столбцов содержат различные уникальные данные (id терминальной сессии или оборудования), которые будут несовпадать из-за применения групповых политик и выхода-входа на терминальный сервер. Приводим к единому виду с помощью PowerShell-скрипта:
Продолжение истории будет на следующей неделе. Спасибо за внимание!
Что ещё интересного есть в блоге Cloud4Y
→ Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым
→ Пароль как крестраж: ещё один способ защитить свои учётные данные
→ Тим Бернерс-Ли предлагает хранить персональные данные в подах
→ Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi
→ Создание группы доступности AlwaysON на основе кластера Failover
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.