Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • 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
     
    Ozelo
    Guest
    #1
    0
    27.07.2006 21:23:00
    Я решил создать эту тему, чтобы обсудить и, возможно, поделиться опытом с сообществом по поводу этих трех пунктов в беспроводных сетях. Изначально я ищу информацию об ограничениях оборудования и технологических ограничениях. Кроме того, эта тема может стать полезным справочником по указанной выше теме на этом форуме. Я провел некоторые измерения в своей беспроводной сети, и было бы неплохо, если бы люди указали на исправления/измерения по всей теме, включая ссылки на посты, тесты производительности и т.д. Давайте скажем, главная таблица для начала: Технология и оборудование. 802.11b показывает ограничения около 200 пакетов в секунду (pps), в то время как в 802.11a я могу видеть около 4000 pps. Помимо физических ограничений в пакетах, есть известные ограничения полосы пропускания и пропускной способности. То есть, если у вас есть ограничение полосы пропускания в 11 мбит/с, это не означает, что у вас будет ограничение в 200 pps или даже соответствующее ограничение пропускной способности. Конечно, есть и другие переменные, такие как tcp, udp, политика формирования кадров, очереди, qos, формирование трафика и т.д. Главная причина этого поста – это производительность беспроводной сети разными способами её реализации: l2tp, dual nstreme, точка доступа, абонентское оборудование, ppp и маршрутизированные/мостовые устройства. Многие люди, возможно, в основном интересуются QoS вместе с p2p, формированием трафика и особенно те, кто использует точки доступа в 802.11b. У нас есть несколько сценариев, чтобы начать разговор, но сначала позвольте мне рассказать вам немного истории. У нас были конкретные проблемы с клиентами, использующими старые карты 802.11b, при переходе на оборудование точек доступа Atheros a/b/g, но только при использовании точки доступа только для 802.11b. У нас также были проблемы с точками доступа, которые делят 802.11b со многими разными типами карт на стороне клиента, например: точка доступа Atheros a/b/g → клиент Atheros a/b/g + только карты 802.11b. Точка доступа беспроводной сети MT с примерно 78 клиентами в 802.11b. Карта Atheros a/b/g на стороне точки доступа, несколько коробок MT с Atheros a/b/g, а остальные — это смесь карт для 802.11b и некоторые из них b/g карты, включая realtek, d-link, ralink, orinoco и т.д… Все скрытые станции. Небольшое примечание: в этом случае, похоже, что MT к MT получают очень высокий приоритет по сравнению с общим 200 pps лимитом. Скажем, вы едва ли видите 300 pps от времени к времени. Также, у этой точки доступа есть смесь клиентов pppoe/статические IP-адреса. Таким образом, трудно обойти трудности с формированием трафика/qos. Большинство жалоб – это клиенты со статическими IP-адресами, но не карты Atheros. Общая пропускная способность в этих условиях не превышает 2,5 Мбит/с. Клиенты с коробками MT могут получить CIR от 80 до 95% по сравнению со всеми остальными. Мы используем платы маршрутизаторов WRAP, и загрузка ЦП составляет менее 25% для выполнения работы. Я искал способ справиться с лимитом в 200 pps, но, похоже, лучший способ (также простой) — переключить точку доступа с 802.11b на 802.11a. Затем у нас возникнут проблемы на стороне клиента. Что ж, около 200 клиентов, которые используют эту башню, должны выбросить карты 802.11b и затем начать использовать карты 802.11a. Очереди, особенно PCQ или формирование трафика, не решают проблему с пакетами в секунду и также увеличивают задержку. Ситуация становится еще хуже, когда на стороне клиента (карты Atheros a/b/g) есть вирусы. В противном случае, нам потребуется гораздо больше точек доступа для обеспечения разумного покрытия с максимальным лимитом примерно 25 клиентов на точку доступа. Я уверен, что, возможно, хороший доброволец мог бы дать нам отличную настройку, чтобы лучше справиться с ситуацией, не покидая 802.11b. Пожалуйста, все комментарии приветствуются.
     
     
     
    sten
    Guest
    #2
    0
    27.07.2006 22:53:00
    78 клиентов борются за верхний предел пропускной способности, возможно, 6 Мбит (без установления соединения, однопоточный). На чем конкретно основывалось это решение? Каковы были начальные цифры? Представьте, вы сантехник, купили трубы и фитинги у разных производителей, и после сборки вы пускаете воду под максимальным давлением, на которое рассчитаны эти трубы. Какова вероятность протечек? А теперь вы решаете повысить давление примерно в 39 раз больше, чем они рассчитаны. Какова новая вероятность протечек? Я пришел к выводу, что терпение людей немного более гибкое, чем законы физики, и ни то, ни другое не любит испытаний.
     
     
     
    Ozelo
    Guest
    #3
    0
    28.07.2006 02:47:00
    Ну что ж, это было не мое решение вообще. Описанный мной сценарий — один из наших критически важных AP на сегодняшний день. Количество подключенных клиентов может меняться примерно от 20 до 80 каждый день. Один из этих клиентов подключен со скоростью 512kbps, на ПК с MT со статическим адресом и использующим полную полосу пропускания 24/7. Есть еще несколько клиентов (около 12) со статическими адресами, подключенных со скоростью 256kbps и использующих полную полосу пропускания примерно меньше шести часов в день. Остальные — pppoe клиенты с динамическими адресами, обычно 50% этих pppoe клиентов подключены со скоростью 256kbps, а остальные 50% — со скоростью 128kbps, большую часть времени запуская p2p-программы. Я вижу, что этот AP получает больше 2.5mbits/s (примерно 3.8mbits/s), когда я делаю загрузку на клиенте, подключенном без какого-либо формирования трафика. Когда подключено примерно 78 клиентов и p2p-tap полностью открыт на нашем магистральном узле концентраторе, также есть потеря пинга и среднее время (2500мс). В этот момент, этот AP в 802.11b я вижу примерно 390–400 пакетов в секунду. Есть другие AP в 802.11b с примерно тем же количеством клиентов, ни один из которых постоянно использует полную полосу пропускания, а лишь изредка. Когда пакетов в секунду меньше 200, нет потери пинга и среднее время 5мс. P2p кажется не проблемой в последней, но кажется, усугубляется с точки зрения пакетов в секунду. Есть еще какие-то цифры, которые вам нужны? Извините, но вы забыли упомянуть, что сумма всех сил любой природы всегда равна нулю в любой из систем отсчета. Но на самом деле ни терпение людей, ни законы физики пока не испытываются. Несомненно, вы не будете первым, ни последним. Для кого-то, кто вливает экспертизу, ваша вежливость была очень поучительной. Нет-нет, ничего, чего я не мог ожидать от такого большого знания!? Спасибо. Что еще можно было сделать лучше? Может быть, почему терпение нужно быть гибким, а не ненужной грубостью к кому-то, кого вы никогда не знаете, кто он или когда вам понадобится помощь… приподнимает бровь. Далее…
     
     
     
    Skaught
    Guest
    #4
    0
    06.10.2006 02:00:00
    Пытаюсь найти способ организации очередей на основе пакетов в секунду. Кажется, это и есть ограничивающий фактор в 802.11b, и если мы сможем это контролировать, то окажемся в более выгодном положении. К сожалению, все очереди, которые я могу найти, основаны на кб/с, а не на пакетах в секунду.
     
     
     
    tpsretard
    Guest
    #5
    0
    06.10.2006 11:59:00
    sten ← Это был такой замечательный пост, постарайся немного убавить сарказм, это на самом деле очень интересная тема… Skaught, есть несколько вещей, которые можно сделать, чтобы помочь, может, не так изящно с точки зрения администрирования, но… Занимайся shaping трафика на клиентском роутере вместо AP, это остановит нежелательный трафик, накатывающий на беспроводную сторону, установи лимит на количество p2p-сессий в секунду. Я немного тестировал с 802.11a, в основном потому, что мы искали способ обеспечить достаточную полосу пропускания для бэкхолла. 802.11a показался нам лучшим вариантом, так как якобы есть предел в 4000ps, что лучше, чем наше оборудование Alvarion, где предел 2000ps. Мы немного тестировали с dual nstream и смогли достичь примерно 5500ps, но тогда наши системы просто вылетали с 100% загрузкой CPU, так что нам нужно получить более мощные системы, прежде чем мы переделаем тесты.
     
     
     
    bushy
    Guest
    #6
    0
    06.10.2006 13:40:00
    Может, попроси добавление этого в раздел запросов для будущих релизов? Они тут быстро исправляют релизы. Если тебе это полезно, то и другим тоже пригодится.
     
     
     
    Skaught
    Guest
    #7
    0
    06.10.2006 15:34:00
    У меня есть 1200 клиентских устройств CPE стандарта 802.11b, произведенных компанией tranzeo, принадлежащей моим клиентам, которые я должен поддерживать. Замена их на Mikrotik обойдется почти в полмиллиона долларов, и это не вариант. Но я уже приоритизирую P2P и т.д. в ядре сети. Хотя этого все еще недостаточно для наших нужд. Но это, безусловно, помогает.
     
     
     
    changeip
    Guest
    #8
    0
    06.10.2006 17:51:00
    Кто-нибудь пробовал использовать Packet Packer в этой ситуации, чтобы объединять пакеты и снижать общую PPS? Сэм.
     
     
     
    tpsretard
    Guest
    #9
    0
    06.10.2006 21:21:00
    Прости, я не знал, что у вас столько CPE развернуто... Вы шаппите только на ноках или на AP тоже? У меня была похожая ситуация, и тогда единственным решением оказалось обновление AP до P4 mobile и шаппинг непосредственно на беспроводном боксе, это вроде бы очень помогло…
     
     
     
    Skaught
    Guest
    #10
    0
    07.10.2006 00:30:00
    Ого, протокол интересный. Помогло бы только в одном направлении, так как наши CPE не Mikrotik. Но стоит иметь в виду. А сработает ли, если только один конец - MT?
     
     
     
    karyal
    Guest
    #11
    0
    07.10.2006 19:50:00
    Да, на перегруженной линии я однажды пробовал… задержки растут, но pps (и загрузка CPU) резко падают, даже при простой агрегации, на RB532. Пока, Рикки.
     
     
     
    jober
    Guest
    #12
    0
    08.10.2006 01:20:00
    Ох, люди, ну что вы! Sten просто пытался помочь и немного повеселить. Нельзя это назвать злобным или саркастичным. Я знаю его достаточно хорошо, чтобы знать, что он не хотел никого обидеть. А я бы точно сделал ему замечание, если бы он хотел. Но я не думаю, что он хотел. Хе-хе. Вы же сами сказали, что любой вклад приветствуется. Лол. Извините заранее, если это кого-то задело в той или иной форме. НО! Как говорят расслабленные ребята из этих мест: "Пусть идет ко всем чертям, если не может принять шутку".
     
     
     
    variable
    Guest
    #13
    0
    09.10.2006 18:30:00
    Можно ли включить m3p только на беспроводных каналах → то есть, чтобы только бриджи сжимали и разжимали пакеты, и чтобы роутер вообще не трогать?
     
     
     
    simonkizi
    Guest
    #14
    0
    10.10.2006 23:17:00
    Привет. Извини, но как ты это делаешь именно так? (Packet Packer) Кстати, можно настроить очереди, чтобы ограничить скорость сопоставления пакетов! Однако, я думаю, что это не контролирует, что принимает беспроводная карта, а скорее после получения. Если опрос в Nstreme может работать для клиентов, отличных от Mikrotik, то равное распределение времени может помочь равномерно распределять ограниченное количество пакетов. По-моему, кто-то упоминал это раньше. Спасибо.
     
     
     
    Skaught
    Guest
    #15
    0
    13.12.2006 00:38:00
    Было бы просто огонь, если бы были два варианта, связанные с этим. Возможность установить RTS на 1 в не-MT клиентах, а затем MT выдает CTS по кругу. Получается псевдо-опрос, но для любого 802.11 CPE. Нужна программа для Windows, которая позволит собирать пакеты прямо в системе. Уверен, я бы уговорил своих P2P пользователей установить её, потому что представляю, что это могло бы улучшить производительность для них и для всех остальных. Если уже есть какой-то вендор, который делает что-то подобное, было бы вообще класс.
     
     
     
    sten
    Guest
    #16
    0
    14.12.2006 18:29:00
    Ага, да, хорошая идея, но это еще потребует доработок со стороны клиентов. Подумайте о процессе подключения клиентов к точке доступа. Что, по-вашему, произойдет, если клиенты, до того, как будут "аутентифицированы" точкой доступа, начнут отправлять RTS-пакеты для пакетов аутентификации?
     
     
     
    NoXy
    Guest
    #17
    0
    20.12.2006 19:14:00
    Привет, Ozelo! У меня та же проблема с pppoe через Wi-Fi. При средней нагрузке сети пинги взлетают до 2000 мс, потери пакетов и всё такое. Примерно на 30% загрузки работает нормально… Не знаю, где проблема.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры