Comments 45
1) Я что-то не понял пассажа про «тонкие клиенты» и 3D.
2) В зене это сто лет назад было. В openVZ тоже. Hyper-V в очередной раз с триумфом лидирует на рынке, только-только сделав то, что у конкурентов даже как фича не анонсируется, а так, штатная функциональность?
2) В зене это сто лет назад было. В openVZ тоже. Hyper-V в очередной раз с триумфом лидирует на рынке, только-только сделав то, что у конкурентов даже как фича не анонсируется, а так, штатная функциональность?
1) Я что-то не понял пассажа про «тонкие клиенты» и 3D.
Это технология, позволяющая использовать фичи «супермегатридэшной видяхи» внутри виртуальной машины. Вплоть до того, что пользователь сможет запустить какой-нибудь Crysis внутри своей виртуалки и играть в него удаленно со своего старенького компа, не имеющего видеокарты с поддержкой всяких там шейдеров и анизотропных фильтраций, главное — чтобы таковая была на сервере. К работе с памятью, разумеется, это никакого отношения не имеет, про Remote FX было упомянуто в контексте новых фич SP1.
2) В зене это сто лет назад было. В openVZ тоже. Hyper-V в очередной раз с триумфом лидирует на рынке, только-только сделав то, что у конкурентов даже как фича не анонсируется, а так, штатная функциональность?
Да было, не было, я что, спорю? Я не ставлю цели как-то «пиарить» Hyper-V перед конкурентами. Я ставлю цель рассказать о технологиях работы с памятью.
1) PCI passthrough — технологии сто лет в обед. Я ещё года 4 назад видел это у vmware, сколько я вожусь с xen'ом, у него это было. А вопрос был в другом: при чём тут «тонкие клиенты»? Оно по RDP играть будет?
Вопрос: а две виртуалки слабо с одной видяхой сделать? Это было бы круто. Например, развести виртуалки по головам.
Вопрос: а две виртуалки слабо с одной видяхой сделать? Это было бы круто. Например, развести виртуалки по головам.
Ну ты бы не поленился и потратил 20 секунд на гугление.
blogs.technet.com/virtualization/archive/2010/03/18/Explaining-Microsoft-RemoteFX.aspx
PCI там и рядом не лежал. В данный момент конкуренты технологии — это VMware View и Citrix HDX (мог ошибиться в названии).
blogs.technet.com/virtualization/archive/2010/03/18/Explaining-Microsoft-RemoteFX.aspx
PCI там и рядом не лежал. В данный момент конкуренты технологии — это VMware View и Citrix HDX (мог ошибиться в названии).
VM Direct Path I/O появился только в vSphere 4.0, т.е. чуть более года назад.
В отличии от существующих решений (VMware PCoIP, Citrix HDX) Microsoft планирует аппаратно ускорять графику за счет ресурсов видеокарт
Плюсы от RemoteFX — снижение нагрузки на CPU за счет использования GPU. Лучший user-experience за счет возможности смотреть HD Video, Flash, 3d удаленно с приемлимым битрейтом (но, естественно, на достаточно толстых каналах).
В отличии от существующих решений (VMware PCoIP, Citrix HDX) Microsoft планирует аппаратно ускорять графику за счет ресурсов видеокарт
Плюсы от RemoteFX — снижение нагрузки на CPU за счет использования GPU. Лучший user-experience за счет возможности смотреть HD Video, Flash, 3d удаленно с приемлимым битрейтом (но, естественно, на достаточно толстых каналах).
Либо я нихрена не понимаю, либо вы говорите малосвязные отрывки из маркетингового текста.
Вопрос: что передаётся с севера клиентам? OpenGL? Или пререндеренная на сервере картинка?
Если передаётся OpenGl, то что именно ускоряется на сервере с помощью GPU? Если передаётся пререндеренная картинка, то где вы такую сетку найдёте?
Насчёт DirectPath I/O в vSphere не скажу, но я 4 года назад видел opengl в vmware workstation.
Вопрос: что передаётся с севера клиентам? OpenGL? Или пререндеренная на сервере картинка?
Если передаётся OpenGl, то что именно ускоряется на сервере с помощью GPU? Если передаётся пререндеренная картинка, то где вы такую сетку найдёте?
Насчёт DirectPath I/O в vSphere не скажу, но я 4 года назад видел opengl в vmware workstation.
Я думаю речь всё-таки не о играх, а о том, что можно рендерить 3d сцены в большом количестве и отдавать клиентам, но при рендеринге можно использовать GPU, а не soft-рендеринг осуществлять, что даёт снижение нагрузки на CPU. Вряд ли имелось в виду удалённо играть в 3D игры :)
Я вас совершенно не понимаю. Итак, есть приложение, которое хочет нарисовать 300000 треугольников на экране с освещением, текстурой и прочими фенечками.
Вариант
1) Данные об этом передаются на клиента. Клиент должен уметь это быстро показать, плюс, передача текстур — не такая уж компактная задача для сети.
2) Картинка рисуется локально и отсылается на тонкий клиент как видео. Сеть опять в ауте, плюс сервер должен каким-то образом это рисовать в памяти.
Собственно, всё. Какой из вариантов этот самый 'FX'? Если 1 — то мощное видео на сервере нафиг не сдалось. Если 2 — то я не верю, что это можно показать в реальном времени в существующих сетях в нормальном разрешении.
Вариант
1) Данные об этом передаются на клиента. Клиент должен уметь это быстро показать, плюс, передача текстур — не такая уж компактная задача для сети.
2) Картинка рисуется локально и отсылается на тонкий клиент как видео. Сеть опять в ауте, плюс сервер должен каким-то образом это рисовать в памяти.
Собственно, всё. Какой из вариантов этот самый 'FX'? Если 1 — то мощное видео на сервере нафиг не сдалось. Если 2 — то я не верю, что это можно показать в реальном времени в существующих сетях в нормальном разрешении.
Если оперировать вашими понятиями — пререндеренная картинка. По поводу толщины каналов рекомендую ознакомиться с материалами Geek Week VDI Day, где VDI решения от разных вендоров сравнивались на каналах разной толщины.
Мне бы циферки. Потому что последнее, что я видел в RDP при передаче массивного изображения вызывало уныние.
50fps при 1920х1200 у 30 клиентов… Сколько у нас там 100G адаптер стоит?
50fps при 1920х1200 у 30 клиентов… Сколько у нас там 100G адаптер стоит?
amarao, вы перегибаете.
Microsoft, как и другие вендоры не виноваты, что отделу видеомонтажа в вашей организации захотелось пересесть на тонкие клиенты и вряд ли сумеет помочь в ближайшие 2-3 года.
Microsoft, как и другие вендоры не виноваты, что отделу видеомонтажа в вашей организации захотелось пересесть на тонкие клиенты и вряд ли сумеет помочь в ближайшие 2-3 года.
Я не перегибаю, я пытаюсь понять суть технологии. А это граничное условие.
Пока, всё что я выяснил, что сервер будет делать пререндеринг изображения с использованием GPU и отдавать его как растр клиенту. Что вызовет просто феерический оверхед по трафику.
Пока, всё что я выяснил, что сервер будет делать пререндеринг изображения с использованием GPU и отдавать его как растр клиенту. Что вызовет просто феерический оверхед по трафику.
судя по всему это надстройка над рдп, с очередным алгоритмом компрессии изображения (более? эффективным?). Т.е. рендеринг происходит на стороне сервера,? эффективно? жмется, бьется и отдается клиенту, клиент должен произвести декомпрессию и сборку изображения, т.е если вы запустите кризис то понадобится очень мощный проц на стороне клиента, и очень жирный и быстрый канал между фермой и ТК.
В общем аналог pcoip который используется в vmware view, вот только вмваре еще может использовать карты теродичи, для ремотфх судя по всему хард расширения нет.
В общем аналог pcoip который используется в vmware view, вот только вмваре еще может использовать карты теродичи, для ремотфх судя по всему хард расширения нет.
кстати кому интересно это технологии компании Calista, гугл расскажет более подробно. Вто несколько ссылок
searchservervirtualization.techtarget.com/news/article/0,289142,sid94_gci1295515,00.html
blogs.technet.com/virtualization/archive/2008/01/21/Calista-joins-the-Microsoft-virtualization-product-lineup.aspx
blogs.technet.com/virtualization/archive/2010/03/18/Explaining-Microsoft-RemoteFX.aspx
требования я к клиенту которые были у калисты до покупки
*************************************************
System Requirements
The minimum requirements for the host running the Calista Virtual Desktop software are: Microsoft Windows Vista x86 Premium Edition such as Windows Vista Ultimate, Windows Vista Enterprise or Windows Vista Business, and hardware required to run these operating environments and the Windows Aero (Glass) user interface including:
1 GHz (32-bit) x86 processor
1 GB of system memory
Support for DirectX 9 graphics with a WDDM driver, 128 MB of graphics memory (minimum), Pixel Shader 2.0 and 32 bits per pixel
Client requirements: Any RDP 5.x compatible thin or fat client.
searchservervirtualization.techtarget.com/news/article/0,289142,sid94_gci1295515,00.html
blogs.technet.com/virtualization/archive/2008/01/21/Calista-joins-the-Microsoft-virtualization-product-lineup.aspx
blogs.technet.com/virtualization/archive/2010/03/18/Explaining-Microsoft-RemoteFX.aspx
требования я к клиенту которые были у калисты до покупки
*************************************************
System Requirements
The minimum requirements for the host running the Calista Virtual Desktop software are: Microsoft Windows Vista x86 Premium Edition such as Windows Vista Ultimate, Windows Vista Enterprise or Windows Vista Business, and hardware required to run these operating environments and the Windows Aero (Glass) user interface including:
1 GHz (32-bit) x86 processor
1 GB of system memory
Support for DirectX 9 graphics with a WDDM driver, 128 MB of graphics memory (minimum), Pixel Shader 2.0 and 32 bits per pixel
Client requirements: Any RDP 5.x compatible thin or fat client.
Ну, HP давно выпускало свой экстендер для RDP, который жмёт. Но я смотрел — феерическое «г». На том качестве сжатия, которое терпимо, оно выжирает больше 80Мбит на ютубе.
ну каталиста вроде говорила, что на клиента нужен канал 1м, хотя что-то мне подсказывает, что это в минимуме ;)
Кстати, а какая теоретически пропускная способность необходима для передачи FullHD при существующих алгоритмах компрессии? И какой процессор должен иметься на стороне клиента для декомпрессии такого потока?
Ну, если вы возьмём фиговенькое FHD, то это примерно 1.2 Gb на час (я про видео). Соответственно, поток составит 2.5 мегабита для 25 кадров (и около 3-5 для 50).
Заметим, это всё надо ещё ходить/раскодировать в реальном времени, плюс, в отличие от h264, в условиях интерактива, особо P/I кадрами не побалуешься, и буфера в пару секунд не сделаешь.
Моё предположение: не меньше 20-30 мегабит.
Заметим, это всё надо ещё ходить/раскодировать в реальном времени, плюс, в отличие от h264, в условиях интерактива, особо P/I кадрами не побалуешься, и буфера в пару секунд не сделаешь.
Моё предположение: не меньше 20-30 мегабит.
То есть, даже на 100-мегабитной сетке вполне реализуемо, не говоря уж о гигабитке и тем более — десятигигабитке?
Значит, самым узким местом будет не сеть, а процессор на стороне клиента. В принципе, если речь идет о тонких клиентах — можно будет попытаться реализовать кодек аппаратно…
Значит, самым узким местом будет не сеть, а процессор на стороне клиента. В принципе, если речь идет о тонких клиентах — можно будет попытаться реализовать кодек аппаратно…
Ну, HP'шный кодек (они, кажись, mjpg использовали) на минимуме да, ел не сильно больше обычного RDP. Но тут была проблемка — текст интерфейса был не читаем (да, они жали картинку целиком, включая GDI'ную часть).
Если MS научится жать только не-GDI часть (т.е. GDI будет передаваться as is), то, возможно, это будет терпимо. Но играть на этом всё равно не получится, потому что приличное разрешение в нормальном FPS занимает МНОГО.
Если MS научится жать только не-GDI часть (т.е. GDI будет передаваться as is), то, возможно, это будет терпимо. Но играть на этом всё равно не получится, потому что приличное разрешение в нормальном FPS занимает МНОГО.
В анонсе они в числе всего прочего упоминали не только HD-видео, но и 3D-приложения и игры. Правда, насколько у них это выдет — надо будет посмотреть.
Что же до отсутствия железок — думается, что как только технология выйдет в свет — NVidia и AMD-ATI быстро подтянутся.
Что же до отсутствия железок — думается, что как только технология выйдет в свет — NVidia и AMD-ATI быстро подтянутся.
Меня беспокоит следующее:
1) Железо потребуется как с серверной стороны, так и с клиентской.
2) Если видяха нормально обсчитывает одного человека, это не означает, что она адекватно сумеет обсчитать аэро или, что там МС собирается рисовать, для 100+ человек терминального сервера.
3) Ни nvidia ни ati не делали ранее серверных видеокарт (насколько я знаю). А в серверах чуть иные требования по надёжности и конструктиву.
1) Железо потребуется как с серверной стороны, так и с клиентской.
2) Если видяха нормально обсчитывает одного человека, это не означает, что она адекватно сумеет обсчитать аэро или, что там МС собирается рисовать, для 100+ человек терминального сервера.
3) Ни nvidia ни ati не делали ранее серверных видеокарт (насколько я знаю). А в серверах чуть иные требования по надёжности и конструктиву.
1) С клиентской стороны потребуется только чуть более мощный CPU, GPU будет на сервере.
В принципе с HD Video худо-бедно справляются даже атомы.
2,3) Да, понадобятся очень мощные видеокарты, но в принципе, используя всякие SLI/Crossfire — желаемую производительность вполне можно получить. Да и наверняка и nvidia и ati выпустят видеокарты специально для таких целей — как только будет спрос. А спрос должен быть — иначе бы RemoteFX просто не разрабатывали бы.
В принципе с HD Video худо-бедно справляются даже атомы.
2,3) Да, понадобятся очень мощные видеокарты, но в принципе, используя всякие SLI/Crossfire — желаемую производительность вполне можно получить. Да и наверняка и nvidia и ati выпустят видеокарты специально для таких целей — как только будет спрос. А спрос должен быть — иначе бы RemoteFX просто не разрабатывали бы.
Во-первых, не «чуть». Атомы в тонких клиентах — достаточно большая редкость; часто ТК делаются на чём-то класса Vortex86sx, который ну совсем не FullHD capable (200-400МГц c производительностью 486).
Во-вторых, я, как виндовый админ, злобно негодую от мысли, что теперь мой сервер будет зависеть не только от прямоты рук разработчиков дров для принтера, но ещё и от степени идиотизма индусов из nvidia.
Во-вторых, я, как виндовый админ, злобно негодую от мысли, что теперь мой сервер будет зависеть не только от прямоты рук разработчиков дров для принтера, но ещё и от степени идиотизма индусов из nvidia.
Атомы в тонких клиентах — достаточно большая редкость
Ну, сейчас полным-полно неттопов а-ля EeeBox. Иного применения неттопам, кроме как в качестве ТК — я не вижу.
Во-вторых, я, как виндовый админ, злобно негодую от мысли, что теперь мой сервер будет зависеть не только от прямоты рук разработчиков дров для принтера, но ещё и от степени идиотизма индусов из nvidia.
Сервер? От драйверов принтера? Выкиньте уже эти гадкие Canon LBP! :))) Думаю, что все же Nvidia и ATI не настолько криворуки. Кстати недалече чем седня видел, что они набирают девелоперов в российское представительство.
М… неттоп примерно в два раза минимум (а то и в три) дороже тонкого клиента (цены на которые начинаются от 4-5т.р., включая софт и лицензию на CE). Т.е. фактор сугубо экономический, не то, что атомы никто не любит.
Сервер от драйверов принтера страдает. Даже не от Canon. Некоторые HP'ные драйвера приводят к страшным лагам при первом запуске первым пользователем после загрузки. До такой степени, что perfmon в этот момент «теряет» примерно 10-15 тиков статистики.
А насколько «некривые» драйвера у nvidia и ati, лучше не будем, ок?
Сервер от драйверов принтера страдает. Даже не от Canon. Некоторые HP'ные драйвера приводят к страшным лагам при первом запуске первым пользователем после загрузки. До такой степени, что perfmon в этот момент «теряет» примерно 10-15 тиков статистики.
А насколько «некривые» драйвера у nvidia и ati, лучше не будем, ок?
RDP-клиент они тоже обещают обновить, как раз для работы с RemoteFX. Возможно, что придумают какие-то хитровыдуманные алгоритмы сжатия, или еще что-то…
В любом случае технических подробностей я пока не знаю, посмотрим, как выйдет SP1.
В любом случае технических подробностей я пока не знаю, посмотрим, как выйдет SP1.
1) PCI passthrough — технологии сто лет в обед. Я ещё года 4 назад видел это у vmware, сколько я вожусь с xen'ом, у него это было.
Remote FX — это не тупой «проброс» устройства. Это именно использование внутри виртуалки функций 3D-видеокарты. Опять же — причем тут «было-не было»?
А вопрос был в другом: при чём тут «тонкие клиенты»? Оно по RDP играть будет?
Мне, к сожалению, на практике не доводилось еще разворачивать инфраструктуру VDI на Hyper-V, но ЕМНИП, удаленный доступ к клиентским виртуалкам там осуществляется именно по RDP.
Вопрос: а две виртуалки слабо с одной видяхой сделать? Это было бы круто. Например, развести виртуалки по головам.
Если я правильно понял — то она позволит использовать функции «железной» видеокарты на нескольких виртуалках, лишь бы хватало ресурсов этой самой видеокарты. Как только более-менее подробно разберусь с технологией — обещаю написать статью, так что обсуждение Remote FX предлагаю до поры до времени отложить.
У меня пока ощущение страшной каши.
1) Если мы прокидываем open GL, то майкрософту придётся изобрести для себя X-сервер. opengl на экране всё равно будет рисовать ТК, и нафига тогда акселерация в виртуалке?
2) Если мы прокидываем opengl в виртуалку, то клиент не сможет его увидеть, если его адаптер не показывает opengl.
1) Если мы прокидываем open GL, то майкрософту придётся изобрести для себя X-сервер. opengl на экране всё равно будет рисовать ТК, и нафига тогда акселерация в виртуалке?
2) Если мы прокидываем opengl в виртуалку, то клиент не сможет его увидеть, если его адаптер не показывает opengl.
Большой стимул заглянуть под кат и углубиться в чтение была замануха Remote FX — жду про неё подробностей
Они предоставляют доступ в интернет на скорости «до 8 Мбит/с», по факту же скорость скорее всего будет колебаться в районе 4-6Мбит/с из-за того, что канал на аплинк у провайдера чуть уже, чем 8Мбит, помноженное на число его абонентов. Тем не менее, при определенных фазах Луны, в полночь, когда Меркурий находится в знаке Водолея и свои любимые видеоролики в интернете никто кроме вас не просматривает – скорость вполне может достичь обещанных 8 Мбит.
Неправильно. Ситуация, когда все пользователи одновременно начинают полностью утилизировать выделенную им полосу, крайне маловероятна. Поэтому, если провайдер покупает 50% от требуемой максимальной полосы и интернетами пользуются 50% пользователей, то скорость у каждого будет как раз на обещанном уровне.
В своём примере Вы делаете неверный вывод, что мультиплексирование обеспечивается за счёт урезания чего-то в чём-то. Это не так. Мультиплексирование обеспечивается за счёт использования теории вероятностей. Вероятность того, что все одновременно начнут что-то качать, сравнима с тем, что все одновременно откроют краны или включат электроприборы. Во всех случаях ресурса — канала, воды или тока — будет недостаточно, но такая ситуация нестандартна и маловероятна.
Учитывая популярность в последнее время всевозможных p2p-приложений а-ля торренты — вероятность, что все несколько тысяч пользователей забьют все свои 8 Мбит одновременно — достаточно высока. Именно поэтому некоторые провайдеры (такие, к примеру, как yota) закупают даже специальное оборудование с единственной целью — зарезать полосу для торрентов.
Разумеется, всё сильно зависит от профиля трафика. По нашему опыту расширение пользовательских полос улучшает ситуацию. Достаточно широкие полосы уменьшают время закачки видео, например. А время, нужное на его просмотр, остаётся прежним. Постоянно нагружают торрентоводы только исходящий канал. Таким образом, при прочих равных условиях куда лучше купить 100 мегабит и продать 300, чем купить 10 и продать 30.
А большинство пользователей знать не знает, что такое торренты — они покупают широкие полосы ради вконтактов и мейл.ру.
А большинство пользователей знать не знает, что такое торренты — они покупают широкие полосы ради вконтактов и мейл.ру.
Если бы все было так классно — провайдеры бы не шейпили трафик и не тратили бы сумасшедшие бабки на ПО и даже на железо для «обрезания» торрентов.
Когда-то у НАГа проскакивала статья про оверселлинг у провайдеров, где его сравнивали с финансовым кризисом.
Когда-то у НАГа проскакивала статья про оверселлинг у провайдеров, где его сравнивали с финансовым кризисом.
Повторюсь — всё зависит от профиля трафика. У кого-то торрентотрафика меньше, у кого-то больше. И от жадности провайдеров — кто-то по доброте душевной не режет ничего, кто-то режет только мюТП в силу его природы, близкой к вирусной. А кто-то режет всё подряд, что, разумеется, ненормально.
Главное, что я хочу сказать — что мультиплексирование осуществляется не за счёт откусывания кусочков канала у тех, кто за этот канал деньги заплатил, а за счёт использования вероятностных характеристик поведения пользователя.
Что до урезания, то на этом вопросе сломаны тысячи копий. Нужно ли резать пользовательский спам на 25 порт, нужно ли резать NBT/SMB порты на шлюзах, нужно ли резать тот же мюТП — это всё темы для отдельных длинных холиваров.
Главное, что я хочу сказать — что мультиплексирование осуществляется не за счёт откусывания кусочков канала у тех, кто за этот канал деньги заплатил, а за счёт использования вероятностных характеристик поведения пользователя.
Что до урезания, то на этом вопросе сломаны тысячи копий. Нужно ли резать пользовательский спам на 25 порт, нужно ли резать NBT/SMB порты на шлюзах, нужно ли резать тот же мюТП — это всё темы для отдельных длинных холиваров.
UFO just landed and posted this here
Как я уже писал выше, всё очень сильно зависит от профиля трафика и масштабов. На малой абонентской базе и 50% будут прекрасно видны. А с ростом количества абонентов можно мультиплексировать сильнее. Например, сейчас в провайдере, который я администрирую, этот коэффициент составляет 1:5, т.е. 20%.
Коэффициент мультиплексирования в 50-100 невозможен. Можно продать гигабит, купив 200 мегабит. Но продать гигабит, купив 10-20 мегабит, нельзя.
В описанном Вами случае работают другие механизмы, пиринг, например. Для абонента нет разницы между ресурсами, подключенными через дорогие узкие заграничные каналы или через дешёвые широкие каналы до ближайшей точки обмена трафиком. А для провайдера разница в цене этих ресурсов огромная. Поэтому можно нести потери на продаже одного ресурса ниже себестоимости, возмещая её на продаже другого, доставшегося дёшево. Как бы то ни было, к мультиплексированию это уже не имеет отношения, это совсем другой механизм.
Коэффициент мультиплексирования в 50-100 невозможен. Можно продать гигабит, купив 200 мегабит. Но продать гигабит, купив 10-20 мегабит, нельзя.
В описанном Вами случае работают другие механизмы, пиринг, например. Для абонента нет разницы между ресурсами, подключенными через дорогие узкие заграничные каналы или через дешёвые широкие каналы до ближайшей точки обмена трафиком. А для провайдера разница в цене этих ресурсов огромная. Поэтому можно нести потери на продаже одного ресурса ниже себестоимости, возмещая её на продаже другого, доставшегося дёшево. Как бы то ни было, к мультиплексированию это уже не имеет отношения, это совсем другой механизм.
Sign up to leave a comment.
Реальная виртуальность, или «640 килобайт памяти хватит всем»