The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Предложение по включению режима TCP_NODELAY по умолчанию, opennews (??), 10-Май-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


80. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:35 
Подход "сделаем всё сами правильно" это отказ от кооперации, когда в ядре за вас уже всё сделали давным давно.
Да, сисколы дорогие относительно буферизации в приложении, но не факт что в приложении получится сделать лучше и что этим вообще стоит заниматся.

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

В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

107. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (-), 12-Май-24, 09:07 
> Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.

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

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

> А таймер это ещё один сискол...

Попробуй посчитать. Вот представь, что приложение генерирует данные по байту, что временя до следующего байта распределяется по Пуассону. Приложение хотело бы байты отправлять по мере появления, чтобы не терять латенси, но готово отчасти пожертвовать латенси ради срупута. Зная задержку на буферизацию в ядре, попробуй прикинуть при каких лямбдах буферизация в ядре будет выгоднее периодической (10 раз в сек?) обработки SIGALRM, а потом попробуй нафантазировать случай, который реализует такую лямбду, при этом хотя бы отдалённо выглядя реалистично. В этом случае, ведь, надо чтобы требования к задержкам со стороны задачи примерно бы совпадали с тем, что ядро использует. На осмысленность экономии трёх байт трафика, давай забьём, примем её как данность, чтобы не сравнивать яблоки с апельсинами, экономию трафика и латенси.

> В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.

Было бы убедительнее, если бы ты привёл пример.

Ответить | Правка | Наверх | Cообщить модератору

108. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 12-Май-24, 10:47 
Как минимум при прототипировании не имеет смысла возится вообще с буферизацией у себя.
В остальном для любой задачи где частота вызова не сильно высокая и не будет расти количество таких писаталей.
Какой нить датчик или сериал порт.


SIGALRM - это какое то жуткое легаси, create_timer_fd(), kqueue() - вот современные методы.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру