Низкозаходное чтение порта UDP

Я читаю один элемент данных из UDP-порта. Очень важно, чтобы это считалось наименьшей задержкой. В настоящее время я читаю через метод boost:: asio library async_receive_from. Кто-нибудь знает, какую задержку я буду испытывать между пакетом, поступающим на сетевую карту, и метод обратного вызова, вызываемый в моем коде пользователя?

Boost - очень хорошая библиотека, но довольно общая, есть ли альтернатива с меньшей задержкой?

Все мнения о написании низкоуровневых сетевых программ UDP приветствуются.

EDIT: Еще один вопрос: существует ли относительно возможный способ оценить задержку, которую я испытываю между NIC и пользовательским режимом?

Ответ 1

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

Boost.Asio

Он постоянно выделяет/освобождает память для хранения "состояния", чтобы вызвать функцию обратного вызова, связанную с вашей операцией чтения.
Он делает ненужную mutex блокировку/разблокировку, чтобы поддерживать разбитое сочетание асинхронных и синхронизирующих подходов.
Хуже всего, он постоянно добавляет и удаляет дескрипторы событий из основного механизма уведомления.

В целом, asio является хорошей библиотекой для разработчиков приложений высокого уровня, но в комплекте с большим ценовым тегом и большим количеством циклов, в которых используются гремлины. Другой альтернативой является libevent, это намного лучше, но все еще нацелено на поддержку многих механизмов уведомления и не зависит от платформы. Ничто не может бить нативные механизмы, т.е. epoll.

Другие вещи

UDP-стек. Это не очень хорошая работа для чувствительных к задержкам приложений. Одним из самых популярных решений является OpenOnload. Он обходит стек и работает непосредственно с вашей сетевой адаптером.
Планировщик. По умолчанию планировщик оптимизирован для пропускной способности, а не для латентности. Вам нужно будет настроить и настроить свою ОС, чтобы сделать ее ориентированной на латентность. Linux, например, имеет множество "rt" патчей для этой цели.
Следите, чтобы не спать. Как только ваш процесс будет спать, вы никогда не получите хорошую латентность пробуждения по сравнению с постоянно сжиганием процессора и ожиданием поступления пакета.
Взаимодействие с другими IRQ, процессами и т.д.

Я не могу сказать вам точные цифры, но, полагая, что вы не будете получать много трафика, используя Boost и обычное ядро Linux, с обычным оборудованием, ваша латентность будет находиться где-то между ~ 50 микросекундами и ~ 100 миллисекундами, Это немного улучшится по мере того, как вы получите больше данных, и после некоторого момента начала падения и всегда будет варьироваться. Я бы сказал, что если вы в порядке с этими номерами, не беспокойтесь о оптимизации.

Ответ 2

Я думаю, используя recv() в потоке цикла "spin" и присоединяю поток к одному ядру центрального процессора (Affinity) процессора, латентность должна быть ниже, чем при использовании select(), точность select() варьируется от 1 до 10 микросекунд, в то время как спиновая петля на 1 микросекунде в моем тесте.