Oct. 19, 2015, 5:20 p.m.
Posted by soar

Тестирование 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-соединений, которые инициализуются клиентом, и основная задача которых — создать нагрузку, схожую с нагрузкой от торрент клиентов.

Также в течение всего теста клиент постоянно пингует сервер, эта информация сохраняется и представлена на графиках.


Виды тестов

По типу физического подключения

LAN

Тесты проводились при подключении к физическим ethernet-портам устройства так, чтобы создать эмуляцию работы в обычном для маршрутизатора режиме, т.е. к WAN- и LAN- портам. Соответственно нагрузочный трафик проходил через NAT, а multicast-трафик задействовал возможности встроеной IGMP-proxy и IGMP-snooping должен был пересылать UDP-пакеты с внешнего интерфейса устройства на необходимый интерфейс конечного клиента.

WLAN

Аналог предыдущего теста, однако теперь был задействован только один ethernet порт — WAN. Клиентское же устройство было подключено по беспроводному стандарту.

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

По характеру нагрузки

Long-Connections — длинные соединения

В этом режиме при запуске нагрузки (см. выше) от клиентского устройства к серверу устанавливается N соединений. Для каждого соединения устанавливается размер буфера — X. Далее клиент начинать отправлять по M пакетов в сторону сервера, а сервер — по М пакетов в сторону клиента, создавая двухстороннюю нагрузку. Время, затраченное на этот цикл — фиксируется, после чего передача повторяется. Продолжительность жизни каждого такого соединения равна продолжительности всего теста.

Short-Connections — короткие соединения

Как и в прошлом случае, при запуске нагрузки, от клиентского устройства к серверу устанавливается N соединений. Для каждого соединения устанавливается размер буфера — X. Далее клиент отправляет M пакетов в сторону сервера, сервер отправляет M пакетов в сторону клиента, после чего соединение завершается. Время, затраченное на полный цикл — фиксируется, после чего устанавливается новое соединение. Количество активных соединений поддерживается на уровне, заявленном в тесте.

По размеру буфера

64B

Буфер приема/отправки X (см. выше) выставляется в 64 байта, а количество пакетов M равно 8. В таком случае полный цикл представляет из себя передачу 512 байт сначала в одну, а потом в другую сторону.

64KB

Буфер приема/отправки X выставляется в 64 килобайта, а количество пакетов M — 1. В таком случае полный цикл представляет из себя передачу суммарно 128 Кбайт данных (64 КБ от клиента на сервер, и 64 КБ от сервера — клиенту).

По количеству одновременных соединений

Каждый тест выполнялся в 3 режимах: 10, 100 и 1000 одновременных соединений.

По максимальной скорости

Стоит так же отметить, что некоторые гигабитные модели тестировались в двух режимах: сначала все тесты проводились при включении физических портов в 100-мегабитном режиме, затем порты переводились в гигабитный режим и повторялся полный набор тестов. Зачем? Во-первых, так уж получилось, что большинство абонентов включены в 100-мегабитные порты на свитчах, и в первую очередь актуален именно такой режим работы. Ну а во-вторых, к сожалению, большинство домашних устройств, носящих гордое название «гигабитный маршрутизатор» с этим самым гигабитом не справляется. Многие из них начинают терять пакеты уже при нагрузке более 200 Мбит, некоторые, особенно удачные, справляются с потоком в 500-700 Мбит. Что уж говорить о том, что в нагрузочном тестировании при 1000 соединений с суммарным потоком в 1 гигабит об IPTV на этих устройствах можно забыть. Так или иначе, эти тесты тоже представлены в таблице — там, где рядом с названием устройства написано «(GB)».

Результаты

Все графики доступны в общей таблице, вы можете сами посмотреть их и сделать выводы.

На данный момент в таблице представлены следующие модели:

  • Asus RT-AC66U
  • D-Link DIR-300 (rev. B7)
  • D-Link DIR-300 (rev. C1)
  • D-Link DIR-615 (rev. K1)
  • D-Link DIR-651 (rev. A2)
  • D-Link DSR-1000N
  • Huawei WS329
  • TP-Link Archer C7
  • TP-Link TL-WDR3500
  • TP-Link TL-WDR3600 N600
  • TP-Link TL-WDR3600 N600 (GB)
  • TP-Link TL-WDR4300 N750
  • TP-Link TL-WDR4300 N750 (GB)
  • TP-Link TL-WR710N
  • TP-Link TL-WR741N rev. 1.4
  • TP-Link TL-WR741ND rev. 4.20
  • TP-Link TL-WR840N
  • TP-Link TL-WR840N rev. 1.0
  • TP-Link TL-WR841N rev. 8.2
  • TP-Link TL-WR841ND rev. 8.1
  • Ubiquiti AirRouter
  • Zyxel Keenetic — rev. A
  • Zyxel Keenetic Giga
  • Zyxel Keenetic Lite — rev. A
  • Zyxel Keenetic Lite — rev. B

Comments