Добрый день, дорогие друзья. Несколько лет работала сисадмином в некотором количестве корпоративных и домашних провайдеров Санкт-Петербурга и по сей день часто сталкиваюсь с тем, что покупая оборудование операторы смотрят больше на цену и описание функций, чем на реальные показатели, о них поставщики обычно ничего не пишут, в следствии чего вместо одного коммутатора приходится устанавливать еще и еще, а качество связи лучше может и не станет. Про существования понятия SLA(Service Level Agreement) тоже не все операторы в курсе, по этой причине собрала достоверную информацию по тестированию сетей и оборудования, и готова предоставить её вашему вниманию.

Ethernet нужно тестировать!

Есть ли точное определение и рецепты того, как проводить тесты пропускной способности канала и качества предоставляемой связи? Я нашла несколько статей, из которых стало понятно только одно, сегодня в России сети тестируют методами, предназначенными для других целей, и это не может не удивлять, ведь услуги связи в крупных городах нашей страны достаточно развиты, скоростной канал есть буквально в каждой квартире, а некоторые операторы уже предоставляют гигабитные каналы домашним клиентам, но о методиках тестирования качества предоставляемых телематических услуг знают далеко не все.

Что конкретно и почему нужно тестировать?

Задумайтесь, как часто сегодня покупают кота в мешке:

• Арендованные вами или сданные в аренду каналы связи;
• Сдача-приемка каналов связи, построенных вами или для вас;
• Предоставляемые услуги связи, особенно при наличии неустойки в договоре;
• Оборудование, которое вы хотите купить, а вам его хотят продать и рассказывают о том, что оно супер-крутое и недорого стоит.

Это крохотная горстка примеров того, чем рискуют на сегодняшний день клиенты и операторы связи.

Софтовые утилиты для тестирование «Интернета»

Полноценным тестированием канала не могут являться echo запросы, ping и mtr никогда не расскажут какая у канала пропускная способность. Об этом не сможет рассказать iperf и прочие софтовые утилиты, так как при одновременном использовании сети и тестировании софтовым утилитам не известен объем пользовательских данных, находящихся в канале в текущий момент, так же при софтовом тестировании возможен ряд неточностей, обусловленных наличием заголовков пакетов, в зависимости от размера кадра заголовки остаются стандартной длины, а тело с данными увеличивается или уменьшается, софтовые утилиты определяют пропускную способность канала без учета размера заголовков, что на разных размерах пакетов вносит в подобное тестирование определенную неразбериху.

Вы не сможете оценить качество арендованного vlan, глядя на график загрузки канала или скачивая объемные файлы из интернета. Почему speedtest.net не является доказательством скорости предоставляемого канала наверное не стоит уточнять? Ведь сразу понятно что - неизвестно какие каналы и через какие сети они идут до серверов speedtest, как и неизвестно насколько загружен канал во время теста, и многие другие параметры теста, а если в тесте столько неизвестных - то его результаты никак не могут быть точными. Результатом speedtest - является скорее некая дельта от неких показателей, а не реальные цифры.

Качество предоставляемых услуг связи - это совокупность многих параметров, и используя правильные инструменты можно быстро и эффективно получить точные данные о предоставляемой услуге. Важно не только получить точные данные, но и иметь уверенность в том, что данные можно будет использовать для доказательства своей правоты, например в суде.

Методики и анализаторы Ethernet

На сегодняшний день есть две основные методики тестирования пропускной способности: старая - RFC-2544 и немного помладше: Y.1564 . Методика ITU-T Y.1564 - более актуальная на сегодняшний день, имеет описания для тестирования современных, высокоскоростных каналов связи с современными понятиями о SLA(Service Layer Agreement).

Так как качество ethernet-канала это совокупность многих факторов, следовательно, правильное тестирование должно максимально охватывать все эти совокупности. При тестировании необходимо учесть многие аспекты и было бы полезно иметь расширенные возможности, такие как BER Test , пакетный джиттер, поддержку MPLS, QoS, тестирование нагрузкой протоколов прикладного уровня (http, ftp, etc...).

Для тестирования каналов от 1G до 10G и выше достаточно сложно делать нагрузочные тесты при помощи неспециализированного железа, зачастую процессоры не способны генерировать достаточный объем трафика, в отличие от специализированных тестеров-анализаторов. Такие приборы можно положить в стойку, шкаф, даже в ящик на чердаке и запускать тесты удаленно, а можно делать автоматические замеры в разные временные интервалы. Любые портативные приборы-анализаторы не испортятся в суровых условиях канализации, так как проходят жестокие испытания на прочность.

