| 1.1, odus (ok), 08:17, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Вообще выключили
FreeBSD 8.2
The TCP bandwidth delay product window limiting algorithm controlled by the sysctl(8) variable net.inet.tcp.inflight.enable is now disabled by default. It has been found that this algorithm is inefficient on a fast network with smaller RTT than 10ms. It had been enabled by default since 5.2-RELEASE, and then had been disabled only if the RTT was lesser than 10ms since 7.0-RELEASE. Pluggable TCP congestion control algorithm modules are planned to be added for the future releases.[r211538]
| | |
| |
| 2.4, анон (?), 10:48, 28/02/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>The TCP bandwidth delay product window limiting algorithm
Скажите, а как это относится к сабжу?
| | |
| |
| 3.14, pavlinux (ok), 17:56, 28/02/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 А это BSD, у них всё через ж...у.
Вместо определения размера буфера, они определяют время задержки. :)
| | |
| |
| 4.15, northbear (ok), 20:31, 28/02/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Да не... Это у тебя мозги оттуда растут.
Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста.
А вот время задержки при прохождении пакета через роутер, это вполне конкретный параметр и измеряется он никак не в мегабайтах.
| | |
| |
| 5.17, pavlinux (ok), 20:56, 28/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну конечно, и в независимости от трафика они все будут торчать в буфере 10 мс,
пофигу что, PPP, WiFi или 10G Ethernet. Получиться этакий Stable Ping.
| | |
| |
| 6.21, northbear (ok), 06:05, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Не тормози... Не более 10ms. На уровне TCP не имеет значения по какому транспорту поступают пакеты в роутер.
Если вдруг это действительно становится принципиальным, то для этого ставятся специализированные железки заточенные под обслуживание конкретного типа траффика.
| | |
| |
| 7.28, DFX (ok), 09:47, 01/03/2011 [^] [^^] [^^^] [ответить] | +/– |  ну нифигасебе, автор уже придумал какой-то свой TCP, с буферастыми маршрутизатор... большой текст свёрнут, показать | | |
| |
| |
| 9.33, DFX (ok), 19:33, 02/03/2011 [^] [^^] [^^^] [ответить] | +/– | то не про статьюж было, а про камент с The TCP bandwidth delay product window l... большой текст свёрнут, показать | | |
|
|
|
|
| 5.20, User294 (ok), 22:30, 28/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Для серьезных систем пох сколько памяти понадобится для буфера.
А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание? Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то не попадались. Также не понятно зачем вообще буферизовать все и вся с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу? oO
| | |
| |
| 6.22, northbear (ok), 06:33, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Для серьезных систем пох сколько памяти понадобится для буфера.
> А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание?
> Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то
> не попадались. Также не понятно зачем вообще буферизовать все и вся
> с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу?
> oO
Ты вообще серьезное железо видел? А документацию хоть раз пробовал почитать? Ты знаешь, например, почему производительность серьезных маршрутизаторов измеряется в pps? А что такое pps ты вообще знаешь? А как соотносится скорость портов, производительность в pps, максимально допустимое время задержки пакета и объем внутренней памяти для буфера можешь сообразить?
Мне лично, да и любому профессионалу, важна пропускная способность и предел латентности системы. Сколько при этом система потратит памяти мне по барабану. Производитель конкретно указывает, что конкретная железка обеспечит указанное время обработки пакета при объеме траффика не более такой-то величины. Исходя из этого и подбирается железо.
Это и есть "Ынтерпрайзный" подход к делу.
А вы дома можете хоть в литрах буфера измерять. Только тип жидкости не забывайте указывать.
| | |
|
|
|
|
|
| 1.2, stalker37 (?), 09:19, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Хех... ну что же посмотрим что из этого выйдет.. Есть где бы такое было интересно пощупать в продакшене.
| | |
| 1.8, Ромка (?), 12:30, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А что такое сетевая буферизация? Нет, серьёзно. Впервые слышу. :-(
| | |
| |
| 2.11, Аноним (-), 13:46, 28/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Гуглить в сторону "Network buffering". На русском я пока не нашел ничего...
| | |
| 2.13, pavlinux (ok), 17:34, 28/02/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> А что такое сетевая буферизация?
Очередь пакетов знаете? Так вот, этот дядька считает, что
принудительное завышение размера очереди это нехорошо для сети.
| | |
|
| 1.18, СуперАноним (?), 21:44, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вот только непонятно, как этот проект будет сочетаться с NAPI, который уменьшает частоту аппаратных прерываний от сетевых адаптеров именно за счёт буферизации нескольких последовательно принимаемых пакетов.
| | |
| |
| 2.19, User294 (ok), 22:22, 28/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Добро пожаловать в реальный мир, мир tradeoff'ов и компромиссов :). В идеальном мире было бы круто передавать данные с входа на выход с нулевой задержкой и бесконечной скоростью. В реальном так, как вы понимаете, не катит - нас забыли снабдить процессорами бесконечной мощности с нулевым временем реакции на событие вида "получена порция данных" ака "прерывание", да и сети почему-то обладают хоть и приличной но конечной скоростью передачи данных :)
| | |
| 2.23, northbear (ok), 07:00, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Полагаю, это вопрос возможностей. Ядро должно уметь обрабатывать траффик с минимальными задержками. А буферы включить принципиальных проблем нет, если вам это вдруг покажется необходимым.
А что собственно вы имеете против прерываний? Они, эти самые прерывания, для того и создавались, чтобы обрабатывать события более важные, чем текущие задачи.
| | |
| |
| 3.24, К.О. (?), 07:24, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко тактов на сохранение основных регистров.
В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.
| | |
| |
| 4.25, К.О. (?), 07:26, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение
> контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.
Ну и да, про аннулирование длиннющего префетча тоже молчу.
| | |
| 4.31, northbear (??), 16:01, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без
> поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко
> тактов на сохранение основных регистров.
> В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение
> контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.
Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой подсистеме прерывания аппаратные.
Не очень хорошо понимаю, что значит уменьшить число прерываний? Если данные пришли, то их надо обрабатывать. Можно конечно попробовать игнорировать прерывания, но что сетевой карте тогда делать с вашими данными?
Может имеет смысл покупать адекватные сетевые карты которые имеют нормальный буфер?
| | |
| |
| 5.32, Andrey Mitrofanov (?), 18:21, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой
> подсистеме прерывания аппаратные.
Иногда эффективнее поллить, говорят... Отключив прерывания, о ужас.
google:NAPI
| | |
| 5.34, К.О. (?), 17:22, 07/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
Про поллинг что-нибудь слышали? Или про обработку нескольких пакетов в прерывание? А это - уже буферизация, и повышение latency.
| | |
|
|
| 3.27, СуперАноним (?), 08:56, 01/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>А что собственно вы имеете против прерываний?
Если они происходят часто, то большой процент времени всяких там переключений аппаратных и программных. Поэтому, собственно, разрабатывашие NAPI и озаботились чтобы снизить частоту прерываний и за счёт этого увеличить пропускную способность сетевой подсистемы. И да, пропускная способность и латентность находятся в некотором антагонизме.
| | |
|
|
|
