Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Распределение пропускной способности с графиками отдельных очередей

    Распределение пропускной способности с графиками отдельных очередей

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Распределение пропускной способности с графиками отдельных очередей, RouterOS
     
    OwenITGuy
    Guest
    #1
    0
    07.09.2012 11:44:00
    Привет. Я техник, который управляет небольшой WISP, и сейчас пытаюсь улучшить нашу инфраструктуру. В сети у нас пока 40-50 клиентов. Сейчас мы используем простые очереди для каждого пользователя, чтобы задавать максимальные скорости загрузки и отдачи. Лимиты у каждого клиента разные. Хочу уйти от такой модели и сделать так:

    - Распределение доступной пропускной способности через PCQ (или другой механизм)
    - У разных клиентов разные максимальные скорости загрузки/отдачи (например, 256/128, 512/256 и 1024/512)
    - Трафик каждого клиента по-прежнему можно смотреть на странице графиков (как сейчас с простыми очередями)
    - Ограничения очереди должны касаться только WAN-трафика и не влиять на трафик между клиентами

    Особенность: у нас интернет через VSAT спутник. Канал — 2 Мбит/512 Кбит при соотношении нагрузки 10:1, то есть реальная пропускная способность сильно плавает (обычно от 400 Кбит до 2 Мбит на загрузку).  

    Я много читал в вики и на форумах про очередь деревья, PCQ, маркировку соединений и пакетов. Но пока не понимаю, как правильно настроить очередь дерево.

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

    Если такое возможно, как может выглядеть очередь дерево?

    Я не совсем понимаю маркировку соединений и пакетов. Большинство рекомендует сначала пометить новое WAN-соединение, а потом использовать эту метку для маркировки пакетов. Понимаю, что это экономит ресурсы по сравнению с проверкой каждого пакета. Но у меня остались вопросы:

    - Какие критерии лучше использовать для маркировки соединений? Думаю, in-interface=Ether1 подойдет для загрузки, но может есть что-то получше.
    - Как лучше помечать WAN-трафик отдачи для маскированной сети?
    - Если соединение, пришедшее через Ether1, помечено меткой загрузки, то помечается ли также его отдача (например, ACK-пакеты)? То есть они будут считаться частью загрузочного квоты (и наоборот)?

    Спасибо за помощь!
     
     
     
    OwenITGuy
    Guest
    #2
    0
    08.10.2012 10:52:00
    Спасибо за полезное пояснение, Caci99 (и извиняюсь за мой ужасно поздний ответ). Поскольку PCQ не сработает из-за колебаний пропускной способности, есть ли другой механизм, который поможет обеспечить равный доступ к доступной полосе пропускания? Почитав немного подробнее, я подумал, что, возможно, очередь SFQ могла бы с этим справиться, но поправьте, если я ошибаюсь. Мне нужно гарантировать, что ни один пользователь не займет всю полосу пропускания, когда другие пользователи за неё борются, и мне нравятся графики для отдельных клиентов, которые есть у простых очередей.
     
     
     
    Caci99
    Guest
    #3
    0
    08.10.2012 16:22:00
    Рад, что хоть немного помог. Что касается вашей проблемы, я не знаком с очередью SFQ, но опять же не понимаю, как маршрутизатор может равномерно распределять пропускную способность, если общий объём неизвестен. Графики — отличная функция RouterOS, но если хотите что-то надёжное, что сохраняет графики даже после перезагрузки роутера или при его замене, то вам точно понадобится, например, Cacti, который собирает трафик по протоколу SNMP. К тому же, простые очереди действительно создают графики, а queue tree — нет. Но queue tree гораздо лучше подходит для качественного QoS, а простые очереди — для более простого QoS и настройки.
     
     
     
    NetworkPro
    Guest
    #4
    0
    09.10.2012 19:02:00
    Извини, если это звучит странно, но ты пробовал использовать Windows ПК в качестве шлюза VSAT и включить на нем cFosSpeed? После этого можно подключить RouterBOARD для ограничения трафика на пользователя и дополнительного контроля. К тому же нужен веб-прокси. P.S. И еще три VSAT-аккаунта для балансировки нагрузки, чтобы увеличить удобство всей системы.
     
     
     
    01101110110110
    Guest
    #5
    0
    09.10.2012 23:09:00
    Есть ли у пропускной способности расписание? Например, днем она около 400 Кб/с, а ночью становится 2 Мб/с или что-то в этом роде? Ты мог бы добавить два отдельных набора очередей и включать/выключать их с помощью скрипта, кажется, что-то подобное есть в репозитории скриптов на вики. На самом деле, реализовать QoS невозможно, если нет гарантированной пропускной способности. Сам роутер не знает, какая пропускная способность у него есть. Насколько я понимаю, Queue trees выделяют минимум для каждой очереди (если все имеют равный приоритет), а уже потом дают возможность брать остаток свободной пропускной способности, что, думаю, и нужно OwenITGuy. Значит, ему просто нужно убедиться, что минимум всех его пользователей достаточно низкий, чтобы не перегружать канал во время пиковых часов. А когда линия получает больше пропускной способности, она распределяется между остальными пользователями в рамках их максимального лимита. Насколько я понимаю, большинство спутниковых провайдеров тоже предлагают гарантированный минимум скорости, примерно как ты собираешься делать для своих пользователей. Просто можно взять это число для первоначальных расчетов. Кстати, у меня настройка довольно похожая на твою, с простыми очередями и так далее, только у меня проводная сеть, и я думал расшириться до Wi-Fi. Каким оборудованием ты пользуешься и какой у тебя радиус действия Wi-Fi?
     
     
     
    Caci99
    Guest
    #6
    0
    10.10.2012 10:48:00
    Queue tree, так же как и simple queue, обеспечивает минимальную пропускную способность (CIR), и она не зависит от приоритета самой очереди. Минимум будет гарантирован при любых условиях, независимо от того, имеет ли очередь высокий приоритет. Приоритет начинает играть роль только тогда, когда минимальные значения для всех очередей выполнены — вот в чём идея минимальной гарантии: независимо ни от чего, вы всегда получаете минимум. Можно рассмотреть и такой подход, реализуя минимумы, но…
     
     
     
    01101110110110
    Guest
    #7
    0
    11.10.2012 07:33:00
    Но если пропускной способности не хватит для всех этих минимумов, разве сначала не будут обслуживаться те, у кого самый высокий приоритет?
     
     
     
    OwenITGuy
    Guest
    #8
    0
    11.10.2012 12:49:00
    Всем спасибо за советы. Думаю, стоит объяснить ситуацию чуть подробнее, потому что у меня всё немного иначе, и мой кейс вряд ли вписывается в стандартные схемы.

    Я работаю в некоммерческой организации в восточном Конго. Нашими клиентами в основном являются НКО, миссионеры и несколько церквей, и общее число клиентов (а следовательно, и ежемесячный доход) вряд ли сильно вырастет в ближайшее время. К тому же здесь проблемы с электроэнергией. Наша система работает от инвертора и батарей, которые в основном заряжаются от солнечных панелей, а дополнительно — от генератора. У нас есть сервер, но мы его выключаем на ночь из-за большого потребления энергии. Поэтому такие решения, как Cacti или другие прокси-серверы, не подходят, ведь для них нужен всегда включённый сервер. Графики, доступные через simple queues на роутере, вполне устраивают, я просто хочу получше сделать равный доступ к каналу для всех.

    Теперь по двум комментариям и небольшое объяснение про VSAT-связь — вдруг кто не знает. Когда мы покупаем канал у спутниковой компании, мы выбираем скорость и коэффициент конкуренции (contention ratio). На той станции, что я обслуживаю, у нас канал 2 Мбит/с на скачивание. Коэффициент конкуренции — 10:1, то есть этот канал одновременно используют 10 станций, включая нашу. Станции работают по схеме TDMA — то есть по очереди получают доступ к каналу на определённое время (миллисекунды). Если работает только одна станция, за счёт большего временного слота её скорость близка к 100% от 2 Мбит/с. Если все 10 станций активно передают данные, тогда время делится на 10, и скорость получается около 10% — около 200 кбит/с. Из-за этого скорость постоянно скачет. В реальном времени можно видеть скорость от 1 до 1,5 Мбит/с, а усреднённая за день — около 400-700 кбит/с.

    Поэтому я не могу задавать большие CIR для каждой очереди, и нельзя использовать родительские очереди с фиксированным объёмом доступной полосы. Теоретически можно взять тариф с меньшим коэффициентом конкуренции, чтобы поднять скорость, но сейчас мы это не рассматриваем из-за большой разницы в цене (VSAT — довольно дорогой канал). Да и на более выгодном тарифе типа 5:1 всё равно будут скачки скорости.

    Из того, что я понял из инструкции (http://wiki.mikrotik.com/wiki/Manual:Queue#SFQ), SFQ планирует все потоки и даёт им равные шансы на передачу данных, не учитывая общий объём канала. Кроме этого единственного параграфа я не нашёл особо полезной информации. На одном сайте (http://wiki.ispadmin.eu/index.php/Documentation/Mikrotik_guide) сказано, что SFQ — это приоритетизация отдельных потоков, а не отдельных пользователей или очередей. Звучит так, что это поможет не дать одному большому потоку (скажем, загрузке большого файла) съесть весь канал. Вот только хотелось бы найти примеры или опыт применения. Может, пора браться за сертификацию MTCTCE!

    Сейчас я решил попробовать такую схему: родительская очередь SFQ без ограничений. А внутри — дочерние простые очереди (pfifo) с ограничениями по максимальному входящему и исходящему трафику, а также с небольшим лимитом на CIR. По моему пониманию, SFQ не позволит большим потокам забивать весь канал, и при этом я буду видеть удобные графики из simple queue. Буду рад другим советам или опыту.
     
     
     
    NetworkPro
    Guest
    #9
    0
    11.10.2012 13:07:00
    Пробовали поставить всех пользователей через ПК с Windows и cFosSpeed, без других очередей и ограничений? Этот ПК может быть на базе Intel Atom с потреблением 14 Вт. Можно добавить ещё один такой же 14-ваттный ПК как медленный, но полезный прокси. Пускайте своих друзей тестировать это через 3G — там примерно такая же переменная пропускная способность — и пусть присылают вам результаты в Конго, когда будет понятно, что это действительно стоит того.

    P.S. Все отдельные клиенты с cFosSpeed тоже помогут, если у них есть лицензия или они могут получить скидку.  
    P.S.2 Рекомендуется строить планы и налаживать партнёрства с близкими и удалёнными WISP, чтобы обеспечить больше связности через nstreme/NV2-ссылки.
     
     
     
    OwenITGuy
    Guest
    #10
    0
    12.10.2012 06:11:00
    NetworkPro, не могу отделаться от мысли, что ты, наверное, продавец cFosSpeed. Спасибо за твой вклад, но меня совсем не интересует переход на другую платформу для нашего шлюза. Что касается твоего совета, что я «должен» заводить партнёрства с другими WISP, у нас просто нет других WISP в нашем регионе. К тому же я не понимаю, как это помогает ответить на мой изначальный вопрос. В любом случае спасибо за твоё мнение.
     
     
     
    NetworkPro
    Guest
    #11
    0
    12.10.2012 06:20:00
    Да. Ты не видишь, как. А я вижу, потому что у меня больше информации. Я даю тебе то, что важно. Твою проблему не решить с помощью RouterOS. Тебе нужна система оптимизации WAN. Программу, которую я рекомендовал, я проверял лично. Взламывай её хоть как хочешь, мне всё равно.
     
     
     
    Caci99
    Guest
    #12
    0
    12.10.2012 08:34:00
    Это то же, что пришло мне в голову. Если нельзя гарантировать доступную пропускную способность, RouterOS мало что сможет сделать. Я познакомился с парнем из Нигерии пять лет назад, и он был в ситуации, похожей на твою — всего 2 Мбит/с. Это был период, когда MikroTik выпускал ROS rc3.x. Парня звали Санди, и он придумал классное решение: установил squid proxy и убедился, что трафик через прокси не ограничивается очередями. Он говорил, что так можно сэкономить почти 40% пропускной способности. Кажется, его руководство есть на вики. Конечно, прокси не улучшит качество Skype, YouTube и подобных сервисов, но веб-страницы и мелкие скачиваемые файлы будут загружаться гораздо быстрее. Понимаю, у тебя проблемы с питанием, но в твоей нынешней ситуации мало что можно сделать, по крайней мере я больше ничего не могу придумать.
     
     
     
    OwenITGuy
    Guest
    #13
    0
    16.10.2012 07:18:00
    Ну, я уже пару дней использую родительскую очередь SFQ simple queue (тип wireless-default). Также установил небольшие limit-at значения для каждой очереди. Честно говоря, пока не могу однозначно сказать, помогает ли это существенно, но теоретически система работает. Если дойдём до того, что сможем включать сервер круглосуточно, возможно, тогда и рассмотрю установку Squid. По крайней мере, начну использовать облегченную версию Squid от MikroTik прямо в роутере — может, это поможет. У меня уже есть очередь, которая пропускает локальный трафик с максимальной скоростью, так что это может слегка помочь. Пока что, учитывая, что тут у нас — Конго… c’est la vie! Всем спасибо за советы!

    Инфраструктура, которая была здесь, когда я приехал несколько месяцев назад, представляла собой смесь Ubiquiti (в основном NanoStation M2, немного NanoStation 2 и PowerStations) и антенн Giganet. А Giganet, кстати, уже вообще не существует. И это понятно. Когда антенны работают, у них довольно приличный радиус действия. Но регулярно возникают проблемы — вдруг они перестают транслировать беспроводной сигнал и не дают зайти в настройки. Кнопки сброса нет, приходится замыкать часть схемы на плате... и это тоже не всегда помогает. Правда, антеннам уже 4-5 лет.

    В ближайшие несколько месяцев я заменю все старые устройства Giganet на оборудование Ubiquiti. Для CPE я использую NanoStation M2, для базовых станций — секторные антенны на 120 градусов с Rocket M2, а для мест, где секторные антенны не так удобны, пару NanoStation M2 как точки доступа. Наш самый дальний клиент находится всего в 3,8 км (2,4 милях). Хотелось бы использовать больше MikroTik, но пока MIMO не стандартизирован, считаю, что лучше выбрать одного производителя для беспроводного оборудования.
     
     
     
    hrehm
    Guest
    #14
    0
    23.06.2013 14:43:00
    Привет, я сам базируюсь в Найроби и работаю со всевозможными W-ISP в центральной Африке. Например, с Datco в Буваку и Гоме, а также с несколькими другими. Возможно, у меня есть для тебя решение... Просто дай знать, если могу помочь. Хайко
     
     
     
    hgonzale
    Guest
    #15
    0
    26.03.2016 21:50:00
    Возрождаю этот пост, ха-ха-ха… У меня похожая ситуация, дружище. VSAT на 20 Мбит/с с неограниченным трафиком, около 10 клиентов, у каждого максимум по 3 Мбит/с. Но иногда из-за перегрузки скорость падает до 2–3 Мбит/с. Как ты справлялся с такими запросами? Спасибо!
     
     
     
    homerwsmith
    Guest
    #16
    0
    15.08.2017 07:02:00
    Я знаю, что это старое сообщение, но, возможно, смогу кое-что добавить для понимания. Очень важно понять, как работают очереди. Нужно прояснить концепцию «честной очередности», исходя из того, как она реализуется, ведь именно реализация — это то, что дает результат. Настоящая проблема не в том, что один загрузочный процесс подавляет другой трафик, а в том, что один ЧЕЛОВЕК подавляет всех остальных. Значит, проблема не в соединениях или типах соединений, поэтому нам в общем-то всё равно, как распределяется пропускная способность между загрузками, стримингом или простыми запросами веб-страниц — если только вам это не важно, но это уже совсем другая история приоритизации.

    Нам важно, чтобы каждый человек получал одинаковый общий объём пропускной способности в тот самый момент, когда он в ней нуждается, как и все остальные, независимо от того, чем он занимается. То есть, если у вас есть 3 мегабита и 3 клиента, и все одновременно нажимают Enter, каждый получает по 1 мегабиту на то время, которое ему нужно. Когда один перестает использовать, его доля автоматически переходит другому, и он получает больше.

    Нам ОЧЕНЬ важно не допустить, чтобы один пользователь открыл 8 соединений для загрузки, а другие двое — по одному. В сумме это 10 соединений, борющихся за пропускную способность, но 8 из них принадлежат одному человеку. Последнее, чего мы хотим — чтобы этот один пользователь забирал 80% из 3 мегабит, а остальные получали по 10%. Мы хотим, чтобы каждый имел по 33,3% от общей скорости, независимо от количества открытых соединений и типа трафика.

    Это реализуется с помощью PCQ (Per Connection Queuing) автоматически — для каждого IP, который открыл соединение, создается отдельная очередь. Когда в роутер приходит пакет, направленный конечному клиенту, он помещается в очередь по dst IP, независимо от мин/макс ограничений. Потом из каждой очереди по очереди берется по одному пакету (round robin). Так что, если в каждой очереди есть пакеты, они будут «выдаваться» с одинаковой скоростью — по одному пакету за цикл, и каждый получит равный объём пропускной способности! Очень просто и работает идеально.

    Если пакеты приходят в роутер достаточно медленно и их можно сразу отправить дальше, смысла в очередях нет. Но если пакеты приходят быстрее, чем роутер может их отправить клиентам, они накапливаются в очередях, а затем для каждой очереди происходит выдача по одному пакету за раз. Так каждому клиенту обеспечивается одинаковая пропускная способность в пакетах в секунду. В некоторых системах выдача происходит в байтах, а не пакетах, но обязательно целыми пакетами, так или иначе.

    И вот проблема: если у вас медленное спутниковое соединение для апстрима и быстрое беспроводное для клиентов, то роутер МОЖЕТ отдавать пакеты быстрее, чем они приходят, и они никогда не будут стоять в очереди. Тогда один пользователь может открыть 8 соединений, и его данные составят 80%, а данные двоих других — всего 20%. Чтобы избежать этого, нужно выставлять максимумы на клиентах примерно равными суммарной входящей пропускной способности или чуть меньше, чтобы скорость отдачи была МЕДЛЕННЕЕ входящего потока. Тогда пакеты будут попадать в очереди PCQ, а потом выдаваться с точной честной долей. Тогда у «80-процентного» пользователя будут теряться пакеты, и его поток замедлится, пока не сравняется с потоками других, которые, соответственно, разгонятся до равного уровня.

    И еще — учтите, что в сильно последовательной беспроводной сети, когда сигнал идет A → B → C → D, клиенты на конечной точке D будут испытывать значительно большие потери пакетов, чем на B, и из-за этого TCP замедлится не из-за перегрузки, а из-за потерь пакетов и подтверждений. Им потребуется большая пропускная способность, чтобы компенсировать эти потери.

    Homer
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры