Как устранить проблему

[Отрисовка]

Доброй ночи!
Есть проблем.а с отрисовкой изображения на больших разрешения по РДП. Условно сейчас в основном мы используем Фул ХД. Есть терминальный сервер, к нему подключаются по каналу ИПсек пользователи. Сам по себе пинг не большой в среднем 5 мс бывает чуток больше, изредко! Само по себе все по РДП отпимизирвал. Убрал картинки к примеру, перешли на 16 бит цвета и т.д.. Но все ровно бывает откроет чел ПДФ. Фигня не приятно, бывает и ексель тяжело смотреть. Вообщем с разных сторон подходил, но все ровно не могу добитсья того, результата, которого мне хотелась. Вызывает пока, что дискомфорт у пользователей. У кого есть опыт потимизации работы терминалок ВТВАРЕ и ОС Windows под большие разрешения. Может видедрайвер лучше использоват какие Ф или У? или же где ОС покрутить?

[aka]

Привези терминал в одну сеть с сервером, чтоб между ними не было никаких каналов ИПсек. Посмотри, как оно работает. Будет "дискомфорт"?

[Antonio]

Либо наоборот, что будет на том же канале, но просто через RDP, без туннеля?

[alexandro]

Пробовали не очень как то! Может кто тюнингует по своему ОС? кто поделиться опытом

[Antonio]

Пробовали -- это замечательно! А что именно пробовали?

У меня лично FullHD-разрешения отрисовываются совершенно нормально на древнем железе. Без всякой "потимизации".

Запустите мастер настройки втвари ("Del" при загрузке). Там есть тест, по результату которого будет выдана некая цифра в "попугаях". Сделайте этот тест для всех драйверов, которые предложит втварь, и огласите цифры.

[alexandro]

. Группа ключей: "Локальный компьютер - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Узел сеансов удаленных рабочих столов - Среда удаленных сеансов".

Ключи:

1.1 "Наибольшая глубина цвета" - значение: Включено, "15 бит";
1.2 "Принудительная отмена фонового рисунка удаленного рабочего стола" - значение: Включено;
1.3 "Ограничить максимально количество мониторов" - значение: Включено, "1";
1.4 "Задание алгоритма сжатия для данных RDP" - значение: Включено, "Оптимизация использования полосы пропускания сети";
1.5 "Оптимизировать визуальные эффекты для сеансов служб удаленных рабочих столов" - значение: Включено, "Текст";
1.6 "Разрешить композицию рабочего стола для сеансов служб удаленных рабочих столов" - значение: Отключено;
1.7 "Не разрешать сглаживание шрифтов" - значение: Включено.
2. Группа ключей: "Локальный компьютер - Административные шаблоны - Компоненты Windows - Диспетчер окон рабочего стола".

Ключи:
2.1 "Не разрешать анимацию окон" - значение: Включено;
2.2 "Не разрешать композицию рабочего стола" - значение: Включено;
2.3 "Не разрешать вызов Flip3D" - значение: Включено.

Так же настройки сетевые:
netsh interface tcp set global rss=enabled — состояние маштабирования на стороне приема
netsh interface tcp set global chimney=enabled — Состояние разгрузки канала
netsh interface tcp set global netdma=enable — Состояние NetDMA
netsh interface tcp set global dca=disable — Прямой доступ к кэшу DCA
netsh interface tcp set global autotuninglevel=normal — Уровень автонастройки окна получения
netsh interface tcp set global congestionprovider=ctcp — Поставщик надстройки контроля перегрузки
netsh interface tcp set global ecncapability=disabled — Мощность ECN
netsh interface tcp set global timestamps=enabled — Отметка времени RFC 1323

Что касается теста, то я видел тест скорости РДП в конфигураторе
И еще REMOTEFX тут не поможет?

[aka]

RemoteFX не взлетит после того, как указано "Наибольшая глубина цвета" - значение: Включено, "15 бит". Подозреваю, что остальное делалось с такой же глубиной понимания.