Сдача-приемка каналов связи.

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

Подробнее о методике тестирования RFC-2544 и том, как это работает.

Методика предлагает набор из 6 тестов, я опишу более подробно, каким образом проходит тестирование, для наглядности восприятия:

Определение пропускной способности тестируемого устройства(Throughput)

Описание теста: посылается небольшой объем, специально сформированных тестером, пакетов, на определенной скорости, на входной порт устройства, на выходном порту количество подсчитывается, если передано больше, чем получено - скорость уменьшается и тест запускается снова.

Определение время задержки кадра(Latency)

Описание теста: после определения пропускной способности(Throughput), для каждого размера кадра, на соответствующей ему максимальной скорости, посылается поток пакетов по определенному адресу. Поток должен иметь минимальную длительность в 120 секунд. В 1 пакет по прошествии 60 секунд вставляется метка. Формат метки определяется производителем оборудования. На передающей стороне записывается время, к которому пакет с меткой был полностью отправлен. На приемной стороне определяется метка и записывается время полного приема пакета с меткой. Задержка (latency) - это разница между временем отправки и временем получения. Данный тест, согласно методике необходимо повторять минимум 20 раз. По результатам 20 измерений вычисляется средняя задержка. Тест следует проводить отправляя весь тестовый поток на один адрес и отправляя каждый кадр по новому адресу.

Определение частоты потери кадров(Frame loss rate)

Описание теста: на входной порт устройства посылается определенное количество кадров на определенной скорости и подсчитывается количество пакетов, принимаемых от выходного порта устройства. Частота потери кадров рассчитывается следующим образом:

((количество переданных кадров - количество полученных кадров) * 100) / количество переданных кадров

Первая отправка происходит на максимально-возможной скорости, затем скорость отправки понижается с максимальным шагом в 10%, согласно методике уменьшение % шага даст наиболее точные результаты. Уменьшение скорости необходимо продолжать до тех пор, пока две последних отправки будут без ошибок, а именно мы узнаем максимальную скорость передачи данных, на которой frame loss rate становится равен 0.

Тестирование способности обрабатывать back-to-back кадры(Back-to-back frames)

Описание теста: тест сводится к отсылке некого количества кадров с минимальной межкадровой задержкой на входной порт тестируемого устройства и подсчету кадров с выходного порта устройства. Если количество отправленных кадров и полученных равно, то увеличивается объем отправляемых кадров и тест повторяется, если принятых пакетов меньше, чем отправленных объем отправляемых кадров уменьшается и тест повторяется. В итоге мы должны получить максимальное количество пакетов отправленных и полученных без потерь для каждого размера пакета, это и будет значение back-to-back теста. Согласно методике длительность посылок кадров на порт устройства не должна быть менее двух секунд, а минимальное количество - не менее 50 раз. Конечная цифра - это усредненный результат 50 тестов.

Восстановление после перегрузки(System recovery), применимо только для тестирование устройств

Описание теста: на вход устройства в течение минимум 60 секунд отсылается поток кадров со скоростью 110% относительно измеренной тестом throughput. Если тест throughput показал идеальные результаты, то выбирается максимальная скорость данного соединения. В момент перегрузки скорость потока уменьшается в два раза и засекается разница между временем снижения скорости потока, и временем когда был потерян последний кадр.

Время восстановления тестируемого устройства после перезапуска(Reset), применимо только для тестирование устройств

Описание теста: на вход устройства отсылается непрерывный поток кадров на скорости, определенной в результате теста throughput с минимальным размером кадра. Устройство сбрасывается. Время восстановления после сброса это разница между временем приема последнего пакета до сброса и временем приема первого пакета после сброса. Тестируется и аппаратный и программный типы сброса устройства.

Что изменилось со свежей методикой Y.1564?

