Alver

Вот так догрузил, линк при этом себя чвствует отлично, сойдёт? 64k2.png Думал, что не нужно напоминать, что тест на ппс делается на линке точка-точка внешними тестерами, то есть через ethernet обоих радиоустройств. У Вас тест с радиоустройсвта МТ через его wireless интерфейс на внешний по отношению к противоположному радиоустройству тестер и к тому же ассиметричный. И повторяю, тест должнен быть симметричный дуплекс 64Байт, счетчик Tx и Rx на Ethernet с двух сторон должен показывать примерно одинаковые значения и на пустом канале.Только тогда тест будет адекватным и оценка ппс устройства этим тестом будет не искажена. A между wireless интерфейсами можно нагнать любой хоть 100k ппс или между ethernet портами минуя wireless ( как это показывает сам Микротик в своих спецификациях). Но для радиоустройств ( а не проводных роутеров)- это такая оценка не применима и не соответствует действительности.

на двух девайсах разные прошивки были ? Девайсы пришли с прошивкой 2.3.2. Один из девайсов при препродажной подготовке проапгрейтили на последнюю 2.3.4. а есть уже информация, когда выйдет новая прошивка ? Да давно уже должна была выйти. Обычно больше чем на месяц раньше не задерживали. Месяц истекает в конце января.

Так ппс не измеряют. Дайте дуплексный ( обязательно) тест UDP пакетами 64 байта, поток ограничьте величиной, когда задержка остается стабильной и не растет, и считайте пакеты полезного ( тестового) трафика. Дуплексный трафик Tx 6Мbps + Rx 6Mbps дает ппс 24.5K

на двух девайсах разные прошивки были ? Девайсы пришли с прошивкой 2.3.2. Один из девайсов при препродажной подготовке проапгрейтили на последнюю 2.3.4.

ППС Камбиум 25.5K. Вот тест на ппс на дальности 17 км- выдал цифру 24.5k. Пропускает и больше до 30K, но с 25.5K начинает увеличиваться задержка. Что касается Микротика, то его ппс без агрегации 6K, c максимальной агрегацией ( A-MSDU -4096 байт и A-MPDU - 64Kбайт) у бордов с 100М ethernet -26K, 1Гб ethernet -32-35K- это на столе. В реальной сети максимальной агрегации нет в силу разных причин. Поэтому ппс на реальных линках МТ обычно меньше 20K, хотя в идеальном эфире без помех может и больше разогнаться с увеличением степени агрегации . Протестите свой линк пакетами 64 байт UDP и увидите, что его ппс не превышает 22K. PS Не выдумывайте проблем, которых нет

И что это нормально 100М в полосе 60МГц?

нет

якщо не таємниця, то яке це обладнання? Простой Микротик N сможет, но на 18 км обязательно 30+ дБи дишами и обязательно LOS и минимум помех. Также сможет выдать на 18 км 200М в любых условиях LOS/NearLOS, средний уровень помех другое оборудование с дишами 25 дБи ( см соседнюю тему), здесь в теме про убнт/мт не могу его назвать. странно, но не хочет больше, стабильных 70 мбит, проганять. уже запарился искать причину. и уровни нормальные и прямая видимость, а не работает.... Вам же объяснили причину. Ничего странного нет.

На 9 км диши 34 дБи -это много и дорого. И у ТС нет LOS. И поэтому дело не только в недостаточной энергетике линка из за затухания сигнала из-за леса. А есть проблема от переотражений. Поэтому на АС стабильного линка не будет. У АС в LOS есть проблемы, а в NearLOS- безнадежно.

Как это 20М в одну при дуплексе ?

Да не в ппс и упаковке дело. У Вас помеха -84дБм и сигнал -64 дБм. CINR 20 дБ и то видимо средний ( а так падает видимо и ниже, чуть ли не до 3 дБ). А для работы 256QAM ( чтобы получить скорость больше чем на устройствах N) нужно CINR минимум 35 дБ, а для стабильности все 40. Ставьте канал 20 Мгц, может подымете 64QAM в downlink ( Tx) нестабильных. А в аплинке RX может в лучшем случае будет 16QAM , на что система сама встала автоматом ( на скрине) . ЗЫ Бросьте это дело, ничего путного на этом линке не выйдет.

