Тестирование SOHO маршрутизаторов -- в поисках качественных мегабитов
Домашние маршрутизаторы сейчас есть практически в каждом доме. Есть спрос – и есть предложение, рынок наполнен различными моделями. Сейчас в тренде гигабитные роутеры с красивой надписью “300 Мбит”, и никто особенно не вдается в подробности – гигабит там, 300 Мбит или 100. Ведь в действительности 80% устройств на рынке не обеспечивают заявленных цифр: “гигабитный” маршрутизатор не выдаст честный гигабит в режиме NAT между портами WAN и LAN, а 300 Мбит вы никогда не выжмете в реальном радио-эфире.
Но есть другая, более специфичная проблема: цифры становятся особенно важны, когда мы говорим про потоковое телевидение. И важно здесь не “количество”, а “качество” этих самых мегабит, по нескольким причинам.
Потоковое ТВ (далее IPTV) многие провайдеры предоставляют по multicast технологии – это снижает нагрузку на оборудование провайдера, снижает задержки, отменяет понятие буфера и вообще удобно для конечного клиентского устройства, задача которого показать картинку. Вот только при этом проявляются и все недостатки UDP – провайдер ничего не знает о том, дошёл ли необходимый пакет до конечного устройства, а конечное устройство не может перезапросить потерянный пакет. Безусловно, если потерян одиночный фрейм – протокол исправит ошибку и потеря останется незамеченной. Но если оказались потеряны несколько фреймов или ключевой фрейм – клиент увидит “рассыпание” картинки. Чем больше потерь – тем хуже качество видео. И, на практике, самым узким местом здесь оказывается именно абонентский маршрутизатор: если ЦПУ устройства слишком занято – именно приходящие UDP-пакеты отправляются в мусорное ведро в первую очередь. И там, где в онлайн игре просто немного вырастет пинг – смотреть IPTV станет уже невозможно.
Прогресс не стоит на месте. В тренде сегодня устройства с так называемым аппаратным NAT’ом – в этих девайсах connection-tracking и непосредственно операцию преобразования адресов исполняет чип, что снижает нагрузку на процессор. Однако multicast трафик не подходит под это правило и он по-прежнему обрабатывается на процессоре – это отлично видно в некоторых тестах.
Как показала практика, для выявления потенциальных проблем, описанных выше, недостаточно просто включить какой-нибудь торрент-клиент и одновременно смотреть IPTV. Был необходим набор синтетических тестов, которые однозначно определяли бы, справится ли устройство с пиковой нагрузкой.
Каждый тест представлял из себя 10-минутный отрезок времени, состоящий из двух логических частей. При старте теста инициализируются 3 мультикаст потока с битрейтами 3750 kbps, 5000 kbps и 8000 kbps. Каждый поток представляет из себя полноценную сессию: от клиента к серверу отправляется IGMP-запрос на подписку, от сервера к клиенту – UDP-поток с псевдо-MPEGTS пакетами. В течение первых 30 секунд теста другой нагрузки на устройство не создается и просто замеряются тайминги прохождения пакетов, с целью убедиться в том, что проблем нет. Начиная с 30-ой секунды запускается нагрузочное тестирование: к мультикаст потокам добавляется N-соединений, которые инициализуются клиентом, и основная задача которых – создать нагрузку, схожую с нагрузкой от торрент клиентов.
Также в течение всего теста клиент постоянно пингует сервер, эта информация сохраняется и представлена на графиках.
По типу физического подключения
Тесты проводились при подключении к физическим ethernet-портам устройства так, чтобы создать эмуляцию работы в обычном для маршрутизатора режиме, т.е. к WAN- и LAN- портам. Соответственно нагрузочный трафик проходил через NAT, а multicast-трафик задействовал возможности встроеной IGMP-proxy и IGMP-snooping должен был пересылать UDP-пакеты с внешнего интерфейса устройства на необходимый интерфейс конечного клиента.
Аналог предыдущего теста, однако теперь был задействован только один ethernet порт – WAN. Клиентское же устройство было подключено по беспроводному стандарту.
Нужно отметить, что если по-началу эти тесты проводились практически для всех устройств, то со временем я от них отказался: как правило, если устройство держало нагрузку при подключении кабелем, то оно справлялось и в беспроводной сети. Здесь NAT используется так же, а тест по большей части выявляет не проблемы железа, а проблемы радио-эфира. В общем, и без меня в интернете полно тестов радио-трактов популярных роутеров.
Long-Connections – длинные соединения
В этом режиме при запуске нагрузки (см. выше) от клиентского устройства к серверу устанавливается N соединений. Для каждого соединения устанавливается размер буфера – X. Далее клиент начинать отправлять по M пакетов в сторону сервера, а сервер – по М пакетов в сторону клиента, создавая двухстороннюю нагрузку. Время, затраченное на этот цикл – фиксируется, после чего передача повторяется. Продолжительность жизни каждого такого соединения равна продолжительности всего теста.
Short-Connections – короткие соединения
Как и в прошлом случае, при запуске нагрузки, от клиентского устройства к серверу устанавливается N соединений. Для каждого соединения устанавливается размер буфера – X. Далее клиент отправляет M пакетов в сторону сервера, сервер отправляет M пакетов в сторону клиента, после чего соединение завершается. Время, затраченное на полный цикл – фиксируется, после чего устанавливается новое соединение. Количество активных соединений поддерживается на уровне, заявленном в тесте.
Буфер приема/отправки X (см. выше) выставляется в 64 байта, а количество пакетов M равно 8. В таком случае полный цикл представляет из себя передачу 512 байт сначала в одну, а потом в другую сторону.
Буфер приема/отправки X выставляется в 64 килобайта, а количество пакетов M – 1. В таком случае полный цикл представляет из себя передачу суммарно 128 Кбайт данных (64 КБ от клиента на сервер, и 64 КБ от сервера – клиенту).
По количеству одновременных соединений
Каждый тест выполнялся в 3 режимах: 10, 100 и 1000 одновременных соединений.
Стоит так же отметить, что некоторые гигабитные модели тестировались в двух режимах: сначала все тесты проводились при включении физических портов в 100-мегабитном режиме, затем порты переводились в гигабитный режим и повторялся полный набор тестов. Зачем? Во-первых, так уж получилось, что большинство абонентов включены в 100-мегабитные порты на свитчах, и в первую очередь актуален именно такой режим работы. Ну а во-вторых, к сожалению, большинство домашних устройств, носящих гордое название “гигабитный маршрутизатор” с этим самым гигабитом не справляется. Многие из них начинают терять пакеты уже при нагрузке более 200 Мбит, некоторые, особенно удачные, справляются с потоком в 500-700 Мбит. Что уж говорить о том, что в нагрузочном тестировании при 1000 соединений с суммарным потоком в 1 гигабит об IPTV на этих устройствах можно забыть. Так или иначе, эти тесты тоже представлены в таблице – там, где рядом с названием устройства написано “(GB)”.
Все графики доступны в общей таблице, вы можете сами посмотреть их и сделать выводы.
Полная таблица результатов тестирования
На данный момент в таблице представлены следующие модели:
TP-Link TL-WDR3600 N600 (GB)
TP-Link TL-WDR4300 N750 (GB)
TP-Link TL-WR741N rev. 1.4
TP-Link TL-WR741ND rev. 4.20
TP-Link TL-WR840N rev. 1.0
TP-Link TL-WR841N rev. 8.2
TP-Link TL-WR841ND rev. 8.1
Zyxel Keenetic Lite – rev. A
Zyxel Keenetic Lite – rev. B
Тестирование SOHO маршрутизаторов — в поисках качественных мегабитов was originally published on soar.name
