[harmer_]

Если как вы пишите пинг 17-20 мс, то о каком джиттере идет речь? Или он у вас периодически взлетает в небеса?

 

Периодически пинг вылазит до 50-70 мс. От нагрузки данное поведение никак не зависит. Даже когда база работает вхолостую данная картина имеет место быть.

[Sonne]

Если CPE в режиме роутера, то это L3 cеть. И кстати, если при этом каждая CPE в отдельном VLAN, то есть вероятность, что бродкастовый трафик в принципе отсутствует. Вот интересно бы спросить m0isa.

 

Нормальная схема, если от базы каналы уходят в оптику и нет колец по радио.

[Sonne]

Если как вы пишите пинг 17-20 мс, то о каком джиттере идет речь? Или он у вас периодически взлетает в небеса?

 

Периодически пинг вылазит до 50-70 мс. От нагрузки данное поведение никак не зависит. Даже когда база работает вхолостую данная картина имеет место быть.

 

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

[SSD]

Если CPE в режиме роутера, то это L3 cеть. И кстати, если при этом каждая CPE в отдельном VLAN, то есть вероятность, что бродкастовый трафик в принципе отсутствует. Вот интересно бы спросить m0isa.

 

Нормальная схема, если от базы каналы уходят в оптику и нет колец по радио.

Будет большая разница если СРЕ будет бриджом, а VLAN будет прописан на роутере подключенном к езернету? :)

 

P.S. У меня используется не epmp, и широковещательного трафика в радио я не наблюдаю.

[magnum50]

40 мбит если и будет то не долго,

а по 10 Мбит/ с можно смело обещать ))) при полосе 40,

но желательно чтобы была прямая видимость и хорошая юстировка

[adron2]

Хочу раздавать инет в частный сектор. Сколько в пике можно выжать из сабжа в 2,4 на расстоянии 1 км при 10 CPE той же модели? Все клиенты почти на одной линии. Тарифы планирую 10, 20 и если хорошо попрёт, 40 мегабит.

 

мой прогноз: минимум 100 мегабит в 40 мгц полосы и 50-60 в 20 мгц.

[Diamont]

Прямая видимость будет. На счёт юстировки, имеет ли смысл вместо еРМР 1000 у клиентов ставить аиргрид м2? Он дешевле и более узконаправленный, но сложнее юстировать.

[rdc]

У них несовместимы протоколы синхронизации. Такая связка может работать только в режиме обычного вайфая.

Обычный вайфай предполагает, что "все слышат всех" - а поскольку в частном секторе клиенты друг друга "не слышат", будут постоянные потери пакетов от клиентов к сектору - они будут одновременно передавать, думая, что эфир чист, и перебивать друг друга.

 

А юстировка никаких проблем не составляет.

[Diamont]

Обычный вайфай и планируется. То, что вы описали может и будет, но на скорость (до 40М на СРЕ) не повлияет.

[rdc]

По мере роста количества клиентов проблема растёт в геометрической прогрессии. В определённой ситуации работа сети может быть вообще парализована.

Пример - один абонент в 200м, другой в 2км. Абонент в 200м начал активно раздавать торренты. Абонент в 2км пытается зайти в одноклассники.

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

 

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

 

И ещё потенциальная проблема.

Я испытывал мост между камбиумом-базой и юбиком-клиентом - работает несколько дней, далее связь рвётся и сама не восстанавливается.

Оба устройства на вид в порядке, вебморды доступны. Перезагрузка юбика не помогает. После перезагрузки камбиума связь восстанавливается.

Глубоко проблему не копал. Версии на момент теста были 2.6.2 и 5.6.4.

[rdc]

Ну десятерых то уж выдержит без ощутимой деградации.

Если база ePMP 1000, а клиенты - гриды, то десятерых не выдержит.

 

Или те кто тут про 60-80 человек на базе еРМР 1000 говорил - звиздуны?

У них клиенты тоже ePMP 1000, работает синхронизация по фирменному протоколу.

[Diamont]

Первые 3 клиента будут тоже на еРМР 1000 без GPS. Для остальных мне придётся делать выбор. Или дорогая еРМР с возможностью использовать не стандартный протокол или дешевый эйргрид М2 с обычной вафлей и минимум помех благодаря узкой ДН.

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

[rdc]

Тогда разумнее будет поставить сразу две базы - имеющуюся ePMP и нанку м2, разнеся их по частотам.

Нанку можно вынести в диапазон 2.3, и гриды цеплять на неё.

Будет исключено "забивание гвоздей микроскопом", всё железо будет жить на родных протоколах.

 

Кстати - если не лень возиться, клиентскую ePMP Integrated можно поставить в фокусе спутниковой антенны.

[rdc]

Кстати, 5ггц litebeam 5ac-23 дешевле грида, и быстрее раза в три.

[Constantin]

У них несовместимы протоколы синхронизации.

чаво чаво????

Также не забываем, что у грида одна модуляция

очередной перл....

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

тоже туда же в перлы

работает синхронизация по фирменному протоколу.

это что же за такая синхронизация то......

 

какой набор умных слов по отдельности не более, вместе такой бред.

[rdc]

это что же за такая синхронизация то

Обычный вайфай работает на основе https://ru.wikipedia.org/wiki/CSMA/CA

Работа CSMA/CA предполагает, что все участники сети находятся в радиовидимости друг друга.

Когда какой-либо из клиентов начинает передачу - другие клиенты это знают, и ждут её окончания.

 

В сетях ШБД полной радиовидимости нет. Сигналы клиентов направлены только на базу.

