[chetkiyparen]

Кто использовал данные точки для построения мостов до 1ГГбит? поделитесь результатами и для чего у них 3 вывода SMA, если для МИМО2*2 нужно 2 разъема?

[bg80211]

1 час назад, chetkiyparen сказал:

Кто использовал данные точки для построения мостов до 1ГГбит? поделитесь результатами и для чего у них 3 вывода SMA, если для МИМО2*2 нужно 2 разъема?

3 Channel ,  если найдете Ite3Xmimo то супер.  1Ггб в теории если тока а в реале до 270-300 TCP/HalDuplex

[chetkiyparen]

я думал на JRC29 EX MIMO подключить эти точки, сейчас там платы 911-е в 40МГц выдают 160-220Мбит full duplex, но куда третий канал задействовать? или есть антенны с 3 channel на 5ГГц для мостов 10км+ ?

 

270-300 TCP/HalDuplex - почему полудуплекс, тем более если трехканальная антенна?

[Saab95]

Надо просто поставить еще комплект антенн с одной поляризацией и повернуть ее на 45 градусов. Дальше надо убавить мощность, что бы свести к минимуму помехи на соседние поляризации. Вполне возможно в режиме N на 40 мгц прокачать мегабит 300-350. Если AC задействовать в 80мгц - то еще больше.

[slv700]

Какие 1 Gbps?  В АС в 40 Мгц Микротик   вытянет в лучшем случае  в идеальных условиях не больше 250-280 Mbps.  В 80 Мгц достаточно небольшой помехи чтобы это толком не работало. 

 Какие 3 чейна?  Третий чейн никогда не работал, нет достаточной развязки по поляризациям  даже если поставить вторую антенну.  Хватит морочить человеку голову. Для точка точка Микротик АС -  сейчас далеко не лучший выбор.

[LostSoul]

40 минут назад, slv700 сказал:

Хватит морочить человеку голову. Для точка точка Микротик АС -  сейчас далеко не лучший выбор.

есть хоть один независимый отзыв, что кто-то поставил на имеющийся p2p вместо микротика ваш cambium и получил более хороший результат?

 

[chetkiyparen]

я все равно камбиум покупать не собираюсь... вопрос в том, стоит ли заморачиваться с этими точками, еще антенны ставить на третий канал полудуплексом или эффективнее 911-е в режиме AC использовать?  Я так понимаю преимущество данных точек по мощности будет, ну так если уровень нормальный и на платах 911-х, то это собственно и не преимущество... 

 

Главная цель из существующего линка точка-точка на 911-е в 40МГц 160-220Мбит full duplex, сделать линк точка-точка на 500/500Мбит

[slv700]

4 часа назад, chetkiyparen сказал:

 

 

Главная цель из существующего линка точка-точка на 911-е в 40МГц 160-220Мбит full duplex, сделать линк точка-точка на 500/500Мбит

Ну какой еще full duplex?  160-220М - это симплекс.  А 500/500 М - на Микротик это невозможно.

Возможно только на Камбиум PTP550 802.11  ac wave 2.

 

6 часов назад, LostSoul сказал:

есть хоть один независимый отзыв, что кто-то поставил на имеющийся p2p вместо микротика ваш cambium и получил более хороший результат?

 

Конечно, любой Камбиум  АС например Force 300 или PTP550    имеет в разы лучший результат по скорости,  чем Микротик АС. Смотрите профильные темы. Независимые отзывы     и дискуссию с  оппонентами - смотрите на украинском форуме локал.ком.ua.  Здесь этого пока нет.

[LostSoul]

42 минуты назад, slv700 сказал:

смотрите на украинском форуме локал.ком.ua. 

спасибо, мне гостей с украины уже тут хватило лет на 10 вперед :-)

 

 

[npokypop]

Может и хороша ваша КОБЫЛА, но дорогая! 

[slv700]

Конечно Микротик дешевле. Но он не дает то, что  нужно.  Сколько выдает Камбиум  -смотреть здесь  

Есть  бюджетные варианты Force 300 с антенной 25дби. Будет  скоро бюджетный Force 300 CSM ( Connectorized). 

Если кто хочет обсудить эти решения перемещайтесь в профильную тему.

[sokrat]

В 26.02.2019 в 22:28, chetkiyparen сказал:

 

 

Главная цель из существующего линка точка-точка на 911-е в 40МГц 160-220Мбит full duplex, сделать линк точка-точка на 500/500Мбит

Как  можно  так  шутить  просидев на форуме 6 лет

[EShirokiy]

покупайте airfiber 5x и забывайте о существовании всяких вайфаев

Работает отлично

[LostSoul]

В 26.02.2019 в 20:52, slv700 сказал:

