> Работает шейпер на 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.me/tips/info/1411.shtml
> Рекомендую делать w_q=0.002, max_p=0.1, min=q/10, max=3*minРекомендации неверные. Допустим, очередь у нас 60 пакетов, min=6 пакетов, max=18 пакетов. Согласно алгоритму GRED - при превышении max в два раза дропаются все пакеты. В соответствии с этим размер очереди должен быть в два раза больше max. Для нашего случая - 36 пакетов.
А если превышение max в три раза или больше?
А смысл - всё равно все пакеты убиваются после max*2.
> Согласно алгоритму GRED - при превышении max в два раза дропаются все пакеты.
Неправильно. Все пакеты отбрасываются при превышении max_th. Длина очереди должна быть не в два раза, а процентов на 10-20 больше max_th.
>Неправильно. Все пакеты отбрасываются при превышении max_th.Речь о терминологии от Eugene Grosbein.
>Длина очереди должна быть не в два раза, а процентов на 10-20 больше max_th.
Это - бессмысленно.