Сетевая карта собрана на тех же двух контроллерах, что и предыдущая. Но используется немного другая PCB и отсутствует радиатор на трансивере. В наличии три светодиодных индикатора, показывающих скорость работы 10/100/1000 Мбит и передачу данных мерцанием. Так как на сайте компании тоже отсутствовали новые версии драйверов, использовались те, что шли в комплекте.
Версия драйвера в Windows 2000 — тоже 5.0.1.24. Но его интерфейс предоставляет намного меньше настроек сетевого адаптера, чем у предыдущей карты. Настройки драйвера тоже были оставлены по умолчанию. Верхний предел размера Jumbo Frame неизвестен, но максимальный используемый при тестировании размер (16128 байт) устанавливался без проблем.
В ОС Linux поставляемые в комплекте драйвера тоже отказались собираться с установками по умолчанию, поэтому я попытался использовать встроенный в ОС драйвер (тот же, что и в предыдущем случае). Но возникла интересная проблема. В связке Linux-Linux карты не детектировали линк. То есть сетевые интерфейсы поднимаются, но линк отсутствует. При перезагрузке одного компьютера в Windows 2000 линк замечательно поднимался. Использовался как прямой, так и кросс-кабель — результат аналогичен. Ситуация повторилась с ядрами 2.4.17, .18 и .19. Поэтому тесты этого адаптера в ОС Linux отсутствуют.
Это уже одночиповое решение (более новое поколение), собранное на микроконтроллере Intel 82540EPВ
, который выполняет функции обоих чипов вышеописанных карт. Карта имеет два светодиодных индикатора, один из которых показывает наличие линка и передачи данных, а второй (двухцветный) — скорость работа 10/100/1000 Мбит. Некоторые параметры микроконтроллера: 1. поддержка скорости 10/100/1000 Мбит в режимах полу- и полного дуплекса;
2. MDI-X — автодетектирование прямого и кросс кабеля;
3. автодетектирование длины кабеля;
4. конфигурируемые очереди FIFO на прием и передачу, размером 64 КБ;
5. очереди приема/передачи с низким временем ожидания;
6. передача до 64 дескрипторов пакетов по шине за операцию;
7. программируемые буфера приема размером от 256 байт до 64 КБ;
8. ускорение обсчета контрольных сумм кадров протоколов IP, TCP, и UDP.
9. поддержка IEEE 802.1Q VLAN c установкой и удалением VLAN-тэгов, а также пакетная фильтрация до 4096 VLAN тагов;
10.средства контроля для уменьшения количества прерываний при работе;
поддержка Jumbo-фреймов размером до 16 КБ.
Драйверы для обоих ОС брались с сайта компании. Версия драйвера в Windows 2000 — 6.2.33.0, он предоставляет богатые возможности по конфигурированию адаптера. Тем не менее, настройки оставлялись по умолчанию. Как обычно, менялся только размер Jumbo Frame (он мог задаваться дискретными значениями: 4088, 9014, 16128 байт).
Linux-драйвер версии 4.3.15 собрался и заработал без проблем.
В качестве тестовых стендов использовались два компьютера со следующими параметрами:
Pentium 4 1,8 ГГц и 2,2 ГГц;
Память 512 Mб;
Жесткий диск Maxtor 20 Гб;
ОС Windows 2000 с установленным сервис-паком версии 3 и Linux Red Hat 7.3 с ядром версии 2.4.19
Компьютеры напрямую (без использования коммутатора) соединялись пятиметровым кабелем категории 5е (практически идеальные условия).
В Windows 2000 для генерации трафика и снятия показаний использовались программы Iperf версии 1.2 и NTttcp из Windows 2000 DDK. Обе программы запускались для снятия показателей скорости передачи данных и загрузки процессора при размерах Jumbo Frame
1514 байт (Jumbo-фреймы отсутствуют);
9014 байт;
16128 байт (драйвер адаптера Hardlink HA-32G этот размер не поддерживал)
Также осуществлялся небольшой тюнинг ОС. Параметры запуска программ и установки реестра следующие:
Максимальный размер пакета 1514 байт (Jumbo Frame отсутствуют)
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
TcpWindowSize = ffff
Параметры запуска Iperf:
клиент: iperf -c 10.0.0.1 -M 100000 -w 64K -l 24K
сервер: iperf -s -m -M 100000 -w 64K -l 24K
Параметры запуска NTttcp:
передатчик: ntttcps -m 1,0,10.0.0.2 -a 4 256K -n 10000
приемник: ntttcpr -m 1,0,10.0.0.1 -a 4 -l 256K -n 10000
Максимальный размер пакета 9014 или 16128 байт (включены Jumbo Frame)
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
TcpWindowSize = 20971520 (20 Мб)
Tcp1323Opts = 3
Параметры запуска Iperf:
клиент: iperf -c 10.0.0.1 -M 100000 -w 1M -l 24K
сервер: iperf -s -m -M 100000 -w 1M -l 24K
Параметры запуска NTttcp:
передатчик: ntttcps -m 1,0,10.0.0.2 -a 4 256K -n 10000
приемник: ntttcpr -m 1,0,10.0.0.1 -a 4 -l 256K -rb 20000000 -n 10000
Каждый тест запускался 15 раз, после чего выбирался лучший (по скорости) результат. В случае NTttcp загрузка процессора измерялась встроенными средствами программы, а в Iperf — с помощью системного монитора Windows 2000.
В ОС Linux для генерации трафика и снятия показаний использовалась программа netPIPE версии 2.4. Программа осуществляет генерацию трафика с постепенно возрастающим размером пакета данных (пакет размера N передается несколько раз, количество передач обратно пропорционально его размеру, но не меньше семи). Эта схема позволяет наглядно увидеть процент использования канала в зависимости от размера передаваемых данных.
Изменение размера Jumbo Frame осуществлялось через изменение MTU в настройках сетевого интерфейса командой
ifconfig eth0 MTU _size_ up
При тестировании устанавливались следующие размеры MTU:
1500 байт (Jumbo фреймы отсутствуют);
6000 байт;
9000 байт (драйверы адаптеров Hardlink HA-32G и LG LNIC-1000T этот размер не поддерживали);
16128 байт (драйверы адаптеров Hardlink HA-32G и LG LNIC-1000T этот размер не поддерживали)
Параметры запуска netPIPE:
приемник: NTtcp -b 65535 -o logfile -P -r
передатчик: NTtcp -b 65535 -o logfile -P -t
1. Windows 2000, скорость передачи данных.
2. Windows 2000, загрузка процессора.
Как ни странно, скорость работы не превышает 600 Мбит/сек даже с размером Jambo frame в 16128 байт. Непонятно, где узкое место, так как процессор в любом случае загружен не полностью. Также заметно, что от увеличения размера кадра менее всего в плане производительности (скорости передачи данных) выигрывает адаптер от Intel — скорость возрастает незначительно, хотя загрузка процессора и падает. Рекордсмен в плане наименьшей процессорной загрузки — адаптер Intel PRO/1000 MT, он минимум в два раза обгоняет своих конкурентов. Это неудивительно — базируется на более новом контроллере. А вот по скоростным характеристикам с отключенными Jumbo Frame вперед опять вырывается Intel, а если их включить, то в основном лидирует LG LNIC-1000T. Почему отстал адаптер от Intel, неясно, возможно проблема в драйвере.
3. Linux, изменяем размер MTU.
Как ни странно, при увеличении размера кадра скорость у адаптера PRO 1000/MT только падает. Наверное, виноват все-таки драйвер. Зато у LNIC-1000T тут все в порядке.
4. Linux, сравнение производительности на одинаковом размере MTU.
При отсутствии Jumbo Frame Intel PRO 1000/MT, как обычно, лидирует, а вот при их включении карты меняются местами, и их скорость сравнивается только на очень больших размерах передаваемых блоков данных.
В заключение приведу диаграмму сравнения пиковой производительности этих двух адаптеров при различных размерах MTU. Кстати, обращаю внимание, что результирующая скорость в Linux больше, чем в Windows.
Тестирование показало значительные преимущества при использовании больших кадров (Jumbo Frame) в работе, поэтому их лучше включать. Конечно, их поддержка требуется не только от сетевого адаптера, но и от коммутатора, а не все из них эти кадры поддерживают.
Безусловно, после нормализации ситуации с производительностью адаптера Intel PRO 1000/MT при использовании Jumbo Frame, он будет безусловным лидером. Хотя он уже выигрывает по наименьшей загрузке процессора, что немаловажно. Повторюсь, что это заслуга в первую очередь более нового контроллера.
Вопрос же низкой (не более 600 Мбит) скорости работы всех объясняется достаточно просто. Максимальная теоретическая пропускная способность шины PCI 33 МГц равна 1066,(6) Мбит/сек (32 бит * 33,(3) МГц). Реальная же пропускная способность шины несколько (до 20-30 процентов) меньше из-за:
накладных расходов по обслуживанию самой шины;
потоков данных, создаваемых другими устройствами, подсоединенными к шине;
реализации PCI в конкретном чипсете и даже в модели материнской платы (включая такую вещь, как параметры BIOS).
Именно поэтому, даже при максимальных размерах Jumbo Frame, рубеж в 600 Мбит не был преодолен — узким местом стала шина. Естественно, для шины PCI с разрядностью 64 бит ситуация должна поменяться, что и будет проверено в следующем тестировании.
По материалам ixbt
