Как стать автором
Обновить

Комментарии 22

А сетевая карта и ядро в линуксе тюнились хоть как-то?
Interrupt coalescing выключить, как минимум, если задержка важна.
На хосте — обычный арч, на плате — тюнили заказчики, подробностей не знаю.

Я думаю, interrupt coalescing для сетевой карточки может помочь, если приходит много пакетов «разом» (а тут отправляющий хост шлёт их по одному и ждёт ответа), в других случаях это не должно значительно помогать. Или всё-таки помогает за счёт чего-то?

его отключение может снизить задержки (прерывание будет генерироваться сразу же). снизит ли и насколько — зависит от конркетной сетевой карты и её драйвера.

А не пробовали qnx, например? Интересно, какой отклик из коробки.
нет, не пробовали, но было бы интересно. Хотя как в статье написано, обычно оптимизация идет по параметру пропускной способности. Просто у Embox сразу получается конфигурировать под заданные характеристики. Скорее всего в QNX что то подобное должно быть
Выбросить долой IP и писать прямо Ethernet-фреймы?
Думаю, да, опрелённое ускорение можно получить за счёт raw-сокетов. Но тут нужно было обрабатывать именно UDP-пакеты из пользовательского приложения, т.е. у нас не было цели оптимизировать само приложение.
Имеется в виду raw сокеты или прямо в драйвере всю логику программы сделать. Если второе, то будет конечно быстрее, но удовольствие еще то. Здесь сохранилась возможность использовать обычные пользовательские приложения.
Спасибо, очень интересная ссылка!
НЛО прилетело и опубликовало эту надпись здесь

а что тут удивительного?


$ netperf -t omni -H 10.0.0.20 -l 30 -- -d rr -r 100 -O "RT_LATENCY,P99_LATENCY"
OMNI Send|Recv TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.0.20 () port 0 AF_INET : demo
Round     99th         
Trip      Percentile   
Latency   Latency      
usec/tran Microseconds 
50.914    78           

ничего не настраивалось (кроме turbo boost на процессорах), с одной стороны вообще рилтек.
на 25G в районе 20мкс получается из коробки.

НЛО прилетело и опубликовало эту надпись здесь

среднее и 99%. на три часа, ожидаемо, 99% вырастет, среднее останется тем же.


вы в свою очередь не сказали ни размер пакета, ни какое время вы привели.

Мой рекорд до 138мкс в течении 48 часового теста для 1Gbps c одним switchем.

Отличный результат! Не поделитесь опытом?:)
Понятно что всё перечисленные Вами
А еще можно настроить сетевые буферы, изолировать ядра и есть куча тонкостей с настройкой сетевых прерываний.

Влияет, но вот как именно. Долго кстати мучались?

последние отморозки пишут отправку пакетов на bare-metal с AMP и pollingом.

Ну порой даже на это идут, и даже рассматривался такой вариант, как мне сказали, но затраты на всякие драйвера, и другие фишки не позволили. В нашем случае все цивилизованно, прикладное приложение, многозадачность и так далее. Ну как я понял и Ваш результат, тоже все это содержал!
НЛО прилетело и опубликовало эту надпись здесь
Можно использовать для приема пакетов технологию TPACKETv3(поддержка есть в ядре) в связке с libpcap. Ускорение получится за счет отсутствия накладных расходов на копирование пакетов из яда в юзерспейс. Так же pcap позволяет применить фильтрацию пакетов, как в tcpdump
спасибо, интересно! Про TPACKETv3 не слышали раньше!
У Gigabit Ehernet такие же задержки, как и у Fast Ethernet, или даже больше. Накосячили с настройкой сети.
Непонятно, зачем две головы в системе (два центра управления).
Про UDP:
Таким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.
Зачем его было вообще брать?

Сама система выглядит сляпанной из того, что было знал исполнитель.

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

Первый пакет может отсылаться с задержкой, если нету arp записи MAC адресата (MAC destination) в arp таблице, и соответственно необходимо выслать широковещательный (broadcast) arp запрос и дождаться arp ответа от адресата, прежде, чем отослать unicast пакет.
Прекрасно видно на примере icmp ping:
ping dest_addr
PING dest_addr (dest_addr) 56(84) bytes of data.
64 bytes from dest_addr: icmp_seq=1 ttl=64 time=6.47 ms
64 bytes from dest_addr: icmp_seq=2 ttl=64 time=0.764 ms
64 bytes from dest_addr: icmp_seq=3 ttl=64 time=0.766 ms


п.с. Если такое задержки критичны, теоретически может помочь multicast, так как ethernet (MAC) multicast адрес вычисляется из multicast ip адреса.
Вы не зря упоминули bpftrace. Сам bpftrace немного про другое, а для вашего случая больше подходит XDP (это одна из разновидностей BPF программ, специально предназначенная для оптимизаций такого рода).

Для того, чтобы написать простой, но максимально быстрый UDP ping (может с включением меток времени), подойдет базовая функциональность XDP. Например, см. мой пример ICMP echo сервера тут.

Если требуется проводить более сложную обработку пакета (т.е. в userspace), то можно смотреть в сторону AF_XDP (вот пример, опять же ICMP echo, из xdp-tutorial).

Для максимальной производительности драйвер карточки должен поддерживать native XDP, но и generic XDP тоже сработает быстрее, чем любое «обычное» решение на Linux.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.