Надшвидкий запит за допомогою пакетів UDP

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

Мені хотілося б дізнатися, які часи подорожі в обидва кінці можливі з типовим обладнанням, де комунікаційні системи, можливо, підключені через дротовий Ethernet на відстані декількох метрів один від одного, беручи до уваги затримки розповсюдження та передачі тощо.

Інші думки та пропозиції також вітаються.

Приклад Juniper MX80 має затримку виходу -> 8с, на перемикачі з низькою затримкою прорізу може бути <1us (можливо 0,7us). (Пам’ятайте, що комутаційний перемикач не може прорізати 100% часу, лише тоді, коли вихідний порт не працює!)

1 км волокна - це затримка приблизно в 5 футів (знову ж таки, в одному напрямку).

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

IP-заголовок - 20B, UDP-заголовок - 8B, у вас - 8B, тобто у вас є лише 36B даних, а це означає, що ваша корисна навантаження в Ethernet буде включати 10B сміття, яке Ви ОБОВ'ЯЗКОВО відправляєте, тобто якщо у вас є що додати до вашої корисної навантаження, додайте його, вона має 0 затримок.

Я сподіваюсь, що ви можете екстраполювати RTT з них, помноживши затримку пристрою на кількість пристроїв і додавши 5us на кожен кілометр волокна, а потім помножте його на 2.

Я не можу втриматися, щоб додати деякі думки про HFT.

Відповідно до цього обсяг HFT зменшився вдвічі між 2009 та 2012 роками. Напрошуючи, що легких перемог вже немає. Я хотів би побачити якийсь науковий документ або просто реальні дані про затримку HFT та його вплив на прибуток. Я підозрюю, що затримка, яка впливає на прибуток від торгівлі, відрізняється від затримки, про яку ми зараз говоримо. Мій друг, який будує мережу для однієї з найбільших бірж, здається, вважає, що це просто клієнт, який робить "нижче == краще", не розуміючи масштабів.
Я цілком можу зрозуміти, наскільки HFT був корисний, коли мало хто робив це, коли ви могли спостерігати за ринком, не бачачи змін, які MarketB бачить і використовує їх. Деякі говорять про використання регулювання, щоб зупинити HFT, оподаткувавши кожну торгівлю, зробивши її дорогою для всіх, я не думаю, що це буде потрібно, я думаю, що вікно можливостей вже закривається.

Я думаю, що на звичайному напівналагодженому обладнанні ви повинні вміти:

1. Вийдіть стек своєї хостової мережі
2. Отримайте наступний мережевий стек
3. Вимкніть цей мережевий стек своїм "новим" пакетом

В ~ 10 нас по 10 гіг. Якщо ви дійсно заблокували речі, це число може бути значно нижчим.

Майже ВСІ затримки, які ви збираєтеся бачити, пов’язані не з мережевим обладнанням / кабелями, а з вашими хост-системами. Розумний вимикач через перемикач (Arista, Gnodal, New Cisco та ін.) Буде суб-1us.

Почніть із забезпечення процесів, що споживають пакети UDP, закріплені на тому ж ядрі, що і переривання NIC. Звідти переконайтесь, що з’єднання в NIC вимкнено, а звідти переконайтеся, що у вас MSI-X та DCA.

Якщо ви серйозніше ... перегляньте OpenOnload SolarFlare. Вони також мають великий набір інструментів для тестування / перевірки працездатності.