» MikroTik RouterOS (часть 3)

Цитата:

то есть для вас шейп и QOS это одно и тоже

для меня это не одно и тоже, это следует из ваших постов, то вы делаете
шейпер а то:

Цитата:

она там обязана организовываться иначе все это не имеет ничего общего с QOS

шейпер это ограничение скорости, а QoS это приоритет трафика, то есть качество
обслуживания... как то так...понятно что очереди и там и тут, но суть не в этом,
хотелось бы увидеть скин где в дереве создаются очереди...
вы считаете что в этом мануале:
тут
на странице Обзор Queue Tree: Winbo в
Total download и Total upload должны образовываться очереди?

Цитата:

на странице Обзор Queue Tree: Winbo в
Total download и Total upload должны образовываться очереди?

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

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


Цитата:

хотелось бы увидеть скин где в дереве создаются очереди...

попроси Chupaka у него создаются такие очереди.

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

в LAN и Global-out должны образовываться очереди?
может они и должны но я их там не замечал, при полной загрузки канала,
все работает исправно, то есть работает Limit-at и скорости режутся у пользователей заявленные в Queue Types...если канал перегружается то и
скорости у пользователей падают равномерно.
по такому же принципу у меня построен QoS для приоритета трафика, там
картина такая же, при полной нагрузке приоритеты срабатывают и очередей
на деревьях тоже не замечал...цвет меняется на листьях при превышении указанного
лимита с зеленый на желтый и далее красный, так же и на самих деревьях...
просветите в таком случае как работает HTB... и почему очереди должны там быть...

vlh

Цитата:

в LAN и Global-out должны образовываться очереди?

Чесслово, не смешно уже, вы около полугода мурыжите шейпер в Микротике и до вас до сих пор не доходят элементарные вещи.

Что такое pfifo, bfifo, pcq ...? Это дисциплины организации очередей. Любой элемент в Queue Tree - это очередь. Вопрос только в её размере.

и мне не смешно, хорошо, вопрос в том почему в дереве не образуются очереди...
то есть их не видно что они образовываются при просмотре в онлайн...
вот в этом и был вопрос у ТС этого вопроса...
теперь и я задаюсь этим вопросом...в дереве PFIFO это тоже очередь -
первым пришел первым ушел, очередь должна образовываться при 100%
загрузки канала? если да то как и писал родитель этого вопроса это баг,
и придется менять версию ROS, на данный момент 4.10

vlh

Цитата:

хорошо, вопрос в том почему в дереве не образуются очереди...

На основании чего эти выводы? На основании выложенной вами картинки такой диагноз поставить невозможно. Вы утверждаете, что на так называемых ваших листовых очередях не образуется очередей? Не поверю.
Или вас интересует почему очередей не наблюдается у родительских очередей? Потому, что у вас сумма limit-at всех оконечных дочерних очередей = max-limit родительской очереди, поэтому все лишние пакеты ставятся в очередь/режутся ещё на уровне листовых очередей, и в родительской очереди количество пришедших в неё пакетов либо равно, либо меньше её max-limit, поэтому ей в очередь ставить нечего. Вы вот уберите в вашем примере у очередей значения limit-at, а затем загрузите канал по максимуму. Что, и теперь не образуются?

Цитата:

На основании чего эти выводы?

да, действительно, был не прав, смутил меня ТС
этого вопроса, что он не видит что образуются очереди...
я тоже посмотрел в колонку PCQ Queue в дереве шейпера и пришел к выводу
почему же у меня тоже не образуются, забыв о том что дерево работает
в PFIFO и в этой колонке я ни чего не увижу
я понимаю что надо отдыхать, но изучение чего то нового всегда интересно и затягивает

Цитата:

Вы утверждаете, что на так называемых ваших листовых очередях не образуется очередей?

это я совсем не утверждал, если бы это было так я бы вас вместе с Chupakа
замучил бы вопросами... у меня все работает, еще раз спасибо Вам, только после Ваших разъяснений сумел настроить все правильно....

Цитата:

Или вас интересует почему очередей не наблюдается у родительских очередей? Потому, что у вас сумма limit-at всех оконечных дочерних очередей = max-limit родительской очереди, поэтому все лишние пакеты ставятся в очередь/режутся ещё на уровне листовых очередей, и в родительской очереди количество пришедших в неё пакетов либо равно, либо меньше её max-limit, поэтому ей в очередь ставить нечего.

Вот, опять в точку, я думаю ваш ответ поможет и fdboss потому что у него вообще Max-limit и Limit-at в родителе меньше чем сумма всех листьев этого
дерева...откуда же там будут очереди...


вопрос не относящийся к этой теме:
приоритет трафика ismp = 1 даже для него выставлен Limit-at=100к, вопрос
в следующем почему при полной загрузки канала при пинге скажем на ya.ru
пинги большие, то есть под правило попадают пакеты это видно и даже знаю
что QoS немного притормаживает с этим но пингую примерно 10 минут так ни чего не стабилизируется, пинги прыгают.

vlh
НА вопрос про пинги могу промазать, но может дело в том, что пинги возрастают не от шейпера, а например от того что провайдер понижает скорость при полной загруженности канала? (т.е. возрастают потому что узкое место где то в другом месте)

Цитата:

НА вопрос про пинги могу промазать, но может дело в том, что пинги возрастают не от шейпера, а например от того что провайдер понижает скорость при полной загруженности канала? (т.е. возрастают потому что узкое место где то в другом месте)

то есть если канал полностью свободный то пинги ~20 а если я его загружу примерно процентов на 80 и пинги становятся 60-120, то это виноват провайдер?
думаю что это не так, а иначе зачем тогда приоритет трафика который не срабатывает?
ща придут спецы и расставят все точки над И

vlh
Ты для начала задай лимиты на 50% ширины канала и протестируй свои приоритеты. Пинги выросли => виноват шейпер, пинги не выросли => странно =)

что-то дискуссия пошла по ложному пути...


Цитата:

Любой элемент в Queue Tree - это очередь

на самом деле, любой элемент - это класс, в терминологии HTB. а очереди создаются только для листьев дерева:
Цитата:

inner class - a class that has one or more child class attached to it. As inner classes do not store any packets, qdiscs can not be attached to them (so their qdisc and filter settings are ignored, although may be still shown in RouterOS configuration), so they only do traffic shaping. Priority setting is ignored as well

http://www.mikrotik.com/testdocs/ros/3.0/qos/queue.php


Цитата:

я думаю ваш ответ поможет и fdboss потому что у него вообще Max-limit и Limit-at в родителе меньше чем сумма всех листьев этого
дерева...

вот жеж блин! действительно, скриншоты без названий колонок - это бред браво! у всех клиентов выставлен limit-at - поэтому до тех пор, пока эти значения не будут достигнуты, очередь будет отдавать трафик клиенту, никак не ограничивая его. именно поэтому во всех мануалах по HTB пишут, что при сумме limit-at большей, чем max-limit родителя, работа становится непредсказуемой


Цитата:

почему при полной загрузки канала при пинге скажем на ya.ru пинги большие

потому что канал полностью загружен. повторю то, что не повторял с прошлого года: эффективно можно управлять только теми пакетами, которые уходят от нас. то, что валится на нас со стороны провайдера, мы получаем "как есть", и если пров в забитый канал в первую очередь суёт TCP, а только потом ICMP - то мы с этим ничего сделать не можем. вывод - надо не допустить забития канала что достигается ограничением всего входящего трафика на 5-15% ниже максимума канала, а дальше работают алгоритмы TCP, которые подстраиваются под новые реалии

Chupaka

Цитата:

на самом деле, любой элемент - это класс, в терминологии HTB. а очереди создаются только для листьев дерева:

Спасибо за науку. Выходит, ошибался. Сорри, что возможно остальных ввёл в заблуждение.
Вообще господам из Микротика следовало бы давно уже составить вменяемый подробный мануал по HTB в ROS, а то на текущий момент информация по разным местам разбросана.

Не могли бы вы, кстати растолковать пример №3 из документа по приведённой вами ссылке?

Цитата:

Consider that Leaf1 has reached its max-limit and changed its state to red, and Leaf2 now uses more than 1Mbps (and less than 2Mbps), so its parent ClassB has to borrow from ClassA and becomes yellow. Leaf3 still has no packets to send.

