AF
Asterisk Forum
обсуждения телефонии, VoIP и IP-PBX
12разделов
5 423тем
34 385сообщений
← К списку тем

QoS Linux

Unix Way 10 сообщений -
#1

Подскажите , возможно ли просто через шейпер дать
высшую приоритезацию войс трафику а весь остальной трафик
который идет пустить сколько осталось в канале

буду благодарен за примеры.

Сейчас использую то что описано http://www.voip-info.org/wiki-QoS

может есть лучше ?
#5

кстати - раз речь зашла о приретизации трафика.
есть узкий канал (128кбит), на нем работает * и не только.
так вот - передача пакета "нормальной" длины занимает 1500*8/128/1024 почти 100ms, и какой бы ни был приоритет у голосового пакета, если начался передаваться пакет с данными - жди 100ms.

какие меры борьбы возможны? уменьшить mtu не очень нравится.
может быть есть туннель какой, который на одной стороне может пакеты дробить, а на другой собирать?
#6

хмм. а что мешает послать параллельно этому пакету - другой? Wink
тоесть по твоей логике если сделать пинг например до microsoft.com то будет пакет идти 100ms (ну к примеру)
а если открыть две консоли и сделать два паралельно пинга тудаже то оба будут уже по 200ms? Wink
ps наверняка счас появится Ded и ткнёт в ссылку на какойнить _базовый_ толмуд по устройству сетей и tcp/ip Wink
#7

что значит параллельно?
ethernet, ipoa, различные вариции ppp так не умеют. то есть один пакет передается - пока он не передался второй не начнет передаваться.
#8

to anest:

Имеется ввиду видимо то, что если в rtp трафик встрянет какая-либо глиста размером 1500 байт (например по протоколу http), то весь rtp трафик задержится на 100 ms (на данном канале).

_________________
ys
http://voip.rus.net/
#9

edo1 писал(а):
кстати - раз речь зашла о приретизации трафика.
есть узкий канал (128кбит), на нем работает * и не только.
так вот - передача пакета "нормальной" длины занимает 1500*8/128/1024 почти 100ms, и какой бы ни был приоритет у голосового пакета, если начался передаваться пакет с данными - жди 100ms.

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


100ms выливается в редкие "щелчки" - в таких условиях это ерунда.
А вот "бульканье" и "прерывания" у вас будут происходить из-за очереди.

Вы канал с двух сторон обслуживаете?

Если нет:
Делайте мост между двумя интерфесами (можно один как dummy попробовать) и... см. "Если да".

Если да:
Не надо использовать никакие "жирные" скрипты - работают нестабильно.
Делайте проще - два класса с гарантированной скоростью, а свободную емкость с приоритетом у голоса.
Для 128К я ставил родительскую скорость в 96Kbps
Голосу (марка через mangle) гарантировал 80Kbps
Остальное - 16Kbps
То есть, если нет голоса - все для "остального", голос появляется - ему гарантируется 80Kbps, при этом "остально" тоже с 2KBps ползает - все довольны.
Для такого канала важно для "остального" поставить очередь в 4 пакета (ибо именно это и забивает вам все), для голоса же можно по умолчанию оставить 128 пакетов (не используйте pfifo!).