разве что в мелкие. Чтоб потери уменьшить. В радиоканале пакеты по любому агрегируются в фреймы A-MSDU длиной 4096 байт. Это для канала с помехами очень много.

Причина-низкая надежность ( потери пакетов) канала на чипсете АС. Попробуйте посатавить роутеры с обеих сторон радиолинка,т.е. переведите его в одтельную IP подсеть. Но не факт что сильно поможет. простите я не понял всмысле "роутеры" , у нас клиент подключен сразу к серверу(гигабитный порт) а АП к гигабитному свичу, у нас все мостовые антены имеют отдельный ИП адрес а сервер в другом диапазане, или вы имеете ввиду АП настроить в роутере? Я имел в виду то что, сказал. Радиоканал надо выделить в отдельную IP подсетку, а для этого надо с каждой стороны радиоканала поставить проводные IP маршрутизаторы ( роутеры), можно Микротик. Это нужно для того, чтобы в случае потери или искажения TCP пакета, его маршрутизатор сразу восстанавливал повторной передачей. Если в сети везде мосты ( бриджи), свичи, то обнаружить такую потерю может только маршрутизатор внешнего канала Интернет. Он может быть далеко от проблемного радиоканала и, чтобы битые пакеты не гуляли в сети, а также чтобы обнаружение потерянных пакетов происходило как можно раньше, то маршрутизаторы должны стоять как можно ближе к проблемному радиоканалу. Но ошибок может быть так много, что это не поможет. Тогда надо менять железо, АС - не лучший выбор. Кто Вам вообще посоветовал использовать АС? Netmetal Миктротик - такая же хрень. У Вас нет прямой видимости, лес мешает. АС даже в LOS работает плохо. Все это сырое и нерабочее. И забудьте про каналы 60 и 80 Мгц.

Упаковка пакетов ничего не даст. Там дело не низкой ппс.

Причина-низкая надежность ( потери пакетов) канала на чипсете АС. Попробуйте поставить роутеры с обеих сторон радиолинка,т.е. переведите его в одтельную IP подсеть. Но не факт что сильно поможет.

На какой дальности от этих 5 клиентов находится конкурирующая БС, раздающая им по 5-7мбит/c?

Но 100М они не дадут, разве что в 40Мгц, и то в LOS без помех.

Там столько всего. Попроще ничего нет? Ссылку дал потому, что А) ее первой выдал гугл %); Б) там в начале есть пару полезных ссылок. Например, тыкаем первую http://mikrotik.axiom-pro.ru/articles/qos.php и там читаем про те же simple queues - в картинках, вроде все просто и понятно. В Вашем случае просто гарантированная(limit-at)/максимальная(max limit) скорость будет 50%/100% от ширины канала. Сработает ли именно в Вашем случае и как - так его проще попробовать... пару команд же. Шейп сработает. Но нужен же не шейп.

Там столько всего. Попроще ничего нет? Все что там написано насчет приоритезации в лучшем случае работает между проводными интерфейсами. Что касается радио - бесмысленный и бесполезный сизифов труд. Для того чтобы обеспечить в радио QoS вообще и приоритеты, в частности, необходимо управлять очередями на МАС уровне, а не скриптами операционной системы -линукса на уровне приложений.

. Канал сам делится при дуплексном ( встречном) трафике, правда не точно поровну, ассиметрично. Заставить МТ делить поровну невозможно, поскольку там нет Time Divison Duplex.