Как это могло произойти, и почему Leaf2 жёлтый, а не красный, если по условиям:

Цитата:

3 name="Leaf2" parent=ClassB packet-mark=packet_mark2 limit-at=256000
queue=default priority=7 max-limit=1024000 burst-limit=0
burst-threshold=0 burst-time=0s

P.S. В конце статьи "классический" косяк с размещением pcq-очередей для исходящего трафика на внешнем интерфейсе при наличии NAT . Так что у меня возникает резонный вопрос о корректности всего остального содержимого статьи: чему верить, а чему нет.

Добавлено:
Chupaka

Цитата:

As inner classes do not store any packets

А что мы тогда в Winbox'е имеем удовольствие наблюдать в таком случае? Счётчики же накручиваются в родительских очередях и количество прошедших через родительскую очередь пакетов равно сумме пакетов, прошедших через все её дочерние классы.

Цитата:

А что мы тогда в Winbox'е имеем удовольствие наблюдать в таком случае? Счётчики же накручиваются в родительских очередях и количество прошедших через родительскую очередь пакетов равно сумме пакетов, прошедших через все её дочерние классы.

угу, пакеты проходят через статистику, но никакими дисциплинами не обрабатываются (например, Queued Bytes/Packets всегда ноль)


Цитата:

пример №3

ну, может, очепятка

касательно цветов: не надо путать "цвета" в HTB и цвет в винбоксе; в боксе жёлтый - это трафик более 50% от max-limit, а красный - более 75%, и от limit-at ничего не зависит

Chupaka

Цитата:

угу, пакеты проходят через статистику, но никакими дисциплинами не обрабатываются (например, Queued Bytes/Packets всегда ноль)

Так, ясно - бутафория для удобства визуального восприятия и контроля.

Цитата:

ну, может, очепятка

Сколько ж тогда их там ещё может быть? Я к тому, как новичку понять из этого документа о том, что такое HTB и как оно функциклирует, если документ этот с "очепятками". Какова фактическая полезность подобного документа? (Это камень в огород мануалописателей от Микротиа, если что, а не вас, Chupaka)

Цитата:

касательно цветов: не надо путать "цвета" в HTB и цвет в винбоксе

Да это я знаю. В документе том, кстати, вроде, ни каких отсылок по поводу цветов на Винбокс и нет.

Добавлено:
Chupaka

Цитата:

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

Ну так человек, вроде, пишет, что канал загружен процентов на 80, а не на 100, но пинги растут.

Цитата:

Chupaka

Цитата:

вот жеж блин! действительно, скриншоты без названий колонок - это бред браво! у всех клиентов выставлен limit-at - поэтому до тех пор, пока эти значения не будут достигнуты, очередь будет отдавать трафик клиенту, никак не ограничивая его. именно поэтому во всех мануалах по HTB пишут, что при сумме limit-at большей, чем max-limit родителя, работа становится непредсказуемой

сори исправлюсь
исходя из полученной инфы вот что получилось.


убрал limit-at, но счетчик в материнском шейпе все равно 0, или при таком раскладе размер очереди на клиентах можно считать размером материнской очереди, ??

по крайней мере теперь материнский шейп отрабатывает как положено, то есть режет скорость.

Цитата:

но счетчик в материнском шейпе все равно 0, или при таком раскладе размер очереди на клиентах можно считать размером материнской очереди, ??

Так и должно быть. Chupaka выше же цитату приводил. Весь трафик обрабатывается (шейпится, приоритезируется) только очередями, прикреплёнными к листовым (leaf) классам, т.е., в вашем случае, очередями, прикреплёнными к классам 123_in, 124_in, 125_in. Всё что выше по "дереву" - это не очереди, а на сколько понял, некая иерархическая структура правил, что ли, на основании которых распределяется трафик между очередями, прикреплёнными к leaf-классам. Но физически через эти структуры (родительские "очереди") трафик на самом деле не ходит (поэтому в них ни чего не шейпится и пакеты в буферы не загоняются), они только собирают статистику своих дочерних элементов (которая и выводится в Винбоксе), на основании которой разрешают или не разрешают, допустим, реальной очереди, через которую реально проходит трафик расширить ей полосу пропускания по её запросу.
Как-то так. Возможно, путано - не до конца ещё разобрался. Chupaka, возможно, поправит, если я не прав. Я раньше представлял себе HTB в виде некоей древовидной структуры каналов, через которые трафик последовательно протекает от leaf к root и по пути лимитируется согласно условиям того или иного канала, но оказалось, что был не прав.

