Эмоционально... Про окно вы все верно сказали. Только при чем тут окно? 0_о
Прочитайте статью Transmission Control Protocol про flow control и congestion control. Вам будет понятно о чем говорится в новости. Про память, еще раз... Меня не интересует размер буфера. Меня интересует время задержки. И если железо не может мне гарантировать в данном узле при данной нагрузке то время задержки которое я считаю приемлемым для себя, то такое железо мне просто не нужно.
Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов.
Я знаю, что такое аппаратные буферы. К буферам о которых говорится в новости они не имеют никакого отношения.
Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиональных систем именно так и должно быть. Пример, jitter-буфер в VoIP-шлюзах Cisco тоже измеряется в миллисекундах.
Я в свое время тоже этому удивился. Теперь же мне непонятно как может быть иначе. :)
еще раз... аппаратные буферы нерасширяемы, т.е. как только они переполняются, система вынуждена дропать пакеты. Удаленная сторона, видя, что пакеты теряются, сообщает отправителю, что надо снизить скорость передачи.
Когда память стала дешевой, кто-то решил, что программные автоматически расширяемые за счет оперативки буферы это круто. С одной стороны выглядит неплохо, пакеты не теряются, никаких ретрансмиссий нет. Но по итогу работа алгоритмов управления потоками и заторами TCP оказалась полностью нарушенной, о чем, собственно и говорится в новости.