Ну какой еще full duplex?  160-220М - это симплекс. 

у меня 160-220 half на микротике на 3.5км  даже без всякого AC.

условия достаточно шумные.

Плата RB411GL и дискретное радио 802.11n на AR922X

на ac ,по идее, должно стать лучше

 

 

[EShirokiy]

@LostSoul погоняйте TCP) UDP у меня на Нетметалах тоже показыает по 500 мегабит, но на реальном трафике скорость заметно ниже

[LostSoul]

6 минут назад, EShirokiy сказал:

 погоняйте TCP) UDP у меня на Нетметалах тоже показыает по 500 мегабит, но на реальном трафике скорость заметно ниже

у меня и iprf и speedtest и прочими методиками результаты сильно не отличаются.

tcp тест на таких скоростях просто перегружает процессор среднего микротика в полку.

А так никаких проблем нету и с tcp при правильном размере окна, соответствующем скорости.

 

 

[slv700]

17 минут назад, LostSoul сказал:

у меня и iprf и speedtest и прочими методиками результаты сильно не отличаются.

tcp тест на таких скоростях просто перегружает процессор среднего микротика в полку.

А так никаких проблем нету и с tcp при правильном размере окна, соответствующем скорости.

 

 

А что неизвестно, что любой 802.11n имеет  max 220 Mbps в 40 Мгц UDP пакетами, 160-180Mbps TCP пакетами ( при правильном размере окна), 140-160 Mbps UDP пакетами 700 байт ( средняя длина пакета реального трафика). ? Столько же порядка  max 140Mbps живого трафика пропускает  наиболее популярная  платформа AR9344 из за полки по ппс в 25-30K ( реальной а не накрученной разными фокусами). 

Вам профессор это неизвестно? Если неизвестно, то  что же вам тогда известно,  о чем же вы писали в своих 3609 сообщениях с 2005 года, бредятину?  Также как и сейчас?

ЗЫ

BT Микротик  ( в том числе многоядерный) имеет полку  на TCP  трафике - порядка 350M в симплексе, или UL+DL в дуплексе. Вполне достаточно чтобы правильно  протестить 801.11n

[Saab95]

Если мощность не завышать, то развязки по каналам хватит для третьей антенны. В свое время использовали антенны 3х3 мимо панельные, когда еще AC не было, на 2-3 километра легко 350 мегабит проходило в полосе 40.

[LostSoul]

5 минут назад, slv700 сказал:

max 220 Mbps в 40 Мгц UDP пакетами, 160-180Mbps TCP пакетами

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

 

 

[slv700]

3 минуты назад, LostSoul сказал:

какая вообще транспорту разница, какие там бегают пакеты?

 

UDP не учитывает потери пакетов, TCP -учитывает и при потерях уменьшает размер окна ( количество пакетов в одной посылке) и соответственно  скорость .

 

3 минуты назад, Saab95 сказал:

Если мощность не завышать, то развязки по каналам хватит для третьей антенны. В свое время использовали антенны 3х3 мимо панельные, когда еще AC не было, на 2-3 километра легко 350 мегабит проходило в полосе 40.

Покажите хоть один скрин MIMO 3x3 и скорость 350Mbps. Я никогда этого не видел.

[LostSoul]

6 минут назад, slv700 сказал:

UDP не учитывает потери пакетов

кто вам сказал такую глупость?

Как лично вы, для себя, оправдываете существование "теста скорости", который не учитывал бы потерянные пакеты?

 

вы может быть хотели сказать, что в tcp тесте возможно снижение отображаемой пропускной способности, в сравнении с фактической,  из за задержек , связанных с  повторной доставкой потерянных пакетов.

 

Но в этом ничего фатального нету.  Даже одно приложение может открывать для своих задач несколько tcp-сессий.

Если же мы говорим про канал , построенный под работу множества клиентов - то там никогда и не ставится задачи, чтоб один абонент сожрал 100% полосы магистрали.

 

 

[slv700]

28 минут назад, LostSoul сказал:

Как лично вы, для себя, оправдываете существование "теста скорости", который не учитывал бы потерянные пакеты?

У UDP трафика нет нет ACK- подтверждения успешности доставки пакетов, поэтому там нет ожидания подтверждения доставки и повтора передачи потерянных или искаженных пакетов.

У TCP есть подтверждение  ACK успешности доставки пачки пакетов. Но время ожидания ACK не есть основная причина снижения скорости TCP. Если хоть один пакет в переданной пачке ( окно стека TCP) потерян, то размер пачки уменьшается на один пакет, что снижает скорость  и передача всей пачки пакетов повторяется. Снижение кол-ва пакетов происходит до получения размера пачки, в которой пакеты ( ни один) не теряются и не искажаются. 