Причина в эфире. Для того, что-бы получить выигрыш от АС надо для начала получить выигрыш по с./ш. +10 дБ по сравнению с N. Реально надо более 40 дБ сигнал/шум для работы QAM-256. В твоем случае поможет антенна большего размера, D 1,8 м. например ) Все программные настройки - это танцы с бубном... Лучшее, что там можно сделать - это найти с помощью спектроанализатора самый незашумленный участок, причем сканировать надо с двух сторон и лучше вечером, когда видна реальная картина. В данный момент Signal to Noise - 50-52 dB, зачем еще больше антенны тогда? Имеется в виду, что нужно обеспечить сигнал/помеха >40 дБ. Для этого нужны большие антенны. Можно делать тест TCP симплекс и дуплекс( both)?. Он даст реальную картину и обьяснение что происходит. А кто-то объясните, Ch0 на этих антеннах как определить? Почему он может так сильно уйти от другого чейна? Разница в 10 дБ в уровнях сигнала по чейнам в конкретно данном конструктиве антенны имеет место вследствие двух причин. 1) Антенна SXT кривая , ее усиление меняется в каждом чейне ( причем по разному и не синхронно) +- 5 дб при изменении частоты с 5.1 до 5.9 MHz 2) Спутниковая тарелка не предназначена быть рефлектором для облучателя 5 Ггц и сам SXT -не предназначен быть облучателем , к тому же он может располагаться не фокусе рефлектора. Поэтому такой рефлектор с таким облучателем может по разному усиливать сигналы в разных чейнах и на разных частотах. У правильных антенн разница сигналов в разных чейнах бывает из за условий NearLOS, но в данном случае основную причину имеющейся разницы дают другие указанные выше две причины. А теперь по сути пропускной способности линка- она составляет в 40 МГц 15/23 Mbps дуплекс ( 38 Mbps UL+DL) на TCP, что соответствует максимальной пропускной способности этого канала на реальном живом TCP/IP трафике. Это для 40 Мгц канала на 15 км дальности и на таких огромных 1.2 м оффсетках неприлично мало, считай линк -говно. При этом следует заметить, что как видно на скринах выше в теме, этот линк на устройствах стандарта АС работает ( сконфигурирован) в стандарте N на максимальных модуляциях 64QAM5/6 ( data rate 270/300Mbps) и на обычных устройствах МТ стандарта N можно было бы получить значительно ( в несколько раз ) больше скорость. Причина почему на чипсете АС работа в стандарте N хуже чем работа в N на чипсете N проста- этот чипсет АС дает низкую надежность канала, измеряемую в BER ( Bit Error Rate) или PER ( packet error rate). Поэтому на линке теряются пакеты. Тест UDP, не учитывающий потери в канале, выдает приличный результат, а вот тест TCP, а также реальная скорость живого TCP/IP трафика полностью деградирует и мы видим это на скринах. Перевести канал в АС и поднять модуляцию 256QAM, как следует из репорта ТС , также не получается , так как там нужно обеспечить сигнал/помеха CINR>40 дБ, что видимо на данном линке сделать невозможно, а обеспечиваемая надежность канала на QAM256 еще ниже , чем на 64QAM, поэтому реальная скорость - никакая.

Причина в эфире. Для того, что-бы получить выигрыш от АС надо для начала получить выигрыш по с./ш. +10 дБ по сравнению с N. Реально надо более 40 дБ сигнал/шум для работы QAM-256. В твоем случае поможет антенна большего размера, D 1,8 м. например ) Все программные настройки - это танцы с бубном... Лучшее, что там можно сделать - это найти с помощью спектроанализатора самый незашумленный участок, причем сканировать надо с двух сторон и лучше вечером, когда видна реальная картина. В данный момент Signal to Noise - 50-52 dB, зачем еще больше антенны тогда? Имеется в виду, что нужно обеспечить сигнал/помеха >40 дБ. Для этого нужны большие антенны. Можно делать тест TCP симплекс и дуплекс( both)?. Он даст реальную картину и обьяснение что происходит.

якщо не таємниця, то яке це обладнання? Простой Микротик N сможет, но на 18 км обязательно 30+ дБи дишами и обязательно LOS и минимум помех. Также сможет выдать на 18 км 200М в любых условиях LOS/NearLOS, средний уровень помех другое оборудование с дишами 25 дБи ( см соседнюю тему), здесь в теме про убнт/мт не могу его назвать.

Протестите канал iperf или BT Микротик пакетами TCP в дуплексе- сразу все увидите. Канал на АС ( в нынешней реализации чипсета, применяемого на мт и убнт ) имеет очень низкую надежность канала BER /PER ( packet error rate), поэтому TCP трафик и реальный TCP/IP тормозится на оборудовании АС в разы по сравнению с тестами UDP пакетами и живым UDP трафиком ( торренты). ЗЫ На 18 км скорость 200М живого трафика можно без проблем получить в 40 Мгц на правильном оборудовании стандарта N.

Не работает на UBNT синхронизация , ни на титанах, ни та старых. GPS типа есть, даже синхронизация какая то своя есть, от которой канал сразу падает ( при включении Airsync ) на 30%, но положительно результата-нет.