| |
| |
| |
| 4.6, Аноним (6), 10:27, 10/05/2024 [^] [^^] [^^^] [ответить]
| +7 +/– |
Лол благодаря ему эта строчка вообще существует. А отключать опцию или нет это дело пользователя.
| | |
|
| 3.4, хрю (?), 09:49, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Зачем? Если кому это действительно надо отключают сей алгоритм и давно - "что уже давно делается в таких проектах, как Node.js и curl." Гражданин вещает с позиций AWS, а позиция обычных смертных может быть немного отличаться.
| | |
| |
| |
| 5.104, Abra (?), 22:02, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Простите, а за счёт чего? Данные просто будут переданы быстрее, и только. Но объем должен быть тот же
| | |
|
| 4.8, Аноним (2), 10:32, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если вдруг обычному пользователю захочется форсировать данный флаг глобально. Чтобы в игрушках были минимальные задержки, например...
| | |
| |
| 5.34, Аноним (34), 13:49, 10/05/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
А разве игрушки не UDP пользуются для минимализации латентности?
| | |
| |
| |
| 7.56, Аноним (56), 17:29, 10/05/2024 [^] [^^] [^^^] [ответить]
| +4 +/– |
Правильнее было бы сказать: "Не все".
Unreal Engine - UDP.
Unity - UDP.
Godot - HTTPS поверх TCP (пздц) по дефолту для ленивых. TCP или UDP для всех остальных.
Но нужно учесть тот факт что на Godot игор нет.
| | |
| |
| 8.83, Аноним (2), 04:56, 11/05/2024 [^] [^^] [^^^] [ответить] | –3 +/– | Фактически, сказал тоже самое, но в более краткой форме Разумеется, есть игры к... текст свёрнут, показать | | |
| |
| 9.99, Аноним (99), 15:26, 11/05/2024 [^] [^^] [^^^] [ответить] | +/– | Чушь несёшь Игры в основном используют TCP для согласования и прочей мелочи И ... текст свёрнут, показать | | |
|
|
|
|
|
|
| 3.7, Аноним (7), 10:31, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
любой дистрибутив может сделать это по своему желанию.
если нет то сами себе сделайте.
| | |
|
| 2.39, timur.davletshin (ok), 14:27, 10/05/2024 [^] [^^] [^^^] [ответить]
| +8 +/– |
 Погодите, панове, а что мешает использовать TCP_NODELAY при открытии сокета? Разве не так задумано было? Нужен интерактив? - Тогда используй соотв. опцию при открытии соединения.
