ну нифигасебе, автор уже придумал какой-то свой TCP, с буферастыми маршрутизаторами и их преферансами в L4 ?а ничего, что результат перемножения пропускной_способности_канала(порта) на задержку(Round Trip Time), основополагающая величина для исчисления окна TCP ?
http://en.wikipedia.org/wiki/Bandwidth-delay_product
"A high bandwidth-delay product is an important problem case in the design of protocols such as TCP in respect of performance tuning, because the protocol can only achieve optimum throughput if a sender sends a sufficiently large quantity of data before being required to stop and wait until a confirming message is received from the receiver, acknowledging successful receipt of that data."
>> Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста.
вот про таких в статье и написано... цена падает -> доступные размеры памяти растут быстро, скорость работы этой памяти - _нет_. войдя в буфер с одного конца, данные уйдут только с другого пока не пройдут всю его величину. больше буфер -> дольше обработка.
задержка(delay) теперь состоит не из RTT, а из RTT+обработка_буфера.
на что автору так уклончиво пытались намекнуть -
1) увеличиваем bandwidth (PPP -> WiFi -> 10G Ethernet)
2) увеличиваем буфер (увеличиваем delay)
3) значит, заменяем _возможный_минимальный_ bandwidth(некий_тощий_порт)*delay(RTT_между_данными_узлами_сети) на bandwidth(некий_жирный_порт)*delay(RTT_между_данными_узлами_сети+обработка_жирного_буфера)
4) алгоритм расчёта окна работает не оптимизировано, latency повышается, по сравнению с тем, чего можно было добиться, если не дрочить на дешёвую память.
более того, если алгоритм вообще не учитывает влияние буферизации, то у него может сложиться "ошибочное впечатление" о максимальной ёмкости канала в целом.
сложная концепция ? вроде в новости доходчиво объяснили.
>> Ты знаешь, например, почему производительность серьезных маршрутизаторов измеряется в pps? А что такое pps ты вообще знаешь? А как соотносится скорость портов, производительность в pps, максимально допустимое время задержки пакета и объем внутренней памяти для буфера можешь сообразить?
действительно, как ?
>> Мне лично, да и любому профессионалу, важна пропускная способность и предел латентности системы.
ещё как!
>> Сколько при этом система потратит памяти мне по барабану.
а не должно, если разговор о коммутации/маршрутизации и latency.
поясняю: RTT - это параметр, обределяющийся совокупностью _каналов_ от одного узла, до другого в сети. если Ваше железо - не говно, то оно делает коммутацию/маршрутизацию на wire-speed и на него не влияет. буфера для коммутации и маршрутизации в "серьезных маршрутизаторах" находятся явно не в обычной оперативе, а отдельном/ых чипе/ах этих самых "специализированных железок" и размером-то небольшим(именно из расчёта для максимальной пропускной способности, и _не больше_).
а потом, больше, чем там напаяно, оно явно не вырастет, значит, если что - пойдёт в медленную оперативу.
http://www.fujitsu.com/emea/services/microelectronics/networ.../
вот, посмотри, автор, где буфера для коммутации живут. сколько там буфера для 10Г ? целых _2Мбайта_!
это если разговор про "специальные железки", а не писюк с DDR3 и BSD'ёй.
что касается BSD, в частности, и ОС на двух узлах(_на узлах, получателе и отправителе_), в целом - RTT оно не улучшит, хоть обпукается, а вот размер буфера - какбэ оператор должен иметь параметр, чтобы настраивать.
а алгоритмы должны это учитывать.
>> Производитель конкретно указывает, что конкретная железка обеспечит указанное время обработки пакета при объеме траффика не более такой-то величины.
мы всё ещё о промежуточных маршрутизаторах, занимающихся именно маршрутизацией, а не фильтрацией там или NAT'ом ? можно посмотреть таблицу, или график там, зависимости времени обработки пакета от нагрузки (причём, нагрузки - до заявленого максимального pps) для какой-нибудь железки ? и заодно узнать, _как это всё связано с алгоритмами расчёта окна TCP_ ?
короче говоря, злоупотребление горами говённой памяти - не к добру, особенно для latency, хоть в сетях (читаем новость ещё раз), хоть в звуке (jack - наше всё), хоть в видео (многие ли слыхали про попытки, в последнее время, избавиться от двойной и тройной буферизации в X и toolkit'ах ? а они есть. даже злобная nvidia подключилась).
PS: delay & latency & QoS в картинках - http://www.agilitycom.com/product-literature/Optimization_WP...