Цитата:

Так и должно быть. Chupaka выше же цитату приводил. Весь трафик обрабатывается (шейпится, приоритезируется) только очередями, прикреплёнными к листовым (leaf) классам, т.е., в вашем случае, очередями, прикреплёнными к классам 123_in, 124_in, 125_in. Всё что выше по "дереву" - это не очереди, а на сколько понял, некая иерархическая структура правил, что ли, на основании которых распределяется трафик между очередями, прикреплёнными к leaf-классам. Но физически через эти структуры (родительские "очереди") трафик на самом деле не ходит (поэтому в них ни чего не шейпится и пакеты в буферы не загоняются), они только собирают статистику своих дочерних элементов (которая и выводится в Винбоксе), на основании которой разрешают или не разрешают, допустим, реальной очереди, через которую реально проходит трафик расширить ей полосу пропускания по её запросу.
Как-то так

ну тут сложно вообще сказать как оно там происходит, просто когда сидишь и смотришь как приведенная мной структура работает, все это как то не укладывается.
если материнский шейп ничем не рулит, то как тогда происходит ограничения по скорости указанное в материнском шейпе, я понимаю это все так, изначально все пакеты находятся в материнском шейпе, (даже при условии что мы их не видим как очередь), а потом уже исходя из лимитов клиентов материнский шейп выстраивает им очередь, потому что при 100% занятости материнского шейпа еще и происходит деление канала поровну между клиентами, и при этом очень хорошо видно что очередь у клиентов разная.
получается что материнский шейп исходя из своих лимитов пошейпил клиентов поровну,
или вся структура работает наоборот, клиентский шейп исходя из данных полученных от материнского выстраивает очередь, но тогда не совсем понятно как все происходит когда в материнском шейпе 10 клиентов, веть для того что бы каждый клиентский шейп выстроил очередь себе он должен анализировать не только материнский шейп и и шейпы своих соседей.


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

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

Цитата:

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

Я пока в общих чертах понял так: если у клиентской очереди задан параметр limit-at, то HTB ему эту скорость в размере limit-at выдаёт по любому (даже если указанная величина будет заведомо больше величины пропускной способности родительского элемента) и данный трафик больше не подпадает ни под какие ограничения ни со стороны других клиентских очередей (приоритеты игнорируются), ни со стороны родителя. Если же клиенту требуется скорость выше своего значения limit-at, то тогда за этой дополнительной скоростью он обращается к вышестоящему родительскому классу.

Родитель снимает статистику по всем своим клиентам и, если сумма скоростей этих его дочерних элементов меньше значения его собственного limit-at, то он разрешает расширить клиентской очереди её текущую полосу пропускания на значение в пределах незадействованной полосы пропускания родителя. Если же клиентская очередь требует прибавку к скорости большую, чем остаток, зарезервированной с помощью limit-at полосы родителя, то в этом случае уже родитель обращается к своему вышестоящему родительскому классу за разрешением на прибавку к скорости в пределах своего max-limit и т.д.

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

Цитата:

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

красавчик, классно излагаешь

народ!!! нужна помощь по балансировки
есть подключения к провайдеру через PPPOE
раздача интернета на контору осуществляется через VPN-сервер

Alek19
И в чём задача?

пропускная способность до провайдера почти 1гигабит
скорость в инет до 25Мбит надо равномерно поделить инет на всех пользователей в разных подсетях

Цитата:

если материнский класс не на что не влияет то почему тогда (исходя из тех же мануалов), пакет проходящий через материнский класс изменит приоритет на тот который имеет материнский класс.?

исходя из мануалов, приоритет родительской очереди, как и её тип, в работе HTB игнорируются. и не надо мешать в кучу приоритет очереди и приоритет пакета. второе работает на оборудовании с поддержкой 802.1p и WMM, к очередям никакого отношения не имеет


Цитата:

пакеты имеющие приоритет выше отправлять первыми

HTB не имеет "строгой" (strict) приоритезации, поэтому такой фокус не пройдёт. приоритет - это просто шанс для очереди первой достигнуть своего limit-at, а затем max-limit


Цитата:

скорость в инет до 25Мбит надо равномерно поделить инет на всех пользователей в разных подсетях

http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ#PCQ_Rate_Examples

Chupaka

Цитата:

приоритет - это просто шанс для очереди первой достигнуть своего limit-at, а затем max-limit

Если относительно max-limit и приоритетов понятно, то вот относительно приоритетов и limit-at как-то не очень, т.к. по тем же мануалам везде говорится, что трафик в пределах величины данного параметра от приоритета ни как не зависит, и полоса в пределах limit-at выделяется очереди в любом случае, что иллюстрирует пример №4 в мануале по HTB: http://wiki.mikrotik.com/wiki/Manual:HTB#Example_4_:_Leaf_queue_limit-at

Цитата:

Ну так человек, вроде, пишет, что канал загружен процентов на 80, а не на 100, но пинги растут.

Chupaka - решил отмолчатся
да и когда загружен на 100%, вроде по словам Chupaka не должны расти,
так как у меня Max-limit- 80% от ширины канала...
может я опять что то упустил, делаю тест на полностью пустом канале,
получаю примерно down 4Мбит\с и upl 450кбит\с Max-limit=3500k и 380к
на пустом канале пинг примерно 20мс, далее запускаю абонентов на этот
канал и они грузят его скажем 3200к и 320к и вот при этом пинги прыгают
от 60 до 120....скорость у клиентов порезана на 400к, в момент теста на пинг
в правилах приоритета появляется активность, то есть пакеты попадают,
приоритет стоит - 1
вот как то так у меня происходит...но думаю наверное так и должно быть потому что как и писал Chupaka мы не знаем что на нас валится от провайдера,
это наверное тоже самое если вы например купили у провайдера тариф в 4М и загрузили его полностью торрентом, а потом пробуете сделать тест скорости,
который естественно будет не айс, или пинги решили проверить....
вообщем печально как то все это...

vlh

Цитата:

вот как то так у меня происходит...

Очень похоже на то, что не весь реально проходящий через данный канал трафик размечен в Мангле и направлен в очереди. Возможно, где-то есть утечка мимо HTB, которая и забивает канал в моменты загрузок близких к максимально разрешённым.

вроде как весь проходит, сужу по тому , что последнем в мангле стоит
правило

Код: 60 ;;; other backup
chain=prerouting action=mark-packet new-packet-mark=other_backup_out
passthrough=no src-address-list=(reserve_channel) in-interface=LAN

61 chain=prerouting action=mark-packet new-packet-mark=other_backup_in
passthrough=no in-interface=PABLIC_1_d

пример из жизни: канал 60 Мбит/с, на входе стоит отдельный шейпер, который банально зарезает входящий канал на 58M; вечером, при наибольшей загрузке канала (плешка на протяжении последних часов, несколько сотен пользователей онлинь) пинг стабильный, потерь нет; днём тянули торрентом порядка 3 Мб/с (догружая канал до плешки), с того же компа пинг настолько же стабильный (на яндех - порядка 25 мс из Минска), потерь нет

так что тут, видимо, вопрос также в том, насколько пров может обеспечить скорость, и по какому принципу делает нарезку

Цитата:

так что тут, видимо, вопрос также в том, насколько пров может обеспечить скорость, и по какому принципу делает нарезку

вот, вот, пров скорее всего недодает канал, что бывает сплош и рядом, а еще бывает рейт лимит с дропом всего что лишнее.

есть 2 вопросика по DHCP Server разделу:

1) Network - DHCP Server опции - WINS Servers - для использования небоходимо отдельно заводить этот самый WINS Server или эта приблуда сама его и формирует и можно использовать адрес самого DHCP сервера в качестве WINS ?

2) Leases - Lease опции - Always Broadcast - может ли вызвать проблемы при использовании простых статических привязок и уменьшится ли служебный трафик ?


Спасибо.