Для сомневающихся, советую поиграться с SSH и попробовать заоверрайдить умолчальные TCP_NODELAY. Консолька интересной становится.
| | |
| |
| 3.75, Ivan_83 (ok), 03:20, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Консольке от флага приятно не не более того.
В качестве аргумента скажу что консолька часто нормально себя ощущает при RTT 50-150мс, подозреваю что ОС без TCP_NODELAY на столько пакет не задерживает.
| | |
| |
| 4.97, timur.davletshin (ok), 13:49, 11/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Консольке от флага приятно не не более того.
> В качестве аргумента скажу что консолька часто нормально себя ощущает при RTT
> 50-150мс, подозреваю что ОС без TCP_NODELAY на столько пакет не задерживает.
Патчить кривой софт надо, а не менять то, что потенциально может много проблем создать.
| | |
|
| 3.89, Аноним (89), 09:38, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>а что мешает использовать TCP_NODELAY при открытии сокета?
Тем что не все это знают, а те кто знают те забывают. Признаюсь честно, я делал что то типа прокси-туннеля и запускал VNC через нее и думал что задержки курсора это комп или сеть тормозит. А потом вспомнил про TCP_NODELAY.
Лучше бы имхо было наоборот, флаг TCP_DELAY_LEGACY_FOR_TELNET.
| | |
| |
| 4.94, Ivan_83 (ok), 12:44, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Так оно нужно только для отдельных применений.
У меня вот есть msd - оно стримит IPTV, там свой огромный буффер из которого рассылает клиентам, и от TCP_NODELAY ничего не изменится совсем, потому что у клиента тоже буфера.
| | |
|
| 3.112, pda (ok), 20:45, 12/05/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Наверное то, что приложению по хорошему неоткуда знать нужно ему использовать этот флаг или нет. Так понимаю, он был актуален во времена медленных каналов, вроде модемных. На них экономия могла иметь смысл, на широкополосных нет. По этому его и выносили в конфиг.
Но теперь модемных каналов не осталось и по идее нет нужды требовать от приложений устанавливать его явно.
Вообще это решение выглядит таким себе. По идее механизм управления потоком стоило привязывать к интерфейсу.
| | |
| |
| 4.115, timur.davletshin (ok), 07:43, 13/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Наверное то, что приложению по хорошему неоткуда знать нужно ему использовать этот
> флаг или нет.
А кто об этом должен знать, как не приложение? Вы бредите или это такой юмор?
> Вообще это решение выглядит таким себе. По идее механизм управления потоком стоило
> привязывать к интерфейсу.
А... это после воскресенья такое. Бывает.
| | |
| |
| 5.118, pda (ok), 12:55, 13/05/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
> А кто об этом должен знать, как не приложение? Вы бредите или
> это такой юмор?
Откуда приложению знать (да ещё и на этапе компиляции) в каких условиях его будут использовать? Модемный канал или нет?
> А... это после воскресенья такое. Бывает.
Вы про себя что ли? Ну, просыхайте. Может перечитаете и поймёте.
| | |
| |
| 6.119, timur.davletshin (ok), 13:33, 13/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Откуда приложению знать (да ещё и на этапе компиляции) в каких условиях
> его будут использовать? Модемный канал или нет?
Вы просто не поняли, для чего TCP_NODELAY делался. К ширине канала это имеет очень небольшое отношение. А вот приложение прекрасно знает, что ему нужно больше - интерактив или пропускная способность. Но ты сильно не расстраивайся, не плакай там. Не ты один такой, вон Mozilla (да и Chrome) до сих пор не умеет помечать ToS в пакетах канала данных WebRTC. Багрепортам уже не помню сколько лет.
> какая-то тухлая эскапада на предмет моей некомпетентности
Воспользуйся моим советом выше и поиграйся с SSH. Если они смогли, то что мешает другим?
| | |
| |
| 7.121, pda (ok), 14:40, 13/05/2024 [^] [^^] [^^^] [ответить] | –1 +/– | Вы текст-то новости прочли RFC для алгоритма Нейгла принят в 1984 году и он не... большой текст свёрнут, показать | | |
|
|
|
| 4.132, Аноним (132), 02:35, 16/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Nagle занимается тем, что буферизует данные, записываемые в TCP-сокет, вместо нерадивых приложений которые делают write(2) по паре байт, чтобы без Nagle-а приводило бы к куче мелких пакетов с пейлоадом в эти самые пары байт.
Потому кроме приложений, которые и дергают write(2)-ы, никто и не может знать, нужен Nagle им, потому что написаны они левой пяткой без нормальной буферизации данных, или нет, потому что у программиста есть мозг, и он им подумал о том, что будет происходить с отправляемыми данными на уровне TCP/IP стека.
| | |
|
|
| |
| 3.63, violation (?), 20:49, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Можно вопрос к знатоку Firefox?
Sandbox: seccomp sandbox violation: pid 2247, tid 2250, syscall 441, args 13 140541341901696 32 0 0 8.
[warn] epoll_wait: Function not implemented
Firefox 115.10 esr Gentoo
Решается через
export MOZ_DISABLE_CONTENT_SANDBOX=1
Работает,но 100500 строчек с ошибкой все время бегут друг за другом без остановки в терминале и чтобы остановить закрываю эмулятор терминала.
Может быть можно решить по-нормальному?
| | |
| |
| 4.64, Аноним (64), 21:38, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Нашел такой вариант без export,но ошибки сыпятся все равно.
about:config
security.sandbox.content.level to 0
| | |
| 4.98, timur.davletshin (ok), 13:50, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Можно вопрос к знатоку Firefox?
> Sandbox: seccomp sandbox violation: pid 2247, tid 2250, syscall 441, args 13
> 140541341901696 32 0 0 8.
> [warn] epoll_wait: Function not implemented
> Firefox 115.10 esr Gentoo
> Решается через
> export MOZ_DISABLE_CONTENT_SANDBOX=1
> Работает,но 100500 строчек с ошибкой все время бегут друг за другом
> без остановки в терминале и чтобы остановить закрываю эмулятор терминала.
> Может быть можно решить по-нормальному?
Знатоки Firefox в Bugzilla. Без шуток, туда лучше сразу иди.
| | |
|
|
|
| 1.11, Аноним (11), 11:41, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +15 +/– | |
> Даже если размер полезных данных составляет считанные байты, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации, использования API-обвязок в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.
всё, что нужно знать о современном программизде. адын байт не могут отослать без JSON и TLS.
| | |
| |
| 2.27, Аноним (34), 13:07, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Без Шизон. Вообще непонятна это стремления в ASCII-сериализацию, есть же и двоичные форматы.
| | |
| |
| 3.77, Ivan_83 (ok), 03:26, 11/05/2024 [^] [^^] [^^^] [ответить]
| +3 +/– |
Потому что для отладки текстовых протоколов достаточно обычного отладчика и текстового редактора, а для бинарных нужны парсеры особые.
Для написания текстового кодера достаточно snprintf() а декодера sscanf().
Итого текстовый протокол делается за пол часа и работает сразу, отлаживать можно любой прогой отправляющей текст.
А всякие питонисты у них этот xml/json/yaml чуть не нативно везде напихан, им даже кодить сильно не надо чтобы оно начало по сети бегать.
Я не говорю что бинарные протоколы плохие (не все, ИМХО, как и текстовые), просто показал процесс со стороны разработчика.
| | |
|
| 2.66, Аноним (99), 22:59, 10/05/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
Скажи спасибо, что уже не XML, а пока всего лишь JSON. Правда, теперь идёт YAML и конца этого идиотизма не проглядывается
| | |
| |
| 3.68, Аноним (99), 23:21, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Хотя не, ещё не уже, как раз этот долбанутый aws использует у себя в протоколах XML
| | |
| |
| 4.85, Аноним (85), 08:10, 11/05/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
У жсона тоже можно схему прописать. Да и в xml никто не мешает насрать чем угодно.
| | |
|
| |
| 4.127, Sem (??), 13:02, 14/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Какой в этом смысл? Лучше сразу protobuf использовать бинарный.
| | |
|
|
| 2.76, Ivan_83 (ok), 03:22, 11/05/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Щас набегут контуженные безхопасностью и расскажут что без TLS жизни угрожает опасность, и что сериализацию надо делать средствами руста, не важно сколько оверхэда оно накидывает :)
| | |
|
| 1.12, Шарп (ok), 11:44, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 >Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения.
Если такие пакеты не отправляются, то и алгоритм Нейгла не гадит. Тогда почему он ноет?
| | |
| 1.14, Аноним (14), 11:48, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Хочешь сам рулить отправкой, используй udp, что собственно и сделал гугл с quic.
| | |
| |
| 2.47, laindono (ok), 15:19, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
 В quic пакеты ACK вообще по другому сделаны кстати. Можно сразу на много-много запросов ACK в один пакет запихнуть.
