Alver

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

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

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

якщо не таємниця, то яке це обладнання? Простой Микротик 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%, но положительно результата-нет.

Skip

Оператор также выложил ( на наге) скрин пинга стандартного ( 50 байт) и длинного (1500 байт) базы ePMP на 120 клиентах и полной загрузке сектора. Результат впечатляющий - такой емкости по пропускной способности , количеству клиентов и задержке в малтипойнт - никто ,никогда и нигде за всю историю ШБД не видел.

Я сказал где находится оригинал. Что касается GPS, то дело не в некоррекности ,а в другом - оператору ( автору скринов) мало резервирования аплинка при делении DL/UL 75/25, то есть при динамическом Flexible делении фрейма любой клиент получает в спидтесте всю незагруженную емкость сектора, а при фиксированном делении -только его четвертую часть. Кроме того при Flexible меньше задержка. В общем получается, что если хочешь Frequency reuse за счет синхронизации GPS, то за это надо немного заплатить емкостью и задержкой. Но это заметно анлим клиентам при тесте доступной скорости в аплинке,

И в дополнение. Пинг на базе с 120 клиентами 40-50 мс, игроки не жалуются. Однако клиенты с тарифами 15/3Мбит/c в момент максимальной загрузки сектора вечером по спидтесту получают 12 Мбит/c. Поэтому сектор перевели в 40Мгц, загрузка сектора увеличилась до 90-100 Мбит/c и есть свободная емкость, спидтест ограничен шейпом 16М. Вот скрин загрузки другого (второго) сектора - 95 клиентов , 20 Мгц, всего на сайте там 4 базы- сектора ePMP - на всех 4-х секторах подключены в сумме 350 CPE ( 3 базы 20 Мгц, один с 120 клиентами перевели на 40Мгц).

Один оператор подключил на одну базу ePMP ( сектор) 120 клиентов- это максимум( программное ограничение). Выложил скрины на наге в профильной ePMP теме. На скрине ниже им пойманы 106 подключенных абонентских станций .Загрузка сектора в канале 20 МГц max Download 60 Мбит/c + Upload 10 Mбит/c в режиме деления DL/UL ratio Flexible. Тарифы downlink/uplink 6/1, 10/2, 15/3 Мбит/c поделены между клиентами примерно поровну.

Проблема не на повербимах, а на базе. У Вас это две разные базы или это все клиенты одной базы? Для начала Вам надо выровнять уровни сигналов в аплинк от всех клиентов одной базы. У Вас классический случай, когда один плохой клиент валит всю базу. Airmax включён?

Ничего не поможет, а если какой то костыль улучшит работу, то все будет временно. Если пришла в сеть убнт проблема, то она уже никогда не уйдёт. До этого работало потому что были другие условия. Сейчас изменилась помеховая обстановка, величина и профиль трафика, количество и условия подключения клиентов, трасса линка- снег например выпал (переотражения увеличились), кран поставили, дом построили и др.и сеть стала падать. Это конец. Меняйте оборудование.

В конструкции радиокарта- пигтейл- кабель типа белден 9913- антенна самым ненадежным участком является антенно- фидерный тракт. Так что в плане надежности и ремонтнопригодности Вы только проиграете. Сама по себе плата RB с радио на борту ( не minipci) достаточно надежное устройство, в хорошем корпусе и грозозащитой может работать без проблем много лет и сама по себе задача ремонтнопригодности этого девайса не актуальна.Не следует создавать себе проблемы с надежностью чтобы потом их решать улучшенной ремонтнопригодностью. Тазики с miniPCI радио - пройденный этап в развитии БШД, не изобретайт

БС не потянет 150-200 беспроводных юзеров. Количество юзеров в малтипойнт не зависит от мощности процессора и объема памяти. Макс. количество юзеров на x86 будет точно таким же как на любой платформе RB - порядка 30-35 при ёмкости базы по пропускной способности 30-40 мбит/с в канале шириной 20 МГц. Я, наверное, неправильно изложил мысль. Беспроводных клиентов будет не 150-200. Их будет максимум 30. Остальные кабелем. Вопрос был именно в унификации решения. На материнке стоит две радиокарты 5 и 2 ггц. 5-входящий линк, 2-базовая станция, сетевая карта это проводной интерфейс, ну или sfp шахта н