Новые рекомендации были рассмотрены и одобрены в 2011 году ITU . К уже изложенным рекомендациям в RFC 2544 добавляется пакетный джиттер(дрожание), а именно возможность вычисления разницы времени при получении ряда последовательных пакетов данных, относящихся к одному и тому же потоку, в идеальном мире ее не должно существовать, но в проблемных сетях последовательность может быть нарушена, что может сказаться на скорости обработки данных. RFC2544 позволяет делать проверки исключительно на максимальной скорости канала, на которой не будет потери пакетов, а это обычно выше чем скорость CIR (Committed Information Rate - гарантированная полоса пропускания) . Y.1564 создан именно для SLA , оценки скорости и качества предоставляемого канала согласно ключевым показателям производительности(KPI) и позволяет проверить предоставляемый канал в соответствие с договором.

Y.1564 позволяет проверить гарантированную полосу пропускания, максимально-допустимую, а так же дать нагрузку сверх полосы, к примеру для проверки настроек шейпера.

Есть еще несколько различий между методиками, RFC2544 не производит верификации корректности настройки сервиса (соответствие KPI заданным, и ограничение скорости выше EIR(Excess Information Rate - максимальная негарантированная полоса пропускания), во избежание перегрузки сети). В оригинальной версии RFC2544 джиттер не измеряется. Согласно RFC2544 каждый тест запускается отдельным потоком, что не позволяет измерить качество предоставляемых услуг в совокупности и увеличивает время тестирования, еще один минус RFC2544 в том, что отсутствует возможность профилирования для проверки разных типов трафика в одном канале, к примеру, если в сети используется QoS, в Y.1564 учтены недочеты и немного расширен функционал.

Тестировать можно только новые каналы или уже рабочие тоже?

Тестировать нужно и новые каналы, и тем более старые. Вы можете заранее узнать о назревающих проблемах, не доводя клиентов до звонка в поддержку. Современными тестерами-анализаторами можно проводить проверки в работающей сети, проверять каналы как со скоростью 10/100/1000Mbit, так и 10/40/100G. Есть одно НО, очень важно понимать что и как вы делаете, важно нечаянно не положить тестируемый канал.

Режимы тестирования - In/Out of service.

На сегодняшний день тестирование сетей стремится к полной систематизации и постоянному контролю каналов, более ранние версии методики RFC2544 были созданы для тестирования каналов/оборудования в режиме OutOfService, и использовались в основном для теста оборудования, но на сегодняшний день все производители тестовых приборов переходят на более новые стандарты тестирования, позволяющие проводить постоянный мониторинг сети в режиме InService. Такое тестирование позволяет проверять скорость полосы пропускания без отключения клиентов, что важно для операторов услуг связи.

Эпилог

Товарищи, как говорит один мой друг, давайте вместе бороться с «коекакерами», и начнем тестировать то, что строим и то, что эксплуатируем.

Используемая литература:

* Мнение компании может не совпадать с мнением автора;-)

Только зарегистрированные пользователи могут участвовать в опросе. Войдите , пожалуйста.

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

1. Признаки неисправности коммутатора

Проблемы в работе коммутатора являются одной из наиболее распространенных причин рабочих сбоев силового агрегата (конечно, при условии, что с топливной системой все в порядке). Чаще всего неисправности коммутатора проявляются в виде падения динамики разгона, отказа пуска мотора, «провалов» при резком ускорении, а также в «троении» двигателя. Опытный водитель сразу заметит неладное, а чтобы убедиться в своей теории, достаточно будет провести несложную диагностику.

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

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

К примеру, для проверки состояния бесконтактного датчика нужно измерить напряжение на выходе датчика – распределителя. В исправном состоянии проворачивание коленвала с помощью ключа должно вызывать резкое изменение (зачастую в пределах от 0,2 - 0,4 В до 5 – 11 В). Если этого не происходит, скорее всего, датчик нуждается в замене. Диагностика состояния коммутатора также не занимает много времени, а для ее выполнения чаще всего не потребуется никакого специального оборудования.

2. Алгоритм действий по проверке коммутатора

Многие автомобилисты предпочитают не терять время на поиск неисправностей, а сразу заменить коммутатор новым узлом. В принципе, в таком решении присутствует логика: во-первых , не придется тратить время на проведение проверки, во-вторых , поставив новую деталь, сразу станет понятно, в ней проблема или нет. Правда, переживать за потраченное время не нужно, ведь диагностика коммутатора не задержит вас надолго.

Выполнить проверку коммутатора можно двумя основными способами. Первый немного проще, и для него понадобится лампа-переноска. Алгоритм проведения процедуры в этом случае следующий:

1. Отсоединяем от катушки зажигания провод, идущий от клеммы коммутатора;

