htb и латентность

Уменьшать размер пакетов, играться с приоритетами и настройками дисциплимн обработки трафика. Эта тема поднималась не раз, вообще-то :)

>как можно уменьшить латентность в случаях, когда канал забит пол завязку

Уменьшить получится до определенных пределов, но не настолько, как хотелось бы :) Если пинг на "пустом" канале 50мс, то на загруженном, как ни старайся, он ну никак не будет тоже 50..

То, что она уже поднималась несколько раз - я это видел. Но как раз касательно этой темы я ничгео не нашёл. Обычно описывают, как выставляют приоритеты для ssh,www и остального тарфика, как для высоко, средне и низкоприоритетного. А про "размер пакетов" и "настройками дисциплимн обработки трафика", что повлияет на латентность - ничего. Задержки в канале 50мс, при нагрузке растут до 2000, поэтому логично предположить, что от этого можно избаваиться.

не нагружать так канал.

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

Поэтому максимум что ты можешь сделать это прокласифицировав трафик дать возможность какому-то трафику проскакивать "без очереди", сделать это для всех не получиться.

Я это прекрасно понимаю. Дело в том, что я работаю в активно развивающемся ISP и рост кол-ва клиентов начал приводить к тому, что в вечерние и дневные часы начинаются проблемы, расширения канала пока не предвидиться. Перерыл мору доков в сторону того, что, например, на линке висят два коннекта и один использует 10 килобит и доступных 100, а второй соклько есть, столько и исопльзует. Результатом этого является не то, что первый получит 10кбит, а второй 90, а что-то вроде 2-5 и 95-98 соответственно. То есть если в воронку льют два потока воды, то почему намного меньший должен страдать? И если зашёл вопрос о приоритетах, то тут тоже масса проблем. Например, высокоприоритетным я обозначу игровой трафик по портам a и b. Остальной трафик я сделаю низкоприоритетным. Но возможен такой слуйчай, что кто-то будет играть в игру, о которой я не знаю и она попадёт под низкоприоритетный трафик, что будет иметь плачевный результат.

>сделать это для всех не получиться.

Но можно попытаться заставить TCP-"воду" поступать в воронку медленнее, чтобы она не скапливалась :)

Да и задержка имеет значение дажеко не для любого трафика, некоторому можно позмолить и задержаться.

Автору: читай поиск тут, lartc.org, статьи на opennet.ru. Все это уже тысячу раз обсуждалось, да и перечитав все это понять принцип может быть легче, чем из ответов на форуме.

>Дело в том, что я работаю в активно развивающемся ISP

Какое оборудование и сети используются? Если обычный ethernet, я бы рекомендовал следующее. Забей на попытки сделать "всем и хорошо", не выйдет - проверено :( Тарифы строй "по принципу" ADLS - для каждого абонента есть верхний предел upload/download (которые ты зарежешь с помощью tbf или другим способом) и пусть в этих пределах барахтаются. И все.

В этом случае, пока сумма скоростей абонентов не больше ширины канала в целом, они особо давить друг друга не будут. Ну а если больше... покупай канал шире или смирись с фактом того, что ты не самый лучший IPS, не обещай клиентам мега-сервиса.

Еще раз говорю, что сделать красиво и удобно для всех не получится с помощью хитрой приоритезации трафика и всего такого - рано или поздно поймешь что все это фиг че помогает на "продакшен"..

Ну постой правила так, чтобы было легко по жалобе клиента на лаги, добавить новый порт в список высокоприоритетных. И поставь на интерфейсах sfq или esfq тогда абоненты будут делить канал между собой поровну.

ICMP сделай высоко приоритетным - счастья абонентам не добавиться, но "видимость счастья" будет - ведь пинги хорошие, "значит это сервер тормозит" :)

>чтобы было легко по жалобе клиента на лаги, добавить новый порт в список высокоприоритетных.

и сразу можно убить себя об стену :( Это не выход, это создание себе дополнительной работы за те же деньги (увы, говорю из своего опыта). Рано или поздно энтузиазм кончится, а кол-во "жалоб" будет только расти...

>И поставь на интерфейсах sfq или esfq тогда абоненты будут делить канал между собой поровну.

поиск рулит :)

Тогда очень непонятно, мой опреатор ограничивает входящий поток 8мбитами, а исходящий 1мбитом. Даже если использовать все 8мбит несколькими потоками, то время отклика нисколько не увеличивается. В случае с исходящим потоком всё иначе. И естественно, это из-за того, что балансировакой занимается моя машина. Все факты говорят о том, что есть возможность настроить так, чтобы латентность не росла.

Поигрался с htb.init. Скорость ограничивать получается,а вот по типам трафика приоритеты никак не сказываются... Не понятно почему.

Мне так кажется, что на скорости 8Мбит пакеты "тормозить" не очень-то и успевают :)

>И естественно, это из-за того, что балансировакой занимается моя машина

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

А вообще, "неколько" потоков - это даже и не нагрузка. Вот посади десяток пользователей, у которых одновременно запущены emule (kad, torrent), flashget (на потоков хотябы 10), 10 ботов на Lineage запущены, а сами они смотрят порнуху в Firefox, открывая по 10 картинок колесиком, чтобы грузились по быстрее.. Вот тогда ты узнаешь, как будет вести себя канал в будни после школы.. :)

определить типытрафика самым простым способом можно в iptables в таблице mangle помечая пакеты с помошью правил, после чего настроить htb.init на метки определённые в iptables.