Перейти к содержимому
Калькуляторы

Осторожно Wi-Fi! Вернемся к больной теме. Сколько абонентов может работать на одной БС

Сорри, господа за то, что я в очередной раз цитирую Вас и самого себя. Причина банальная - слишком много вопросов от новичков в личку о том, "почему так мало, написанно же много" - да, я все еще о классическом вайфае. Складывается ощущение, что сколько тему не обсуждай, торгаши все равно побеждают логику впаривая вайфай как абсолютное, халявное и 100% рабочее решение для пиратско-провайдерского решения последней мили. Посколько пару лет назад сам очень сильно обжегся на этом, в очередной раз предупреждаю:

Внимание! Дочитайте до конца! Классический" Wi-Fi мало пригоден как решение операторского класса, в силу общей для всего стандарта болезни - CSMA/CD

(стандарт 802.3 - множественный доступ с контролем несущей и обнаружением коллизий) доставшейся в наследство от Ethernet. Так вот проблема "обнаружения коллизий" а также их предотвращения и является не решаемой в задаче операторского класса. Дело тут в том, что БС (или как принято называть Точка Доступа - ТД или англ. AP) работает в "общем доступе" по отношению ко всем абонентам, как хабы в локальной сети. Да, именно как хабы. Т.е. она (AP) посылает пакеты в эфир всем и получает пакеты тоже от всех Клиентов (или Станций англ. Station), без коммутации. Причем, по сути в монопольном доступе, т.е. если не используется OFDM, то весь канал занимает ОДИН абонент. И когда АР отправляет пакет в эфир, то все нормально - кому из Клиентов не нужно, тот и не примет, а вот когда АР принимает пакеты от Клиентов, вот тут и начинается "бермудский треугольник". Собственно коллизии - есть процесс сталкивания встречных потоков. Т.е. идущих от БС и к БС. А сталкиваются они по одной причине - БС не управляет процессом приема-передачи пакетов, за нее это должны сделать сами Клиенты, согласовав монопольные временные слоты (тайм-слоты) на отправку пакетов в сторону БС (на прием согласование не требуется в большинстве стандартов). И все бы работало, но это как минимум подразумевает некий "тесный контакт" между всеми Клиентами. Согласны? Ведь им (Клиентам) нужно как-то согласовать между собой время, так чтобы БС в согласовании участия не принимала, потому что у АР и так работы хватает - нужно принять одни пакеты от множества Клиентов, которые они ей согласованно скормили и передать им целую кучу их пакетов, причем пачками, там сами разберутся кому что предназначалось. Так почту в армии приносят. И вот АР наконец разобравшись с пачкой пакетов снова готова принять, но только от КАЖДОГО Клиента и только по ОЧЕРЕДИ, для этого она посылает короткий сигнал, который означает "Я свободна на прием" всем Клиентам, и получив этот маяк, самый "сильный" Клиент (клиент с наиболее сильным уровнем сигнала) сразу начинает отправку своих пакетов, другие обязаны проверить, свободен ли эфир, и по логике, обнаружив, что уже вещает "сильный" Клиент дожидаться своей очереди пока эфир освободиться. Т.е. каждый Клиент должен "слышать" весь эфир чтобы согласованно отправить свои пакеты. А как они могут видеть друг-друга, они же у нас на значительном расстоянии друг от друга, да еще и с направленными антеннами в сторону БС? Правильно, никак. Каждый из них, проверяя эфир, не слышит соседа и потому искренне уверен что его очередь наступила и эфир свободен для него, начинает передачу, причем все активные Клиенты могут начать одновременную передачу пакетов. Но, по БС может принять только от одного Клиента, потому как одновременная передача превращает 2 разных пакета в одной физической среде в простой "цифровой шум", лишенный всякого смысла. БС в этом случае отбрасывает пакеты и делает запрос на повторную отправку, причем не факт, что в этот момент не идет передача в сторону БС, повторный запрос либо уничтожается встречным потоком, либо доходит до Клиентов и они заново отправляют тот же самый пакет. И так до бесконечности. В целом эфир превращается в хаос или попросту в цифровой шум. Естественно ни о какой нормальной работе при таком хаосе речи быть не может.

