ETegro Technologies
Компания
22,92
рейтинг
26 февраля 2014 в 09:55

Разное → Производительность 40G Ethernet с коммутатором на основе Intel ONS


Сегодня доступно приличное количество интерфейсов, каждый из которых претендует на полезность и необходимость. Традиционный Ethernet с 1G, 10G, 40G; InfiniBand FDR 56G и QDR 40G; FibreChannel 8G, 16G, обещанный 32G.

Все обещают счастье и рассказывают про свою крайнюю необходимость и полезность в быту. Как с этим быть, что выбрать и где подводные камни?



Как тестировали:

Принимали участие традиционный для всех гигабит, который есть в каждом сервере, 40G Ethernet, QDR и FDR InfiniBand, 10G не стали брать. Сразу надо отметить, что мы считаем FC уходящим интерфейсом, сейчас в тренде конвергенция. 32G пока что недоступен, а 16G вне лиги высокоскоростных решений.
Для выяснения пределов испытания провели на достижение минимальных задержек и максимальной пропускной способности, что удобно сделать с помощью HPC методик, заодно проверили пригодность 40G Ethernet для HPC приложений.

Неоценимую помощь оказали и провели натурные испытания коллеги из ЦКО, которым один коммутатор на базе Intel ONS был передан на тестирование.

Кстати, раздача коммутатора в самый интересный проект продолжается.

Аппаратное обеспечение:

Программное обеспечение:
  • Замер производительности проводили с помощью синтетического теста pingpong из набора тестов Intel MPI Benchmark v3.2.3
  • Версия используемой MPI библиотеки S-MPI v1.1.1 – клон Open MPI.


В процессе подготовки выяснился нюанс адаптеров Mellanox — они требуют принудительного перевода в режим Ethernet. Заявленный функционал автоматического определения типа подключенной сети почему-то не работает, может поправят.

Для оценки производительности «традиционно» смотрим на значения времени задержки (latency) при передаче сообщений длиной 4 байта и полосы пропускания при передаче сообщения длиной 4 МБ.

Начало опытов:

Используется обычный для Ethernet режим. В нашей терминологии, использовалась tcp фабрика. То есть MPI библиотека использует socket интерфейс для передачи сообщений. Конфигурация драйверов, коммутатора, и MPI по-умолчанию.

В таблице слева результаты для 1G ethernet, справа для 40G (с нашим коммутатором). Видим «провалы» в полосе для сообщений длиной 256К-1М и максимальный результат, подходящий для 10G Ethernet. Очевидно, что нужно настраивать ПО. Задержка, понятное дело, очень велика, но при прохождении через стандартный TCP стек много ожидать и не стоит. Надо отдать должное, в три раза лучше 1G Ethernet.

Mpirun –n 2 –debug-mpi 4 –host host01,host02 –nets tcp --mca btl_tcp_if_include eth0 IMB-MPI1 PingPong mpirun -n 2 -debug-mpi 4 -host host01,host02 -nets tcp --mca btl_tcp_if_include eth4 IMB-MPI1 PingPong


Кликабельно:


Продолжаем:

Обновляем драйвера. Берем драйвер с сайта Mellanox.
Для уменьшения «просадки» в диапазоне 256К-1М увеличиваем размер буферов через настройки MPI:

export S_MPI_BTL_TCP_SNDBUF=2097152
export S_MPI_BTL_TCP_RCVBUF=2097152

mpirun -n 2 -debug-mpi 4 -host host1,host2 -nets tcp --mca btl_tcp_if_include eth4 IMB-MPI1 PingPong


Кликабельно:


В результате улучшение в полтора раза и уменьшение провалов, но всё равно мало, да еще подросли задержки на малых пакетах.

Конечно же, для улучшения полосы пропускания при применении высокоскоростных Ethernet интерфейсов имеет смысл использовать сверхдлинные Ethernet-кадры (Jumbo frames). Конфигурируем коммутатор и адаптеры на использование MTU 9000, и получаем заметно более высокую полосу пропускания, которая всё равно остается на уровне 20 Гбит/с.