2. Подключаем освобожденный наконечник провода к контрольной лампе, а второй вывод лампы – к клемме катушки зажигания;

3. Включаем зажигание и проворачиваем коленчатый вал двигателя с помощью стартера.

Если при вращении коленвала контрольная лампа не мигает, значит, от коммутатора на катушку зажигания не исходят соответствующие импульсы тока. То есть деталь неисправна и требует замены. Для второго способа диагностики коммутатора вам потребуется больше инструментов, в том числе паяльник и металлический лист в роли «массы».

В этом случае последовательность выполнения проверочных действий несколько отличается. Для начала следует знать определенные обозначения, располагающиеся на корпусе устройства. Зачастую эти обозначения представлены в виде латинских букв (к примеру, B, C, T, K).

Во-вторых, нужно понимать, что при проверке устройства необходимо обращать внимание на надежность соединений, а на самом корпусе должен присутствовать хороший «минус». Довольно часто после длительных ремонтных работ или же под воздействием окислительных процессов в работе коммутатора возникают определенные неполадки, объясняющиеся «плохой массой».

Для проверки коммутатор вместе с катушкой зажигания необходимо поместить на один металлический лист, исполняющий роль «массы», и еще раз проверить надежность всех соединений, а также расстояние от катушки зажигания (точнее, «выхода на ней») до металлического листа. Значение этого расстояния должно соответствовать 15-25 мм.

На следующем этапе диагностики следует поочередно замыкать и размыкать провод, который должен идти на контакт коммутатора. Его подключают к контрольной 12-вольтной лампе, и по общим правилам сигнал блока не должен превышать 5 В.

Однако, если этих самых 12 В подавать кратковременно, то можно проверить коммутатор сразу в двух направлениях: на его исправность и на качество работы в «экстремальных» условиях.

Как и в первом варианте, для результативности проверочных работ необходимо провернуть мотор стартером, и если коммутатор находится в работоспособном состоянии, то вы увидите, как искра бьет в металлический лист (лампочка начинает светиться). Использование металлического листа – совсем необязательное условие, и можно обойтись без него (как описано в первом варианте); главное, чтобы имелась хорошая «масса».

Для проверки работоспособности внутреннего коммутатора выполняют все те же действия, только уже снимается и подставляется другой контакт.

3. Материалы для проверки коммутатора

Для выполнения проверки коммутатора, в обоих вышеописанных случаях вам понадобится контрольная лампа с номинальным напряжением в 12 В и стандартный набор ключей, с помощью которых можно убедиться в наличии или отсутствии импульсов (то есть в исправности самого устройства). Второй вариант диагностики предусматривает присутствие и других элементов: самой обычной кнопки, паяльника и металлического листа в качестве «массы».

Однако, если вы совсем не желаете тратить время, тогда для проверки исправности коммутатора вам всего лишь необходимо купить новое устройство. Если после установки все будет нормально, значит, проблема и правда была в старом элементе.

Подписывайтесь на наши ленты в

Сети и сетевые устройства становятся все более сложными. Расширение предприятия, конвергенция в ЦОДе и реализация новых услуг требуют слаженной совместной работы различных сетевых технологий и устройств.

Поскольку различные специализированные сети объединяются в одну сеть, передающую голос, видео, данные и беспроводный трафик, важно, чтобы производители коммутаторов и маршрутизаторов проверяли масштабируемость, стабильность функционирования и производительность своих разработок.

Сервис-провайдеры должны поддерживать мультисервисное обслуживание на единой IP-сети, чтобы обеспечивать своим клиентам возможность использования таких все более популярных сетевых служб, как YouTube, Facebook и службы однорангового (peer-to-peer — P2P) обмена информацией. Потребность в более широкой полосе пропускания и необходимость предоставлять все больше услуг обусловливают усложнение сетей и сетевых устройств, а также увеличение их производительности. Провайдерам следует тщательно проверять возможности своих сетей дифференцированно обслуживать (на основе сконфигурированных правил системной политики в области QoS и требований SLA) трафик различных сервисов, а также определять влияние новых приложений на работу имеющихся сетевых служб.

В ЦОДе трафик ЛВС и трафик сети хранения данных (Storage Area Network — SAN) традиционно передавались по отдельным сетям Ethernet и Fibre Channel. Появление недорогих средств 10GE создало экономический стимул к объединению этих сетей с использованием новых компонентов DCB (Data Center Bridging), включая коммутаторы FCoE (Fibre Channel over Ethernet) и решения для SAN.

