Оценка задержки передачи кадров в сетевых адаптерах

Бойченко М.К.; Иванов И.П.; Лохтуров В.А.

УДК 004.724; 004.728

ОЦЕНКА ЗАДЕРЖКИ ПЕРЕДАЧИ КАДРОВ В СЕТЕВЫХ АДАПТЕРАХ

М.К. Бойченко, И.П. Иванов, В.А. Лохтуров

МГТУ им. Н.Э. Баумана, Москва, Российская Федерация e-mail: noc@bmstu.ru; ivanov@bmstu.ru

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

Ключевые слова: компьютерная сеть, компьютерные технологии, утилита, модификация, операционная система, сетевой интерфейс.

EVALUATION OF FRAME TRANSMISSION DELAY IN NETWORK INTERFACE CARDS

M.K. Boichenko, I.P. Ivanov, V.A. Lokhturov

Bauman Moscow State Technical University, Moscow, Russian Federation e-mail: noc@bmstu.ru; ivanov@bmstu.ru

The method is proposedfor evaluating a delay of information transmission by network adapters in the computer networks, built according to Ethernet technology, as one of components of the network response time. The evaluation was conducted as measurement of the round trip time of the frame passage in forward and reverse directions between the source computer and the destination computer connected with a crossover cable. In this case, the time of the similar frame passage using the IP address 127.0.0.1 has been taken into account, which excludes the frame transmission using the network adapter into the segment of the network. This method requires no special equipment and is based on the modified software of network operating systems, due to which it is accessible for using by a system administrator on any hardware platform and with any operating system in corporate networks of different size.

Keywords: computer network, computer technologies, utility, modification, operating system, network interface.

К основным характеристикам производительности компьютерных сетей кроме прочих показателей относят задержку передачи и вариацию задержки передачи [1, 2]. Задержка передачи определяется как интервал времени между моментом поступления информации на вход какого-либо сетевого устройства и моментом ее появления на его выходе [3]. Задержка передачи — составляющая времени реакции сети, знание задержки передачи позволяет оценить производительность

отдельных маршрутов в транспортной системе и компьютерной сети в целом, выявляя и модернизируя "узкие места" [4]. Обязательным элементом оконечных узлов компьютерных сетей являются сетевые адаптеры. В настоящее время как для компьютеров пользователей, так и для серверов применяются сетевые адаптеры четвертого поколения, построенные на интегральных схемах ASIC (Application-Specific Integrated Circuit) и выполняющие большое количество высокоуровневых сетевых функций (приоритезация кадров, поддержка агента удаленного мониторинга, поддержка автоконфигурирования и т.п.). В серверных вариантах адаптеров используется процессор, разгружающий центральный процессор компьютеров. Кроме того, для серверов возможно использование сетевых сопроцессоров [5]. Однако значение задержек передачи ни на сетевых адаптерах, ни на сетевых сопроцессорах фирмы-производители не указывают. Пропускная способность и задержка передачи — независимые характеристики [1]. Если сетевой адаптер клиентского компьютера или сервера работает медленно, то никакие высокопроизводительные транспортные системы компьютерной сети не смогут снизить время ее реакции и повысить производительность в целом [6].

Передача пересылаемых пакетов из буфера оперативной памяти компьютера в аппаратный буфер сетевого адаптера требует временных затрат, независимо от наличия у адаптера канала прямого доступа к памяти (Direct Memory Access, DMA) или отсутствия такового, т.е. при передаче через общую шину компьютера [5]. Обмен информацией между оперативной памятью и аппаратным буфером адаптера может осуществляться одновременно с передачей в сегмент информации, ранее помещенной в буфер (конвейерная схема обработки кадров). В этой ситуации сложно установить, что принять за задержку передачи собственно сетевого адаптера, так как до момента помещения в его аппаратный буфер первого байта полезной информации (в случае IP-пакета — первого байта заголовка) в буфер необходимо поместить шесть байтов MAC-адреса назначения, шесть байтов MAC-адреса источника и минимум два байта с размером кадра [1, 2]. Вывод информации в сегмент начинается с последовательной передачи восьми байтов (преамбула и стартовый байт), а заканчивается передачей дополнительно четырех байтов контрольной суммы и выдержкой 12-байтового межкадрового интервала: если размер передаваемого IP-пакета составляет Lp байтов, то в сегмент передается Lp + 38 байтов, на что необходимо потратить время, соответствующее 8 (Lp + 38) бит-таймам (bt) принятой технологии передачи информации. Для каналов Fast Ethernet длительность одного бит-тайма составляет 10 нс, для технологии Gigabit Ethernet — 1 нс. Необходимость измерений с

