>> Только при чем тут окно? 0_ото не про статьюж было, а про камент с "The TCP bandwidth delay product window limiting algorithm controlled by the sysctl(8) variable net.inet.tcp.inflight.enable"
>> Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов.
о чём речь в каментах и была. про soft-router'ы на BSD, да и вообще ковыряние в сетевой подсистеме BSD и Linux
>> Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиональных систем именно так и должно быть.
в этом конкретном случае размер буфера похоже не тольк не настраивался, но и не учитывался алгоритмом вообще.
>> Пример, jitter-буфер в VoIP-шлюзах Cisco тоже измеряется в миллисекундах.
ммм, ничего про это не знаю, но может быть подразумевается, что поток данных звука там с постоянным bitrate, да и вообще какого-то одного формата ? и указано так мол "вот на столько ms эта мера по снижению jitter добавит к задержкам передачи речи, а сколько это в байтах и насколько большие отклонения сгладит - сами посчитаете"
>> Когда память стала дешевой, кто-то решил, что программные автоматически расширяемые за счет оперативки буферы это круто. С одной стороны выглядит неплохо, пакеты не теряются, никаких ретрансмиссий нет. Но по итогу работа алгоритмов управления потоками и заторами TCP оказалась полностью нарушенной, о чем, собственно и говорится в новости.
именно по-этому фразы вроде "Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста." бесят. специалисты и необделённые деньгами - не всегда одно и тоже. специалисты soft router'ов и разработчики ядра небось тоже негодуют.
и я не уверен, что ядро Linux вообще выделяет бесконечные программные буферы, тем более выделяет вообще, если знает, что на текущем железе есть аппаратные. хотя может быть именно о выпиливании такого поведения и подразумевалось под "добавлены исправления в код драйверов e1000, e1000e и ath9k", но всё равно маловероятно.
да и не факт вообще, что в статье речь только о soft маршрутизатор или только о конечных узлах. может быть имелось ввиду, что алгоритмы congestion control (cat /proc/sys/net/ipv4/tcp_available_congestion_control, их много) на узлах обламываются из-за запредельной буферизации на soft-router'ах ?
