LINUX.ORG.RU

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


2

3

Суть задачи: RedHat Linux MRG Realtime Есть структура, содержащая (условно) список сокетов, в которые надо писать одинаковые данные (мультиплексирование). Сокетов достаточно много - сотни и единицы тысяч.

Операции записи должны быть асинхронными, при этом потокобезопасными. Высокие требования к латентности (распространение рыночных данных).

На какие низкоуровневые средства предложите посмотреть и какие высокоуровневые реализации посоветуете посмотреть?

Спасибо заранее.


Ответ на: комментарий от anonymous

клиентов столктьо и ненужно - нужно просто 2 машины соединенных гигабитом
на одном запускается сервер tcp - который скажем раз в секунду на всех подключенных юзеров отсылает 128 байт
а на второй машине делает эмуляция клиентов - ab -c 1000 -n 1000 http://сервер:1000/index.html
и пускай сервер замеряет и печает - за сколько времени он разослал сообщение (само собой от первого до последнего - а не какаято постановка в очередь всего задания)

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

ae1234 ★★
()
Ответ на: комментарий от ae1234

Не, такая эмуляция - это не то. Там ядро хитрит. Поэтому и профит от того модуля маленький. Я хоть и простой быдлокодер, но быть похожим на фороникс не хочу.

anonymous
()
Ответ на: комментарий от ae1234

Тьфу на меня)). Для четкого экперимента нужно синхронизировать время на машинах, отметить время начала отсылки сообщения с сервера, и время приема каждым клиентом. Наибольшее время клиента и будет временем отсылки сообщения. Так что 2 машины не прокатят.

anonymous
()
Ответ на: комментарий от anonymous

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

ae1234 ★★
()
Ответ на: комментарий от ae1234

за сколько времени он разослал сообщение (само собой от первого до последнего - а не какаято постановка в очередь всего задания)

Еще раз уточню, чтобы не было недопониманий в части постановки тестов. Меня интересует не доставка клиенту, не уход даже с сетевой карточки, а ИМЕННО окончание (успешное) записи в клиентский сокет (для всех клиентов).

Еще раз подчеркну - клиент, не справившийся с нагрузкой, УБИВАЕТСЯ. Се ля ви. Клиент должен или иметь канал достаточной толщины или брать столько данных, сколько он может переварить. Объем данных регулируется клиентом через объем подписок.

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

Спасибо большое за внимание к проблеме, сам по факту сбора стенда постараюсь сделать постановочные тесты, о результатах доложусь :)

westtrd
() автор топика
Ответ на: комментарий от ae1234

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

ae1234 ★★
()
Ответ на: комментарий от westtrd

а что будет если из 1000пакетов мгновенно отосланных - 750 просто сразу потеряються на следующем хосте у вас ? неужели это всеравно ? :)

ae1234 ★★
()
Ответ на: комментарий от anonymous

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

В данном случае не нужно, поскольку не интересует латентность доставки, хотя тоже интересную проблему подняли.

Я, если нужны точные замеры, пользую или CLOCK_MONOTONIC или constant_tsc, ибо даже простой счетчик процессорных тиков на такой точности уже начинает врать, и существенно.

А кардинальное решение проблемы синхронизации в локальной сети - карты, поддерживающие РТР, в промышленном варианте возможна синхронизация с дискретностью порядка 200 наносекунд.

westtrd
() автор топика
Ответ на: комментарий от ae1234

Не катит.

В данной предметной области неприемлемо ожидание следующих пакетов, котировка с рынка должна быть немедленно доставлена клиента, это специфика финансового рынка.

Другой вопрос, что когда идет группа однотипных пакетов, они, естественно, будут отправляться группой. НО - модель строится исходя из худшего сценария.

westtrd
() автор топика
Ответ на: комментарий от ae1234

а что будет если из 1000пакетов мгновенно отосланных - 750 просто сразу потеряються на следующем хосте у вас ? неужели это всеравно ? :)

