Re: [SPAM]уменьшение т рафика в сети

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Wed, Mar 11, 2009 at 07:17:10PM +0200, MZ wrote:

> Igor Sysoev wrote:
> >On Tue, Mar 10, 2009 at 10:50:54PM +0300, Михаил Монашёв wrote:
> >
> >>IS> Не нужен polling для em. Не нужен.
> >>IS> Драйвер em в 7ке сам делает что-то вроде адаптивного поллинга.
> >>
> >>Читал:
> >>http://groups.google.com/group/fido7.ru.unix.bsd/browse_thread/thread/75877aaebabc4343/0bc35750213fd9b0
> >> ?
> >
> >Интересно.
> >
> >Там есть вот какие моменты:
> >
> >1) там вместе с
> >
> >dev.em.0.rx_processing_limit: 1000 
> >
> >были увеличены таймауты:
> >
> >dev.em.0.rx_int_delay: 200
> >dev.em.0.tx_int_delay: 200
> >dev.em.0.rx_abs_int_delay: 200
> >dev.em.0.tx_abs_int_delay: 200
> >
> >Их хорошо бы оставить дефолтными или даже уменьшить до нуля, чтобы
> >прерывания шли по первому же пакету: em потом запрещает прерывания
> >и начинает обрабатывать пакеты. Возможно, этой задержкой объясняется
> >некоторое преимущество polling'а (при тестировании с INVARIANTS, без
> >INVARIANTS, насколько я понял тестировался только polling).
> 
> Немедленные прерывания по первому пакету приведут к тому что в очереди 
> будет находиться очень мало пакетов (или вообще этот один первый) и 
> прерываний будет очень много.

Нужно иметь ввиду, что пакет не будет сразу обработан в прерывании.
Обработчик только зашедулит em taskq, которая выполнится немного позже.

> int_delay от abs_int_delay отличается следующим:
> для каждого пакета таймер int_delay обнуляется, но если задержка между 
> временем получения последнего пакета и текущим моментом достигла 
> int_delay (таймер int_delay проекспайрился и за это время новых пакетов 
> не пришло) - генерируется прерывание
> 
> Если пакеты идут так плотно, что разница постоянно меньше int_delay - то 
>  тут вступает в действие abs_int_delay - он отсчитывается от последнего 
> прерывания, и если експайрится - прерывание генерируется принудительно.
> 
> То есть abs_int_delay <= int_delay или int_delay == 0 приводит к тому 
> что прерывания генерятся с периодом (abs_int_delay + средняя задержка от 
> последнего прерывания до прихода нового пакета)
> 
> Ставить abs_int_delay в очень высокое значение или в очень маленькое 
> значение не рекомендуется - очередь будет переполняться или прерывания 
> пойдут очень часто.

Вообще-то, с ненулевым rx_int_delay могут быть проблемы:

     hw.em.rx_int_delay
             This value delays the generation of receive interrupts in units
             of 1.024 microseconds.  The default value is 0, since adapters
             may hang with this feature being enabled.

> Это все для выключенного поллинга, естественно.
> 
> >2) Настроойка net.inet.ip.intr_queue_maxlen влияет только на приём пакетов
> >и только, если обработка входящего TCP/IP делается [swi1: net], то есть,
> >в случае net.isr.direct=0.
> >
> >
> >Но я хочу ещё раз подчеркнуть, что в твоём случае 2/3 работы em - это
> >обработка входящего TCP/IP, а не карты и эзернета. Там же, насколько
> >я вижу, тестируется передача UDP одним потоком (ng_source).
> >В твоём же случае передача осуществляется параллельно несколькими 
> >nginx'ами.
> >
> >
> 

-- 
Игорь Сысоев
http://sysoev.ru