Одновременная запись в несколько сокетов

Solarflare OpenOnload как раз и рассматривается )

Вот это однозначно решает проблему переключений контекста. Но между передачей пакета первому и последнему клиентам задержка при ваше схеме всё равно будет. Очевидно, что решить проблему в рамках IP можно только мультикастным фидом, что биржевые движки и делают, но у них все клиенты сидят в одном датацентре. Если ваши клиенты раскиданы как попало, то с неравными приоритетами при рассылке придётся, по всей видимости, смириться.

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

Никто не собирается управлять неуправляемым :)

Кстати, небезынтересно ваше мнение вот по какому вопросу: Если разбить архитектуру на 2 слоя: 1. backend - принимает биржевые потоки, трансформирует в проприетарный протокол и по Reliable IP Multicast раздает своим серверам - frontendам. 2. frontend (несколько десятков) - работает как кеширующий прокси, раздает маркет дату сотням клиентов на разношерстных интернет соединениях.

Посмотрел на Cisco Catalyst 6513 VS-S720-10G-3C - там латентность переключения портов около 12-16 микросекунд, по сетевым картам в блейдах HP пока нет информации. Не поделитесь соображениями, на что там можно рассчитывать ?

Не знаете ли, на картах Broadcom которые обычно ставятся в эти блейды, есть ли нечто подобное OpenOnload?

Имелось в виду, на какие реализации Reliable IP Multicast посмотреть?

по сетевым картам в блейдах HP пока нет информации. Не поделитесь соображениями, на что там можно рассчитывать ?

На блейдах HP можно рассчитывать на вагон SMI на каждом ядре. Пролианты для настоящего low latency не подходят.

Не знаете ли, на картах Broadcom которые обычно ставятся в эти блейды, есть ли нечто подобное OpenOnload?

Слышал, что люди переписывали прошивки, чтобы принимать/гнать пакеты напрямую из юзерспейса.

Имелось в виду, на какие реализации Reliable IP Multicast посмотреть?

Ни на какие. Гоните данные по обычному udp мультикасту, дублируя пакеты вторым фидом.

Спасибо,

Если не затруднит, поясните, почему :)

по сетевым картам в блейдах HP пока нет информации. Не поделитесь соображениями, на что там можно рассчитывать ?

На блейдах HP можно рассчитывать на вагон SMI на каждом ядре. Пролианты для настоящего low latency не подходят.

Не знаете ли, на картах Broadcom которые обычно ставятся в эти блейды, есть ли нечто подобное OpenOnload?

Слышал, что люди переписывали прошивки, чтобы принимать/гнать пакеты напрямую из юзерспейса.

Буду признателен за чуть более подробную инфу, если уместно конечно

UDP-пакеты внутри своей сети имеют свойство не пропадать. Простого дублирования через два фида хватает (у NASDAQ так). Можно в своём протоколе реализовать сквозную нумерацию пакетов, чтобы ловить пропажу пакетов на время отладки. После отладки, по своему опыту, пакеты до клиента доходят всегда.

Буду признателен за чуть более подробную инфу, если уместно конечно

По SMI на HP или левых прошивках для броадкома?

И про то и про другое.

Если не затруднит, куда смотреть в части корневых серверов маркет даты - как бы Вы видели наиболее подходящее аппаратное решение серверной платформы с low latency.

И про то и про другое.

Влияние SMI вычисляется по постоянному замеру TSC и вычитанию переключений контекста в ядро. Можно ещё 52-й MSR читать (Machine Specific Registers) через rdmsr. У нас на DL380 G7 каждое ядро десятки SMI получает. Пробовали отключать, латентность лучше, но фиг его знает, что там за код в SMM исполняется.

Про броадком читал в какой-то англоязычной тусовке HFT. Линк не вспомню.

Если не затруднит, куда смотреть в части корневых серверов маркет даты - как бы Вы видели наиболее подходящее аппаратное решение серверной платформы с low latency.

Становитесь нашими дистрибуторами :)

Про последнее, если удобно, намекните, где смотреть )))

Про последнее, если удобно, намекните, где смотреть )))

http://www.novasparks.com

Спасибо, небезынтересно, весьма :)

libev

И как это приспособить для записи в группу сокетов? С минимизацией оверхедов на сисколлы?

одним вызовом писать в группу сокетов? ишь чего захотел)

еще - помниться был/есть проект - суть которого заключалась в следующем

на каждый процессор делался буффер - в который собирались вызовы сисколов (собирались от других процессов пока процессор находиться в ядре) - собирались для того чтобы при завершении текущего сискола не выходя из ядра начать выполняться накопившиеся сисколы

этакое накопление

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

да не - в вашем случае дикий оверхед на само переключение в ядро и обратно

а если боитесь за оверхед при перекладывании - то можно воспользоваться zerro-copy способностью стандартных ядер

ее суть в том что один write заменяется на 2 вызова ( tee + splice )
и при этом данные ваще не попадают в юзерспейс
и еще неизвестно что лучше или один сискол+копирование или 2 сискола