точностью до наносекунды усложняется еще и проблемой синхронизации, поскольку следует четко фиксировать байты какого-либо поля кадра [7]. Сложность синхронизации двух компьютеров препятствует применению прямых измерений временных интервалов при передаче информации между ними. В связи с этим управляющие процедуры и методы измерений основаны на определении времени двойного прохождения информации от компьютера-источника до компьютера-приемника и обратно (Round Trip Time, RTT) [2]. Так, широко распространенная утилита ping дает возможность вычислить значение RTT при прохождении пакета ICMP (Internet Control Message Protocol) между двумя хостами в сети. При этом могут варьироваться размер посылаемого пакета ICMP (размер эхо-запроса), число посылаемых эхо-запросов, интенсивность их посылки [8]. В ответ на каждый эхо-запрос запрашивающий компьютер получает эхо-ответ от запрашиваемого хоста. Содержимое полезной информации в эхо-ответе идентично содержимому в эхо-запросе. Сравнением информации в эхо-запросе и эхо-ответе устанавливается факт отсутствия потерь информации при передаче. В результате проведения серии измерений значения RTT утилита ping позволяет определить его минимальное (min), среднее (avg), максимальное (max) значения, среднеквадратичное отклонение (mdev), время выполнения серии посылок (time) и процент пакетов в серии, искаженных при пересылке. Точность измерений в утилите ping составляет миллисекунды, что достаточно для ее назначения [8]. Вместе с тем в работе [9] предложено существенное повышение точности измерений в утилите ping путем замены функции gettimeofday( ) функцией clock_gettime( ) в надлежащих программных модулях утилиты. С помощью такой модернизированной утилиты nanoping можно измерять значение RTT в наносекундах, что существенно расширяет диапазон возможных экспериментальных исследований в узлах и сегментах компьютерных сетей [10].

Предлагаемая методика оценки задержки передачи информации сетевыми адаптерами основана на известном соглашении о специализированном IP-адресе 127.0.0.1, именуемом loopback [1, 2, 4]. При таком адресе получателем информации является хост-источник. Особенность пересылки пакетов заключается в прямой передаче IP-пакета из одного буфера оперативной памяти в другой, минуя сетевой адаптер компьютера. Если измерить значение RTT при выполнении утилиты nanoping по адресу 127.0.0.1, то можно узнать задержку обработки отсылаемого и принимаемого пакета собственно в компьютере. Далее, осуществив кроссовую коммутацию двух сетевых адаптеров идентичных компьютеров, можно определить значение RTT при реализации утилиты nanoping с пересылкой пакета от компьютера-источника

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

Процессор

root@nodeN:# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 2

model name : Intel(R) Pentium(R) 4 CPU 2.40GHz

stepping : 9

cpu MHz : 2393.778

cache size : 512 KB

Оперативнаяпамять

root@nodeN:# cat /proc/meminfo

MemTotal: 347216 kB

Сетеваякарта

root@nodeN:# dmesg

[ 1.437220] eth0: SiS 900 PCI Fast Ethernet at 0x8800, IRQ 19,

00:11:2f:40:42:e8

root@nodeN:# ethtool eth0

Settings for eth0:

Speed: 100Mb/s

Duplex: Full

На указанные компьютеры была установлена операционная система Linux, описание которой представлено ниже: Операционная система root@nodeN:# uname -a

Linux node1 2.6.32-21-generic-pae #32-Ubuntu SMP Fri Apr 16 09:39:35

UTC 2010 i686 GNU/Linux

root@nodeN:# lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 10.04 LTS

Release: 10.04

Codename: lucid

Далее описаны настройки систем сетевых адаптеров для этих компьютеров:

Настройки систем root@node1:# ifconfig

eth0 Link encap:EthernetHWaddr 00:11:2f:40:42:e8

inet addr:10.20.32.46 Bcast:10.20.32.255 Mask:255.255.255.0

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0

root@node2: # ifconfig

eth0 Link encap:EthernetHWaddr 00:11:2f:40:49:d4

inet addr:10.20.32.47 Bcast:10.20.32.255 Mask:255.255.255.0

lo Link encap:Local Loopback inetaddr:127.0.0.1 Mask:255.0.0.0

Экспериментальные исследования заключались в посылке эхо-запросов и в приеме эхо-ответов пакетов ICMP различной длительности с разной интенсивностью. Интервал между посылками пакетов назначался с таким расчетом, чтобы исключить возможную потерю пакетов вследствие блокировки (At = 0,01 с). Размер пакетов ICMP варьировался в диапазоне значений 32... 1460 байт. В процессе обмена информацией операционные системы указанных компьютеров не выполняли никаких других задач. Ниже приведены результаты выполнения утилиты nanoping для серий, состоящих из 10 000 пакетов каждая:

root@node1:# nanoping -i.01 -s32 -c10000 127.0.0.1 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 15801/16798/109948/1107 ns

