Вопрос по сабжу: есть какие-то рекомендации\алгоритмы\формулы по расчету
размера очереди для pipe с определенной пропускной способностью?
Проблема: работает шейпер на dummynet, наблюдается некотороая потеря
траффика. Hавскидку проблема в дефолтных значениях размера очереди (50 пакетов)
для pipe'ов от 32 до 512 Кбит\с. Скорее всего, поток не влезает в очередь и
часть пакетов отбрасывается. Как правильно рассчитать размер очереди для
каждого pipe в отдельности?
Заранее спасибо за ответы.
C уважением, Sergey A. Yakovets.
E-mail: for-t...@yandex.ru ICQ UIN: 165641526
... FaqServer 2:5088/50.50 Subj: %HELP %LIST
SAY> Вопрос по сабжу: есть какие-то рекомендации\алгоритмы\формулы по
SAY> расчету
SAY> размера очереди для pipe с определенной пропускной способностью?
SAY> Проблема: работает шейпер на dummynet, наблюдается некотороая потеря
SAY> траффика. Hавскидку проблема в дефолтных значениях размера очереди (50
SAY> пакетов)
SAY> для pipe'ов от 32 до 512 Кбит\с. Скорее всего, поток не влезает в очередь
SAY> и
SAY> часть пакетов отбрасывается. Как правильно рассчитать размер очереди для
SAY> каждого pipe в отдельности?
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 и выше.
Hу или что-то в этом роде.
Eugene
--
Смерть не разбирается, что сделано и что не сделано. (Артха)
Пожалуста... сделайте так чтобы я неразучился читать и писать. (Чарли Гордон)
20 Feb 07, Sergey A. Yakovets writes to All:
SAY> Вопрос по сабжу: есть какие-то рекомендации\алгоритмы\формулы по
SAY> расчету размера очереди для pipe с определенной пропускной способностью?
SAY> Проблема: работает шейпер на dummynet, наблюдается некотороая потеря
SAY> траффика. Hавскидку проблема в дефолтных значениях размера очереди (50
SAY> пакетов) для pipe'ов от 32 до 512 Кбит\с. Скорее всего, поток не влезает
SAY> в
SAY> очередь и часть пакетов отбрасывается. Как правильно рассчитать размер
SAY> очереди для каждого pipe в отдельности?
В очередь должно помещаться не менее 150 пакетов, а лучше -- 200.
... Hе стоит пить из лужи -- пригодиться плюнуть.
Надо определить допустимую задержку на каждой очереди - и все дела.
Мы у себя остановились на 2000 мс - такой размер и ставится на все
очереди. Что не влазит - нафик.
Мои бортовые системы запеленговали, что в 20 Фев 07 16:09, Slawa Olhovchenkov
писал Sergey A. Yakovets:
SAY>> Вопрос по сабжу: есть какие-то рекомендации\алгоритмы\формулы по
SAY>> расчету размера очереди для pipe с определенной пропускной
SAY>> способностью? Проблема: работает шейпер на dummynet, наблюдается
SAY>> некотороая потеря траффика. Hавскидку проблема в дефолтных
SAY>> значениях размера очереди (50 пакетов) для pipe'ов от 32 до 512
SAY>> Кбит\с. Скорее всего, поток не влезает в очередь и часть пакетов
SAY>> отбрасывается. Как правильно рассчитать размер очереди для
SAY>> каждого pipe в отдельности?
SO>
SO> В очередь должно помещаться не менее 150 пакетов, а лучше -- 200.
Да, примерно так и получилось. См. мое предыдущее сообщение.
Мои бортовые системы запеленговали, что в 20 Фев 07 19:54, Eugene Grosbein
писал Sergey A Yakovets:
SAY>> Вопрос по сабжу: есть какие-то рекомендации\алгоритмы\формулы по
SAY>> расчету размера очереди для pipe с определенной пропускной
SAY>> способностью? Проблема: работает шейпер на dummynet, наблюдается
SAY>> некотороая потеря траффика. Hавскидку проблема в дефолтных
SAY>> значениях размера очереди (50 пакетов) для pipe'ов от 32 до 512
SAY>> Кбит\с. Скорее всего, поток не влезает в очередь и часть пакетов
SAY>> отбрасывается. Как правильно рассчитать размер очереди для
SAY>> каждого pipe в отдельности?
EG>
EG> Pipe и должен отбрасывать пакеты, иначе какой же это шейпер?
EG> Ты не можешь увеличивать длину очереди бесконечно, потому что задержки
EG> вырастут настолько, что соединение начнет рвать сам юзер :-)
EG>
EG> Hа таких низких скоростях размер очереди надо бы, наоборот, уменьшать,
EG> чтобы не допустить гигантских задержек типа нескольких тысяч
EG> милисекунд.
Пол-дня игрался с параметром queue. В итоге подобрал на первый взгляд
кое-что подходящее. Алгоритм\мысли были следующие:
Дано: асинхронный спутниковый Инет. Входящий канал - 1024 Кбит\с.
Опытным путем установлено, что проблемы с потерей траффика (до 10% от
общего объема) возникают при многопотоковых http\ftp закачках, т.к. спутниковый
провайдер в этом случае может отдать поток на все 1024 Кбит\с. При серфинге все
нормально. Исходя из этого, мною были сделаны некоторые расчеты:
При максимальной пропускной способности входящего спутникового канала
в 1024 Кбит\с и размере пакета в 1500 байт, пропускная способность канала
равна ~ 87 пакетов\сек. В это же время, для канала в 128 Кбит\с пропускная
способность равна ~ 11 пакетов\сек. Гипотетическая разница, при условии что на
юзера будет идти поток в 1024 Кбит\с, а отдаваться только 128 Кбит\с, может
составить 76 пакетов\сек.
Итого, опытным путем установлено:
- (было) при дефолтной очереди в 50 пакетов на pipe 128 Кбит\с потери 10%
- при размере очереди = разница*2 = 150 пакетов потери 2%
- (стало) при размере очереди = разница*3 = 230 пакетов потери 0%
Серфинг не страдает, задержек нет. Закачка идет на скорости шейпера, потерь
нет. Вроде бы, результат достигнут. Сегодня\завтра буду наблюдать.
EG> А если хочешь и рыбку съесть, и потерь иметь минимум, то читай-ка ты
EG> про RED/GRED на unixfaq.ru и делай не просто pipe, а queue/pipe с
EG> gred. Рекомендую делать w_q=0.002, max_p=0.1, min=q/10, max=3*min, где
EG> q - длина очереди, q=20 для скоростей меньше 100Kbit/s, q=30 для
EG> скоростей от 100 до 300Kbit/s и q=50 для скоростей 512Kbit/s и
EG> выше. Hу или что-то в этом роде.
Пробовал этот вариант.
Hа pipe 128 Кбит\с было выставлено gred 0.002/3/6/0.1 В итоге - огромные
потери, т.к. канал практически все время работал на скорости пакетов намного
больше чем max_th*2. Изменение параметров до gred 0.002/50/150/0.1 не влияло на
результат, т.к. дефолтный размер очереди в 50 пакетов часто переполнялся и gred
не имел никакого действия. Хотя, может быть я чего-то не так понял и сделал...
EG> Eugene
10.0.0.0/22 -> Vlan 1 port 1
-> Planet WGSD-1020 port3 tag -> port1 Dlink DGS-1016T
10.0.4.0/22 -> Vlan 2 port 2 (only port based vlan)
|
| port2
FreeBSD 5.5
Вопрос
Пропустит ли Dlink DGS-1016T сквозь себя вланы 802.1Q
Или лучше все свичи настроить на port based vlan, но как тогда FreeBSD
настроить?
Я понимаю что туповат в этих вланах, но направьте на путь истиный. Как
лучше сделать в данной схеме, чтобы связь сети 10.0.0.0/24 к
10.0.0.4/22 был только через сервер, что бы я мог c помощью ipfw зарезать
ненужный трафик.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
K> Решил разделить локальную сеть на две подсети.
K> Схема
K> 10.0.0.0/22 -> Vlan 1 port 1 -> Planet WGSD-1020 port3 tag -> port1 Dlink
K> DGS-1016T
K> 10.0.4.0/22 -> Vlan 2 port 2 (only port based vlan)
K> |
K> | port2
K> FreeBSD 5.5
K> Вопрос
K> Пропустит ли Dlink DGS-1016T сквозь себя вланы 802.1Q
Это к техподдержке D-Link. Может, и пропустит.
K> Или лучше все свичи настроить на port based vlan, но как тогда FreeBSD
K> настроить?
Откуда информация, что DGS-1016T поддерживает port based vlan?
Eugene
--
Пробуй, но не смей глотать
Прогнал DGS-1216T и в нем есть 802.1Q
>> Откуда информация, что DGS-1016T поддерживает port based vlan?
K> Прогнал DGS-1216T и в нем есть 802.1Q
Делай все на тегах. Простая и прозрачная схема.
Eugene
--
Что делают там, где воруют и сам царь, и его советник, и главный жрец? (Артха)