| | |
| 2.79, Ivan_83 (ok), 03:28, 11/05/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Да, и теперь гугол может списать за показ рекламы и сказав: "я тут ваш баннер по юдп послал, услуга оказана".
| | |
| 2.90, Аноним (89), 09:40, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>используй udp
И огреби кучу проблем в реальном мире например с проксями и файрволлами
| | |
|
| 1.15, 12yoexpert (ok), 11:49, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > что уже давно делается в таких проектах, как Node.js
так вот, почему на node.js всё так летает
| | |
| 1.18, 12yoexpert (ok), 11:53, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Последний довод это какой-то вынос мозга, нет слов. Как будто кроме перекладывателей json-ов на свете больше никого нет
| | |
| |
| |
| 3.103, MaleDog (?), 21:40, 11/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Любой алгоритм, где на надежность и гарантия доставки важнее скорости. Но нет, давайте сделаем, как удобнее "прикладникам", а не "сетевикам" и "системщикам". Это как с монгой по умолчанию выставим "0.0.0.0", а кому надо безопасно поставит "127.0.0.1". Напомнить к чему привело?
| | |
|
| 2.42, Аноним (-), 14:51, 10/05/2024 [^] [^^] [^^^] [ответить] | +/– | Он касается всех, не только перекладывателей json а Если ты дёргаешь ядро на ка... большой текст свёрнут, показать | | |
| |
| 3.50, Аноним (50), 16:55, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Это воннаби дед, у него от слов современный, api, json начинается кружится голова и мутнеет перед глазами.
| | |
| 3.80, Ivan_83 (ok), 03:35, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Подход "сделаем всё сами правильно" это отказ от кооперации, когда в ядре за вас уже всё сделали давным давно.
Да, сисколы дорогие относительно буферизации в приложении, но не факт что в приложении получится сделать лучше и что этим вообще стоит заниматся.
Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.
А таймер это ещё один сискол...
В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.
| | |
| |
| 4.107, Аноним (-), 09:07, 12/05/2024 [^] [^^] [^^^] [ответить] | +/– | Идеальная замена алгоритма буферизации, не потребует ничего этого В ядре генера... большой текст свёрнут, показать | | |
| |
| 5.108, Ivan_83 (ok), 10:47, 12/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Как минимум при прототипировании не имеет смысла возится вообще с буферизацией у себя.
В остальном для любой задачи где частота вызова не сильно высокая и не будет расти количество таких писаталей.
Какой нить датчик или сериал порт.
SIGALRM - это какое то жуткое легаси, create_timer_fd(), kqueue() - вот современные методы.
| | |
|
|
|
|
| 1.24, кр3рр (?), 12:05, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
И к слову, отключение TCP_NODELAY не отменяет агрегирования. Десять вызовов send() подряд не приведут к отправке 10 TCP-пакетов. Их, разумеется, будет в среднем больше, чем без NODELAY, но не 10.
| | |
| |
| 2.28, Аноним (28), 13:08, 10/05/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Я далек от глубокого понимания сетей и возможно не понял что ты имеешь ввиду, но ты же выше сам скинул ссылку на пост того самого Джона Нейгла (имени которого алгоритм) и он там утверждает что таки на каждый write() в сеть даже одного байта будет таки слаться отдельный IP-пакет с +40 байтами служебной информации:
"Turning on TCP_NODELAY has similar effects, but can make throughput worse for small writes. If you write a loop which sends just a few bytes (worst case, one byte) to a socket with "write()", and the Nagle algorithm is disabled with TCP_NODELAY, each write becomes one IP packet. This increases traffic by a factor of 40, with IP and TCP headers for each payload."
чего я не догнал, что упустил?
| | |
| |
| 3.40, Аноним (28), 14:28, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
А, сорри. Невнимательно прочитал.
после прочтения строчки:
> Десять вызовов send() подряд не приведут к отправке 10 TCP-пакетов
подумал что имеется ввиду "их будет меньше" и уже глазами мельком проскочил и неверно прочитал следующую строку:
> Их, разумеется, будет в среднем больше
>> БОЛЬШЕ | | |
| |
| 4.46, кр3рр (?), 15:18, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
При 10 вызовах send/write с малым количеством данных без NODELAY в идеале отправится 1 TCP-пакет, но с NODELAY не факт, что отправится 10 — это зависит от заполненности буфера или других факторов.
Подробно не исследовал, у меня была как раз задача отправлять по отдельному пакету на каждый вызов send/write в Linux для TCP-сокета, и я не смог ее решить стандартными средствами юзерспейса.
| | |
|
|
|
| 1.26, Аноним (26), 13:02, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
очередной один "умный" чувак пытается решить за всех
почему он не рассказал что вырастет нагрузка на сетевые устройства из-за возросшего pps?
| | |
| |
| 2.30, 12yoexpert (ok), 13:20, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
потому что на таких сюрпризах амазон веб сервисес зарабатывает бабки. дурить клиентов - основной источник их дохода
| | |
| |
| 3.51, Аноним (50), 16:57, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так он отвечает на комбинаторе, зайди поспорь с ним) А общими словами кидать всякий горазд. Ты ведь даже не понял о чем речь в статье, судя по комментам)
| | |
|
| 2.37, Аноним (37), 13:54, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
В их датацентре pps сетка потянет, а за его пределами - хоть трава не расти.
| | |
| |
| 3.53, Аноним (50), 16:59, 10/05/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
На чем должна быть сетка, чтобы не потянуть возросшие pps от no_delay?! На dlink des-3526 или распбери пи?
| | |
|
| 2.48, Аноним (48), 15:55, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> вырастет нагрузка на сетевые устройства из-за возросшего pps
Устройства младше 15 лет не развалятся, а старше в такие места не ставят. Максимум какому-то помойному оператору с оборудованием с ебея придётся проапгрейдиться, но разве ж это вред?
| | |
|
| 1.31, anonymous (??), 13:30, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
хорошая новость. Я раньше следил за проектом bufferbloat, так как раз с этими странностями TCP/IP пытались бороться (codel, cake они придумали и протолкнули в ядро). Там очень сложно все, и я через слово все понимал на форуме но было безумно интересно. Основной толчок проекту был тогда когда на какую то конференцию сетевиков приперлась куча народу с вайфаем и никто не мог понять вроде по параметрам все должно было работать надежно и с большим запасом а по факту жуткое лагалово особенно в лайвстримах. Это начали раскручивать, и оказалось что там совсем неочевидные вещи происходят, в том числе и то с чем должен был бороться этот алгоритм Nagle но там настолько сложно все - прямо детективная история с аппаратными очередями пакетов, их разбивка, невозможность контролировать это программно из драйверов, аномальное поведение которое при попытке исправить делает еще хуже (вроде до сих пор не побороли сложности с ECM). Короче, очень здорово что снова пытаются разобраться с этим и не только команда с buffetbloat.
| | |
| |
| 2.33, Аноним (37), 13:34, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>детективная история с аппаратными очередями пакетов
Проприетарные истории с сетевыми карточками - конечно же проблема ядра и его разработчиков.
| | |
| |
| 3.55, Аноним (55), 17:14, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это вообще-то очевидно, так как именно им придётся с этим разбираться.
Ну или пусть вешают табличку "ваше оборудование не поддерживается" и идут разрабатывать свободное железо вместо траты сил на кривой вяланд и сустемды.
| | |
|
| 2.81, Ivan_83 (ok), 03:37, 11/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
bufferbloat это примерно как борьба с изменением климата: никто не понимает но всем весело.
| | |
| 2.135, КТОТОТАМ (ok), 17:03, 17/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Прочитал ваше сообщение и заинтересовался) А вы для каких целей занимаетесь изучением темы с Bufferbloat ? Просто у меня тоже в этой теме кое какие наблюдения есть...
| | |
|
| 1.32, Аноним (37), 13:33, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Если это внушение для разработчиков сетевых приложений, не отправляющих по 1 байту, то в принципе нормальный посыл. setsockopt в руки.
Если же хотят в сетевом стеке по умолчанию включенный nodelay, то пусть идут лесом. Если ценой задержек в сети гуляет меньше пакетов, весь мир экономит электричество. Где-то получается обходиться менее производительным оборудованием. Топовые датацентры корпораций - это не весь мир. Даже если в них большая часть передаваемых данных сосредоточена.
| | |
| |
| 2.35, Ананимус (?), 13:49, 10/05/2024 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Если ценой задержек в сети гуляет меньше пакетов, весь мир экономит электричество.
Расчеты экономии в студию, что ли. Звучит как экономия на спичках.
| | |
| |
| 3.36, Аноним (37), 13:53, 10/05/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Звучит как корпоративный буллшит, за который в случае факапа никто отвечать не будет. Присвоить прибыль, обобществить убытки - ваше всё!
| | |
| |
| 4.38, Ананимус (?), 13:57, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Звучит как корпоративный буллшит, за который в случае факапа никто отвечать не будет. Присвоить прибыль, обобществить убытки - ваше всё!
Если это единственная техническая аргументация, на которую ты способен, то я за то чтобы поменять дефолту просто чтобы тебе и дальше жопу рвало.
| | |
| |
| |
| 6.61, Ананимус (?), 20:34, 10/05/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> "отморожу себе уши что бабушке было больно"
Нет, отморожу ему уши. Я не вижу никаких внятных обоснований заметного увеличения трафика от NODELAY.
| | |
|
|
|
| 3.44, Аноним (-), 15:15, 10/05/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Если по-хорошему, то Брукер тоже не привёл никаких расчётов. Прежде чем такое изменение выкатывать в качестве нового дефолта, неплохо было бы оценить последствия.
Я лично, думаю, что так будет правильно -- буферизировать надо в юзерспейсе, там где известен характер данных и требования к задержкам, там где буферизацию можно заточить под юзкейс. И предлагаемая стратегия взять и поменять всем дефолты, неплохой способ заставить юзерспейс думать об этом, а не лепить как придётся. Но я к тому, что если требовать расчётов экономии, то требовать их надо от тех, кто агитирует за изменение дефолтов.
| | |
| |
| 4.49, Ананимус (?), 16:00, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Если по-хорошему, то Брукер тоже не привёл никаких расчётов. Прежде чем такое изменение выкатывать в качестве нового дефолта, неплохо было бы оценить последствия.
Latency можно померять, но если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY. Чтобы далеко не ходить -- это даже в NGINX дефолт. То есть большая часть HTTP трафика в мире ходит с NODELAY и всем нормально.
| | |
| |
| 5.52, Аноним (-), 16:57, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY.
Вот я об этом и говорю. Умозрительные рассуждения на базе голословных утверждений. Но мало того, ты ещё смотришь на ситуацию однобоко и не с того бока. Если изменить дефолты, то проблемой могут стать не столько латенси-критикл приложения, сколько срупут-критикл, которые не используют ноделей. И поэтому интереснее взгляд именно с этой стороны, исследование которое бы оценило как много таких приложений в дикой природе, и как в абсолютных числах может измениться объём мирового трафика.
| | |
| |
| 6.62, Ананимус (?), 20:36, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
>> если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY.
> Если изменить дефолты, то проблемой могут стать не
> столько латенси-критикл приложения, сколько срупут-критикл, которые не используют ноделей.
> И поэтому интереснее взгляд именно с этой стороны, исследование которое бы
> оценило как много таких приложений в дикой природе, и как в
> абсолютных числах может измениться объём мирового трафика.
Оло, NGINX использует NODELAY. Это, считай, 70% мирового трафика. CDN, стриминг и прочее объемное человеческое творчество.
| | |
| |
| 7.84, Аноним (99), 06:32, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Это только фронты, внутри ДЦ идёт гораздо больший трафик и никакого HTTP там нет. Ну и, конечно, замечательные у тебя рассужедния уровня ~ на 30 % можно забить. Собственно по положительному ответу на вопрос топика можно легко определять проф непригодных
| | |
| |
| |
| |
| |
| 11.129, Sem (??), 13:16, 14/05/2024 [^] [^^] [^^^] [ответить] | +/– | Есть некое количество приложений, которые опираются на текущий дефолт И сколько... текст свёрнут, показать | | |
|
|
|
|
|
|
| 5.82, Ivan_83 (ok), 03:42, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Тут надо понимать что и почему, а не просто подражать кому то.
С одной стороны у nginx почти всегда отправляеся большая пачка данных (и я не думаю что DELAY сработал бы).
С другой надо конкурировать с другими, а конкурируют они по всяким дроческим метрикам, среди которых и задержка.
| | |
|
|
|
| 2.58, Аноним (58), 19:13, 10/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Экономия должна достигаться не таким способом. Буквально почти все мобильные приложения построены на базе веба, тянут с собой вебдвижок, и весят сотни мегабайт, при функционале максимум на десятки. Только один запуск такого приложения прожигает, наверное, месяцы потерь на эти 40 байт. Веб - вот где сверх избыточность. Веб и мобильные приложения нужно жестко ограничивать, как по памяти, так и по ресурсам CPU и GPU.
| | |
| |
| 3.65, Аноним (48), 22:38, 10/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну раз нужно, то можешь начинать прямо сегодня, прямо сейчас. Засовываешь свой браузер в cgroup с любыми лимитами и дело в шляпе.
| | |
|
|
| 1.69, Аноним (69), 23:21, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Даже если размер полезных данных составляет считанные байты, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации, использования API-обвязок в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.
Информации мало, а данных много. Вот на это действительно нужно обратить внимание. А опцию каждый разработчик сам решит - включать её в своём приложении или нет.
| | |
| 1.71, Ivan_83 (ok), 02:16, 11/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
1. Кому надо давно сами ставят TCP_NODELAY.
2. Есть разные реализации TCP и я сильно сомневаюсь что TCP_NODELAY и "delayed ACK" работает везде именно как описал Марк.
3. Оптимизации зависят от сценария использования, натягиывать всех на TCP_NODELAY не означает сделать всем лучше, кому то определённо поплохеет.
| | |
| |
| 2.72, Аноним (72), 02:37, 11/05/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> 1. Кому надо давно сами ставят TCP_NODELAY.
А у Вас в велобаджо все еще ставят TCP_NODELAY, а
в веларибо уже давно все могло бы работть и так.
> 2. Есть разные реализации TCP и я сильно сомневаюсь что TCP_NODELAY и "delayed ACK" работает везде именно как описал Марк.
А по конкретнее?
> 3. Оптимизации зависят от сценария использования, натягиывать всех на TCP_NODELAY не означает сделать всем лучше, кому то определённо поплохеет.
Кому-то в 1984 году? Непонятно зачем вообще эту фичу надо по умолчанию включать?
| | |
| |
| 3.73, Ivan_83 (ok), 03:02, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Есть как минимум один стёк в венде, два во FreeBSD, вероятно в других BSD и огрызке ещё минимум полтора наберётся, есть юзерспейсные реализации для всяких DPDK/netmap, и есть линуксовый.
И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем" я бы лучше послушал мнение разработчиков которые пилят сейчас TCP, как минимум из нетфликса и гугла, они должны быть глубоко в теме и иметь адекватную экспертизу.
Кто такой Марк и насколько он больше в теме по сравнению с местными коментаторами и мной - я не знаю.
Своей экспертизы у меня нет, есть только понимание что современный TCP стёк очень сложный и учитывает очень много всего.
У того же RACK крутилок наверное более 150, а там ещё рядом крутилки СС, и крутилки от самой ОС, и это всё вместе очень не тривиально взаимодействует.
И даже если мнение нетфликса и гугла совпадёт с мнением Марка это будет означать что рекомендация годная для серверов/раздачи, но не факт что клиенту оно надо.
| | |
| |
| 4.87, Ананимус (?), 09:02, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
> И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем"
> я бы лучше послушал мнение разработчиков которые пилят сейчас TCP, как
> минимум из нетфликса и гугла, они должны быть глубоко в теме
> и иметь адекватную экспертизу.
Это ведет к помойным интерфейсам, которыми нельзя пользоваться без книжек и best practices.
| | |
| |
| 5.88, крок (?), 09:18, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Иногда нет простых и хороших решений для сложных комплексных проблем.
Книжки нужны тем кто считает что в его ситуации дефолты не оптимальны.
| | |
| |
| 6.91, Ананимус (?), 09:48, 11/05/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Иногда нет простых и хороших решений для сложных комплексных проблем.
> Книжки нужны тем кто считает что в его ситуации дефолты не оптимальны.
Как мы тут выяснили, дефолты неадекватны почти всем современным применениям.
| | |
| |
| 7.93, Ivan_83 (ok), 12:40, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Это вы где то для себя выяснили, но лучше дефолтов от вас как то ничего не видно.
Сысоев хотя бы в 2007 описывал как, что и для чего тюнить.
| | |
|
|
| 5.120, Аноним (120), 14:32, 13/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>помойным интерфейсам, которыми нельзя пользоваться без книжек и best practices
Книжки читать и best practices разбирать - это-ж какая нагрузка на мозги.
| | |
| |
| 6.126, Ананимус (?), 01:08, 14/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Книжки читать и best practices разбирать - это-ж какая нагрузка на мозги.
Конечно. Приходишь ты в гости, зашел в туалет. Нажимаешь кнопку слива и тут внезапно унитаз начинает квартиру говном заливать. Ты выбегаешь в панике, а хозяева говорят: ну ты чо надо было инструкцию читать это кнопка фонтанирования говном, чтобы слив работал надо переключить унитаз в правильный режим специальной педалью за бачком.
Вот примерно так это выглядит, если переносить на реальность. Good defaults matter, очевидные вещи должны делаться очевидным способом. Если в большинстве случаев Нагль это неочевидная история, которая только все портит, ему не место в дефолтах.
| | |
|
|
| 4.124, Аноним (-), 18:04, 13/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем" я бы лучше послушал мнение разработчиков
Мнение анонимов имеет право на существование. Характер задач выполняемых tcp меняется, и исторические наслоения легаси становятся иррелевантными. Keep It Simple, Stupid, выкидывай всё, что не выглядит строго необходимым, потому что иначе все эти протоколы под своим весом обвалятся.
| | |
|
|
| 2.74, Ivan_83 (ok), 03:14, 11/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Во фре вообще нет крутилки глобально включающей TCP_NODELAY для всех сокетов.
Видимо оно нафиг не надо.
| | |
|
| 1.113, Аноним (113), 21:03, 12/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> ... использования API-обвязок в JSON и отправки ...
Всё так: сколько там переизбыток на передаче описания структуры данных через обвязку. Но зато проще войти в IT. Но - недостатки потом всюду.
| | |
| 1.116, Аноним (116), 08:20, 13/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А в венде можно активировать TCP_NODELAY по умолчанию для всех соединений через реестр. А в линуксе как это сделоть, а?
| | |
| 1.131, Электрон (?), 23:01, 15/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Его текст заслуживает отдельно потраченного против него времени. Там если пройтись с CTRL+C по тексту, много раз будет "проблема во всех вокруг, но не из-за меня".
Есть: периодический дебаг отклика приложений.
Хочет: давайте перевернем все наоброт!
Но почему-то он не идет к авторам программ (своих же амазоновских микросервисов? Кто же еще будет 0.5мс отклик иметь) и не просит их включить издавна рабочий флаг.
Да, программы чаще всего отправляют большие пакеты, а не по байту. А ещё программы ничего не знают о фактическом MTU, поэтому (и только с TCP, не UDP!) единственный способ не терять в оверхеде -- дать системе самой разбивать поток данных на TCP пакеты. Особенно с pMTUd в IPv6 это должно работать на 100%.
Почему сразу NODELAY? Может стоит изменить значения таймера, из-за которого задерживается? Либо эвристика в этом месте, либо эвристика в плане автоматического включения NODELAY.
В конце он пишет, мол, "когда я write(), то оно должно [отсылаться]". Нет, мой дорогой, по семантике надо flush!
Ненаучный подход, подискутировать можно и нужно, но не с его статьи в качестве вводной. Кроме себя ничего не видит.
| | |
| |
| 2.134, Аноним (134), 09:42, 16/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> в чём заключается nodelay если оно приостонавливает отправку?)
Наоборот, TCP_NODELAY отключает приостановку отправки. Приостановка нужна, чтобы вместо 1000 пакетов с 1 байтом данных в каждом и 40 байтов заголовков отправить один пакет и сэкономить 40К на сетевых заголовках.
| | |
|
|