[Antonio]

alexandro, сделайте хоть что-то из того, что вам сказали, и сообщите результаты. Пока что вы, судя по всему, занимаетесь ерундой.

[alexandro]

Интересно, я вообще то ответил на вопрос, что делал! Про remotefx вообще то не включал. И тем более 15 бит. Вы какие то странные выводы сделали. Я только про него спросил поможет он или нет? И надо учесть, что проблема с удаленным офисом. Что каксается надо или нет оптимизировать. ТО сами попробуйте картинки или пдф открыть удаленно.

[alexandro]

Вот как раз значение, может и ерунда для вас гуру.. Это при remotefx естественно 32 бита. По другому не извращался.

[Antonio]

Не знаю внутренней механики теста, но в результатах читаю про скорость канала. Скорость по мне так нормальная, но гораздо больше на работу через RDP влияет задержка. Понимаете разницу? Причем стандартный пинг ее не всегда отражает.

Вижу в тесте ассиметрию в скорости. Что за канал? Не ADSL случайно?

И второй раз задам все те же наводящие вопросы:

какие значения показывает втварный тест видеокарты с разными значениями параметра video=... ?

как работает тот же тонкий клиент в одной локалке с сервером? тормозит в тех же приложениях или нет?

Как работает тот же тонкий клиент на том же канале, но без IPsec-туннеля?

Кстати, майкрософтовский RDP-клиент как работает с тем же сервером через ВПН? есть ли разница?

[alexandro]

Не знаю внутренней механики теста, но в результатах читаю про скорость канала. Скорость по мне так нормальная, но гораздо больше на работу через RDP влияет задержка. Понимаете разницу? Причем стандартный пинг ее не всегда отражает.

Вижу в тесте ассиметрию в скорости. Что за канал? Не ADSL случайно?

И второй раз задам все те же наводящие вопросы:

какие значения показывает втварный тест видеокарты с разными значениями параметра video=... ?

как работает тот же тонкий клиент в одной локалке с сервером? тормозит в тех же приложениях или нет?

Как работает тот же тонкий клиент на том же канале, но без IPsec-туннеля?

1. В этом то и суть но тем не менее мту уменьшили до1400, что бы без фрагментации доходил пакет. При таком мту пинг - в срднем 6-7 мс.
2. Канал не АДСЛ, 50 мбит.
3. НЕ нашел этот тест, нашел только то что я вам скинул.(Единственное обнаружил время выполнения 15,9 на одном драйвере) много или мало?
4. Локально работает нормально, но опять же если слишком много графики то заметно. Но лучше чем в удаленном офисе.
5. Без ипсека пробовали так же, но кстати нашел кое что для этого. Надо отключать TCO offload Для этого..
6. Куча всяких тонких настроек. Вот и думаю, лучшей практикой какие лучше изменять.

[aka]

Ещё раз запусти терминал локально. Запусти на сервере диспетчер задач, смотри загрузку сети. Делай на терминале то, что заметно тормозит. И смотри, что с загрузкой сети творится. Много?

ЗЫ: тонкие настройки это только настройки. Магии там нет, секреной настройки "сделай зашибись" тоже нет.

[alexandro]

По чему этот параметр не возможность поставить меньше 50? с чем это связано? (redraw_delay)

[aka]

Смысла нет. 50 милисекунд на кадр это 20 кадров в секунду. Почти видео. Для офисных приложений такое не нужно. И особенно это не нужно за тонким тормозящим каналом.

[alexandro]

НУ как вам сказать, вот сейчас бы с удовольствием попробовал. Вот как раз я в это упираюсь. Народ жалуется. В екселе это ощутимо. В фул ХД. С большими таблицами.Тут листает плохо, тот тут отрисовка не такая. НУ почему не предоставить такую возможность, а админы сами бы уже смотрели. Понятно что будет много НО, вот возможность использовать 25-30 кадров была бы не плохо совсем.

[aka]

Опция в конфиге никак не сделает тормозящий канал быстрым.