Кроме основной проблемы согласования передачи существуют еще и побочные - одна из них это "несправедливый" метод самовольной монополии для "сильного" Клиента. Т.е. "сильный" Клиент быстро захватывает в монопольный режим БС, и не торопится его отдавать конкурентам. И Вам очень повезет, если "сильным" Клиентом окажется абонент, который изредка обновляет страницы, и ОЧЕНЬ не повезет, если это будет заядлый качок с торрентов, т.к. торренты вообще любят захватывать всю доступную монополию в силу конструктивных особенностей и многопоточности.

Было предложено некоторое решение, которое в теории должно было бы частично решать эту проблему, а именно механизм RTS/CTS (Request To Send / Clear To Send, Запрос на отправку/Разрешение отправки) принцип работы которого прост: Клиент посылает свое скромное "А можно я отправлю пакет" (в "продвинутых" версиях указывается еще и размер пакета), а БС, если не занята, отвечает на него "Давай, только быстро", а Клиенты, которые не отправляли запрос RTS, воспринимают полученный CTS как "Заткнуться и ждать!" Но, метод абсолютно не эффективен по нескольким причинам: во-первых, хаос настает задолго до активации этого "защитного" механизма в силу отправки пакетов более мелкой величины, во-вторых, сразу несколько станций отправляют RTS и если хотя бы один дойдет до БС, и БС ответит на него CTS, то все станции отправившие RTS получат по сути сигнал для отправки, результат - сами понимаете, в-третьих, в общем "цифровом шуме" скромный возглас БС в виде CTS просто затеряется и не дойдет до большинства Клиентов. Так что в целом этот метод не то что не решает проблемы, а скорее ее еще больше усугубляет.

На моей личной практике такой хаос и позиция "сильного" Клиента приводит к тому, что больше 15 абонентов "посадить" на 1 сектор БС не представляется возможным, и даже это количество не гарантирует какой-либо стабильности, т.к. есть еще неоднородность трафика и помехи разного рода, в т.ч. и от соседних секторов собственной же станции. Причем, разнос у секторов как правило, совсем не большой и они сильно фонят друг на друга, так что иногда 15 абонентов - это предел на всю станцию, а даже не на сектор. Я думаю в этой части я дал достаточно полный ответ на вопрос почему никто не может сказать сколько абонентов может работать на БС. Ответ очевиден - гарантированно 2-4, остальное - как повезет.

Именно по этой причине "классический" Wi-Fi во всех его стандартах абсолютно не пригоден для решения последней мили. Однако, это касается исключительно PtMP варианта, а вот по PtP нареканий у меня по нему нет, только похвала. Так что для соединения в режиме "мост" или просто "точка-точка" можете смело использовать в равной степени как (а,б,g,n) стандарты.

 

Еще дополнение: Не стоит путать вайфай и поствайфай. Поствайфай - микротик с включенным Nstream (Nv2) или UBNT серии M со включенным Airmax'oм показывают совершенно другие результаты, так как в них решены проблемы CSMA/CD посредством реализиции поллинга!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно и на стандартном вайфае работать и подключать 30 и более клиентов, но это настолько трудоемкая операция, требующая монтажников очень высокой квалификации, но и она обречена на провал, как только появляются помехи от других сетей.

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно и на стандартном вайфае работать и подключать 30 и более клиентов, но это настолько трудоемкая операция, требующая монтажников очень высокой квалификации, но и она обречена на провал, как только появляются помехи от других сетей.

 

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

 

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

 

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

Это все очень красиво звучит, но где Ваша сеть на вимаксе? Вы ее до сих пор как я понимаю планируете, всем советуете, но не эксплуатируете.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сорри, господа за то, что я в очередной раз цитирую Вас и самого себя. Причина банальная - слишком много вопросов от новичков в личку о том, "почему так мало, написанно же много" - да, я все еще о классическом вайфае. Складывается ощущение, что сколько тему не обсуждай, торгаши все равно побеждают логику впаривая вайфай как абсолютное, халявное и 100% рабочее решение для пиратско-провайдерского решения последней мили. Посколько пару лет назад сам очень сильно обжегся на этом, в очередной раз предупреждаю:

