Скорость пинг-понга - 40 тыс запросов/сек

имхо ты както нетак понимаеш эти примеры в моем примере - идут именно контент свитчи - один процесс пишет в пайп - а потом говорит ядру - ЖДИ данных от другого процесса - и засыпает

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

... и при этом исполняется в 13 раз быстрее, и сумме на передачу того же количества байтов потратил раз в восемь меньше CPU :)

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

Ну значит прога написана так, что не позволяет забивать весь канал. Т.е. надо сразу пулять по 1.6 миллиону пакетов за секунду... Во что упирались определили? Это ядро тормозит или что?

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

Ну так разница и заключается в одном единственном факторе: поллинг в юзерспейсе вместо переключений контекста. не понимаю, чем ты недоволен :)

неа - не определили
просто не хватало скорости проца
что так и как происходит в ядре и драйвере - мне вот неизвестно
поступает пакет от юзерспейса - проходит по сетевой инфраструктуре ядра - посылается в драйвер - драйвер как то пинает сетевую
вот на это все затрачивается 5-6микросекунд

полинг - это достаточно тупая трата ресурсов - иногда можно иногда нет

Переключение контекстов тоже непроизводительная трата ресурсов - иногда оно лучше иногда нет. И что?

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

прям типа микроядро - и теже тормаза

это общение с другим процессом - тобиш все тотже контент свитч

Ну вот же у тебя на предыдущей странице два процесса общаются без контент-свитчей. Через пайпы.

Что-то странно. Если вы упирались в проц, то это значит вызывали write/read (sendto/recvfrom) до бесконечности (как в ваших примерах), т.е. когда надо и когда не надо. Для полной картинки желательно ответить на такие вопросы:

1. За сколько доль секунд выполняется sendto и recvfrom, по отдельности. Возможно косяк в драйвере/сетевухе.

2. За сколько секунд у вас формируется пакет (если юзаете SOCK_RAW). Если не юзаете, то достаточно учесть пункт 1.

3. Определить лимиты на pthread и т.п.

4. Статистика по ошибкам EAGAIN и т.п. Возможно у вас нет нагрузки только из-за того, что валится туча EAGAIN.

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

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

суть то в том что вызовы непредсказуемы

тестировали тока отправку
отправлялся udp - за все вместе с отправкой 6микросекунд
небыло никаких лимитов
ошибок небыло
то непроблема

была простая схема теста - отсылка около 1000 пакетов - раз в секунду
и замеряли время что заняла отправка
Одновременная запись в несколько сокетов
вот эта тема

будет конечно профит в скорости - но стоит ли оно такого

Ну топик стартер пытается максимум выдавить

суть то в том что вызовы непредсказуемы

В непредсказуемом случае можно понизить приоритет процессу - и пусть он добирает остатки CPU за другими

Если принять классический MTU=1500 байт (твои восьмибайтовые пинги всё равно ходят по сети в виде пакетов, размером в MTU), 40К * 1.5К = 60М: 40К запросов/сек займут полосу примерно 60 Мбит/с. Поместится ли она в канал между клиентом и сервером - это уже другой вопрос. Для подключения 100 Мбит/с, считаю, полученное значение вполне нормальным, если нет другого трафика. А для гигабита, пожалуй, маловато.

у 8ми байтного пинга - размер пакета 50-60 гдето

ну да - максимум - но максимум с контент свитчами именно :)

можно то можно - если это 4-6 ядерный проц - это даже может быть весьма выгодно
а если какойнить i3 - в 2 ядра - иль атом
и приложение уже юзает для работы 2 ядра - что сейчас почти на любой (игра 3д например)

всё равно ходят по сети в виде пакетов, размером в MTU

Не, это я чего-то проглючил. Это же максимальный.

Почитал доку на openonload, думаю это предел нынешней архитектуры ядра. Честно, не знал.

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

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

Не в курсе, надо спрашивать у спецов.

и причем тут нынешняя архитектура ядра ?

В доке openonload даны цифры: 4 byte UDP packet with kernel 470k p/s vs openonload 2m p/s. Да, они не указали в каком виде был замер userspace или kernelspace, думаю что в userspace, раз их софт расчитан под это. Возможно дело в переключениях, но что-то подсказывает, что это не так.

Проверил скорость под виндой:
1) клиент(винда) - сервер(линукс): 3.2-3.6к запросов/сек,
2) клиент(линукс) - сервер(линукс): 40к запросов/сек.

P.S. TCP_NODELAY ничего, кстати, не поменял.

1) клиент(винда) - сервер(линукс): 3.2-3.6к запросов/сек,

антивирусы, файрволы - отключены