 |
Анализ влияния коллизий и ошибок на производительность сетевых приложений
эксперт Сергей Поповский popovsky@iba.com.by
Анализ компьютерных сетей в первую очередь связан с нахождением ошибок и определением их реального влияния на работу сети. Однако существует много мнений относительно того, какие ошибки могут появляться, а какие нет и каким должно быть их количество при нормальной работе сети. Причем обычно говорят о проблемах с коллизиями и широковещательными пакетами, но крайне редко о сетевых ошибках, таких как CRC, Alignments, Fragment и т.п. Для определения того, как коллизии и ошибки влияют на работу приложений в сети, было проведено тестирование.
В эксперименте рассматривались только ошибки CRC, но как будет показано далее - ошибки других типов, вызывающие повреждение пакета, приводят к тем же результатам.
Под ошибкой CRC будем понимать пакет с неверной контрольной суммой, т.е. поврежденный пакет. Вариантов, из-за чего может произойти повреждение очень много, но в данном исследовании интересен только результат потери пакета - механизм его повтора и, соответственно, влияние на производительность сетевых приложений. В принципе, коллизия также пакет с неверной контрольной суммой, но коллизия не является ошибкой работы сети.
Было проведено два эксперимента. В первом исследовалась зависимость производительности приложения от коллизий, во втором от ошибок CRC.
Схема стенда приведена на рис.1.
В качестве тестового приложения на рабочей станции запускалась задача обращения к файловой базе на сервере Novell, транспортный протокол – SPX. Используемая задача при работе в сети только сервера и клиента загружает канал 10 Мбит/с примерно на 3.6% и выполняется в течение 1,03 мин.
Для исследования коллизий, между коммутаторами был создан сегмент сети Ethernet с разделяемым доступом. Коммутаторы Cabletron SmartSwitch Router 2000 (более подробная информация на странице http://www.enterasys.com/products/items/SSR-2-B128) и 3Com Super Stack II 3300 (http://www.3com.com/products/switches/sw1100_3300_family.html) были подключены через концентратор 10 Мбит/с. Подобный канал можно было бы создать и конфигурированием портов коммутаторов в режим 10 Мбит/с HalfDuplex, но концентратор также предназначался для подключения аппаратно- программного анализатора WinPharaoh (http://www.gnnettest.com/pages/wp.htm), которым создавалась изменяющаяся фоновая нагрузка данного сегмента сети. Для создания в сети ошибок CRC (потерь пакетов с их повтором), порт коммутатора 3Com Super Stack II 3300, подключенный к концентратору, принудительно переводился в режим 10 Мбит/с FullDuplex. Кстати, весьма распространенная ошибка конфигурирования активного сетевого оборудования. В результате Super Stack II 3300 не “слушал” сеть, и пакеты уничтожались при столкновении с пакетами от WinPharaoh. Статистика количества коллизий и ошибок снималась с порта Super Stack II 3300, подключенного к концентратору, с помощью RMON модуля программного анализатора Observer (http://www.netinst.com/html/observer_suite.html).
Нагрузка в сети создавалась искусственным образом и никак не зависела от сетевых ошибок. Если бы нагрузка создавалась реальными приложениями, она бы снижалась при появлении ошибок и коллизий. Сервер был подключен через слабо загруженную рабочую сеть, нагрузка сервера другими пользователями не контролировалась. Однако эти условия крайне мало влияли на результат тестирования, в чем можно будет убедиться далее.
Тестирование проводилось пошагово. На каждом шаге нагрузка тестового сегмента сети с помощью WinPharaoh увеличивалась на 10%, одновременно измерялась общая нагрузка тестового сегмента, которая состояла из нагрузки от WinPharaoh и нагрузки от приложения. Среднее количество коллизий и ошибок в секунду в тестовом сегменте, т.е. их относительное число, измерялось с помощью опции анализатора Observer - Ethernet Vital Signs. Т.к. их количество во время выполнения тестовой задачи колебалось значительно, приведены минимальные и максимальные значения.
Перейдем к результатам тестирования. В первом тесте (таблица 1) видно, что при нагрузках сети до 60% время выполнения тестовой задачи росло незначительно. После 70% время выполнения тестовой задачи начинает резко расти, уменьшается нагрузка сети от тестовой задачи и начинает уменьшаться количество коллизий. Во-первых, столь большое количество коллизий, достигающее 180 в секунду при нагрузке сети 63,9%, слабо влияет на скорость работы тестового приложения. Во-вторых, относительное количество коллизий начинает снижаться после достижения пика производительности сети. Практически такой же эффект наблюдается при анализе ошибок и говорит только об одном – в результате слишком большого количества коллизий и ошибок начинает падать скорость работы приложения в сети, а соответственно и относительное количество коллизий и ошибок.
Таблица 1.
|
№ |
Время выполнения тестовой задачи, мин. |
Нагрузка тестового сегмента сети, создаваемая анализатором, % |
Нагрузка тестового сегмента сети (анализатор + приложение), % |
Среднее количество коллизий в секунду |
|
1 |
1.03 |
10 |
13.8 |
29 |
|
2 |
1.03 |
20 |
23.8 |
60-64.8 |
|
3 |
1.03 |
30 |
33.9 |
77-96 |
|
4 |
1.03 |
40 |
44 |
135-148 |
|
5 |
1.03 |
50 |
54 |
150-170 |
|
6 |
1.10 |
60 |
63.9 |
160-181 |
|
7 |
1.38 |
70 |
73.4 |
138-201 |
|
8 |
2.55 |
80 |
81.2 |
120-150 |
|
9 |
9 |
90 |
90.7 |
68-95 |
|
10 |
17.4 |
99 |
97.8 |
40-60 |
|
Во втором тесте (таблица 2) при 10% нагрузке сети время выполнения тестового задания начинает катастрофически расти, и уже при 50% нагрузке стало бессмысленным продолжать тестирование. Однако относительное количество ошибок в десятки раз меньше и на первый взгляд практически не может влиять на работу сетевых приложений.
Для понимания результатов экспериментов разберемся, как в сети отрабатываются коллизии и ошибки. В случае возникновения коллизии сетевой интерфейс сам повторяет передачу пакета, и происходит это примерно за 0,5 мсек. Повтором уничтоженных пакетов занимается по тайм-ауту транспортный уровень протокола передачи и, естественно, он не может быть столь малым, как в случае коллизии. Начальное значение тайм-аута для данного тестирования составляет примерно 0,2 сек. Данные были получены с помощью WinPharaoh при анализе захваченных пакетов. Начальные и последующие значения тайм-аута могут меняться для различных протоколов и сред передачи. Учитывая время передачи уничтоженного пакета и обработки ошибки, суммарное время повтора составляет примерно 0,5 сек, что в тысячу раз дольше, чем для обработки коллизии.
Таблица 1.
|
№ |
Время выполнения тестовой задачи, мин. |
Нагрузка тестового сегмента сети, создаваемая анализатором, % |
Нагрузка тестового сегмента сети (анализатор + приложение), % |
Среднее количество ошибок CRC в секунду |
|
1 |
2 |
10 |
12 |
4.6-7.2 |
|
2 |
3.08 |
20 |
21.3 |
4.5-7.2 |
|
3 |
4.26 |
30 |
31 |
4.5-7.7 |
|
4 |
10.42 |
40 |
40.5 |
0.7-5.7 |
|
5 |
25.40 |
50 |
50.4 |
0.5-4.3 |
|
6 |
- |
- |
- |
- |
|
7 |
- |
- |
- |
- |
|
8 |
- |
- |
- |
- |
|
9 |
- |
- |
- |
- |
|
10 |
- |
- |
- |
- |
|
Основным выводом является то, что коллизии мало влияют на производительность сети, с большим вниманием следует относиться к сетевым ошибкам. Также необходимо обратить внимание на то, что при кажущемся малом количестве ошибок CRC сеть становится практически неработоспособной.
|
к выбору публикации