vmsplice - splice user pages into a pipe
splice - splice data to/from a pipe
tee - duplicating pipe content

суть в том - что ядро умеет - пайпы и данные в них - оперировать с ними чисто внутри ядра

на каждый сокет на юзера - делаеться пайп
и один общий пайп для общих поступающих данных
через vmsplice загоняете нужные для отправки данные в общий пайп
и потом для делаете tee между общим пайпом и юзерским пайпом
после чего для каждого юзерского делаете splice из него уже в сокет

к сожалению массированно так не сделать

Спасибо, посмотрю )

По теме: https://github.com/erdizz/mwritev

Интересно ) Если не затруднит, пару комментариев очень неплохо было бы ) И что там получается в итоге?

Сам не пробовал. Услышал на конференции выступление автора этого модуля.

а если этот проект расшириться на ВСЕ сисколы ...

то стандартная операция epoll + [n]read + [n]write может выполниться за 2 сискола ...

Да, это тот самый вариант с ядерным модулем.

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

Сокеты клиента лимитированы, high watermark установлен, в случае его превышения, клиент дропается. Суть задачи именно в реализации интересов прежде всего сервера - стабильно низкая латентность на этой операции, причем предсказуемая.

Бутылочное горлышко в виде сисколлов пока видится основным. Сеть достаточной мощности, поэтому тут угрозы не видится.

автор этого модуля - в презентации говорил о чтото вроде 25% снижении нагрузки при использовании модуля вместо стандартного решения но у него видеопоток на 2-6т клиентов

попробуйте оценить выигрыш в латентности от применения модуля ?

Основной выигрыш тут будет в экономии сисколлов, далее надо думать над потоками в ядре и тп.

Еще один момент - это перекладывание данных между юзерспейсом и ядром и наоборот, но тут явных идей пока нет :)

явная идея описанный zero-copy

и ваще - начинает напоминать чтото вроде шейдера на видеокартах скомпонованное задание для ядра

Да, если скрестить этот самый zero-copy с ядерным мультиплексором, может получиться очень недурственная реализация, мне кажется

подумалось

если все пакеты не мультикаст - то
при требовании минимизации задержки - то вся пляска исходит от внешнего интерфейса

скажем обычьный гигабит
и пакет в 500 байт рассылается 1000 клиентов

то чтобы нагрузить сеть полностью - нужно чтобы все сисколы занятые на выдачу пакета сработали за 4микросекунды

если успевают - то дальнее улучшение работы достаточно бесполезны - они неприведут с уменьшение задержки

а клинетов - порядок отправки на них можно радомейзить - для усреднения задрержки

Спасибо за мысли, но есть нюансы

Типичный пакет данных около 64-128 байт Важна не столько пропускная способность, сколько минимизация показателей средней латентности ухода пакетов при минимизации девиации, то есть если средняя будет несколько микросекунд или менее того, но будут выбросы в сотни и тысячи микросекунд, это не есть айс.

и всеже делали ли тестирование с обычьный схемой ? epoll и так далее успевает ли она выгрузить по максимому один гигабит при выдаче пакета ?

если потоки tcp-ip - и обьем данных не приводит к забиванию канала на клиента - выходное окно на передачу всегда будет свободно и любая запись в сокет на клиента приведет в этомже сисколе - к формированию пакета и выдачу его на сетевую

стало быть - нужно обеспечить нужную интенсивность выдачи на сетевую пакетов - как раз ту чтобы забила гигабитную карту

если один поток это сможет сделать - то и задача решена полностью если нет - то можно по колву процессоров распрееделить раздачу + распределить потоки от клиентов по мультибуфферной сетевой и так далее

а до клиетов точно есть гигабит ? небудет ли потерь пакетов - при столь массированной импульсной выдаче ?

а то что выбросы - одно переключение контента с одно процесса на другой займет около минимум 5-10микросекунд и если обеспечить отсутвие конкуретной борбы хотябы на этой процессоре между процессами (привязать только этот процесс на это ядро) - и включить ему вдобавок реалтайм то должно всяко уменьшить их (если они есть)

Вот над мультипоточной раздачей думаю, но тут свои особенности, ибо нужно обеспечивать последовательность сообщений одного типа.

Скорее, тут будет привязка к процессорным ядрам тредов, которые работают каждый со своим типом сообщений.

Гигабита до клиентов нет, есть до следующего роутера, и, как я и говорил ранее, приоритетна латентность (стабильная) на записи в сокет, ибо при переполнении high watermark сокет отрубается.

ZeroMQ показывает по надежной сети (гигабитной) латентность порядка 20-40 микросекунд с приемлемой девиацией. Вроде как они там пользовали epoll и прочие такого класса механизмы.

20-40 это от выдачи одного пакета до другого иль от поступления пакета до выхода на клиентов ?

если первое - то это крайне высоко ... это 50-100тысяч пакетов в секунду это похоже на ограничение по колву контент свитчей между двумя потоками

неужели не пробовали сделать однопоточную схему на еполе ? даже неинтересно ? что точно делает ZeroMQ в этой ситуации - неизвестно

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

