> Работает шейпер на dummynet, наблюдается некотороая потеря
> траффика. Hавскидку проблема в дефолтных значениях размера очереди (50 пакетов)
> для pipe'ов от 32 до 512 Кбит\с. Скорее всего, поток не влезает в очередь и
> часть пакетов отбрасывается. Как правильно рассчитать размер очереди для
> каждого pipe в отдельности?

Eugene Grosbein:

Pipe и должен отбрасывать пакеты, иначе какой же это шейпер?
Ты не можешь увеличивать длину очереди бесконечно, потому что задержки
вырастут настолько, что соединение начнет рвать сам юзер :-)

Hа таких низких скоростях размер очереди надо бы, наоборот, уменьшать,
чтобы не допустить гигантских задержек типа нескольких тысяч милисекунд.

А если хочешь и рыбку съесть, и потерь иметь минимум, то читай-ка ты
про RED/GRED на unixfaq.ru и делай не просто pipe, а queue/pipe с gred.
Рекомендую делать w_q=0.002, max_p=0.1, min=q/10, max=3*min,
где q - длина очереди, q=20 для скоростей меньше 100Kbit/s,
q=30 для скоростей от 100 до 300Kbit/s и q=50 для скоростей 512Kbit/s и выше.

----------
Sergey A Yakovets:

Пол-дня игрался с параметром queue. В итоге подобрал на первый взгляд
кое-что подходящее. Алгоритм\мысли были следующие:

Дано: асинхронный спутниковый Инет. Входящий канал - 1024 Кбит\с.

Опытным путем установлено, что проблемы с потерей траффика (до 10% от
общего объема) возникают при многопотоковых http\ftp закачках, т.к. спутниковый
провайдер в этом случае может отдать поток на все 1024 Кбит\с. При серфинге все
нормально. Исходя из этого, мною были сделаны некоторые расчеты:

При максимальной пропускной способности входящего спутникового канала
в 1024 Кбит\с и размере пакета в 1500 байт, пропускная способность канала
равна ~ 87 пакетов\сек. В это же время, для канала в 128 Кбит\с пропускная
способность равна ~ 11 пакетов\сек. Гипотетическая разница, при условии что на
юзера будет идти поток в 1024 Кбит\с, а отдаваться только 128 Кбит\с, может
составить 76 пакетов\сек.

Итого, опытным путем установлено:

    - (было) при дефолтной очереди в 50 пакетов на pipe 128 Кбит\с потери 10%
    - при размере очереди = разница*2 = 150 пакетов потери 2%
    - (стало) при размере очереди = разница*3 = 230 пакетов потери 0%

Серфинг не страдает, задержек нет. Закачка идет на скорости шейпера, потерь нет.

Пробовал другой вариант.
Hа pipe 128 Кбит\с было выставлено gred 0.002/3/6/0.1 В итоге - огромные
потери, т.к. канал практически все время работал на скорости пакетов намного
больше чем max_th*2. Изменение параметров до gred 0.002/50/150/0.1 не влияло на
результат, т.к. дефолтный размер очереди в 50 пакетов часто переполнялся и gred
не имел никакого действия.
---------

Что такое алгоритмы RED и gentle RED у ipfw?
http://unixfaq.ru/index.pl?req=qs&id=310

Ответ на этот вопрос скомпилирован из статей в конференции RU.UNIX.BSD от следующих авторов:
Valentin Ermolaev, Alexander V. Naumochkin, Jen Linkova.

Сокращение RED означает "Random Early Detection". Метод используется для выравнивания всплесков трафика.

Основным критерием метода является так называемая перегрузка.

В качестве показателя перегрузки avg используется вычисляемое среднее значение длины очереди пакетов,
принадлежащей к определенной сессии TCP. Использование усредненного,
а не мгновенного значения очереди позволяет отделить кратковременные перегрузки,
которые могут быть нормально обработаны устройством и сетью, от длительных перегрузок,
которые могут утопить сеть.

Алгоритмически это выглядит так:

В момент прихода пакета
; ; if (очередь не пуста)
; ; ; ; avg = (1 - w_q)*avg + w_q*q
; ; else
; ; ; ; m = f(time - q_time)
; ; ; ; avg = (1 - w_q)^m * avg;

где

avg -средний размер очереди
q_time - "start of queue idle time"
q - размер очереди

w_q - вес очереди (фиксированный параметр)

f() - линейная функий от времени

В /usr/src/sys/netinet/ip_dummynet.c по этому поводу написано следующее:

* RED algorithm
*
* RED calculates the average queue size (avg) using a low-pass filter
* with an exponential weighted (w_q) moving average:
* avg <- (1-w_q) * avg + w_q * q_size
* where q_size is the queue length (measured in bytes or * packets).
*
* If q_size == 0, we compute the idle time for the link, and set
* avg = (1 - w_q)^(idle/s)
* where s is the time needed for transmitting a medium-sized packet.

- что полностью согласуется с приведенными выше формулами.

Далее в алгоритме вводятся два порога уровня перегрузки: min_th и max_th.
Когда уровень перегрузки ниже первого порога min_th, то пакеты не отбрасываются.
Если уровень перегрузки находится между двумя порогами, пакеты отбрасываются с линейно
возврастающей вероятностью из диапазона от 0 до конфигурируемой величины max_p,
которая достигается при достижении второго порога max_th. Выше порога max_th
отбрасываются все пакеты.

Такой метод вычисления позволяет сглаживать всплески трафика - для сравнения в первой из статей (см. ниже)
на одном графике приводятся и изменение размера очереди q, и усредненного размера
очереди (avg) от времени. В той же статье есть выкладки на тему значений w_q.

При gentle RED ситуация выглядит чуть сложнее:

Если перегрузки лежит в интервале от min_th до max_th, то пакеты отбрасываются с линейно
возрастающей от 0 до max_p вероятностью. Когда перегрузка превышает max_th,
но не превышет 2*max_th, пакеты отбрасываются не все (как в случае RED), а с линейно возрастающей
от max_p до 1 вероятностью. Все пакеты отбрасываются только после превышения перегрузки канала значения 2*max_th.

Вот как это сделано в ip_dummynet.c:

если длина очереди > max_th, то в случае gred вероятность
отбрасывания пакета вычисляется как

; ; p_b = c_3 * avg - c_4
где c_3 = (1 - max_p) / max_th
; ; c_4 = 1 - 2 * max_p

В случае просто RED пакет отбрасывается.

При загрузке очереди, большей min_th, но меньшей max_th, функция
вероятности одинакова и выглядит след. образом:

; ; p_b = c_1 *avg - c_2
где c_1 = max_p / (max_th - min_th),
; ; c_2 = max_p * min_th / (max_th - min_th)

Полезные ссылки:

   1. http://www.icir.org/floyd/papers/red/red.html
   2. http://www.icir.org/floyd/red.html
   3. http://www.cisco.com/warp/public/732/Tech/red/

URL: http://groups.google.com/group/fido7.ru.unix.bsd/msg/f7484c0...
Обсуждается: http://www.opennet.dev/tips/info/1411.shtml