Решения Ixia

Решения Ixia обеспечивают всестороннее тестирование совместимости, производительности и масштабируемости сетевого оборудования. Тестовое приложение IxNetwork компании Ixia представляет собой самое полное в отрасли решение для функционального и нагрузочного тестирования этого оборудования посредством эмуляции протоколов маршрутизации, коммутации, MPLS, IP multicast, широкополосного доступа и аутентификации.

Тестовые порты Ixia точно имитируют сетевую среду масштаба Интернета, содержащую тысячи маршрутизаторов и коммутаторов, миллионы маршрутов и достижимых хостов. Можно легко сконфигурировать миллионы потоков трафика для определения и контроля производительности плоскости данных.

Возможна имитация действий групп пользователей (в масштабе города), использующих разнообразные сервисы, включая веб, e-mail , FTP, P2P, VoIP и видеосервисы. Средства Ixia позволяют проводить стресс-тестирование даже самого мощного сетевого оборудования.

Нагрузочные модули Ixia имеют множество тестовых портов и поддерживают сетевые интерфейсы всех типов. Интерфейсы Ethernet в этих модулях работают в полном диапазоне скоростей — от 10 Мбит/с до 400 Гбит/с. Для оценки скорости и надежности продвижения (forwarding) данных трафик генерируется на полной линейной скорости.

Для выполнения сложных тестов решения Ixia обеспечивают:

• моделирование миллионов сервисов с детерминированными профилями трафика;
• задание различных профилей трафика (с управляемой скоростью передачи) для каждого сервиса;
• проверку выполнения SLA (путем динамической модификации профилей трафика);
• выдачу статистики по сервисам и пользователям.

Тестовые порты Ixia имитируют сложную сетевую среду в процессе тестирования инфраструктурного сетевого устройства

С помощью графического пользовательского интерфейса тестового приложения IxNetwork можно легко конфигурировать имитацию сложных топологий VPN уровней 2 и 3. Средства тестирования хорошо масштабируются, что позволяет проводить стресс-тестирование мощнейших BGP- и MPLS-маршрутизаторов. Каждый тестовый порт, будучи оборудованным процессором, может реализовать сотни LDP-сеансов и тысячи классов эквивалентности продвижения (FEC), а также сотни VPN-сессий и тысячи VPN-маршрутов. Для одновременного тестирования плоскости данных и плоскости управления трафик, передаваемый по VPN, может генерироваться на полной линейной скорости.

Тестовое приложение IxNetwork идеально подходит как для интерактивной разработки тестов, так и для их автоматизированного выполнения. Простые в использовании графические интерфейсы и программы-мастера помогают организовывать имитацию сложных сетей и различных видов трафика. С помощью агрегированной статистической информации, а также статистики по пользователям, виртуальным ЛВС (ВЛВС) и VPN можно быстро идентифицировать любой сбой или неправильно работающий сервис. Решение Test Composer с графическим пользовательским интерфейсом обеспечивает автоматизацию тестирования, а утилита ScriptGen транслирует установки, сделанные в графическом интерфейсе, в код сценария. Quicktests реализует основанные на стандартах методики тестирования. Для автоматизации тестирования приложение IxNetwork предоставляет полнофункциональные интерфейсы API .

Тестирование неуправляемых коммуторов включает в себя физическое тестирование в реальной сети, анализ полученных данных и субъективные оценки функциональности и дизайна коммутатора.

Для первой части использовалась утилита IOMeter, разработанная компанией . Больше компания не развивала этот продукт. Но некоторое время назад на сайте появилась новая версия . К сожалению, она еще достаточно сырая - часто зависала во время тестирования. Поэтому в тестах используется версия программы от Intel.

IOMeter, работая на транспортном уровне и используя протокол TCP, позволяет генерировать трафик с заданными параметрами, а также собирать по нему статистику. Для трафика можно задавать множество параметров, но нас интересовала генерация трафика максимальной интенсивности, поэтому было выбрано:

• тип передачи - 100% последовательная
• вид передачи - 100% запись
• размер блока данных - 64KB (это не размер кадра ethernet, а блок данных, которым оперирует программа)
• время задержки при передаче пакетов - минимально.

Для снятия скоростных показателей передачи данных использовалась системная утилита операционной системы "Perfomance Monitor".