[alexandro]

Вопрос не в канале. К примеру, берешь файл екселя, строк так 16000. Раздвигаешь просто столбы с данными, уже как не комфортно, в внутри сети. Вот тот результат теста удовлетворителен?
ping 192.168.0.3 -t -l 1400 -f

Обмен пакетами с 192.168.0.3 по с 1400 байтами данных:
Ответ от 192.168.0.3: число байт=1400 время=7мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=8мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=9мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=8мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=6мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=9мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=7мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=7мс TTL=63
Ответ от 192.168.0.3: число байт=1400 время=7мс TTL=63
Статистика Ping для 192.168.0.3:
Пакетов: отправлено = 31, получено = 31, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 5мсек, Максимальное = 14 мсек, Среднее = 7 мсек
Типичные пинги

[aka]

RDP траффик же идёт не через пинги. Оператор канала вполне мог поставить пингам наивысший приоритет, тогда они будут быстро пробираться через забитый канал. Проверить просто: запусти прокачку очень больших файлов через канал в несколько потоков, чтоб канал плотно забился до ограничения скорости, и пусти пинг ещё раз. Изменится время пингов? Потери начнутся?

Ты скриншот скорости выше выкладывал. А в локалке терминал с тем же сервером какую скорость RDP показывает? Я на гигабите вижу от-сервера-к-терминалу 10Мб/с и от терминала к серверу 30Мб/с. У тебя в двадцать раз меньше. Когда пользователь смотрит ПДФ, всякая векторность графических примитивов отваливается и канал плотно забивается перекачкой слабо сжатых картинок. То же будет, если раскрыть большую картинку на весь экран и быстро скролить мышью, или при просмотре видео. Можешь посмотреть загруженность канала при просмотре на терминале полноэкранного видео?

[Antonio]

Ака, а можно встроить в втварь тест латентности RDP?

[alexandro]

RDP траффик же идёт не через пинги. Оператор канала вполне мог поставить пингам наивысший приоритет, тогда они будут быстро пробираться через забитый канал. Проверить просто: запусти прокачку очень больших файлов через канал в несколько потоков, чтоб канал плотно забился до ограничения скорости, и пусти пинг ещё раз. Изменится время пингов? Потери начнутся?

Ты скриншот скорости выше выкладывал. А в локалке терминал с тем же сервером какую скорость RDP показывает? Я на гигабите вижу от-сервера-к-терминалу 10Мб/с и от терминала к серверу 30Мб/с. У тебя в двадцать раз меньше. Когда пользователь смотрит ПДФ, всякая векторность графических примитивов отваливается и канал плотно забивается перекачкой слабо сжатых картинок. То же будет, если раскрыть большую картинку на весь экран и быстро скролить мышью, или при просмотре видео. Можешь посмотреть загруженность канала при просмотре на терминале полноэкранного видео?

Проверяли давно правда ну пол года назад в 5 потоков, помниться пинги не терялись точно. 50 мб все таки. Оптика вообще 100. Мы прибывало и разными провайдерами. соединсять с офисами, лучше не становилось. И трафик делили по разным каналам. Наверное детальнее не готов ответить.
НА локалке по лучше раза в 3. Сейчас проверяю, из 50 потребляет 20-30 мбит. В 5 потоков занимали все 50.

[Antonio]

помниться пинги не терялись точно. 50 мб все таки.

Скорость канала и (отсутствие) потери пакетов никак между собой не связаны.

Пинг -- не очень хороший инструмент диагностики проблем с латентностью канала.

Возникло желание посмотреть, нет ли в каких-то сниферах возможности посчитать для RDP среднее время отклика сервера... но нет сейчас времени заниматься

[aka]

Что называть "откликом RDP"?

Основная задача RDP - рисовать на экране. Значит надо опираться на рисование. Допустим я нарисую в конфигураторе зелёный квадрат. Юзер по нему кликает - квадрат становится синим. Кликает ещё раз - опять зелёным.