Внимание! Дочитайте до конца! Классический" Wi-Fi мало пригоден как решение операторского класса, в силу общей для всего стандарта болезни - CSMA/CD

(стандарт 802.3 - множественный доступ с контролем несущей и обнаружением коллизий) доставшейся в наследство от Ethernet. Так вот проблема "обнаружения коллизий" а также их предотвращения и является не решаемой в задаче операторского класса. Дело тут в том, что БС (или как принято называть Точка Доступа - ТД или англ. AP) работает в "общем доступе" по отношению ко всем абонентам, как хабы в локальной сети. Да, именно как хабы. Т.е. она (AP) посылает пакеты в эфир всем и получает пакеты тоже от всех Клиентов (или Станций англ. Station), без коммутации. Причем, по сути в монопольном доступе, т.е. если не используется OFDM, то весь канал занимает ОДИН абонент. И когда АР отправляет пакет в эфир, то все нормально - кому из Клиентов не нужно, тот и не примет, а вот когда АР принимает пакеты от Клиентов, вот тут и начинается "бермудский треугольник". Собственно коллизии - есть процесс сталкивания встречных потоков. Т.е. идущих от БС и к БС. А сталкиваются они по одной причине - БС не управляет процессом приема-передачи пакетов, за нее это должны сделать сами Клиенты, согласовав монопольные временные слоты (тайм-слоты) на отправку пакетов в сторону БС (на прием согласование не требуется в большинстве стандартов). И все бы работало, но это как минимум подразумевает некий "тесный контакт" между всеми Клиентами. Согласны? Ведь им (Клиентам) нужно как-то согласовать между собой время, так чтобы БС в согласовании участия не принимала, потому что у АР и так работы хватает - нужно принять одни пакеты от множества Клиентов, которые они ей согласованно скормили и передать им целую кучу их пакетов, причем пачками, там сами разберутся кому что предназначалось. Так почту в армии приносят. И вот АР наконец разобравшись с пачкой пакетов снова готова принять, но только от КАЖДОГО Клиента и только по ОЧЕРЕДИ, для этого она посылает короткий сигнал, который означает "Я свободна на прием" всем Клиентам, и получив этот маяк, самый "сильный" Клиент (клиент с наиболее сильным уровнем сигнала) сразу начинает отправку своих пакетов, другие обязаны проверить, свободен ли эфир, и по логике, обнаружив, что уже вещает "сильный" Клиент дожидаться своей очереди пока эфир освободиться. Т.е. каждый Клиент должен "слышать" весь эфир чтобы согласованно отправить свои пакеты. А как они могут видеть друг-друга, они же у нас на значительном расстоянии друг от друга, да еще и с направленными антеннами в сторону БС? Правильно, никак. Каждый из них, проверяя эфир, не слышит соседа и потому искренне уверен что его очередь наступила и эфир свободен для него, начинает передачу, причем все активные Клиенты могут начать одновременную передачу пакетов. Но, по БС может принять только от одного Клиента, потому как одновременная передача превращает 2 разных пакета в одной физической среде в простой "цифровой шум", лишенный всякого смысла. БС в этом случае отбрасывает пакеты и делает запрос на повторную отправку, причем не факт, что в этот момент не идет передача в сторону БС, повторный запрос либо уничтожается встречным потоком, либо доходит до Клиентов и они заново отправляют тот же самый пакет. И так до бесконечности. В целом эфир превращается в хаос или попросту в цифровой шум. Естественно ни о какой нормальной работе при таком хаосе речи быть не может.

Кроме основной проблемы согласования передачи существуют еще и побочные - одна из них это "несправедливый" метод самовольной монополии для "сильного" Клиента. Т.е. "сильный" Клиент быстро захватывает в монопольный режим БС, и не торопится его отдавать конкурентам. И Вам очень повезет, если "сильным" Клиентом окажется абонент, который изредка обновляет страницы, и ОЧЕНЬ не повезет, если это будет заядлый качок с торрентов, т.к. торренты вообще любят захватывать всю доступную монополию в силу конструктивных особенностей и многопоточности.

