Сверхбыстрые запросы с использованием пакетов UDP

10

Я внедряю систему, в которой одно устройство в сети запрашивает с очень высокой частотой (сотни или тысячи запросов в секунду), отправляя небольшой пакет UDP с 8 или около того байтами данных. Это принимается другим приложением, возможно, на другом устройстве, которое выполняет очень простую обработку и отправляет результат размером в несколько байт, заключенный в другой пакет UDP.

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

Другие мысли и предложения также приветствуются.

ethernet latency speed

— Джон Смит
источник

2

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

— Майк Пеннингтон,

Большое спасибо за ваш ответ. В данном случае это не совсем система финансовой торговли. Я просто хотел смутное представление о том, что было возможно до начала реализации, скорее в качестве технико-экономического обоснования, чем что-либо еще.

— Джон Смит

11

Например, Juniper MX80 имеет задержку входа-выхода около 8 мкс, на переключателе с малой задержкой это может быть <1 мкс (может быть 0,7 мкс). (Помните, что сквозной коммутатор не может выполнять сквозной режим 100% времени, только когда выходной порт простаивает!)

1 км по волокну - это задержка около 5 с (опять же, в одном направлении).

Задержка сериализации @ 10G для полезной нагрузки минимального размера (46B) составляет около 67 нс (0,067us), увеличивая скорость соединения, вы уменьшаете задержку сериализации.

IP-заголовок равен 20B, UDP-заголовок равен 8B, ваши данные - 8B, поэтому у вас есть только 36B данных, что означает, что ваша полезная нагрузка Ethernet будет содержать 10B мусора, который вы ДОЛЖНЫ отправить, т. Е. Если у вас есть что добавить в свою полезную нагрузку, добавьте ее, у него 0 латентных затрат.

Я надеюсь, что вы можете экстраполировать RTT из них, умножив задержку устройства на количество устройств и добавив 5us для каждого километра волокна, а затем умножьте это на 2.

Я не могу не добавить некоторые мысли о HFT.

Согласно этому объему HFT сократился вдвое между 2009 и 2012 годами. Предполагается, что легких побед уже нет. Я хотел бы увидеть какую-нибудь научную статью или просто реальные данные о задержке HFT и ее влиянии на прибыль. Я подозреваю, что задержка, которая влияет на торговую прибыль, находится на другой величине, чем задержка, о которой мы сейчас говорим. Мой друг, который строит сеть для одной из крупнейших бирж, похоже, считает, что это просто клиенты, которые делают «ниже = лучше», не понимая масштабов.
Я могу полностью понять, как HFT был полезен, когда это делали немногие, когда вы могли наблюдать за рынком. Не видя изменений, рынокB видит и извлекает выгоду из этого. Некоторые говорят об использовании регулирования, чтобы остановить HFT, облагая налогом каждую сделку, делая ее дорогой для всех, я не думаю, что это будет необходимо, я думаю, что окно возможностей уже закрывается.

— ytti
источник

Отличный ответ и очень информативный, спасибо. Еще несколько личных мыслей о HFT!

— Джон Смит

1

@JohnSmith, не забывайте учитывать задержку, вносимую в ваши конечные точки (такие как планировщик ОС или обработка ядра) ... это может значительно увеличить задержку, о которой я упоминал в предыдущем комментарии.

— Майк Пеннингтон

Отличное замечание об использовании полного минимального размера пакета при стоимости задержки 0.

— generalnetworkerror

1

Я думаю, что на обычном полу-настроенном оборудовании вы сможете:

Выйди из своего сетевого стека хоста
До вашего следующего сетевого стека
Откажитесь от этого сетевого стека с вашим «новым» пакетом

В ~ 10 нас на 10гиг. Если вы действительно заблокируете вещи, это число может быть значительно ниже.

Почти ВСЕ задержка, которую вы увидите, связана не с сетевым оборудованием / кабелями, а с хост-системами. Разумный сквозной коммутатор (Arista, Gnodal, New Cisco и т. Д.) Будет sub 1us.

Начните с обеспечения того, что процессы, использующие пакеты UDP, прикреплены к тому же ядру, что и прерывания вашей сетевой карты. Оттуда убедитесь, что объединение на вашей сетевой карте отключено, и оттуда убедитесь, что у вас включены MSI-X и DCA.

Если вы более серьезны ... проверьте OpenOnload SolarFlare. У них также есть отличный набор инструментов для тестирования / проверки производительности.

— radikalus
источник