Анализ влияния коллизий и ошибок на производительность сетевых

эксперт Сергей Поповский popovsky@iba.com.by Анализ компьютерных сетей в первую очередь связан с нахождением ошибок и определением их реального влияния на работу сети. Однако существует много мнений относительно того, какие ошибки могут появляться, а какие нет и каким должно быть их количество при нормальной работе сети. Причем обычно говорят о проблемах с коллизиями и широковещательными пакетами, но крайне редко о сетевых ошибках, таких как CRC, Alignments, Fragment и т.п. Для определения того, как коллизии и ошибки влияют на работу приложений в сети, было проведено тестирование. В эксперименте рассматривались только ошибки CRC, но как будет показано далее - ошибки других типов, вызывающие повреждение пакета, приводят к тем же результатам. Под ошибкой CRC будем понимать пакет с неверной контрольной суммой, т.е. поврежденный пакет. Вариантов, из-за чего может произойти повреждение очень много, но в данном исследовании интересен только результат потери пакета - механизм его повтора и, соответственно, влияние на производительность сетевых приложений. В принципе, коллизия также пакет с неверной контрольной суммой, но коллизия не является ошибкой работы сети. Было проведено два эксперимента. В первом исследовалась зависимость производительности приложения от коллизий, во втором от ошибок CRC. Схема стенда приведена на рис.1. В качестве тестового приложения на рабочей станции запускалась задача обращения к файловой базе на сервере Novell, транспортный протокол – SPX. Используемая задача при работе в сети только сервера и клиента загружает канал 10 Мбит/с примерно на 3.6% и выполняется в течение 1,03 мин. Для исследования коллизий, между коммутаторами был создан сегмент сети Ethernet с разделяемым доступом. Коммутаторы Cabletron SmartSwitch Router 2000 (более подробная информация на странице ) и 3Com Super Stack II 3300 (http://www.3com.com/products/switches/sw1100_3300_family.html) были подключены через концентратор 10 Мбит/с. Подобный канал можно было бы создать и конфигурированием портов коммутаторов в режим 10 Мбит/с HalfDuplex, но концентратор также предназначался для подключения аппаратно- программного анализатора WinPharaoh ( ), которым создавалась изменяющаяся фоновая нагрузка данного сегмента сети. Для создания в сети ошибок CRC (потерь пакетов с их повтором), порт коммутатора 3Com Super Stack II 3300, подключенный к концентратору, принудительно переводился в режим 10 Мбит/с FullDuplex.Анализ влияния коллизий и ошибок на производительность сетевых Кстати, весьма распространенная ошибка конфигурирования активного сетевого оборудования. В результате Super Stack II 3300 не “слушал” сеть, и пакеты уничтожались при столкновении с пакетами от WinPharaoh. Статистика количества коллизий и ошибок снималась с порта Super Stack II 3300, подключенного к концентратору, с помощью RMON модуля программного анализатора Observer ( ). Нагрузка в сети создавалась искусственным образом и никак не зависела от сетевых ошибок. Если бы нагрузка создавалась реальными приложениями, она бы снижалась при появлении ошибок и коллизий. Сервер был подключен через слабо загруженную рабочую сеть, нагрузка сервера другими пользователями не контролировалась. Однако эти условия крайне мало влияли на результат тестирования, в чем можно будет убедиться далее. Тестирование проводилось пошагово. На каждом шаге нагрузка тестового сегмента сети с помощью WinPharaoh увеличивалась на 10%, одновременно измерялась общая нагрузка тестового сегмента, которая состояла из нагрузки от WinPharaoh и нагрузки от приложения. Среднее количество коллизий и ошибок в секунду в тестовом сегменте, т.е. их относительное число, измерялось с помощью опции анализатора Observer - Ethernet Vital Signs. Т.к. их количество во время выполнения тестовой задачи колебалось значительно, приведены минимальные и максимальные значения. Перейдем к результатам тестирования. В первом тесте (таблица 1) видно, что при нагрузках сети до 60% время выполнения тестовой задачи росло незначительно. После 70% время выполнения тестовой задачи начинает резко расти, уменьшается нагрузка сети от тестовой задачи и начинает уменьшаться количество коллизий. Во-первых, столь большое количество коллизий, достигающее 180 в секунду при нагрузке сети 63,9%, слабо влияет на скорость работы тестового приложения. Во-вторых, относительное количество коллизий начинает снижаться после достижения пика производительности сети. Практически такой же эффект наблюдается при анализе ошибок и говорит только об одном – в результате слишком большого количества коллизий и ошибок начинает падать скорость работы приложения в сети, а соответственно и относительное количество коллизий и ошибок. Таблица 1. Во втором тесте (таблица 2) при 10% нагрузке сети время выполнения тестового задания начинает катастрофически расти, и уже при 50% нагрузке стало бессмысленным продолжать тестирование. Однако относительное количество ошибок в десятки раз меньше и на первый взгляд практически не может влиять на работу сетевых приложений. Для понимания результатов экспериментов разберемся, как в сети отрабатываются коллизии и ошибки. В случае возникновения коллизии сетевой интерфейс сам повторяет передачу пакета, и происходит это примерно за 0,5 мсек. Повтором уничтоженных пакетов занимается по тайм-ауту транспортный уровень протокола передачи и, естественно, он не может быть столь малым, как в случае коллизии. Начальное значение тайм-аута для данного тестирования составляет примерно 0,2 сек. Данные были получены с помощью WinPharaoh при анализе захваченных пакетов. Начальные и последующие значения тайм-аута могут меняться для различных протоколов и сред передачи. Учитывая время передачи уничтоженного пакета и обработки ошибки, суммарное время повтора составляет примерно 0,5 сек, что в тысячу раз дольше, чем для обработки коллизии. Таблица 1. Основным выводом является то, что коллизии мало влияют на производительность сети, с большим вниманием следует относиться к сетевым ошибкам. Также необходимо обратить внимание на то, что при кажущемся малом количестве ошибок CRC сеть становится практически неработоспособной.

Hosted by uCoz