Было предложено некоторое решение, которое в теории должно было бы частично решать эту проблему, а именно механизм RTS/CTS (Request To Send / Clear To Send, Запрос на отправку/Разрешение отправки) принцип работы которого прост: Клиент посылает свое скромное "А можно я отправлю пакет" (в "продвинутых" версиях указывается еще и размер пакета), а БС, если не занята, отвечает на него "Давай, только быстро", а Клиенты, которые не отправляли запрос RTS, воспринимают полученный CTS как "Заткнуться и ждать!" Но, метод абсолютно не эффективен по нескольким причинам: во-первых, хаос настает задолго до активации этого "защитного" механизма в силу отправки пакетов более мелкой величины, во-вторых, сразу несколько станций отправляют RTS и если хотя бы один дойдет до БС, и БС ответит на него CTS, то все станции отправившие RTS получат по сути сигнал для отправки, результат - сами понимаете, в-третьих, в общем "цифровом шуме" скромный возглас БС в виде CTS просто затеряется и не дойдет до большинства Клиентов. Так что в целом этот метод не то что не решает проблемы, а скорее ее еще больше усугубляет.

На моей личной практике такой хаос и позиция "сильного" Клиента приводит к тому, что больше 15 абонентов "посадить" на 1 сектор БС не представляется возможным, и даже это количество не гарантирует какой-либо стабильности, т.к. есть еще неоднородность трафика и помехи разного рода, в т.ч. и от соседних секторов собственной же станции. Причем, разнос у секторов как правило, совсем не большой и они сильно фонят друг на друга, так что иногда 15 абонентов - это предел на всю станцию, а даже не на сектор. Я думаю в этой части я дал достаточно полный ответ на вопрос почему никто не может сказать сколько абонентов может работать на БС. Ответ очевиден - гарантированно 2-4, остальное - как повезет.

Именно по этой причине "классический" Wi-Fi во всех его стандартах абсолютно не пригоден для решения последней мили. Однако, это касается исключительно PtMP варианта, а вот по PtP нареканий у меня по нему нет, только похвала. Так что для соединения в режиме "мост" или просто "точка-точка" можете смело использовать в равной степени как (а,б,g,n) стандарты.

 

Еще дополнение: Не стоит путать вайфай и поствайфай. Поствайфай - микротик с включенным Nstream (Nv2) или UBNT серии M со включенным Airmax'oм показывают совершенно другие результаты, так как в них решены проблемы CSMA/CD посредством реализиции поллинга!

Это все верно и известно специалистам с 1997 года. Однако есть и определенные моменты, которые получили уточнение. Раньше я лично считал что wifi в малтипойнт ( хотя бы на трех клиентах) деградирует при наличии uplink трафика от хотя бы одного "сильного" клиента ( находящего в hidden node и монопольно захватывающего ресурс базы) порядка 128-256 Mbps на data rate 11 Mbps ( реально в эзере до 5 Mbps )- то есть примерно 5% от пропускной способности канала. Сейчас получается что на 54 Mbps ( 27 Mbps в эзере - в стандартном wifi ) эта критичная величина достигает 1.5-2 mbps uplink - те же 5% ( то есть критическая точка не абсолютная а отностительная величина). В стандарте 802.11n на data rate 135 Mbps ( в канале 20 Мгц ) в малтипойнт MIMO в эзере где то max 40-50 Mbps -это критичная величина в uplink может составить, если это ПРЕДПОЛОЖЕНИЕ верно порядка 2-2.5 Mbps.

При этом если есть на базе хотя бы ОДИН слабый клиент с низкой модуляцией, то вероятность монопольного захвата ресурсов у сильного клиента возрастает на более низком uplink трафике.

Теперь что касается точка-точка. Тут есть два момента.

1) низкая пакетная производительность канала wifi. Теоретический предел на wifi - порядка 6-8K pps. Она не может быть выше даже если использовать ПК. Это также было замечено лет 12 назад. Ставят люди канал , мерят "прокачку" FTP - типа все нормально, пускают реальный трафик ( где сидят 200 юзеров) канал проседает. Ответ был найдет очень быстро. Много юзеров, много сессий,много коротких пакетов ведут к деградации канала wi-fi в PTP.