Количества сессий TCP -другой вопрос.  Для усреднения результата  и получения близкого к реальному трафику  результата обычно в тесте  запускают 10+ потоков.

[LostSoul]

8 минут назад, slv700 сказал:

Чем больше вы говорите, тем больше убеждаюсь что вы не в теме, профессор еще блин называется.

У UDP трафика нет нет ACK- подтверждения успешности доставки пакетов, поэтому там нет ожидания подтверждения доставки и повтора передачи потерянных или искаженных пакетов.

У TCP есть подтверждение  ACK успешности доставки пачки пактов. Но время ожидания ACK не есть основная причина снижения скорости TCP. Если хоть один пакет в переданной пачке ( окно стека TCP) потерян, то размер пачки уменьшается на один пакет, что снижает скорость  и передача всей пачки пакетов повторяется. Снижение кол-ва пакетов происходит до получения размера пачки, в которой пакеты ( ни один) не теряются и не искажаются.  

Количества сессий TCP -другой вопрос. Обычно запускаю от 10 до 100 сессий.

Вы сейчас реально прикалываетесь что ли?

Вы мне будете про tcp congestion control рассказывать?   :-)

 

Я 6 лет занимался сервисом рассылки файлов через DVB ( без обратной связи вообще, и с таковой ) , а так же ассиметричным спутниковым и эфирным доступом в интернет в москве ( через DVB-T ) .

 

 

У вас конкретно написано "UDP не учитывает потерю пакетов" .  

Это или наглая ложь или полная безграмотность.

 

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

В самом примитивном случае, отправляющей стороне достаточно сказать "отправляю в тебя миллион пакетов, СЧИТАЙ"

разница между отправленным и принятым уже даст количество потерянных пакетов. Без всяких ACK.

 

А теперь смотрим.   Через тест UDP было отправлено 10000 пакетов по 1500 байт , дошло 9995  , 5 потеряно.

Результаты теста : 9995 пакетов в попугай

Через тест TCP за ту же единицу времени "попугай" пытаемся отправить  10000 пакетов ,   5 сегментов данных было отправлено повторно.  Допустим из-за неоптимальной регулировки размера окна ,средний размер сегмента получился на ну скажем 3 пакета.  Итого, нам пришлось 15 пакетов отправлять повторно, за единицу времени "попугай" мы сумели впихнуть в канал 9985 пакетов.

результаты теста: 9985 попугаев

 

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

 

Откуда та обьявленная разница в 22% ?  Ее нету. А если есть, то чаще в пользу TCP написанного самыми лучшими умами сетевого мира, а не UDP теста, написанного кустарями-одиночками с мотором

 

 

[slv700]

Контроль доставки пакетов  UDP, в том числе проверка контрольной суммы происходит на уровне приложений, а не протокола. Но дело даже не в этом. У UDP нет повтора передачи потерянных или искаженных пакетов, как есть у TCP.  

PS

Да приложение знает, что не все пакеты из миллиона дошли. Поэтому приложение, например торрент,  и инициирует повторную передачу. Но этого не происходит  на уровне протокола,, в частности в тесте UDP.

Википедия.

UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.

[LostSoul]

23 минуты назад, slv700 сказал:

Контроль доставки пакетов  UDP, в том числе проверка контрольной суммы происходит на уровне приложений, а не протокола. Но дело даже не в этом. У UDP нет повтора передачи потерянных или искаженных пакетов, как есть у TCP.  

PS

Да приложение знает, что не все пакеты из миллиона дошли. Поэтому приложение, например торрент,  и инициирует повторную передачу. Но этого не происходит  на уровне протокола,, в частности в тесте UDP. 

 

Я никак не пойму вы издеваетесь и толсто троллите или серьёзно?

Про ACK и UDP цитаты из википедии уже были , ждем цитату из книжек Фигурнова , про то как отличить мышку, клавиатуру и системный блок.

 

Да, в протоколе UDP нету контроля доставки ( мы все тут собравшиеся , первый раз об этом слышим )

Но в специализированном ПО для тестирования пропускной способности канала с помощью UDP-датаграмм то оно есть.

Точно так же, как есть и в ПО работающем с RAW пакетами или езернет-кадрами.

И для синхронного последовательного интерфейса с фиксированной скоростью тоже есть тесты.

 

Тестовое ПО для тестирования канала создает симуляцию сетевой нагрузки разной степени сложности и достоверности. 

От простого потока одинаковых пакетов, до симуляции сложного паттерна сетевой активности с иммитацией трафика реальных приложений.

 

С какого перепугу вы решили , будто тест скорости , работающий через UDP и не учитывающий возникшие потери пакетов  , может является ТЕСТОМ?

Если ваш тест не считает потери, то это не тест, а тупо пакетный генератор.