LINUX.ORG.RU

Предельная пропускная способность loopback на мощной машине


1

2

Допустим, есть машина:
- 6x10 ядер по 2-3 ГГц,
- ОС Linux 3.x,
- 1 TB памяти.

Какую максимальную скорость обмена TCP-пакетами по 36 байт можно выжать из канала loopback в реальности? Как это померять?

★★★★★

ты забыл сферические флаги :)))))

Jetty ★★★★★
()

Вот здесь человек пишет про 500к-1млн коннектов. Программа на Erlang: http://urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/

ты забыл сферические флаги

Я прошу отозваться людей, которые имеют конкретный опыт, и
могут примерно оценить. Или привести аналогичную статистику.
Хотя бы для обычного 8-ядерного процессора с 32 гигами памяти.

pacify ★★★★★
() автор топика

Судя по всему ты всё делаешь неправильно.

Огласи задачу, скорее всего IPC выбран неправильный.

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

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

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

Вот здесь человек пишет про 500к-1млн коннектов.

Так человек пишет про количество коннектов, а не пропускную способность.

mv ★★★★★
()

канала loopback

Что подразумевается?

Если это TCP-клиент и TCP-сервер на localhost, то:

1. Для сообщений по 36 байт (если это не шутка) в обязательном порядке вырубить алгоритм Нагля. Примерно так:

const int on = 1 ;
     
setsockopt( s, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on));

2. Если допустимо, то использовать не TCP, а UDP. Это малость по-живее будет.

Как это померять?

ethtool/mii-tool? Например, ethtool -S интерфейс даст Вам статистику... Как-то так подойдёт?

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

QNX, Mach, вполне нашли реальные применения, в OSX все гуи эвенты пересылаемые меж приложениями и UI сервисами сделаны через mach_msg, в iOS скорее всего тоже. Так что оно используеться вполне в RL, фетишем и не пахнет, т.к. реально быстро и удобно. А «ненативные стороны микроядра», та же apple обошла тупо поместив все «обычные кернельные функции» в монолит BSD ядра, который работает под управлением mach ядра. Никакого фетиша, голимые кривые, но работающие, проприетарные костыли

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

Теперь объясни, как увеличением количества переключений контекста для выполнения одного действия предлагалось бороться с ограничением по количеству переключений контекста в единицу времени?

Для ТС на локалхосте вообще никакие переключения не нужны: сбацал две безлочные очереди в расшаренной памяти, и вперёд.

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

Кстати, да...

Для ТС на локалхосте вообще никакие переключения не нужны: сбацал две безлочные очереди в расшаренной памяти, и вперёд.

Но чует сердце-вещун что почему-то надо именно так как ТС описал. Вот это select() + FD_ISSET() несколько намекает...

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

Почему? На знаменах в качестве девиза для холивара - вполне себе ничего :)

slackwarrior ★★★★★
()

Не знаю пропускную способность lo, но при переходе на UNIX-сокет она вырастает в разы.

OxiD ★★★★
()

прошлую тему вспомни - по 150тон на ядро

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

Для ТС на локалхосте вообще никакие переключения не нужны: сбацал две безлочные очереди в расшаренной памяти, и вперёд.

Ну я как-бы намекал загнать все в 1 процесс тоже. А Apple в своей OSX умудрились свести кол-во переключений контекста по сути к минимуму, я про то, что сам механизм сообщений в микроядерных системах - это явно очень эффективный IPC, т.к. там это очень критичная часть системы. Если ТС-ну нужно обмениваться чем-то меж разными процессами все-же, то это может быть выходом. Хотя да, лучше конечно загнать все в 1 процесс, и пущай треды общаются не дергая ядро вообще.

qrck ★★
()

А зачем TCP на localhost ? Прогрессия на лицо:

speed: TCP < UDP < named pipe

Нужно бы написать простые клиент-сервер, желательно многопоточные, т.к. при частых вызовах read/write выходим в лимит на cpu/ядро.

gh0stwizard ★★★★★
()

Как это померять?

Если речь про bandwidth, то, например:

# iperf -s -i 2
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 37835
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 2.0 sec  2.09 GBytes  9.00 Gbits/sec
[  4]  2.0- 4.0 sec  1.82 GBytes  7.84 Gbits/sec
[  4]  4.0- 6.0 sec  2.10 GBytes  9.02 Gbits/sec
[  4]  6.0- 8.0 sec  2.12 GBytes  9.13 Gbits/sec
[  4]  8.0-10.0 sec  2.02 GBytes  8.66 Gbits/sec
[  4]  0.0-10.0 sec  10.2 GBytes  8.72 Gbits/sec
# iperf -c localhost -i 2
------------------------------------------------------------
Client connecting to localhost, TCP port 5001
TCP window size:  331 KByte (default)
------------------------------------------------------------
[  3] local 127.0.0.1 port 37835 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 2.0 sec  2.09 GBytes  9.00 Gbits/sec
[  3]  2.0- 4.0 sec  1.82 GBytes  7.84 Gbits/sec
[  3]  4.0- 6.0 sec  2.10 GBytes  9.02 Gbits/sec
[  3]  6.0- 8.0 sec  2.12 GBytes  9.13 Gbits/sec
[  3]  8.0-10.0 sec  2.02 GBytes  8.66 Gbits/sec
[  3]  0.0-10.0 sec  10.2 GBytes  8.73 Gbits/sec

зависит от состояния sysctl(8) и sysctl.conf(5).

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

а зачем это нужно?

Заказчик попросил прикинуть производительность линуксового
loopback. Для нашей задачи это необходимо (нужен хост,
который будет генерировать уникальные хэш-значения, и
рассылать его другим узлам).
Соответственно, нужно определить - какие машины под приложение закупать.

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