LINUX.ORG.RU
ФорумAdmin

Шейпинг трафика трафика без явного указания скорости канала

 , ,


0

1

Можно ли, при помощи tc и чёрной магии, организовать разделение исходящего канала между разными классами траффика, например, в отношении 30/70, не зная заранее ширину канала? HTB требует точных цифр. CBQ не осилил, но судя по описанию - та же фигня.

★★★

Последнее исправление: selivan (всего исправлений: 1)

Вроде таких классов нет. CBQ не стоит использовать, в LARTC пишут мол, что он очень плох для шепинга трафика.
А что с шириной канала ? Почему нету точных данных ?

demsi
()
Ответ на: комментарий от demsi

Иногда сильно меняется в течении дня. Мерять при живых пользователях невозможно(или всех отрубать для точночти измерения, или намеряю фигню), а то, что я намеряю ночью, к тому, что провайдер отдаст днём, может не иметь никакого отношения

selivan ★★★
() автор топика
Ответ на: комментарий от devl547

Ширина канала заранее неизвестна. Нужно отдавать часть полосы высокоприоритеным сервисам, ещё часть - среднеприоритетным, и остаток - низкоприоритетным. При этом низкоприоритетным должно оставаться хотя бы 10% полосы, то есть совсем их забивать чем-нибудь вроде PRIO не годится

selivan ★★★
() автор топика
Ответ на: комментарий от selivan

Иногда сильно меняется в течении дня. Мерять при живых пользователях невозможно(или всех отрубать для точночти измерения, или намеряю фигню), а то, что я намеряю ночью, к тому, что провайдер отдаст днём, может не иметь никакого отношения

Так может стоит ограничить c помощью HTB всем пользователям ширину там до rate 1kbit ceil 5kbit, а себе в default по максимуму поставить. На время измерения. И нормально замерить ширину.
Или же можно не парится и и раскидать всем rate минимальный, а ceil средний. Вроде тогда он будет делить по ровну всех. Или вообще поставить бесклассовую дисциплину sfq, и не париться.

demsi
()
Ответ на: комментарий от demsi

Прерывать нормальную работу филиала для измерения не годится, хотя если не найду других вариантов, эта идея пригодится.

С SFQ у меня отправляемый на печать толстый документ будет забивать телефонию, от чего я сейчас стараюсь избавится.

selivan ★★★
() автор топика
Ответ на: комментарий от selivan

Ну тогда можно сделать так:
Примерную ширину канала то знаем.
Сделать HTB: Поделить его на сколько нужно подклассов. И сделать типо: 1 - дочерний класс высокий приоритет, rate минимально необходимый, ну например 256 kbit(или больше) а ceil максимальный там можно даже больше ширины канала. И направить туда весь трафик который нужен в высоком приоритете - ssh telnet icmp,udp принт-сервер и все что нужно.
Затем другой дочерний класс тоже с минимально необходимым rate и максимальным ceil. Сюда там траффик www и так далее.
Ну и сколько нужно дочерних таких создать. А остальное (всякие торренты) в дочерний класс по умолчанию также с мнимальным rate.

То есть смысл в том что, если например вы печатаете документ он будет в высоком приоритете, а кто нить качает фильм через торрент ,он будет гораздо ниже.

demsi
()
Ответ на: комментарий от demsi

HTB не совсем подходит: пусть есть три(на самом деле больше, но трёх хватит) класса траффика: высший, средний и низкий приоритет. При скорости 1 Мбит/с мне нужно, чтобы они получали канал в отношении 1:2:1, то есть 256, 512 и 256 кбит. Потом скорость поднялась до 8 Мбит/с. Я хочу сохранить соотношение 1:2:1. HTB предлагает два варианта: или я урезаю трафик высшего приоритета некоторым ceil, допустим 512, и соотношения 1:2:1 уже не будет, получится что-нибудь типа 1:4:2. Или я делаю очень большой ceil для класса с высшим приоритетом, и тогда он может оттянуть на себя всю освободившуюся полосу, получится например 5:2:1, опять соотношение не сохранится.

То есть при динамически меняющейся ширине канала получить одно и то же соотношение выделенного для разных классов трафика каналов невозможно.

selivan ★★★
() автор топика
Ответ на: комментарий от selivan

Ну а если будет так:
1 - rate 256kbit ceil 100mbit - высший
2 - rate 512kbit ceil 100mbit - средний
3 - rate 256kbit ceil 100mbit - низкий
То как себя будет HTB вести ?
Предположим www трафик стоит на высшем ,а torrent на низком, то при одновременном скачивании файла что будет происходить ?

demsi
()
Ответ на: комментарий от selivan

С SFQ у меня отправляемый на печать толстый документ будет забивать телефонию

Кстати, fq_codel в ядре есть?

devl547 ★★★★★
()
Ответ на: комментарий от demsi

Как я понимаю, раз у www prio выше, он забьёт всеь свой rate+ceil, оставив торрентам только их гарантированный rate. Ну по крайней мере, забьёт настолько, насколько скорости отдачи www-сервера хватит

selivan ★★★
() автор топика
Ответ на: комментарий от selivan

А что оно даёт?

Рекомендую погуглить по fq_codel.
Если кратко - то офигенное снижение latency и более честный шейпинг пакетов.
Я у себя дома везде поставил - даже про полной загрузке канала торрентами и i2p, в онлайн игрушках пинг стабильно низкий, а видеоболтовня через skype или hangoups не тормозит.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

В вики не очень понятно. Оно classless или classful? Его тупо вместо sfq присобачивать и радоваться жизни?

selivan ★★★
() автор топика
Ответ на: комментарий от devl547

Попробую, спасибо за совет. Но проблему с разделением трафика пропорционально ширине канала это, увы. не решает

selivan ★★★
() автор топика
Ответ на: комментарий от selivan

Это решает другую проблему - почему tcp congestion не работает, а шейперы это дело только усугубляют.

devl547 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.