Кликабельно:


Опять растет латентность на малых пакетах.
Пробовали другие параметры «покрутить», но принципиальных улучшений не получили. В общем, решили, что «не умеем их готовить».
В какую сторону смотреть?
Безусловно, если искать производительность, то нужно это делать в обход TCP стека. Очевидное решение — попробовать RDMA технологии.

Суть технологии:
  • Доставка данных непосредственно в окружение пользователя, без переключения контекста приложения между режимами ядра и пользователя.



  • Данные от адаптера помещаются сразу в память приложения, без промежуточных буферов.



  • Сетевые контроллеры обрабатывают транспортный уровень без привлечения процессора.





Одно из следствий – значительное снижение латентности доступа.
Есть два конкурирующих стандарта, Internet Wide Area RDMA Protocol (iWARP) и RDMA over Converged Ethernet (RoCE), их соревнование и попытки сторонников утопить друг друга достойны отдельного холивара и объемного материала. Картинки приведены для iWARP, но суть общая.

Адаптерами Mellanox поддерживается RDMA over Converged Ethernet (RoCE), используем OFED-3.5.2.
В результате, получили отличные цифры. Задержку 1.9 мкс и полосу 4613.88 Мбайт/с (это 92.2% от пика!) при использовании Jumbo frames. Если размер MTU оставить по умолчанию, то полоса будет ниже, примерно 4300 Мбайт/с.

mpirun -n 2 -debug-mpi 4 -host host1,host2 --mca btl openib,self --mca btl_openib_cpc_include rdmacm IMB-MPI1

Кликабельно:


Для Pingpong теста время задержки можно улучшить до 1.4 мкс, для этого процессы нужно разместить на CPU «близких» к сетевому адаптеру. Какое практическое значение это имеет в реальной жизни? Ниже небольшая сравнительная табличка Ethernet vs InfiniBand. В принципе, такой «трюк» возможно применить к любому интерконнекту, поэтому в таблице ниже приведен диапазон значений для некоторых сетевых фабрик.

  1G Ethernet (TCP) 40G Ethernet (TCP) 40G Ethernet (RDMA) InfiniBand QDR InfiniBand FDR
Latency, usec 24.5 7.8 1.4-1.9 1.5 0.86-1.4
Bandwidth, Mbytes/s 112 1126 4300-4613 3400 5300-6000


Данные для 40G и FDR плавают в зависимости от близости ядер, на которых исполняются процессы, к ядрам, ответственным за сетевой адаптер, почему-то на QDR этот эффект был почти не виден.
40G Ethernet значительно обогнал IB QDR, но до IB FDR не догнал по абсолютным цифрам, что не удивительно. Однако по эффективности 40G Ethernet лидирует.
Что из этого следует?
Торжество конвергентных Ethernet технологий!
Недаром Microsoft усиленно продвигает возможности SMB Direct, который полагается на RDMA, в NFS поддержка RDMA также встроена.
Для работы с блочным доступом есть технологии iSCSI offload на сетевых контроллерах и протокол iSCSI Extensions for RDMA (iSER), эстеты могут попробовать FCoE :-)

При использовании таких коммутаторов:



Можно построить кучу интересных высокопроизводительных решений.
Например, программно-конфигурируемая СХД наподобие FS200 G3 с 40G интерфейсом и ферма серверов с 10G адаптерами.
При таком подходе отпадает необходимость строить выделенную сеть для данных, значительно экономя как средства на второй набор коммутаторов, так и время на развертывание решения, ведь кабелей тоже требуется вдвое меньше подключить и проложить.

Итого:
  1. На Ethernet можно построить высокопроизводительную сеть со сверхмалыми задержками.
  2. Активное использование современных контроллеров с поддержкой RDMA значительно повышает производительность решения.
  3. Матрица Intel с уровнем задержки в 400 ns cut-through помогает получить отличный результат :-)
