ВН
я думаю в таких кейсах тебе надо busy poll
Я не могу - у меня io_uring и 1 поток, в котором надо совместить сеть и диск
Size: a a a
2020 June 08
ВН
Но epoll сам по себе быстрый и прикол именно в том, что если программа НИЧЕГО НЕ ДЕЛАЕТ, то сетевой раундтрип 40-50 микросекунд, а если она ещё что-то делает, то сетевой раундтрип становится 90 микросекунд (в дополнение ко времени выполнения самой операции)
ВН
Т.е. я беру один и тот же код. Просто убираю часть которая делает работу - раундтрип 40-50 мкс. Возвращаю - 90 мкс.
IF
Интересно, а никто не знает, как понять источник сетевой задержки?
Прикол следующий: вот есть 2 компа, соединённые 10г сетью, напрямую, попа в попу. Замеряю производительность sockperf pp -m 4096 - получаю среднюю задержку 35 микросекунд. Дальше пишу сам на блокирующем i/o (read/write) тестовый сервер и тестовый клиент (ничего не делающие) - получаю чуть больше: для операций по 4096 байт примерно 43 микросекунды. Но ладно, в целом порядок тот же. А потом - беру своё поделие, которое по запросу фактически что-то пишет на диск - и задержка диска составляет примерно 30-40 микросекунд, но при этом сетевая задержка возрастает аж до 85-90 микросекунд! (т.е. суммарно операция начинает занимать ~130 микросекунд) И это реально происходит именно в момент, когда программа больше ничем не занята. То есть тупо с момента завершения sendmsg до момента получения события в epoll (следующего запроса от тестового клиента) проходит 90 микросекунд. ОТКУДА???
Прикол следующий: вот есть 2 компа, соединённые 10г сетью, напрямую, попа в попу. Замеряю производительность sockperf pp -m 4096 - получаю среднюю задержку 35 микросекунд. Дальше пишу сам на блокирующем i/o (read/write) тестовый сервер и тестовый клиент (ничего не делающие) - получаю чуть больше: для операций по 4096 байт примерно 43 микросекунды. Но ладно, в целом порядок тот же. А потом - беру своё поделие, которое по запросу фактически что-то пишет на диск - и задержка диска составляет примерно 30-40 микросекунд, но при этом сетевая задержка возрастает аж до 85-90 микросекунд! (т.е. суммарно операция начинает занимать ~130 микросекунд) И это реально происходит именно в момент, когда программа больше ничем не занята. То есть тупо с момента завершения sendmsg до момента получения события в epoll (следующего запроса от тестового клиента) проходит 90 микросекунд. ОТКУДА???
Latency матрицы коммутатора. Они очень бывают разными
RS
ну либо шедулер тебя нахер шлет либо цпу пока выйдет из сберегайки
ВН
Latency матрицы коммутатора. Они очень бывают разными
нету коммутатора. попа в попу
IF
Там прямая зависимость от цены
RS
Latency матрицы коммутатора. Они очень бывают разными
нет коммутатора
AT
Это что то наёбывает в ядре, вангую
ВН
ну либо шедулер тебя нахер шлет либо цпу пока выйдет из сберегайки
паверсейв отключен
ВН
Это что то наёбывает в ядре, вангую
вот да - а вот что!
IF
нету коммутатора. попа в попу
А mtu сколько?
RS
вот да - а вот что!
смотри профилировщиком че там вызывается и сколько времени тратится
IF
Ради эксперимента уменьши до 1.5
AK
Вынеси I/O в отдельны тред вообще
ВН
смотри профилировщиком че там вызывается и сколько времени тратится
ну вот внутри моей программы ничего не вызывается
VO
я бы еще раз попробовал бы убедиться что дополнительная работат занимает ровно столько сколько ты считаешь
RS
Т.е. я беру один и тот же код. Просто убираю часть которая делает работу - раундтрип 40-50 мкс. Возвращаю - 90 мкс.
как тогда тебя понять?)
RS
видимо что-то таки вызывает