В процессе перехода на Centaurus 7 резко затормозилась работа с удаленным рабочим столом Windows Server. Как проявляется: обычно, если открыть меню "Пуск" и вести курсором вверх-вниз, подсветка "бегает" за курсором. Теперь курсор перемещается, а подсветка меню отражается через 5-6 секунд. И так с любыми операциями отображения чего бы то ни было, соответственно приложения тормозят нещадно. На одном и том же компьютере. С rdesktop и с xfreerdp. На материнских платах с Intel и с AMD. На Centaurus 6 не замечено.
Задержка отображения в клиентах RDP - rdesktop и xfreerdp Очень похоже на http://www.linux.org.ru/forum/admin/7627499/page1#comments Только решение --gdi sw в нашем случае не помогает. Поставить rdesktop 1.7.1-alt0 из ветки p6 пробовал, проблема остаётся. Имеем два Windows Server 2003 Base терминальных сервера. Один 32-разрядный, проблем нет. Другой 64-разрядный, с ним тормозит, вне зависимости от нагрузки на сервер. Вынуждены откатываться на Centaurus 6, в нём на том же железе не тормозит.
Методика постановки опыта 1: берём любой подходящий блок с Centautus 6, ставим дополнительный такой же жесткий диск и ставим Centaurus 7. Тормоза. Перезагружаемся обратно в Centautus 6 - всё нормально. Проверял на материнских платах MSI MS-2767 (Intel 945GCM5) и MS-7786 (AMD A55M-P33), пробовал ставить дискретную видеокарту ATI Radeon AX700. Пробовал сносить все пакеты radeon или ставить их заново - без эффекта. Методика постановки опыта 2: берём два одинаковых блока, подключенные к одному коммутатору локальной сети. На первом Centautus 6, на втором Centaurus 7. И попеременно, командой rdesktop -k en-us -u pavelri asserver таскаем туда-сюда одну и ту же сессию. На 6 всё ok, на 7 тормозит. tcpdump src asserver and src port 3389 показывает наличие задержек между поступающими с сервера пакетами ack и seq на эти самые 2-3-4 секунды, как будто сервер чего-то выжидает. Пока непонятно, почему с Centaurus 6 такого не происходит и сервер более охотно отдаёт данные об изменении изображения.
Created attachment 5980 [details] На всякий случай, system-report Проблема проявляется на любых конфигурациях (Intel - AMD, Asus - MSI) во всяком случае на всех которые удалось перепробовать - одинаково.
Взял артиллерийскую вилку по ядрам из p6. std-def-3.0.101 test ok, торможения нет un-def-3.4.67 и un-test-3.9.7 уже тормозят
Что-то тамс реалтеками было не так, посмотрите на всякий случа 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
Виноват, мимо кнопки нажал. Посмотрите на всякий случай, не похожая ли сетевуха в конфигурациях, на которых наблюдаются тормоза.
Created attachment 5989 [details] Другая конфигурация Сплошной Интел, тормоза те же
(В ответ на комментарий №6) > Посмотрите на всякий случай, не похожая ли сетевуха > в конфигурациях, на которых наблюдаются тормоза. Нет, сетевухи самые разные. Единственный общий момент - с ядрами 3.0.x std-def из p6 не тормозит (иначе давно бы заметили), а с более поздними, начиная c un-def из p6 - тормозит всегда и на любом оборудовании из того что пробовалось. И хотя прямо сейчас на стенде у меня действительно оно, RTL8111/8168 PCI Express Gigabit Ethernet controller интегрированный в мать MSI A55M-P33, однако при проверке под Кентавром 6.0 (3.0.x std-def) тормозов или нет вовсе, или совсем незаметные.
http://blog.tmcnet.com/blog/tom-keating/microsoft/remote-desktop-slow-problem-solved.asp Автор статьи полагает, что имеет место несовместимость алгоритмов Receive Window Auto-Tuning. Проблема по описанию один-в-один как наша, в любом случае проблемный сервер точно такой же: Windows 2003 R2 64-bit Server
Есть решение. Источник http://kaivanov.blogspot.ru/2010/09/linux-tcp-tuning.html Проблему устраняет # sysctl net.ipv4.tcp_window_scaling=0 или # echo net.ipv4.tcp_window_scaling=0 >> /etc/net/sysctl.conf # reboot Вывод: вообще не баг, а особенность настройки на работу в сети при взаимодействии с Windows Server 2003 x86_64. Изменений в пакетах либо дистрибутив не требуется.