БС не потянет 150-200 беспроводных юзеров. Количество юзеров в малтипойнт не зависит от мощности процессора и объема памяти. Макс. количество юзеров на x86 будет точно таким же как на любой платформе RB - порядка 30-35 при ёмкости базы по пропускной способности 30-40 мбит/с в канале шириной 20 МГц.

ePMP Force 110 PTP Cambium Networks. Но антенны диш 25 дби надо заменить на 30 дби рокет диш или джирус.

Теоретически АС в 20 МГц может выдать порядка 130-140 мбит/с ( uplink + downlink) за счёт использования модуляции 256AM. Но на практике заставить устройства, в том числе бим АС, стабильно работать на этой модуляции на 7 км с помехами и преградами на трассе (NearLOS) нереально. Если условия идеальные - полный LOS и минимум помех, то попробовать АС можно. При этом 130-140М может быть на UDP трафике. На TCP , а значит и на реальном трафике будет намного меньше. Из Камбиум скоро будет в продаже ePMP Force 110 PTP. Он будет немного дороже бима АС, но стабильных 100-110М в 20 МГц и 200- 220М (

выложены скрины работы базы ePMP1000 GPS Sync c 72 абонентскими станциями. Канал шириной 20 МГц. Тариф 5 Мбит/c, загрузка сектора max 40/8 МБит/c. Свободная емкость сектора при максимальной загрузке сектора трафиком при канале шириной 20 МГц еще остается порядка 30 Мбит/c. То есть еще можно подключить порядка 30 клиентов или увеличить тариф до 10+Мбит/c.

Вы на своем линке переключили устройства ePMP Con. на другие антенны?

Хочу видеть ваш тест tcp на 11 км в загаженном эфире зы: Харе пиарить свое говно железо в каждой теме. Пример ( исключительно для сравнения, а не пиара ;-) канала с надежностью BER в 10 в -6 ( TDMA Камбиум ePMP1000), поэтому тесты скорости TCP и UDP, а главное реальная пропускная способность TCP/IP - примерно одинаковые. LOS 17 км TCP дуплекс через ethernet, 100/75М duplex- полка по 100% CPU тестера. UDP 110/110М дуплекс. Помеха на рабочем канале -85 дБм. В Микротик АС надежность канала, IMHO, BER 10 в -1 или -2, поэтому и есть такая разница с TCP и UDP. Тест UDP для такого

Выдайте тест TCP дуплекс ( both) и не встроенный , а через ethernet. UDP тест не учитывает BER канала ( или PER packet error rate) и разница между TCP и UDP на АС может составлять 3-5 раз ( что и обьясняется низким BER канала). TCP тест даст то , что канал имеет реально на живом TCP/IP трафике. В симплексе TCP ( на первом скрине ) скорость 117М. В дуплексе ( both) да через ethernet, думаю, будет 50М duplex c существенным перекосом на 20-30М. Это и есть реальная пропускная способность живого реального трафика Вашего канала .

Для того чтобы на АС получить 200+ М нужно или 80 Мгц канал или/и модуляцию 256QAM. И то и другое возможно в нынешней реализации АС только на очень коротких дальностях ( 1-3 км) на мощных внешних антеннах. Ставьте канал 40 МГц. Но на 15 км скорость 200М ( суммарно UL+DL) на TCP/IP по любому не получите из за низкой надежности канала на 256 QAM ( как и 64QAM) на АС , в том числе АС микротике, никакие настройки не помогут. На 15 км лучше ставьте обычный N (Микротик или Камбиум ePMP ) в 40 Мгц. Если помех мало, то 200М ( суммарно UL+DL) можно вытянуть..

Если есть помехи ( а их если сейчас нет, то могут появится в любой момент) и нельзя уйти по частоте ( лицензия), то даже на 3 км чтобы получить стабильных не менее 80 мбит/c живого трафика в 20 Мгц обязательно надо ставить устройства по внешнюю антенну с дишем 22-25 дБи. Что лучше? Выше озвучили.

Причина проблемы - переотражения в условиях NearLos ( рельеф, деревья, дома,трубы...) от клиентов. Лайты усугубляют проблему, так как фонят широко в напрявлении базы и не только. У антенн лайтов слабая кроссполяризационная развязка и сильный перекос сигналов по чейнам в зависимости от частоты. В los это может быть терпимо,но при наличии препятствий один такой клиент может положить всю сеть. Что делать? Выпрямлять рельеф :-). Или избавляться от клиентов , работающих в таких условиях,возможно ставить им другую антенну (но не факт что поможет). Это те клиенты,у кого не низкие сигналы, а низкие мо