Дело сдвинулось с мертвой точки!

С помощью программы Dr. TCP я поигрался с MTU на нескольких клиентах. На некоторых это не возымело никакого эффекта, зато на других появилась положительная тенденция. (TCP/IP)

Вот результат тестирования на двух клиентах.
Виртуальный_Клиент - P4 2.4, 400 Mb RAM
Реальный_Клиент - P4 2.6, 2 Gb RAM

MTU Виртуальный_Клиент Реальный_Клиент
1400 0.4% 0.4%
1300 1.4% 1.17%
1200 2.7% 2.1%
1000 2.6% 2.6%
900 4.4% 3.1%
700 6.3% 4%
500 4.6% 4.1%

Вот такие результаты. Могут быть небольшие погрешности. При этом появилась нагрузка на процессор (30-60%) и сетевую карту.

Кто знает, на что влияет MTU и какой вывод можно сделать из этих результатов? Что все-таки является тормозов?

LunxЯ бы не рекомндовал дергать MTU, просто потому, что предугадать, какой размер пакета будет сформирован 1С - мне сложно. Решить аналогичную проблему - когда сервер не был нагружен, а отчет формируется медленно - мне удалось вышеописанным мной способом. Более того - он общепринят. Я не понимаю Ваших упорствований и фраз, что соединять sql с сервером терминалов бессмысленно.Еще как осмысленно. Известно, что пять одновременных подключений с серверу, на котором находится и sql и сервер приложений приводят 1С в ступор. Ну так и разносите эти подключения. Запускайте все приложения на сервере терминалов, а базу держите на sql сервере. Более того - такая архитектура используется и другими ИС. Единственно, постарайтесь выделить соединение сервера приложений с sql, так чтоб он не обрабатывал все пакеты от других компов.

Я не упорствую, это моя цель сделать отдельными терминальный сервер и сервер SQL. Проблема в том, что терминальный сервер очень медленно общается в SQL сервером. Об этом я писал выше. Я не говорю, что терминальный тормозит или SQL тормозит. Все работает прекрасно. Тормозит само формирование отчета, если его запускать не локально с SQL.