Усовершенствованная настройка обратного канала - лучший тестовый процесс

У меня есть маршрутизированная сеть, которая для обычного просмотра веб-страниц и передачи файлов работала нормально. Высокие скорости (клиенты ограничены 256k/3Mb в загрузке/выгрузке), стабильные загрузки и QoS отлично работают на основном маршрутизаторе. Все соединения на 5GHz. Но я struggle получить «реальный» трафик без перебоев. Я использую ROS3.22 или 3.23 (еще не обновил все) и пакет wireless-test. На точках доступа я начал использовать RTS/CTS с установленным порогом Hw.Protection на 256. Это значительно улучшило VOIP и Skype (L7 в QoS). (Точки доступа с 20-30 клиентами). Обычный просмотр практически не заметно пострадал. На моих точках обратно я использую протокол nstreme, без ограничения кадра и с динамической политикой размера. Чистая пропускная способность, измеренная с помощью инструментов тестирования полосы пропускания, показала немного лучшие результаты, чем без nstreme. Уровни CCQ показали около 90-95%. Время пинга по соединению было около 7ms (пакет 50b). Время пинга по соединению в среднем составило около 16ms для пакета 1500b. Но разница между Hw Frames и Frames чтения была огромной. Примерно в 10-20 раз больше! Когда nstreme был отключен, время пинга едва изменилось. CCQ немного снизился до около 90%. Но разница в кадрах почти вернулась к 1-1! Поскольку я где-то прочитал, что разница в кадрах на самом деле является признаком того, сколько пакетов повторно отправляется, а повторная отправка — это убийца «реального» времени трафика, как VoIP и т.д., я думаю, лучше отказаться от протокола nstreme на этом соединении? Большинство соединений длиной всего несколько километров, но на относительно низких мачтах (домах), но достаточно Френеля, насколько я могу судить (и получить…). Чтобы уменьшить накладные расходы в пакетах, я использую короткий преамбулу. Никакой веб или WPA не используется. (Авторизация по MAC и 5GHz достаточно защитят от злоумышленников.) WMM Support включен везде, но фактически пока не настроен (еще) на любом маршрутизаторе. Так что в основном не используется. Создает ли эта поддержка WWM дополнительные накладные расходы в отправляемых пакетах? QoS работает на основном маршрутизаторе и некоторых маршрутизаторах по всей сети. Это кажется нормальным. Но на самом деле я ищу некоторую помощь в том, как максимально оптимизировать обратные соединения, чтобы добиться минимальной задержки и потерь пакетов, чтобы реальный трафик работал нормально. Как вообще протестировать соединения? Является ли тест полосы пропускания хорошим инструментом, если не запускать его с устройств, создающих соединение? Является ли пинг хорошим инструментом? Какой размер выбрать? Когда следует использовать ARP пинг? (Какой размер имеют VOIP пакеты? А HTTP? (Skype), HTTPS (Skype)?) Если используется nstreme, какой хороший размер предела кадров? Лучшая политика? Я, конечно, могу спросить клиентов за обратными соединениями, каковы их впечатления. Но такая информация обычно не имеет большой ценности. Обычно вы получаете комментарий: «Вчера было хорошо» или «Это не так быстро, как в начале». Я не могу с этим работать… Чтобы оптимизировать, мне нужны быстрые ответы/мониторинг и результаты изменения настроек. У меня несколько соединений, некоторые с хорошими уровнями сигнала (70dBm или меньше), некоторые менее (около 70-80dBm). Много работы! Было бы здорово, если бы некоторые из вас, эксперты, могли бы поделиться своим обширным опытом, чтобы вместе мы могли создать своего рода руководство и мануал, которые могли бы обогатить вики. Руди