Для тестирования строилась одноранговая локальная сеть Fast Ethernet из пяти компьютеров:

• Платформа - Asus Terminator
• Процессор - VIA C3 866MHz
• Память - 128MB SDRAM
• Жесткий диск - Maxtor 20GB
• ОС - Windows2000 Pro +SP2

В качестве сетевых адаптеров использовались Intel Pro/100+ Management Adapter и 3COM 3c905B-TX с последними драйверами с сайта производителей. Сетевые карты Intel использовались только во множественных тестах (где работают больше двух компьютеров одновременно) и только на скоростях 100Mbit. Тесты с участием только двух компьютеров и где изменяется режимы работы сетевых карт (скорости и дуплекса), прогонялись на сетевых адаптерах от 3COM. Это связано с тем, что в процессе тестирования выяснилось - невозможно однозначно установить режим дуплекса и контроля потока при скорости 10Mbits на Intel адаптерах со стороны драйвера. К примеру, хотя последний и рапортует о выставлении 10Mbits/FDX/Flow=on, вполне вероятно что адаптер, тем не менее работает на 10Mbits/HDX/Flow=off. Но при выставлении нужной скорости со стороны управляемого коммутатора, адаптер правильно на нее переключался. Эта ситуация проверялась на разных компьютерах/драйверах и управляемых коммутаторах (Intel 460T и нескольких моделях от Cisco).

Настройки сетевых адаптеров:

• Flow Control Settings (управление потоком) - включено
• QoS packet tagging (приоритетная обработка кадров) - запрещено.
• Link Speed & Duplex (скорость передачи и дуплекс) - менялась в зависимости от конкретного теста.

Физическое тестирование

Из списка тестов были убраны большинство пунктов с одностороннем тестированием, так как по предыдущем тестам видно, что результаты двусторонних (с передачей трафика в обе стороны) тестов подобны результатам односторонних.

• 1. Максимальная загрузка коммутатора.
  • Задействуются восемь портов (или пять в случае пяти-портового) портов коммутатора.
  • Скорость передачи - 100Mbits, Full Duplex.
  • Устанавливаем режим передачи трафика "все со всеми" - каждый хост передает и принимает данные с остальных хостов. Число хостов (сетевых адаптеров) равно числу портов коммутатора.
  Таким образом мы имитируем общение всех компьютеров друг с другом, выясняем, выдерживает ли коммутатор подобную нагрузку, и смотрим скорость передачи данных на каждом из портов.
• 2. Передача данных между двумя портами при отсутствии трафика на остальных (идеальный случай).
  • 2.1 Односторонняя передача из 100Mbits Full Duplex в 100Mbits порт Full Duplex.
  • 2.2 Двусторонняя передача между 100Mbits Full Duplex и 100Mbits портами Full Duplex.
  Тут, скорее всего, результаты окажутся одинаковыми у большинства коммутаторов, так как это идеальный случай и щадящий режим для устройства. Тем не менее, здесь мы определяем максимально достижимую скорость передачи данных между двумя клиентами.
• 3. Передача данных между 100Mbits Full Duplex и 10Mbits сегментами.
  Здесь мы выясняем качество коммутации между сегментом 100Mbits Full Duplex (другой коммутатор или клиент) и 10Mbits сегментом с различными параметрами дуплекса.
  • 3.1 Двусторонняя передача между 100Mbits Full Duplex в 10Mbits Full Duplex портами.
  • 3.2 Двусторонняя передача между 100Mbits Full Duplex в 10Mbits Full Half портами.
• 4. Передача данных между 100Mbits Half Duplex и 10Mbits сегментами.
  Смотрим коммутацию сегментом 100Mbits Half Duplex (обычно 100Mbits концентратор) и 10Mbits сегментом с различными параметрами дуплекса.
  • 4.1 Двусторонняя передача между 100Mbits Half Duplex и 10Mbits портами Full Duplex.
  • 4.2 Двусторонняя передача между 100Mbits Half Duplex и 10Mbits портами Half Duplex.
