Боюсь, что для энерго-эффективного процессора ноутбука может быть сложно захватывать видео и рендерить RDP FullHD. К сожалению у меня нет отдельной платы видео захвата.
Не исключаю, что VNC в игровых сценариях может работать лучше… Но я все равно остался крайне доволен. Старый и новый RDP — земля и небо. Поверьте. К тому же все шрифты и текст теперь пиксель-в-пиксель. Ничего не раздражает глаз. Реакция на нажатие в Word\Excel моментальная.
Кстати, небольшой офтоп. Во время сравнения шрифтов и текста, я отчетливо понял, что мой 27 дюймовый IPS монитор от Acer несравненно хуже монитора жены. Dell Ultrasharp.
Косые линии в SketchUp имеют на моем мониторе какую то рябь или стробицу.
Думали, что проблема в RDP, оказалось в мониторе! Заказал себе новый монитор в магазине.
Насчет тонких клиентов, думаю, что работать будет, когда обновят прошивку, так как MS умудрились сделать совместимость с обычными h264 кодерами\декодерами.
Версия Windows10, где установлен RDP сервер должна быть самой свежей 1709. Посмотреть версию Windows можно при помощи winver (пуск — выполнить — winver)
Кстати, забыл указать в статье, я пробовал клиент RDP из магазина Windows Store и к моему великому удивлению AVC444 кодек не запустился. RDP работало со старыми добрыми тормозами. Хотя я думаю, что если форсировать новый кодек на сервере, то все заработает.
Принудительное включение кодека и его настройки можно выполнить через групповые политики.
Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment
Я понял, но сжатие в RDP можно вообще выключить или настроить соотношение качество\скорость. По-умолчанию это соотношение = баланс.
Думаю с появлением h264 у MS была дилемма, оставить как было, или использовать новый на тот момент «быстрый» кодек в ущерб качеству. Теперь такой дилеммы не стоит.
Возрадуемся!
Возможно. Но не будем спорить о значениях слов… думаю мы оба правы.
В любом случае, результат достойный.
Не важно заслуга ли это кодека или чего то другого. Это работает!
И еще h264 AVC444, это не h264. Он не должен быть четче за счет битрейда, на самом деле это практически h265 (backport, если хотите), которые имеет те же характеристики!
Посмотрите первое видео из моей статьи и вы увидите, что в среднем на FullHD ролике, развернутом на весь экран, новый кодек требует в 2 раза меньшую полосу пропускания и работает существенно быстрее и четче.
В сценариях повседневного использования разница между старым и новым кодеком будет в среднем еще выше! По моим прикидкам экономия полосы 60-80%
«As part of the AVC 444 mode in RDP 10 we solved the challenge to get 4:4:4 quality text with 4:2:0 hardware encoders / decoders. In addition, with the AVC 444 mode we were able to improve the frame throughput significantly, for example with 1440p we can achieve a consistent frame rates of up to 50 fps on standard hardware.»
Так, что вы правы, не все так просто, и вероятно они решили попутно некоторое количество технических ребусов.
Очень не дурно. Добавлю, что в вашем виджете скорость измеряется в MiB (мебибайтах). Это значит, что 1,6 MiB на виджете будет равно 12,8 Mbps. Учитывая не полноэкранное видео, не FullHD разрешение и много статических элементов, могу сказать, что RDP намного экономнее расходует канал.
Да, игровой компьютер до обновления работал на 1703. Виртуальные машины для тестов, я готовил с нуля. На всякий случай покажу как форсировать новый кодек, но вроде бы этого больше не требуется! habrastorage.org/webt/ty/m9/_r/tym9_rymm41f3y6l7izvxiwaftc.png
Дело в том, что RDP получает в свое распоряжение видеокарту хоста. Доступно вся мощь, я проверял, но есть одно «но». Некоторые программы очевидно просто не желают запускаться в RDP режиме.
Запустить SketchUp в RDP я не смог! Мне пришлось запустить его в консольном сеансе, затем подключиться по RDP ^)
Мне вот интересно, за что минусуют… написали бы, не поленились. Я искренне не понимаю.
В чем проблема базы в контейнере? Ничего, кроме красоты нечеловеческой и гибкости мы не заметили… Напомню, это рабочий проект
«Всегда считал, что данные не должны находиться в контейнерах.» Ну так напиши почему ты так считал!!! Мы же здесь не в гадалку собрались играть. (Заметьте, я никому минусы не ставлю, и стараюсь ответить максимально развернуто..)
Вы очевидно путаете контейнеры и Docker :)
Контейнеры в практическом смысле тоже самое что виртуальные машины.
Докер — очень своеобразная штука. Докер использует контейнеры, но можно сказать выворачивает «идею» наизнанку…
Короче в сети есть мнение что docker = container. Это не так! Возможно я сделаю об этом отдельную статью.
Контейнеры = виртуальные машины (если не брать во внимание «иллюзию» изоляции)
Как это не печально, докер сдел так, что когда люди слышат слово «контейнер», они думают «докер». Черт возьми, как сильно они ошибаются!
Почитайте как работают Linux Container (LXC) или FreeBSD jails! Мне очень повезло, я познакомился с Jails во FreeBSD еще до того как появился Docker и начал засирать мозги специалистам.
То, о чем вы говорите, это уже репликация (репликацию можно сделать в другую файловую систему, в файл, или на удаленную площадку).
С точки зрения практической ценности, описанное в статье можно называть клоном, который мы можем использовать в разработке и тестировании.
Главное преимущество описано: не нагружает сервер и не занимает время.
Я показал как можно использовать превосходную технологию. Вам решать когда и где :)
Если у вас неприятность на проде, бакап делать уже поздно.
В том то и дело, что не поздно. На проде делаются моментальные снимки каждый час по крону. Эти же снимки затем отправляются на бэкап ассинхронно.
То есть ZFS дает нам возможность версионирования прода. Мы делаем клон с любого удобного снимка. То есть у нас так и так все карты на руках.
Отчасти вы конечно же правы. Но вы снова забываете о контексте. Нельзя бездумно перенимать чужой опыт. Как я уже говорил, наш проект для внутренних нужд. Там нет персональных данных. Кроме того им занимается, внимание — 1 senior Fullstack .net программист, который является нашим сотрудником, работает fulltime. У него и так есть доступ ко многим вещам.
И да, порой тесты и разработка гораздо эффективнее, когда работа идет с реальным данными.
Обычно dev/test разворачивают с бэкапа. (вы же их делаете?) Для разработки отставание клона в день-два не существенно.
На самом деле последнее время так и происходит.
Цепочка реплик выглядит так:
Prod Server -> Backup Server (удаленная площадка) -> Hyper-V VM на ноутбуке разработчика
Но зачастую держать отдельную машину для тестирования и разработки не имеет смысла. Например базы для тестирования мы получаем именно описанным мною в статье способом!
Не забудьте, что база должна жить рядом с приложением! Если между ними будет высокий Latancy, будет худо.
То есть я хочу сказать, простую вещь. Реплики то мы делаем, но на той стороне некому запустить базу и приложение, на это нужны громадные ресурсы, которыми не обладает наш Backup Server.
Не исключаю, что VNC в игровых сценариях может работать лучше… Но я все равно остался крайне доволен. Старый и новый RDP — земля и небо. Поверьте. К тому же все шрифты и текст теперь пиксель-в-пиксель. Ничего не раздражает глаз. Реакция на нажатие в Word\Excel моментальная.
Кстати, небольшой офтоп. Во время сравнения шрифтов и текста, я отчетливо понял, что мой 27 дюймовый IPS монитор от Acer несравненно хуже монитора жены. Dell Ultrasharp.
Косые линии в SketchUp имеют на моем мониторе какую то рябь или стробицу.
Думали, что проблема в RDP, оказалось в мониторе! Заказал себе новый монитор в магазине.
Версия Windows10, где установлен RDP сервер должна быть самой свежей 1709. Посмотреть версию Windows можно при помощи winver (пуск — выполнить — winver)
Кстати, забыл указать в статье, я пробовал клиент RDP из магазина Windows Store и к моему великому удивлению AVC444 кодек не запустился. RDP работало со старыми добрыми тормозами. Хотя я думаю, что если форсировать новый кодек на сервере, то все заработает.
Принудительное включение кодека и его настройки можно выполнить через групповые политики.
Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment
Подробности здесь
Думаю с появлением h264 у MS была дилемма, оставить как было, или использовать новый на тот момент «быстрый» кодек в ущерб качеству. Теперь такой дилеммы не стоит.
Возрадуемся!
В любом случае, результат достойный.
Не важно заслуга ли это кодека или чего то другого. Это работает!
Посмотрите первое видео из моей статьи и вы увидите, что в среднем на FullHD ролике, развернутом на весь экран, новый кодек требует в 2 раза меньшую полосу пропускания и работает существенно быстрее и четче.
В сценариях повседневного использования разница между старым и новым кодеком будет в среднем еще выше! По моим прикидкам экономия полосы 60-80%
cloudblogs.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview
«As part of the AVC 444 mode in RDP 10 we solved the challenge to get 4:4:4 quality text with 4:2:0 hardware encoders / decoders. In addition, with the AVC 444 mode we were able to improve the frame throughput significantly, for example with 1440p we can achieve a consistent frame rates of up to 50 fps on standard hardware.»
Так, что вы правы, не все так просто, и вероятно они решили попутно некоторое количество технических ребусов.
habrastorage.org/webt/ty/m9/_r/tym9_rymm41f3y6l7izvxiwaftc.png
hsto.org/webt/hc/vx/t-/hcvxt-dxwpcafqjv8buqo95gkuu.png
Дело в том, что RDP получает в свое распоряжение видеокарту хоста. Доступно вся мощь, я проверял, но есть одно «но». Некоторые программы очевидно просто не желают запускаться в RDP режиме.
Запустить SketchUp в RDP я не смог! Мне пришлось запустить его в консольном сеансе, затем подключиться по RDP ^)
В чем проблема базы в контейнере? Ничего, кроме красоты нечеловеческой и гибкости мы не заметили… Напомню, это рабочий проект
«Всегда считал, что данные не должны находиться в контейнерах.» Ну так напиши почему ты так считал!!! Мы же здесь не в гадалку собрались играть. (Заметьте, я никому минусы не ставлю, и стараюсь ответить максимально развернуто..)
Контейнеры в практическом смысле тоже самое что виртуальные машины.
Докер — очень своеобразная штука. Докер использует контейнеры, но можно сказать выворачивает «идею» наизнанку…
Короче в сети есть мнение что docker = container. Это не так! Возможно я сделаю об этом отдельную статью.
Контейнеры = виртуальные машины (если не брать во внимание «иллюзию» изоляции)
Как это не печально, докер сдел так, что когда люди слышат слово «контейнер», они думают «докер». Черт возьми, как сильно они ошибаются!
Почитайте как работают Linux Container (LXC) или FreeBSD jails! Мне очень повезло, я познакомился с Jails во FreeBSD еще до того как появился Docker и начал засирать мозги специалистам.
С точки зрения практической ценности, описанное в статье можно называть клоном, который мы можем использовать в разработке и тестировании.
Главное преимущество описано: не нагружает сервер и не занимает время.
Я показал как можно использовать превосходную технологию. Вам решать когда и где :)
В том то и дело, что не поздно. На проде делаются моментальные снимки каждый час по крону. Эти же снимки затем отправляются на бэкап ассинхронно.
То есть ZFS дает нам возможность версионирования прода. Мы делаем клон с любого удобного снимка. То есть у нас так и так все карты на руках.
И да, порой тесты и разработка гораздо эффективнее, когда работа идет с реальным данными.
На самом деле последнее время так и происходит.
Цепочка реплик выглядит так:
Prod Server -> Backup Server (удаленная площадка) -> Hyper-V VM на ноутбуке разработчика
Но зачастую держать отдельную машину для тестирования и разработки не имеет смысла. Например базы для тестирования мы получаем именно описанным мною в статье способом!
Не забудьте, что база должна жить рядом с приложением! Если между ними будет высокий Latancy, будет худо.
То есть я хочу сказать, простую вещь. Реплики то мы делаем, но на той стороне некому запустить базу и приложение, на это нужны громадные ресурсы, которыми не обладает наш Backup Server.