root@node1:# nanoping -i.01 -s32 -c10000 10.20.32.47 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 62078/65240/175071/1392 ns

root@node1:# nanoping -i.01 -s64 -c10000 127.0.0.1 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 15745/16710/103935/1019 ns

root@node1:# nanoping -i.01 -s64 -c10000 10.20.32.47 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 68715/72181/2052027/19816 ns

root@node1:# nanoping -i.01 -s128 -c10000 127.0.0.1 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 16323/17267/104533/1076 ns

root@node1:# nanoping -i.01 -s128 -c10000 10.20.32.47 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 81679/85064/2038144/20069 ns

root@node1:# nanoping -i.01 -s256 -c10000 127.0.0.1 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 16664/17660/101395/1005 ns

root@node1:# nanoping -i.01 -s256 -c10000 10.20.32.47

10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 108180/111375/208010/1354 ns

root@node1:# nanoping -i.01 -s512 -c10000 127.0.0.1 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 16720/18284/106401/1068 ns

root@node1:# nanoping -i.01 -s512 -c10000 10.20.32.47 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 161489/164816/497557/3665 ns

root@node1:# nanoping -i.01 -s1024 -c10000 127.0.0.1 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 19848/21292/106741/1188 ns

root@node1:# nanoping -i.01 -s1024 -c10000 10.20.32.47 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 266331/269774/638385/4007 ns

root@node1:# nanoping -i.01 -s1460 -c10000 127.0.0.1 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 21636/22898/108414/1124 ns

root@node1:# nanoping -i.01 -s1460 -c10000 10.20.32.47 10000 packets transmitted, 10000 received, 0% packet loss rtt min/avg/max/mdev = 356626/360103/463648/1656 ns

Обработка результатов проводилась по следующему алгоритму.

1. Определение по длине пересылаемого и возвращаемого пакета ICMP размера IP-пакета Lp = L+28 и размера Ethernet-кадра (фрейма), байт:

Lf = L + 38 + 20 + 8 = Lp + 38,

где 20 — длина заголовка IP-пакета; 8 — длина заголовка эхо-запроса и эхо-ответа для пакета ICMP длиной L.

2. Установление суммарной длительности на пересылку эхо-запроса и эхо-ответа в Ethernet-кадрах

Tf = 16Lf T,

где t — длительность бит-тайма (10 нс для пропускной способности адаптеров 100 Мбит/с).

3. Расчет задержки в сетевом адаптере At на передачу и прием Ethernet-кадров с эхо-запросом и эхо-ответом. Из среднего значения RTT, полученного в результате посылки эхо-запроса по IP-адресу компьютера-приемника, вычитается среднее значение RTT, определенное при посылке эхо-запроса по loopback, и соответствующее значение Tf. Результат вычитания делится пополам и характеризует задержку в адаптере. Результаты расчетов для той же серии экспериментов приведены ниже:

L, байт....................................32 64 128 256 512 1024 1460

Lp, байт ................................60 92 156 284 540 1052 1488

Lf, байт ................................98 130 194 332 578 1090 1526

Tf, нс ......................................15 120 20 240 30480 52 560 91920 173 840 243 600

Ar, нс ....................................16661 17615 18658 20577 27306 37321 46802

Анализ величин Дт в зависимости от длины передаваемых IP-пакетов позволяет предположить линейную связь задержки Дт и размера Lp: Дт = ALp + B, где A и B — коэффициенты, которые могут быть найдены методом наименьших квадратов при решении системы линейных уравнений

£ L^i + B £ Lpi = £ L^;

i=1 i=1 i=1

A £ Lpi + 7B = £ Дт.

i=l i=l

Решая систему, определяем следующие значения: А = 21,08 нс/байт, B = 15487,6 нс, т.е. Дт = 21,08Lp + 15487,6 нс.

Сравнение теоретических значений RTT с экспериментальными средними (avg) значениями дает максимальную относительную погрешность 3,8 %, что вполне приемлемо для проведения необходимых поверочных расчетов при проектировании локальных вычислительных сетей. Дополнительно точность полученной зависимости задержки Дт от размера пакета Lp проверялась при передаче и приеме эхо-запросов и эхо-ответов для сетевых адаптеров на скорости передачи данных 10 Мбит/с. Предполагалось, что задержки в адаптерах и средние значения RTT при выполнении утилиты nanoping по IP-адресу 127.0.0.1 постоянны. Изменяется только длительность бит-тайма (т = 100 нс) и, следовательно, для тех же размеров пакетов ICMP в 10 раз возрастают значения суммарной длительности тf. Результаты одной из серии замеров значения RTT при пропускной способности сетевых адаптеров 10 Мбит/с приведены ниже:

nanoping —1.01 -s32 -c10000 node2