• 5. Передача данных между двумя 10Mbits портами.
  Конечно, обычно нет смысла подключать 10Mbits сетевые адаптеры к 100Mbits порту при сегодняшних ценах на Fast Ethernet платы, но тем не менее такое бывает. Ну а установка коммутаторов в центре звезды из концентраторов или просто объединения двух 10Mbits сегментов является обычной практикой. Поэтому рассмотрим и такую возможность.

  Эмуляция работы двух рабочих станций с 10Mbits сетевыми адаптерами или передачи данных между двумя 10ти мегабитными концентраторами.

  • 5.1 Двусторонняя передача между 10Mbits Full Duplex и 10Mbits Full Duplex портами.

    Моделируем подключение двух концентраторов к портам коммутатора.

  • 5.2 Двусторонняя передача между портами 10Mbits Half Duplex и 10Mbits Half Duplex.

    Моделируем подключение концентраторов к одному из портов коммутатора и 10Mbits сетевого адаптера к другому.

  • 5.3 Двусторонняя передача между портами 10Mbits Full Duplex и 10Mbits Half Duplex.
• 6. Передача данных между 100MBit портами c различными параметрами дуплекса.
  Эмулируется наличие коммутатора или концентратора на одном из портов (100Mbits) и 100Mbits концентратора на другом.
  • 6.1 Двусторонняя передача между 100Mbits Full Duplex и 100Mbits портами Half Duplex.
  • 6.2 Двусторонняя передача между двумя 100Mbits Half Duplex портами.

Возможно, более наглядно это будет представить в виде таблицы:

Анализ полученных данных

Для сравнения коммутаторов между собой будем использовать безразмерные интегральные показатели. Для начала результат каждого теста конвертируется в безразмерную величину по следующим правилам:

• Максимальную теоретическую скорость в текущем тесте, берем за единицу или 100%
• Максимальная скорость для тестов 100MBit, Full Duplex равна 100,000,000/8/1024 = 12,207KB
• Максимальная скорость для тестов 100MBit, Half Duplex (при двусторонней передаче данных) равна 100,000,000/8/1024/2 = 6,107KB
• Максимальная скорость для тестов с участием 10MBit, Full Duplex портов равна 10,000,000/8/1024 = 1,221KB
• Максимальная скорость для тестов с участием 10MBit, Half Duplex портов (при двусторонней передаче данных) равна 10,000,000/8/1024/2 = 610KB
• Скорость передачи данных текущего теста принимается за X% и рассчитывается исходя из пропорции.
  Например, безразмерный показатель для значения 800Kb, снятого при тестировании пункта 6.1 рассчитывается как
  800/1221 = 0.66

Очевидно, что теоретически рассчитанный максимум не достижим практически. Хотя бы потому, что часть пропускной способности съедается служебными заголовками протоколов более низких уровней. Поэтому величина порядка 0.9 уже говорит об очень хорошем результате в тесте.

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

Теперь рассмотрим деление тестов на группы и их весовые коэффициенты:

Весовые коэффициенты выбирались эмпирическим путем. Статистики по использованию коммутаторов в различных режимах у меня нет.

Функциональность и дизайн

Под функциональностью понимается как наличие дополнительных возможностей (типа QoS), так и "информативность" коммутатора. Так как для неуправляемых коммутаторов единственный способ передачи информации и статистики о своей работе - это светодиодные индикаторы, то оцениваем их количество и способность отразить максимум информации о порте - скорость работы, наличие полного дуплекса, обнаружение коллизии, индикация передачи данных, информацию об аварийном отключении порта. А также индикатор питания. В эту же категорию относим наличие (или соответственно отсутствие) порта "uplink".

К дизайну отнесем размеры коммутатора (относительно количества его портов), возможность установки на горизонтальные поверхности и наличие крепежных отверстий для установки устройства на стену, удобство расположения (обзора) индикаторов, ну и его внешний вид.

Естественно, это не окончательный вариант методики, она будет дополняться шлифоваться. Любые Ваши предложения высказывайте в .

Почему коммутаторы? Почему гигабитные? Зачем небольшому офису или дому такое устройство. Можно обойтись либо более дешевым 100мегабитным коммутатором, либо вообще воспользоваться беспроводным подключением, так популярным сейчас.

Но ответ не так прост. Во-первых, на большинстве современных материнских плат или ноутбуков по умолчанию установлены гигабитные сетевые карты. Во-вторых, стоимость гигабитных коммутаторов (иное название свитч, англ. switch) существенно сократилась. В-третьих, нет альтернативы, если идет речь о копировании больших объемов данных в сети, например, резервном копировании информации на другое устройство.

В качестве примера можно посмотреть на график типичного времени копирования информации с одного стандартного CD диска объемом 700Мб в различных типах сети.

