задержка при отправке пакетов UDP через петлевой интерфейс?

Question

Я собираюсь написать программу, которая прослушивает порт UDP, а затем отправляет данные нескольким экземплярам сервера.Код серверного программного обеспечения был структурирован для прослушивания самого порта, а не для получения данных от другой программы, работающей локально.Таким образом, моя идея заключается в том, чтобы создать второй поток UDP от интерфейсной программы к экземплярам сервера через интерфейс обратной связи.Приложение критично к задержке, то есть накладные расходы не должны превышать 1 миллисекунду.Тогда мне интересно, будет ли это тогда лучшим подходом или нет: я боюсь, что пакет будет снова запланирован для другого поворота ядра (в моем случае linux).Если я прав, будет ли эта задержка заметна?Если да, то является ли единственным решением переписать новую форму межпроцессного взаимодействия между интерфейсом и серверным приложением?

Answer 1

Планирование на самом деле не проблема.Если процесс или поток ожидает на select() или recvmsg(), он должен быть мгновенно разбужен входящей дейтаграммой.(Отправитель отказывается от своего процессорного среза, когда он вызывает sendmsg(), ядро ​​заставляет его передать сообщение через обратную петлю, тогда получатель будет выше, чем отправитель в планировщике.)

Задержка черезИнтерфейс обратной связи будет меньше миллисекунды при условии, что получатель готов к приему.

Большая часть вашей задержки будет зависеть от того, что делает каждый получатель между чтением пакетов из сокета.Например, если получателю требуется 0,5 миллисекунды обработки процессорного времени между квитанциями, то ваша задержка составит около 0,5 миллисекунды.Но если вы используете 3 таких приемника на ядро ​​процессора, то ваша задержка не может быть меньше 1,5 миллисекунд.