Архитектура ZMQ как раз у них и расписана на сайте.

У меня проблема не в epoll, а в том что подписчиков сотни, и каждый из них может подписываться на разные потоки данных. Поэтому дабы найти способ избежать оверхедов на системные вызовы, я и завел этот топик. Основные варианты понятны уже, это lio_* + zero-copy.

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

В моем случае основное - за одно переключение между контекстом ядра и юзерспейса писать в группу сокетов, которая относительно постоянна по своему составу. Все остальное решается только через специализированное оборудование.

Когда соберу тестовый стенд и поставлю серию экспериментов, отпишусь, чего получилось добиться или не добиться :)

ох
а о чем же я хочу то сказать ...

еще раз - если обычьное решение на епуле обеспечит нужную частоту мелких пакетов чтобы забить гигабитные канал
но абсолютно нет надобности еще более улучшать этот раздатчик ядерными модулями - потому как это НИЧЕГО недаст
вообще ничего - даж микросекунды на сообщение :)

это так или нет ?

Смотрите в чем сомнения.

Идет пакет или группа пакетов, без разницы, ибо для этой операции буфер уже есть, память выделяется незатратно, нужно отправить потребителю. Последовательные пакеты, если сложилось, в памяти лежат последовательно.

Один пакет выровнен по границе 64 бита, как правило. Варианты - выравнивание через SSE/AVX.

Этот пакет надо записать в зависимости от финансового инструмента и потока данных в разное количество сокетов.

Делается карта сокетов по принципу: инструмент, тип потока -> список сокетов (список номеров или файловых дескрипторов). Она есть, причем относительно стабильна.

Задача: За один системный вызов это отправить, ибо 500 или 1000 подряд системных вызовов убивают все напрочь за счет переключения контекста.

А теперь внимание, вопрос - как именно к групповой записи в сокеты приспособить epoll? Маны читал, или я чего то не догоняю? Если нетрудно, буду признателен за пояснения.

вот это нужно? http://kerneltrap.org/node/7728

Подохло оно. Слишком медленно мы двигаемся к post-unix

ну - простая схема
несколько связанных списков сокетов
и сообщение что поступают - идут на определенный список сокетов

вы говорили что вас «напрягает» делать столько вызовов однообразных на все сокеты - ну 500 write на 500 клиентов
а я спрашиваю - а вы точно пробовали эту схему ? почему эта простая схема вам так не нравиться ? может вы пробовали и она не успевала выдавать нужную частоту пакетов ?

чтобы нагрузить гигабит - пакетами по 64+40 байт - нужно выдать pps равным примерно 1.2 миллиона пакета в секунду
тоесть если сискол + выбор следующего будет в районе 1 микросекунды - то эта простая схема полностью нагрузит теоритический максимум скорости сети

и дальнейший поиск улучшения через ядерные модули бесполезен

в случае одного потока - и открытом окне tcp на посылку - write - в сокет - в этомже сисколе приведет к заворачиванию данных в пакет и тутже отправки его в буффер сетевой на отправку - и только после этого сискол закончиться и вернеться в юзерспейс
тоесть после write - после вертания управления уже можно гарантировать что пакет отправлен

да не медленно - вопрос - нужно ли вообще это движение :) вся то проблема - в том что переключение в кернел моде требует ресурсов - если это както улучшить апаратными методами - то плюса будет куда больше

Как говорил один очень известный товарищ, мы планируем идти другим путем:

http://pubs.opengroup.org/onlinepubs/009604599/functions/lio_listio.html

:)

(я уже просто рыдаю ...)

еще раз вопрос
вы пробовали через обычные сисколы это все сделать - и какой получился результат по пакетам в секунду ?

завтра попробую сделать тестову схему - 64-128 байт пакеты - пара тысяч клиентов - напишу чего получиться по pps

Вот тут у меня и вопрос - каковы провалы по латентности будут на массированных сисколлах?

За тесты буду признателен, интересно, но у меня такое ощущение что десятком микросекунд тут не отделаешься.

Кстати, по 1 сокету на 1 клиента :)

понятно - не пробовали
просто думал что такой поиск как раз и вызван недостаточностью простого решения

У меня эта задачка возникла совсем недавно, начитавшись исследований и понимаю всю пагубность перебора сокетов в цикле, пришел к такой гипотезе :)

Тестового стенда пока не собрали, а на локальной машине проверять - не та чистота эксперимента :)

А за внимание к проблеме - большое спасибо :)

у меня бальшое подозрения - что начитавшись - несовсем то
наверняка там было про проблемы select-а с перебором сокетов для tcp сервера
вот я ни разу не встречал описание подобных проблем для выхода

а на локальной такое тестировать просто не имеет смысла - потому как будет идти постоянная переключение контента

Спасибо, как идейный вариант, погляжу )

Собственно надо завернуть, условно выражаясь, 500-1000 однотипных практически сисколлов в один :) Пока желание состоит именно в этом :)

Только, пожалуйста, обратите внимание, что у меня не проблема получения данных, а записи их - идентичных - в сотни сокетов, принадлежащим разным клиентам :)