Тогда стали использовать поствафай - с програмной агрегацией пакетов, что позволило ( тогда в начаде 2000 гг) решить проблему коротких пакетов и низкого ппс. Также применяли народные средства - ставили ПК с linих/bsd и использовали например туннели, где пакеты агрегировались ( инкапсулировались в суперфреймы), что также как то решало вопрос ппс за бесплатно ( поствайфай стоил денег)

2) повышение ппс путем агрегации снижает помехоустойчивость. Чем больше фрейм -тем больше вероятность его потери при помехах.

В этом одна из причин низкой помехоустойчивости поствайфай ( про помехоустойчивость вайфай вообще не говорим )и зависимости задержки о чистоты эфира. В поствайфай было экпериментально установленао что длина суперфрейма агрегации не должна превышать 2048 (3200 уже многовато) байт, иначе даже при малейшей помехе идет деградация. А новом стандарте 802.11n длина суперфрейма 4-8K байт. Это дает высокий ппс порядка 28K pps,но при этом помехоустойчивость никудышная.

Поэтому тезис о том что вайфай и поствайфай - хорошее средство для канала точка -точка ОПЕРАТОРСКОГО КЛАССА - не выдерживает критики. Для пионеров -да , но не более.

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

 

Про поллинг в малтипойнт на базе вайфай типа Nstreme, Airmax, Outdoor router и т.п. -разговор отдельный. Это тоже решение для пионеров и в серьезных сетях он "плывет и сыпется". Чем правильней сделан поллинг ( как например в outdoor router протоколе -от которого это все и пошло), тем больше ему нужно ресурсов и тем дороже оборудование способное поллинг держать в реалтайме при высоких нагрузках.

С появлением торрентов и все большим преобладанием мультисервисного трафика ( голос, видео, игры и др)ни вайфай ни поствайфай в малтипойнт в более менее серьзных сетях вообще не справляется с трафиком и клиентами. Что касается особо продвинутого поствайфай ( превимакс ) то и там также ситуация на пределе - не тянет перегрузы современного трафика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Многабуков!

 

Разбейте свой опус хотя бы на абзацы, читать невозможно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

начальство дало задание - разработать сеть для частного сектора. решил выбрать в качестве базовых станций две Rocket M2 с панелями на 120 градусов а в качестве клиентских - Nanostation M2. Расстояния небольшие - в пределах 2-3 км. Планируется установить антенны на многоэтажку, стоящую возле частного сектора. Возник ряд вопросов:

1) жизнеспособна ли схема?

2) максимальное число абонентов на БС?

3) протокол TDMA спасает от вышеописанных трудностей?

П.С. в построении wi-fi сетей я чайник.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1) жизнеспособна ли схема?

Скорее нет, чем да.

 

2) максимальное число абонентов на БС?

10-15.

 

3) протокол TDMA спасает от вышеописанных трудностей?

Спасет, только в наносах его нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

начальство дало задание - разработать сеть для частного сектора. решил выбрать в качестве базовых станций две Rocket M2 с панелями на 120 градусов а в качестве клиентских - Nanostation M2. Расстояния небольшие - в пределах 2-3 км. Планируется установить антенны на многоэтажку, стоящую возле частного сектора. Возник ряд вопросов:

1) жизнеспособна ли схема?

2) максимальное число абонентов на БС?

3) протокол TDMA спасает от вышеописанных трудностей?

П.С. в построении wi-fi сетей я чайник.

 

Только заменить 120 на 90 если не хватит поставить две.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3) протокол TDMA спасает от вышеописанных трудностей?

Спасет, только в наносах его нет.

 

AirMax же эмулирует TDMA программно, хоть и примитивно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3) протокол TDMA спасает от вышеописанных трудностей?

Спасет, только в наносах его нет.

 

AirMax же эмулирует TDMA программно, хоть и примитивно?

Делает вид. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Делает вид. ;)

10 клиентов же вытягивает нормально.

