> Вы серьезно так думаете? С учетом того что мне приходилось сталкиваться с задачей "CAD-решение на VDI, на блейдах разумеется, на не одну сотню рыл." По сравнению со стоимостью TeamCenter+NX - копейки :)

Я серьезно так думаю, потому что теории в п. 1,2,3 вами предполагается "решение" вопросов затупа, задержек итд., которое не соответствует реальности.

В реальности то подмножество приложений, которым не нужна графика, но нужна доставка проще переписать, на веб-формы с REST API, чем городить терминальное решение, если количество пользователей выше 200 сотрудников. И так уже давно.

Растровые и 3D приложения требуют корректного развертывания. Современный VDI тюнится только под видео-вариант. Все пиринговые сети переносятся на тонкого клиента, по мере возможности в то время как приложения продолжают рисоваться на серверной стороне. Большинство приложений прекрасно вытерпят лаг в 40 мс round trip time. Дальше лаг зависит от сети. Нужно бороться с перегрузкой и джиттером.

Вы же понимаете что весь этот лаг берётся на коммутаторах и надо выяснять почему он возникает, правда же?
То что под VDI вам нужно реализовать Diffserv Assured Forwarding? И то что вам нужно разговаривать с провайдерами о проблемах на внешних отрезках сети?

> Да-да, начиная с 10GbE - штатно.

Хммм... не понимаете. Что такое "штатное RDMA"? Их 2 протокола, которые не совместимы друг с другом от разных вендоров. Наличие 10GbE порта не даёт вам возможность делать оффлоадинг CPU, нужна поддержка конкретного протокола и в вашем кластере в рамках проекта он у вас может быть только 1. Есть сетевки с обоими протоколами, а есть вообще не поддерживающие RDMA.

И с коммутаторами проблема... наличие возможности его применять на сетевке не даёт вам рабочее решение. У вас либо потери на сети, во время перегрузки (RoCEv2) или чудовищные провалы по задержкам (iWARP) вы либо заплели себе косы на коммутаторе под это, либо они у вас ничего не делают, или делают хуже. А коммутатор должен уметь это всё. Или может поддержка RDMA на коммутаторах у вас там штатная? Ха-ха-ха. Опыт с RDMA вне барахла от Intel был? Как деплоить знаем? А если знаем, чего так тупим?

Далее, выгода RDMA заметна там, где есть перегрузка по CPU. Оно даже с QoS-ами вам не сделает магически низкую задержку. А вот избавление от Ethernet в сторону IB улучшит... в рамках IB-сети.

Вы уже сейчас можете написать свое приложение которое пользуется RDMA поверх losless-фабрики, поможет ли вам это или нет зависит от сетевой топологии. Есть уже готовые решения от nvidia по вопросы применения RDMA в кластерах с их картами для машинного обучения и там цена как раз сравнима со стоимостью отраслевых решений.

Ну и самое главное... что вы собрались делать с Pause-фреймами в офисной/кампус сети?
RDMA применяется для важных данных, в частности для стораджей. Как работает Ethernet PFC, и что вы будете делать в офисной сети с портами на паузе? Про MTU я уже писал.

Вывод наличие RDMA именно на передаче буферов по терминальным соединениям не применимо даже в локальной сети. Только в рамках кластера виртуализации/терминалов. Не понятно только что там этот кластер тогда делает... зачем он сам себе свои приложения показывает... Ну на шлюзы свои во внешку разве что передаёт.