Автор: @ETegro_Technologies
ETegro Technologies
рейтинг 22,92
Компания прекратила активность на сайте

Комментарии (50)

  • +1
    А зачем MPI? Есть netperf (TCP) и ib_write_bw (RoCe). И для сравнения, можно было бы выложить back to back (без коммутатора) тесты.
    • 0
      $ ib_write_bw -F
      — RDMA_Write BW Test
      Dual-port: OFF Device: mlx4_0
      Number of qps: 1 Transport type: IB
      Connection type: RC Using SRQ: OFF
      CQ Moderation: 100
      Mtu: 2048[B]
      Link type: Ethernet
      Gid index: 0
      Max inline data: 0[B]
      rdma_cm QPs: OFF
      Data ex. method: Ethernet
      — local address: LID 0000 QPN 0x00d7 PSN 0xc71fec RKey 0xa0010519 VAddr 0x007fcb10e0c000
      GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:142:192
      remote address: LID 0000 QPN 0x00f2 PSN 0x3d2abe RKey 0xa8010519 VAddr 0x007f62d588f000
      GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:143:96
      — #bytes #iterations BW peak[MB/sec] BW average[MB/sec] MsgRate[Mpps]
      65536 5000 4565.82 4565.73 0.073052
      — $ ib_write_lat -F
      — RDMA_Write Latency Test
      Dual-port: OFF Device: mlx4_0
      Number of qps: 1 Transport type: IB
      Connection type: RC Using SRQ: OFF
      Mtu: 2048[B]
      Link type: Ethernet
      Gid index: 0
      Max inline data: 220[B]
      rdma_cm QPs: OFF
      Data ex. method: Ethernet
      — local address: LID 0000 QPN 0x00da PSN 0x9127b4 RKey 0xb8010519 VAddr 0x00000001b16000
      GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:142:192
      remote address: LID 0000 QPN 0x00f3 PSN 0xed6e66 RKey 0xb0010519 VAddr 0x000000014fd000
      GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:143:96
      — #bytes #iterations t_min[usec] t_max[usec] t_typical[usec]
      Conflicting CPU frequency values detected: 1200.000000 != 2801.000000
      Test integrity may be harmed!
      Warning: measured timestamp frequency 2789.35 differs from nominal 1200 MHz
      2 1000 1.56 16.90 1.76
      ---------------------------------------------------------------------------------------
    • 0
      Так чуть быстрее получилось.

      $ ib_write_bw -R -F -s 4194304
      — RDMA_Write BW Test
      Dual-port: OFF Device: mlx4_0
      Number of qps: 1 Transport type: IB
      Connection type: RC Using SRQ: OFF
      CQ Moderation: 100
      Mtu: 2048[B]
      Link type: Ethernet
      Gid index: 0
      Max inline data: 0[B]
      rdma_cm QPs: ON
      Data ex. method: rdma_cm
      — Waiting for client rdma_cm QP to connect
      Please run the same command with the IB/RoCE interface IP
      — local address: LID 0000 QPN 0x0219 PSN 0x9c52ef
      GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:143:96
      remote address: LID 0000 QPN 0x0201 PSN 0xb490d7
      GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:142:192
      — #bytes #iterations BW peak[MB/sec] BW average[MB/sec] MsgRate[Mpps]
      4194304 5000 4671.96 4671.96 0.001168
      ---------------------------------------------------------------------------------------
  • 0
    <оффтоп> А не подскажете ли честный 10ГБ коммутатор портов этак на 16? </оффтоп>
    • 0
      Есть 8 портов у HP, по-моему.
    • 0
      Есть у всяких Netgear.
  • 0
    Ну раз уж пиарите свитч и ASIC — как в нем реализован QoS, и, в частности, как боретесь с head of line blocking? Серьезная проблема для многих cut-through свитчей, способная сильно нагадить.
    • 0
      Интел клянется, что их езернет самый lossless из всех езернетов.

      Патенты публикуют, что все доступные Efficient means to provide back pressure without head of line blocking используются.
      • 0
        Ну положим в FCoE для lossless главное — вовремя сообщить назад «хорош пакеты слать, подожди немного», даже когда всего один перегруженный в исходящем направлении интерфейс мешает трафику ходить между совершенно другими интерфейсами. Дропов-то не будет, PFC отработает, вот только скорость просядет жестоко…

        А патент, по-моему, описывает store-and-forward архитектуру. Да и вообще, у вас там что, совсем никакой документации нет, если патентами кидаетесь, которые опубликованы 15 лет назад? :) Честно, мне впервые дали ссылку на патент в ответ на просьбу рассказать про архитектуру :)

        Ну да, в патенте говорится про VOQ, вполне нормальное решение, только интересно, относится ли оно к данному чипу и сколько там очередей.
        • 0
          Fulcrum (оригинальный разработчик чипа) ставил одной из целей — избавиться от head of line blocking.
          У них это получилась еще в первом коммерческом продукте в 2003 году.
          • 0
            Я в недоумении. Честно. Вроде простой вопрос. Вы вовсю пиарите мир дружбу жвачку опенсорс и SDN, открытость и т.д., и при этом не можете найти ответ на простой архитектурный вопрос :)

            5 секунд в гугле находят аналогичную информацию по напрочь проприетарному и кроваво-ентерпрайзному цискиному нексусу 5500:
            Скрытый текст
            The Cisco Nexus 5500 platform implements virtual output queues (VOQs) on all ingress interfaces, so that a congested egress port does not affect traffic directed to other egress ports. Every IEEE 802.1p class of service (CoS) uses a separate VOQ in the Cisco Nexus 5500 platform architecture, resulting in a total of 8 VOQs per egress on each ingress interface, or a total of 384 VOQs per ingress interface on the Cisco Nexus 5548P, and a total of 768 VOQs per ingress interface on the Cisco Nexus 5596. The extensive use of VOQs in the system helps ensure high throughput on a per-egress, per-CoS basis. Congestion on one egress port in one CoS does not affect traffic destined for other CoSs or other egress interfaces, thus avoiding head-of-line (HOL) blocking, which would otherwise cause congestion to spread.

            А варианты разные. Можно было бы сделать, например, сэконосить и сделать по одному VoQ на порт-группу без разделения по COS. Этого было бы, наверное, достаточно для маркетингового заявления «мы избавились от head of line blocking», но это не совсем соответствовало бы реальности.

            И я сильно сомневаюсь, что в 2003-м году где-то были сотни очередей на входящий порт…
            • 0
              Интел не экономил.

              By providing full bandwidth access to every output queue from every input port, no blocking occurs within the switch, eliminating the need for complex VoQs and schedulers.
              • 0
                With the Intel®Ethernet Switch Family, all packets arriving at any ingress port are immediately queued at full line rate into shared memory. Packets are then scheduled from shared memory to the egress ports.

                По-моему, это описание чего угодно кроме cut-through архитектуры (если пакет сначала всегда копируется в shared memory). Или я не прав?
                • 0
                  Для cut-through достаточно, чтобы процесс передачи фрейма в порт назначения начался сразу по дешифровке адреса назначения.
                  Получил-расшифровал адрес-кинул в буфер на выдачу.
                  Особых противоречий не вижу.
                  • 0
                    Погодите… Cut-through — это когда хвост пакета торчит из одного порта свитча, а первые байты уже покидают другой. Понятно, что когда исходящий интерфейс уже занят, надо без вариантов поместить пакет в буфер, но тут вроде как говорится о том, что все пакеты попадают в буфер, т.е. мы говорим о store-and-forward. Архитектура чем-то схожа с таковой у того же cat4948, у которого тоже единый shared buffer под всё.
                    • 0
                      Store-and-forward сначала закидывает пакет в буфер, потом разбирается, что с ним делать.
                      • 0
                        Так указанный свитч cut-through или store-and-forward?
                        • 0
                          Интел заявляет, что cut-through.
                          Сначала выясняет, что за пакет, потом отправляет по назначению. По латентности матрицы это видно.
                          • 0
                            Интел заявляет, что cut-through.

                            Верю. Так про архитектуру где почитать, если указанное выше явно относится к каким-то другим store and forward чипам (которые сначала полностью буферизируют пакет)? :)
                            По латентности матрицы это видно.

                            По абсолютным цифрам тяжело ориентироваться. Надо смотреть увеличение задержки с ростом размера пакета. Если увеличения нет или почти нет, то явно cut-through.
                            • 0
                              При cмене размера кадра с по умолчанию на 9К латентность увеличилась процентов на 10-15.
                              • 0
                                Такие вещи мерить компьютерами бесперспективно. Гонялись ли тесты с участием специализированных железяк вроде Spirent TestCenter для генерации и приема трафика? По-моему, вендор просто обязан иметь несколько таких девайсов, они позволяют исключить искажения результата на стороне сетевух, сетевого стека ОС, приложений и т.д., сконцентрировавшись на самом тестируемом оборудовании.
  • 0
    > В процессе подготовки выяснился нюанс адаптеров Mellanox — они требуют принудительного перевода в режим Ethernet. Заявленный функционал автоматического определения типа подключенной сети почему-то не работает, может поправят.

    Это потому что в скриптах инициализации по-дефолту ставится режим IB у интерфейсов, что весьма правильно, поскольку настройки на серверах все равно сильно зависят от выбранного протокола.
    • 0
      Обещают же auto-negotiation.
      Написали бы — ставить вручную, то вопрос бы не возник.
  • +1
    И, кстати, при сравнении 40GE и 40G IB надо помнить, что у эзернета 40G — это net data rate, а у IB — gross data rate (кодирование такое же, как и у ethernet — 8b/10b).

    И еще с IB есть такой нюанс, что IPoIB медленный (от 2 до 10 гигабит в секунду для 40G), дает большую нагрузку на ЦП, а также сильно зависит от используемого MTU и типа QP (от 2k для UD до 64к RC).
  • 0
    А не пробовали тюнить по данному руководству? 22 ГБ/сек удалось выжать, меряли iperf'ом между двух карточек.
    • 0
      Плохо вижимали :)
      Если всё по этой инструкции + последние драйверы + Gen 3 сервер, будет 40.
    • 0
      22 гигабайта — это больше теоретического пика двух портов.
      Может все таки гигабита?
      • +1
        Да, гигабита, конечно же
        • 0
          Так у нас получилось в итоге 37,4 гигабита :)

          Или вы про работу через TCP стек?
          • 0
            IPoIB, connected mode.
            • 0
              А, вы про комментарий iavael.
            • 0
              Какой MTU? И какая получилась загрузка CPU?
              • 0
                64k — точных цифр по загрузке сейчас не вспомню, но выше 60% не поднималось на e5-2600 ксеоне. В ближайшем будущем еще буду тесты гонять — скажу точнее.
      • 0
        Кстати да, про руководство. VMA пробовали включать? Мне показывали лабу, latency в одну сторону между двумя машинками падала с 9.5мкс до 1.5мкс для мелких пакетов.
  • +1
    Можно уточнить, как выглядит использование RDMA с точки зрения приложения? У нас есть программа, которая говорит
    sock = socket(AF_INET, SOCK_STREAM, 0);
    connect(sock, &addr, sizeof(addr))
    send(sock, message, sizeof(message), 0);
    recv(sock, buf, sizeof(message), 0);
    


    Что меняется для приложения? Для ядра?
    • +1
      Выглядеть будет чуть сложнее. На OFED есть разные примеры в части RDMA, например простой клиент. Фактически тоже самое для iWARP

      Для приложения меняется API. Для ядра принципиально ничего не меняется — но должны быть соответствующее оборудование, драйверы и библиотеки.
      • 0
        Ага, спасибо, я услышал главное. Меняется userspace-API для приложений, пользующихся сетью.
        • 0
          Зависит от API. Например, для приложений использующих MPI ничего не меняется.
          • 0
            MPI это, мягко говоря, экзотика. Меня интересовала её применимость с точки зрения обычных сетевых приложений. Получается не очень.
            • 0
              Как сказать, такая латентность и скорости для _обычных_ сетевых приложений тоже в общем то экзотика и далеко не всем нужны. Оборудование специфическое, ограничения по кабелям… Основные области для таких скоростей и латентности — HPC и хранение, а для них RDMA варианты основных протоколов есть давно — MPI, iSCSI, CIFS, NFS…
              • 0
                Ну, 40G уже вполне хочется. Например, когда в каком-нибудь CDN'е приходится поднимать ещё один сервер ради лишних 10-20Г на выходе, 40G выглядит интересно. Или где-нибудь в районе аггрегации.

                Но, разумеется, хочется 40G нормальные маршрутизируемые интернетные, а не «хоть как-то».
                • +1
                  IPoIB на маршрутизируемых в интернете значениях MTU — это лишь несколько гигабит в секунду и жор процессорного времени. И еще отдельная боль — это взаимодействие ethernet и infiniband сегментов сети, потому что, напомню, в IB свой стек протоколов, которые, чуть ли не в HCA оффлоадятся и даже IP прибит сбоку лишь для совместимости. Соответственно, ethernet-совместимых вланов, как и вообще чего-то ethernet-совместимого, нет. В одном облачном провайдере для того, чтобы отдавать клиентам именно ethernet даже пришлось изобрести свой multipoint VPN, инкапсулирующий ethernet-фреймы в IP-пакеты.
                  В общем, использовать IB только ради того, чтобы гонять по нему IP-трафик, почти бессмысленно.
                  • 0
                    тыг я не про infinyband, а про Ethernet.
                    • 0
                      Если хочется просто воткнуть железку от мелланокса и сразу получить буст в скорости/задержке, ничего не меняя в коде — то это у них называется VMA ( ru.mellanox.com/page/software_vma?mtag=vma). Аппаратный оффлоад TCP/IP стека, уменьшает latency.

                      RDMA over Ethernet работает только если обе карты эзернетовские, да ещё и специальный свитч (эзернет, но от мелланокс) стоит. И код естественно переписать придётся под RDMA, а там всё по-другому (в конце презентации есть про это www.docstoc.com/docs/2705254/Introduction-to-RDMA-Programming).

                      Могу дать контакты их московского продажника (именно мелланоксовского, не посредника).
                      • 0
                        Почему эзернет должен быть именно от Меланокса? RoCE поддерживают многие производители, как устройств, так и силикона. В посте в частности речь идет о таком устройстве.
                        • 0
                          Не должен. Знаю, что проблемы с совместимостью могут быть. Рассказываю про те комплекты, что знаю :)
        • 0
          Еще есть rsocket в возможностью подменять обычные сокеты через специальную библиотеку, подгружаемую, например, через LD_PRELOAD. Но в любом случае для работы RDMA потребуется поддержка технологии с обеих сторон соединения.
          • 0
            Библиотека зовется libsdp, но это костыль и он не дает всем примуществ RDMA.
            • 0
              Не совсем, я имел ввиду костыль под именем librspreload.so и rsocket.

              А Вы можете рассказать про различные варианты API для RDMA в приложениях, с учетом их достоинств и недостатков?
              • 0
                > А Вы можете рассказать про различные варианты API для RDMA в приложениях, с учетом их достоинств и недостатков?

                Я вообще админ, да и с infiniband-ом уже не работаю, потому вряд ли что-то дельное по программированию под IB могу рассказать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное