Дорогие читатели, рад вас видеть на своём канале!
В настоящее время я проектирую, собираю и настраиваю частную систему видеонаблюдения для гаража. Под этот проект на известном маркетплейсе (слишком известном, чтобы называть его здесь) был куплен коммутатор фирмы Netis, модель P110GC, оснащённый функцией POE, а также некоторыми другими, полезными именно для систем видеонаблюдения, функциями. Я уже сделал краткий обзор этого устройства, а теперь проведу несколько испытаний.
А вы уже решите, приобретать его для своих нужд или нет.
Первая часть статьи: Коммутатор Netis P110GC с POE. Часть первая: знакомство. Краткий обзор
ИСПЫТАНИЕ ФУНКЦИИ VLAN
Пожалуй, самое простое из всех испытаний. В чём суть функции VLAN? Устройство, подключённое к любому из восьми «входящих» портов, начинает
работать в отдельной виртуальной локальной сети. Обмен данными между устройствами на «входящих» портах становится невозможным. Отмечу, что такая функция востребована как раз в системах видеонаблюдения (далее по тексту — СВН), и многие производители сетевого оборудования предлагают именно для СВН коммутаторы с поддержкой VLAN. Всё дело в безопасности: злоумышленник может добраться до камеры на объекте, условно говоря, отсоединить от неё кабель и попытаться саботировать работу СВН или даже атаковать сеть объекта. VLAN призвана служить ещё одним рубежом защиты от подобных попыток.
Активируем функцию переключателем на передней панели. Включаем два компьютера в любые два «входящих» порта, и с помощью программы ping, которая имеется в любой современной операционной системе, пытаемся проверить связь между ними. Терпим неудачу, а это значит, что функция VLAN работает исправно. Ну, правда же, это было очень просто!
ИСПЫТАНИЕ ФУНКЦИИ WATCHDOG
Здесь требуется отвлечься на пояснение. Сторожевой таймер (watchdog) в этом коммутаторе определяет «зависшие» устройства и автоматически перезагружает их. Для этого с соответствующего порта кратковременно снимается питание, а затем снова плавно подаётся. Но как он узнает, что устройство «зависло»? Китайцы заявляют, что для этого задействован ИИ, но я, по опыту наблюдения за работой коммутатора, могу сказать, что это ерунда
полная. Отслеживается лишь активность на порту, и если обмена данными через него нет в течение какого-то времени, то выполняется перезагрузка устройства на нём.
К коммутатору я подключил камеру фирмы CNB, модель TDT41R-28W, она совершено точно не «зависает», но было замечено, что если с камерой нет
обмена достаточно долго, то камера многократно перезагружается, а период перезагрузки составляет 100 минут.
Проблему удалось решить очень просто, даже случайно: я настроил камеру
на синхронизацию времени по NTP. Теперь камера непрерывно шлёт в сеть запросы на синхронизацию времени, коммутатор «видит» активность на порту и держит питание камеры непрерывно.
К чему может привести такое поведение коммутатора? Допустим, в вашей системе потоки с камеры не берутся вплоть до наступления определённого события. В этом случае камера может циклически перезагружаться. Первая же перезагрузка сотрёт все ваши настройки из энергозависимой памяти камеры. Это, например, дата и время, и если вы хотите получить на кадрах штамп с датой
и временем, то часы камеры благополучно собьются. Кроме того, пока камера перезагружается, она, очевидно, недоступна в течение нескольких десятков секунд и запись какого-то события, произошедшего так некстати, будет невозможна.
ИСПЫТАНИЕ ПРОПУСКНОЙ СПОСОБНОСТИ
Я не могу измерить пропускную способность коммутатора, поскольку все имеющиеся в моём распоряжении компьютеры оборудованы сетевыми контроллерами с пропускной способностью 1000 Мбит/сек, то есть такой же, как у самого коммутатора. Для этого необходимы, как минимум, контроллеры
на 2,5 ГБит/с, ведь только они смогут нагрузить коммутатор до предела. Но я могу испытать пропускную способность коммутатора, то есть убедиться, что он не снижает скорость типичного гигабитного канала.
Для испытаний была собрана установка из:
1. Сервера фирмы DEPO, модель STORM 3300P1, с мощным сетевым контроллером Intel 82576. Операционная система — Альт Сервер Виртуализации 10.2;
2. Ноутбука фирмы ASUS, модель X751LD с контроллером RealTek RTL8168/8111 потребительского класса. Операционная система — Windows 8.1;
3. Самого испытуемого коммутатора;
4. Соединительных кабелей фирмы Panduit.
Для измерения пропускной способности была выбрана программа iPerf3, она умеет считать фрагменты данных, потерянные из-за плохой работы сети, позволяет выбрать протокол между TCP или UDP, в качестве пересылаемых данных выбирать псевдослучайный поток бит или реальный файл, а также настраивать многие другие параметры передачи.
НЕМНОГО ТЕОРИИ
Данные по сети пересылаются внутри отдельных самодостаточных единиц, которые называются кадрами. В кадре содержится порция непосредственно самих полезных данных, перед и после них идут служебные данные, благодаря которым сетевая аппаратура автоматически доставляет кадры получателю, как бы далеко от отправителя тот не находился, а также обнаруживает возникшие при доставке нарушения целостности самого кадра. Сетевой коммутатор извлекает из кадра служебные данные, читает оттуда адрес устройства -получателя, а затем отсылает кадр на нужный порт. Здесь я намеренно упрощаю картину, не касаясь такого понятия, как пакет, потому что это не принципиально в данном случае, и пусть владеющий теорией сетей читатель не ставит мне в вину такое упрощение, ведь статья ориентирована на самую широкую аудиторию.
В испытаниях через коммутатор будут пересылаться данные по протоколу UDP, то есть протоколу негарантированной доставки. Вообще протоколом называют всеобъемлющий свод правил и соглашений, по которым идёт передача данных. Также я пробовал протокол гарантированной доставки TCP, но в статью эти результаты не вошли, ибо не имеют большого значения.
ПЕРВАЯ ПОПЫТКА
Была собрана установка из сервера и ноутбука, на которых запускалась программа iPerf3, они поочерёдно настраивались на роль отправителя и получателя, а в роли данных выступал поток псевдослучайных бит. Нужно было измерить пропускную способность канала без коммутатора, затем принять её за эталонную. После этого, включив коммутатор в канал, можно будет узнать, справляется ли он с пересылкой на скорости, близкой к максимальной. Для того, чтобы сетевые контроллеры моих компьютеров развили максимально возможную скорость передачи, потребовалось изменить настройки операционных систем, а в программе iPerf3 задать дополнительные параметры.
Нюансы этих настроек выходят за рамки статьи, но вкратце коснуться их всё-таки стоит.
Дело в том, что кадр может нести в себе порцию данных разного размера, и его можно ограничить, что и сделано в настройках операционной системы; этот параметр называется MTU и по умолчанию он равен 1500 байт. Допускается его подъём до 9000, а теоретически — до 12000 байт. Смысл в том, что для пересылки одного и того же объёма данных за единицу времени можно:
1) либо отсылать больше кадров с малым MTU,
2) либо меньше кадров, но с большим MTU.
Очевидно, что выгоднее слать мало крупных кадров, ведь с отправкой и приёмом каждого кадра связано много «телодвижений» (назовём это так) в недрах операционной системы, на которые тратится время. Я установил MTU сначала 3000, затем 9000 байт.
Теперь пара слов о буфере, речь идёт о настройках программы iPerf3. После чтения документации (https://iperf.fr/iperf-doc.php), а также экспериментально было выяснено, что размер буфера в iPerf3 (указывается через ключ -l или --length) задаёт размер порции полезных данных, отсылаемых в кадре, а максимальный размер буфера — MTU минус 40 служебных байт.
Документация по ссылке на две версии программы: третью, которая написана не очень хорошо, и вторую, написанную сильно лучше. Так, по документации на iPerf3 понять, что это за буфер такой, трудно, ведь написанное там просто не совпадает с реальной работой программы, и лишь в разделе для iPerf2 дано адекватное описание буфера. Рекомендую читать обе документации.
При размере MTU по умолчанию я получил пропускную способность канала 840−870 Мбит/сек, подъём MTU до 3000 байт дал заметную прибавку, и именно эти результаты вошли в таблицы. Пара слов о них и о том, как понимать результаты. Все значения взяты из отчёта iPerf3, объём переданных данных и скорость, думаю, в комментариях не нуждаются. Джиттер, как гласит документация, представляет собой усреднённую разность (а точнее — среднее отклонение) времён передачи каждых двух порций данных подряд, и следует ожидать, что включение в канал коммутатора увеличит джиттер; приведённые в таблицах числа, кажется, подтверждают это, но влияние коммутатора получается несущественным. Пока мы не будем делать поспешных выводов по джиттеру. Датаграммами называются отдельные самостоятельные единицы передачи по протоколу UDP, которые, буквально, упаковываются в так называемые IP пакеты, а те, в свою очередь, упаковываются в кадры, о которых вы уже знаете. И поскольку я обещал сделать статью доступной широкой аудитории, то подробных объяснений всего этого не будет. Но пугаться не надо: просто имейте ввиду, что порция полезных данных упрятана в самый центр «матрёшки», снаружи — кадр, а всего «матрёшек» три, для понимания статьи этого будет
достаточно. Интерес представляет счётчик потерянных датаграмм, который покажет, что какой-то из участников испытаний не справляется с нагрузкой.
Просто листайте галерею влево-вправо и сравнивайте столбцы. Измерения выполнялись три раза по 30 секунд. Внимательный читатель заметит, что объём переданных «туда» и «обратно» данных разный: дело в том, что я столкнулся с проблемой потери датаграмм на первой секунде измерений при передаче
«от сервера». Пришлось увеличить время измерений на секунду и указать программе iPerf3 игнорировать результаты первой секунды. Поэтому потери датаграмм в отчётах стали нулевыми, а объём данных вырос. Но сам факт потерь меня озадачил.
Максимальную пропускную способность канала можно получить, лишь увеличив MTU. Поднимаем до 9000 байт и смотрим результаты, листая галерею. Напомню, что MTU задаёт предельный размер порции полезных данных, которая в таблицах называется буфером и равна MTU − 40 служебных байт.
И вот тут начинаются интересные вещи. Пошли потери датаграмм, а пропускная
способность канала оказалась несимметричной. После обдумывания результатов стало ясно: сетевой контроллер ноутбука не справляется с нагрузкой. А всё потому, что с разных сторон канала работают компьютеры
разного класса: пусть старый (2009 года), но сервер — техника промышленного класса, и ноутбук — техника потребительского класса. Мощный сетевой контроллер в сервере разгоняет скорость передачи до предела и просто «забивает» потоком данных контроллер ноутбука, тот «захлёбывается» и теряет
датаграммы. В свою очередь, контроллер ноутбука не способен развить заявленные 1000 Мбит/сек на передачу и его потолок — 980 Мбит/сек, что контроллер сервера обрабатывает играючи. Таким образом, испытания ещё и стали наглядной демонстрацией превосходства по производительности серверной техники над домашней.
А теперь включим коммутатор в канал и посмотрим, как он справляется с нагрузкой. Здесь MTU установлен снова равным 3000 байт. Никакого сколь-нибудь заметного влияния на пропускную способность коммутатор не оказывает, листайте галерею и убедитесь в этом сами.
Теперь разгоняем канал до предела, с MTU в 9000 байт. Снова ноутбук «захлёбывается», хотя даже по таким результатам можно увидеть, что коммутатор не снижает сколь-нибудь заметно пропускную способность канала.
Вот только почему скорость от ноутбука к серверу вдруг так снизилась? Я не нахожу этому объяснений, похоже на случайное стечение обстоятельств. Иногда iPerf3 выдаёт такие результаты, но позже очередной запуск программы даёт в отчётах уже корректные числа, так что просто не обращайте на это внимания.
Итак, подведём итоги. Китайский коммутатор фирмы Netis показывает достойные результаты пропускной способности.
Кстати, вы заметили, что я пишу название фирмы с заглавной буквы, тогда как сами китайцы придумали писать со строчной? Просто я настолько привык к тому, что имена собственные и торговые марки пишутся с заглавной, что не ожидал от китайцев здесь подвоха и заметил ошибку только теперь.
Так вот, уже сейчас можно сказать, что этот коммутатор является достойным выбором. Но корректность испытаний нарушена из-за несовершенства применённых инструментальных средств, проще говоря, ноутбук оказался слабоват. С целью разгона канала до предельно возможной пропускной способности, методику испытаний пришлось сменить, и об этом — в следующей части (ссылка будет позже).