В случае использования для ШБД обычного WiFi, когда какой-либо из клиентов начинает передачу - другие клиенты об этом не знают, и тоже могут начать передачу.

Из-за этого вероятность потери/перепосылки пакета возрастает в геометрической прогрессии относительно количества клиентов.

Частично это решается механизмом RTS/CTS, но это полумера.

 

Для решения этой проблемы CSMA/CA заменяется на TDMA с помощью проприетарного протокола синхронизации базы и клиентов.

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

И этот протокол у всех вендоров разный, стандарта нет. Если между камбиумами можно включить режим Flexible или TDD, то между камбиумом и убиком будет работать только обычный вайфай.

Причём работать может не очень стабильно - см.выше про зависания канала.

 

Также не забываем, что у грида одна модуляция

Прошу прощения за опечатку.

Одна поляризация, конечно же.

 

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

тоже туда же в перлы

Аргументированные возражения есть?

[Constantin]

Аргументированные возражения есть?

 

а ни че, что клиент авторизован на базе, и по вашему база легко отбросит его как помеху???? это что то новенькое

 

остальную вашу синхронизацию я оставлю без комментариев ))))))

[rdc]

Удивительно, что вы не знаете элементарных вещей.

https://ru.wikipedia.org/wiki/Проблема_скрытого_узла

 

Я по этим граблям ходил ещё 15 лет назад, когда пытался делать многоточку на длинках.

[Constantin]

Удивительно, что вы не знаете элементарных вещей.

https://ru.wikipedia...а_скрытого_узла

 

Я по этим граблям ходил ещё 15 лет назад, когда пытался делать многоточку на длинках.

 

я рад за вас что вы умеете пользоваться поиском и умеете читать, а вот про 2 часть где про 15 лет и тд не верю

ибо длинк был уже IEEE 802.11 а там уже CSMA/CA и проблемма скрытого узла стояла не так уж катастрофично

 

я бы не возмущался если бы как раз 14-15 лет назад не строил вай вай сети , в роли монтажника (а это установка и настройка конечного оборудования у клиента) и тд

там правда не на длинке строили.....))))) а если не изменяет память z-com IEEE 802.11b, Orinoco как IEEE 802.11b так и CLARINET (если правильно написал), и были сектора с 15-20 клиентами и это добро даже довольно сносно работало , конечно для того времени и потери на большом пакете в 2% считалось достаточно нормальным для продакшина

 

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

 

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

[rdc]

Проблемой как раз и были эти потери, за которые абоненты нас чмырили порядочно.

Причём величина потерь плавающая, иногда были сильные всплески.

В итоге решили переделкой сети на p2p мосты.

[adron2]

Проблемой как раз и были эти потери, за которые абоненты нас чмырили порядочно.

Причём величина потерь плавающая, иногда были сильные всплески.

В итоге решили переделкой сети на p2p мосты.

 

ЫЫЫ.

У меня такие isa-шные валяются. турбоцелл на писюках тогда рулил :-)

[m0sia]

Такой вопрос: на сколько можно доверять тесту скорости в ePMP 1000 ? Что он показывает? TCP или UDP ? И на сколько % от его результата можно рассчитывать на деле?

 

UDP. примерно на столько же, на сколько можно рассчитывать при UDP тесте iperf

 

"на деле" - это speedtest.net?

[slv700]

"на деле" - это speedtest.net?

speedtest.net -это тест на TCP пакетах , которые имеют ACK- подтверждение успешной доставки. UDP пакеты не имеют ACK и не учитывают потери.

Скорость на TCP пакетах при высокой надежности канала ( низких потерях) обычно на 7% ( тесты на столе) до 15% ниже скорости UDP тестов. Если потерь пакетов много ( не путать с потерями пингов ), то скорость TCP может быть в 2 и более раз ниже скорости UDP ( но это не у ePMP).

ePMP имеет фичу Link adaptation ( или это также называется AMC - Adaptive Modulation and Coding ), которая выбирает рабочую модуляцию , не позволяя опускаться BER в канале ( потерям) ниже определенного порога . Поэтому разница между скоростью TCP и UDP у ePMP обычно невелика - не превышает 15%. Хотя в отдельных случаях при сильных импульсных и специфических помехах типа, например, коротких малтипасс переотражениях, когда Link adaptation малоэффективен, разница может увеличиваться, но все равно у ePMP редко превышает 30%.

[slv700]

"на деле" - это speedtest.net?

Скорее торренты.

Торренты - это UDP и TCP, причем торрент сам выбирает себе протокол в зависимости от состояния канала. Если идет UDP на плохом канале, то торрент уменьшает длину пакета вплоть до 150 байт, что резко увеличивает пакетную нагрузку в канале, идут большие потери мелких фрагментов данных и переповторы передачи на сессионном L4-L5 уровне работы приложений( торрент), что снижает полезную реальную пропускную способность канала, когда на интерфейсах трафик виден в полке, но на самом деле может наполовину забит переповторами передачи потерянных/поврежденных фрагментов данных.

"На деле" реальную пропускную способность канала показывает сквозной ( через ethernet устройств) TCP тест в 5-10 потоков.

[Diamont]

Вообщем провёл настольный тест по FTP в один поток даунлинк. Условия: засраный эфир 2,4 ггц, расстояние 5 метров через бетонную стену. Режим TDD. Канал 20 мгц - прокачка 8 мб/с. Тоже самое в канале 40 мгц - 10 мб/с, но чуть больше плавает. Я доволен.