Это проблема буферов TCP, сетевого оборудования, клиента наконец, но вовсе не моя :) До провайдера стоит сеть достаточного качества, чтобы оно не исчезало как пыль, а уж дальше - как Бог пошлет, я не собираюсь и не могу управлять неуправляемым :)

westtrd
() автор топика
Ответ на: комментарий от westtrd

ну - вот обычьная отправка это 6микросекунд на пакет - а если скажем через tc - show / manipulate traffic control settings засунуть отсылку пакетов в класс с 0левой скоростью - сделать буффер в >1000 пакетов - и write сделать на каждый сокет - при этом пакеты будут накапливаться в буффере - и есть надежда что сискол будет 1микросекундным - и загонит все 1000 пакетов за 1000микросекунд после чего - разблокировать скорость - и пакеты попрут (наверно) на фулл гигабите по 1.3 микросекунды на 128байтный пакет и общее время отсылки будет не 7000 а 2300 микросекунд (ну и да - 1000микросекунд будет ожидание)

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

ae1234 ★★
()
Ответ на: комментарий от ae1234

при этом пакеты будут накапливаться в буффере

не самый желательный вариант

почемуже это неуправляемое

исходим из того, что оборудование качественное, толщина канала достаточная до провайдера, если будет недостаточная - будет расширена, таким образом, на этом участке проблем нет.

Самое смешное заключается в том, что ДОСТАВКА внутри гигабитной сети в приложении, сделанном на дот-оффтопик с момента попадания пакета в буфер данного сервера показывает среднее порядка 2 миллисекунд. Что не устраивает в данном решении - отвратительная девиация. Потому и принято решение ухода с оффтопика.

westtrd
() автор топика
Ответ на: комментарий от ae1234

Миллисекунд.

Это не я - я как раз в том решении не участвовал. За что купил, за то и продаю :)

westtrd
() автор топика
Ответ на: комментарий от ae1234

Вчера общался с человеком из Штатов, работающим в реалтайм солюшнах

Он мне выдал довольно таки интересные рекомендации: http://www.openonload.org/

Но там надо модифицировать код драйвера под свой NIC.

Что это дает - работа с NIC из userspace минуя kernel со всеми вытекающими, включая уход от проблемы переключения контекстов.

westtrd
() автор топика
Ответ на: комментарий от westtrd

и что - эмулировать всю работу с tcp в юзерспейсе ? а смысл ? ядро ОЧЕНЬ хорошо работает с tcp - тут и сомневаться то бесмысленно

был бы udp - смысл был бы

ae1234 ★★
()
Ответ на: комментарий от westtrd

ксеон 2.4 выдает 250 мегабит если поставите типа i7 на 4.5 ггрц - будет выдавать 500 мегабит из гигабита

вы уверены что это вам мало ?

ae1234 ★★
()
Ответ на: комментарий от westtrd

уж незнаю какие 12 - у меня было 6-7 :)

если там говориться о 4.2 микросекунд - это хардваре причем на том же железе - 2.4ггрц ксеон - то то что у меня получилось 6-7 микросекунд - это крайне хорошо уж чтобы не было - но 2-3 микросекнуд на обработку всех tcp премудростей - всяко не жалко

ae1234 ★★
()
Ответ на: комментарий от westtrd

и если не заметили - там все тесты на udp
у вас же tcp - и я тестил tcp
с udp все конечно просто - там логики в обработке и нет совсем - это вам не tcp

ae1234 ★★
()
Ответ на: комментарий от ae1234

Кстати, в openonload свой стек протоколов :) Единственно, надо фрагменты драйвера корректировать, что совсем муторно :)

Дождусь тестового стенда, начну тестить разные варианты )

Результатами поделюсь :)

westtrd
() автор топика
Ответ на: комментарий от ae1234

Вот потому и фрагмент дров надо переписывать под ту карту с которой будете работать.

Архитектура же openonload не меняется для этого, она включает дрова + стек в юзерспейсе.

westtrd
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.