А терминал обучу засекать время между отправкой серверу события "мышекнопка нажата" и получением от сервера команды "нарисуй квадрат следующего цвета".

Это время можно называть "откликом RDP"?

[Antonio]

Многим хочется отрабатывать зарплату, кликая по квадратикам. Но на самом деле задержку отклика интересно посмотреть в тот момент, когда юзер вдруг, внезапно, все-таки занят какой-то работой, и тут начинаются тормоза...

В идеале я вижу так: втварь как-то связывает "пакет с кликом мышки/клавы" и первый ответный "пакет с реакцией сервера", считает разницу времени и пару раз в секунду отображает значение в циферках в углу экрана. Не в всплывающем угловом окошке, а так, чтобы можно было видеть в процессе работы. Ну, типа как во многих играх на экран можно вывести FPS. Естественно, эта отрада глаз и мечта сисадмина должна включаться по секретному параметру в конфиге. Или по секретной комбинации клавиш.

Не знаю, возможно ли это, но знаю, что нужно.

PS: В демо-режиме (без лицензии) на экране как раз есть место для красивого разноцветного графика..

[aka]

Втварь получает стопиццо пакетов при каждом шевелении на экране. Курсор моргает, баннер шевелится, часики минуту прибавили. Втварь не сможет определить, какой из пакетов является ответом на действие юзера.

[Antonio]

А нельзя отправлять на сервер "особенный" пакет, который не помешает юзеру работать, и получать именно на него "особенный" ответ?

[aka]

Можно. Проще чем квадратик искать. Но полезность у этого особого пакета будет такой же, как и у пинга. Зачем нам скорость прохождения особого пакета, пусть и завёрнутого в RDP? Нам отзывчивость графики нужна.

[Antonio]

Ты имеешь в виду, что ответный особый пакет будет маленький? Или то, что сервер его пошлет, почти не думая?
Чем значение, измеренное по этим пинг-пакетам, будет отличаться от значения, измеренного по настоящим пакетам с графикой?

[alexandro]

Пока сегодня думал, и внезапно родилась мысль. Типо про скорость канала. В локально сети же мы понимаем, что скорость выше по умолчанию, то есть за 1 отрезок времени получает и отправляет больше информации, чем через интернет. Даже если у вас гарантированная скорость те же 100 мбит в интернете. Что бы запить канал нужна много поточность ведь. Типо торрент. Но по чему возникает вопрос все таки через интернет нельзя в один поток занят 1 канал? 1 юзер 1 поток. Пытаемся копать в сторону окна TCP. Как вы думаете это поможет? и еще как сам втваре будет реагировать на такое изменение TCP?

[alexandro]

Так когда на ожидать возможность уменьшить redraw_delay до такого уровня, что бы можно было видно до 30 кадров в секунду? Я пока не видел от вас внятного объяснения по чему не возможно реализовать, или по чему не хотите делать?

[Antonio]

alexandro, что именно должен рисовать клиент 30 раз в секунду, если картинка с сервера еще не пришла?

[alexandro]

alexandro, что именно должен рисовать клиент 30 раз в секунду, если картинка с сервера еще не пришла?

НА сколько я понимаю, из ходя из ваших слов, абсолютно исключено получить 30 кадров в локальной сети? Даже если сеть гигабит, и может использовать remotefx и т.д. А на самом деле, должен быть выбор в любом случае. С чем я сталкиваюсь сейчас, с тем, что на мой взгляд и кроется тут, именно нехватка кадров. ВОТ к примеру, кто давно с компами связан, и играл всякие кваки и т.д. Раньше как раз и видюшки были по слабее и т.д. Тогда так хотелось супер пупер графику, что-то только не придумывали. Но когда ФПС падал меньше необходимого, мышка такая пьяная становилось. Вот абсолютно иногда с этим и я сталкиваюсь. В екселе, явно идет задержка в кдрах. Двигаешь столбцы в екселе, и сразу в ностальгию. Аля 90х. Дайте выбор, а админы разберутся нужно им или нет.