Видел тут кто-то 56 умудрился посадить (на рокет)... вообще каким чудом)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так не читаите

 

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

 

Вместо этого получайте с лопатки на вентилятор :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

 

Если такая статья будет - у нага сразу продажи наносов упадут=)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Делает вид. ;)

10 клиентов же вытягивает нормально.

Видел тут кто-то 56 умудрился посадить (на рокет)... вообще каким чудом)))

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

Ставить сеть на вайфай -это всегда большой риск. Маленькая сеть- риск меньше и потерь при неудаче меньше тем более если сетка нелегальная. Поэтому строители нелегальных сетей в селах на 10-15 абонентов и есть основной контингент потребителей наносов-рокетов. Добро пожаловать в клуб любителей наносов !

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

лучше уж база МТик с R52n и клиенты с SiXtами

в NV2 будет лучше, чем с наносами

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

 

Если такая статья будет - у нага сразу продажи наносов упадут=)

А продажи максбриджей сразу возрастут, мечтайте далее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ИМХО nstream надёжнее nv2...Пинги меньше-стабильность выше...Но это лично по моему опыту-может у кого-то наоборот...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ИМХО nstream надёжнее nv2...Пинги меньше-стабильность выше...Но это лично по моему опыту-может у кого-то наоборот...

Я тоже склоняюсь к такому мнению. Причина похоже кроется в том что нв2 допиливают в режиме "быстро-быстро", надо идти в ногу со всеми. Отсюда и такая работа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

 

Если такая статья будет - у нага сразу продажи наносов упадут=)

А продажи максбриджей сразу возрастут, мечтайте далее.

На самом деле большинству любителям наносов все равно какое качество каналов связи -лишь бы связь была но за минимимальную плату. Их юзер готов терпеть ( ПОКА) почти любые проблемы работы на вайфай лишь бы цена была демпинговая типа 300 руб анлим в месяц.

Поэтому для них имеет значение только цена, все остальные технологические заморочки -это не для них.

Есть такой термин -"дешевая услуга". Она в кризис стала доминантой и не только в телекоме. Наинизшая цена достигается любой ценой - нелегальной сетью и вплоть до полного отсутствия у услуги качества. Это и достигается на вайфай. И следует признать что ubnt на этом как нельзя вовремя ( со втрой половины 2008 г) и сыграл.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ИМХО nstream надёжнее nv2...Пинги меньше-стабильность выше..

 

пинги меньше, это да, а вот стабильность у меня наоборот, при Нстриме точка со слабым сигналом посоянно отваливается, на НВ2 нет, да и скорости при НВ2 повыше

ветка 5.4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ИМХО nstream надёжнее nv2...Пинги меньше-стабильность выше...Но это лично по моему опыту-может у кого-то наоборот...

 

NV2 лучше, быстрее, стабильнее только в условиях отсутствия помех и интерференции.

 

В Nstreme применяется последовательный опрос каждого клиента, поэтому если что не так сразу следует переповтор. NV2 же использует групповой поллинг, и если клиент не смог принять данные от БС несколько раз подряд, то ему нужно затратить время на повторный вход в сеть с использованием конкурентного доступа для получения таймслотов для себя. И пока разработчики микротика не набьют шишек на этом, нормально протокол в условиях города не заработает. Собственно больше никаких проблем в нем нет.

 

Поэтому для дистанций менее 3-4км., при условии что большинство клиентов слышат друг друга, NV2 все же будет предпочтительнее. В других случаях стоит использовать Nstreme, ну и конечно же периодически обновлять версию ОС и пробовать переключать в NV2=)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

NV2 лучше, быстрее, стабильнее только в условиях отсутствия помех и интерференции.

 

Поясните общественности, чем отличаются помехи от интерференции.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

NV2 лучше, быстрее, стабильнее только в условиях отсутствия помех и интерференции.

 

Поясните общественности, чем отличаются помехи от интерференции.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

NV2 лучше, быстрее, стабильнее только в условиях отсутствия помех и интерференции.

 

Поясните общественности, чем отличаются помехи от интерференции.

 

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

А интерференцию в городе словить никак, а помеху в глухом таежном поселке? :))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.