Из графика видно, что пока альтернативы у гигабитной сети просто нет.

В тест была отобрана широкая группа коммутаторов со стоимостью в диапазоне от 18 до 140 долларов США. Одна часть коммутаторов оснащена 5ю портами, другая – 8ю портами. Также некоторые коммутаторы оснащены функциями управления, как, например, настройка качества обслуживания (QoS), позволяющей улучшать качество VoIP телефонии в нагруженных сетях или создание виртуальных сетей (VLAN), по сути разделения портов коммутатора на несколько независимых сетей и т.д.

В тест попали:

Главный вопрос состоит в том, насколько отличается производительность данных устройств при столь значительной разнице в цене.

Для тестирования использовалась известная программа IxChariot компании Ixia. В качестве оборудования были подготовлены 4 мощных компьютера с высококачественными сетевыми картами Intel 82556DM Pro. Всего было проведено 4 теста:

1. Отправка больших файлов размером 512Мб с одного компьютера на другой (полу дуплекс). В тесте участвуют 2 компьютера.
2. Отправка большого количества маленьких файлов размером 4Кб с одного компьютера на другой (полу дуплекс). В тесте участвуют 2 компьютера.
3. Отправка больших файлов размером 512Мб по кругу (полный дуплекс). В тесте участвуют 4 компьютера. Первый компьютер отправляет файлы второму, второй третьему, третий четвертому, а четвертый первому одновременно.
4. Отправка большого количества маленьких файлов размером 4Кб по кругу (полный дуплекс). В тесте участвуют 4 компьютера. Первый компьютер отправляет файлы второму, второй третьему, третий четвертому, а четвертый первому одновременно.

Также было протестированы коммутаторы на предмет потребления электроэнергии в активном режиме и в состоянии ожидания.

Результаты оказались совершенно неожиданными. Разница в пропускной способности между самыми быстрыми и самыми медленными оказалась достаточно небольшой, тем более учитывая, что цены отличаются в разы. В тесте с большими файлами между двумя компьютерами, самой высокой была скорость 920 Мбит/с, а самая низкая 901 Мбит/с. Разница менее одного процента! Тест с большим количеством маленьких файлов между двумя компьютера показал бОльшую разбежку 148 Мбит/с против 138 Мбит/с, то есть разница чуть выше 7%. В тесте с полной нагрузкой с большими файлами между четырьмя компьютерами разница между лидером и аутсайдером составила уже 12%, 2800Мбит/c и 2500Мбит/c соответственно. Ну и наконец тест с полной нагрузкой и с большим количеством маленьких файлов показал разницу между лучшим и худшим значением 5%, что в результатах значится, как 540Мбит/с и 514Мбит/с. Самым же большим удивлением было то, что в лидерах оказались совсем недорогие устройства. В повседневном использовании различия в скорости будут практически незаметны.

Также было проведено измерение потребляемой электроэнергии. Казалось бы, какая разница, если идет речь о 5-10 Ватт. Тем не менее, в течение года экономия может быть достаточно ощутимой, особенно в конфигурациях включающих несколько таких коммутаторов. Сравнительные тесты показали, что по данному параметру отличия между устройствами были значительно более ощутимыми. Лидером по энергопотреблению оказался D-link. С четырьмя подключенными компьютерами он потребляет 4,9 Ватт, в холостом режиме лишь 1,8 Ватта. Для сравнения 8-портовая модель Belkin потребляет 9,6 и 7,9 Ватта соответственно.

В результате проведенных тестов можно утверждать, что большая ценовая разница практически не влияет на быстродействие. Если же соотнести все результаты тестов и сравнить с ценами на устройства, то лидером окажется устройство компании TP-LINK TL-SG1005D. Также близки по этим параметрам коммутаторы от компаний Belkin, Konig и LevelOne. Экономичность коммутатора от D-link является скорее рекламным трюком, так как он существенно экономичнее только при отсутствии нагрузки. В рабочем режиме разница с ближайшим конкурентом составила около 0,5 ватта. Разница же с лидером теста коммутатором TP-LINK составляет всего около одного ватта, что обыкновенного пользователя вообще не должно интересовать, при этом TP-LINK был быстрее практически во всех тестах. Смысл покупать дорогой коммутатор от Linksys или 3Com есть только в том случае, если вам действительно нужны дополнительные функции управления. На скорость, как видно из тестов цена практически не повлияла.