начало выбор продуктов   карта сайта контакт поддержка english
  о наспродукты и решенияit-услугитренингикупить  
 

о насотзывыпубликациипартнерствовакансии

 
публикации

 

- White Papers
- Публикации на сайте
- Буклеты ProLAN
- Публикации в журналах
- Статьи из Базы Знаний
Дефекты сетей
Другое
О производительности
Программы 1С
Программы БЭСТ
Программы Инотек
Программы Парус

- Пресс-релизы
- Клуб Экспертов

 

Перейти в раздел Базы Знаний:

Посмотреть результаты публикации

 

Дополнительно:

Загрузить данный документ в формате pdf

 

 

к выбору публикации

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

эксперт Сергей Поповский popovsky@iba.com.by

Анализ компьютерных сетей в первую очередь связан с нахождением ошибок и определением их реального влияния на работу сети. Однако существует много мнений относительно того, какие ошибки могут появляться, а какие нет и каким должно быть их количество при нормальной работе сети. Причем обычно говорят о проблемах с коллизиями и широковещательными пакетами, но крайне редко о сетевых ошибках, таких как CRC, Alignments, Fragment и т.п. Для определения того, как коллизии и ошибки влияют на работу приложений в сети, было проведено тестирование.

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

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

Было проведено два эксперимента. В первом исследовалась зависимость производительности приложения от коллизий, во втором от ошибок CRC.

Схема стенда приведена на рис.1.

 

Рисунок 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 сеть становится практически неработоспособной.

наверх

о нас   продукты и решения   it-услуги   тренинги   купить  
начало   карта сайта   контакт   поддержка   english