Jump to content
Калькуляторы

Переход с NanoBridge на MikroTik/NanoBeam - профит?

Имеется мост на 2хNanoBridge M5, заинтересовали новые нанобимы 400, и микротики sxt, в течении ближайшей недели планирую поставить пакинг из микротиков на этот мост, что должно решить проблему с ппс (знаю что у бимов те же проблемы).

На сегодня в час пик ~80/10мбит и соответственно ппс ~8k/8k, если будет не хватать, к осени думал ставить ещё один мост на бриджах, которые лежат в качестве запаски, но задумался о переходе на новую платформу...

Вопрос к знающим, что даст переход на микротики/бимы, конкретно в плане пингов (приведите цифры) под нагрузкой на 100дуплексе, если текущий мост работает так:

8745a6da48f7f307b2e7220df904c35f.jpeg

Share this post


Link to post
Share on other sites

В п2п у НБ с ппс-ом проблем нет: включите агрегацию на максимум и будет Вам счастье.

 

если текущий мост работает так:

А что такой джитер большой? Да и задержка...

у меня не более 7мс под нагрузкой..

что с ccq?

Share this post


Link to post
Share on other sites

NewUse

Агрегация включена:

57b97ae8428f9937a453b86cea34f09a.jpeg

ccq колеблется в зависимости от нагрузки 98.8-100%

Share this post


Link to post
Share on other sites

В п2п у НБ с ппс-ом проблем нет: включите агрегацию на максимум и будет Вам счастье.

 

если текущий мост работает так:

А что такой джитер большой? Да и задержка...

у меня не более 7мс под нагрузкой..

что с ccq?

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

Поэтому, если нанобридж не тянет по ппс, то замена ни на нанобим, ни мт не помогут.

ЗЫ

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

Share this post


Link to post
Share on other sites

УБНТ просто по PPS не тянет, нужно увеличить мту на нем, увеличить мту на железках и включить упаковку. Микротик нормально пропускает через себя транзитом по радио под 60-90 тысяч пакетов.

Share this post


Link to post
Share on other sites
Ппс, задержка и джитер убнт/мт зависит от степени агрегации пакетов ( а не от указанной цифры максимума агрегации в конфиге)

при загруженной магистрали джитер менее 2мс, а никак не 7(можно глянуть athstat, но при ccq 99-100 -- помехи маловероятны)...

Share this post


Link to post
Share on other sites

при загруженной магистрали джитер менее 2мс, а никак не 7(можно глянуть athstat, но при ccq 99-100 -- помехи маловероятны)...

Пусти пинг 1500 и 2097 байт. Увидишь свои 2 мс...

Share this post


Link to post
Share on other sites
Пусти пинг 1500 и 2097 байт. Увидишь свои 2 мс...

блин, при чём здесь размер пакета?

на скрине пинг стандартными пакетами 64 байта...

Share this post


Link to post
Share on other sites
Пусти пинг 1500 и 2097 байт. Увидишь свои 2 мс...

блин, при чём здесь размер пакета?

на скрине пинг стандартными пакетами 64 байта...

Если ты дашь пинг по кабельной сети или на нормальном беспроводном оборудовании, то задержка не будет зависеть от размера пакета . А вот на убнт/мт - будет. Поэтому задержка на стандартном пинге в 64 байта на вайфай -это фейк, что известно, уже лет так 15 всем. Ставь минимум 1470 байт, а лучше 4097 байт ( +1 к размеру A-MSDU -длина которого 5.2 мс ) -это будет правильный результат. А свои 2 мс задержки впаривай пионерам убнт.

Share this post


Link to post
Share on other sites

Если ты дашь пинг по кабельной сети или на нормальном беспроводном оборудовании, то задержка не будет зависеть от размера пакета . А вот на убнт/мт - будет. Поэтому задержка на стандартном пинге в 64 байта на вайфай -это фейк, что известно, уже лет та 15 всем. Ставь минимум 1470 байт, а лучше 4097 байт ( +1 к размеру A-MSDU -длина которого 5.2 мс ) -это будет правильный результат. А свою 2 мс задержки впаривай пионерам убнт.

Какая разница в каких "попугаях" мерить качество канала на одном и том же оборудовании?

Сейчас ведь речь не идёт о сравнении?

7мс джитера при стандартном размере echo-icmp пакета это НЕ нормально для UBNT.

Share this post


Link to post
Share on other sites

Если ты дашь пинг по кабельной сети или на нормальном беспроводном оборудовании, то задержка не будет зависеть от размера пакета . А вот на убнт/мт - будет. Поэтому задержка на стандартном пинге в 64 байта на вайфай -это фейк, что известно, уже лет та 15 всем. Ставь минимум 1470 байт, а лучше 4097 байт ( +1 к размеру A-MSDU -длина которого 5.2 мс ) -это будет правильный результат. А свою 2 мс задержки впаривай пионерам убнт.

Какая разница в каких "попугаях" мерить качество канала на одном и том же оборудовании?

Сейчас ведь речь не идёт о сравнении?

7мс джитера при стандартном размере echo-icmp пакета это НЕ нормально для UBNT.

Стандартным пингом 64 байта качество канала на вайфай никто ( специалисты по крайней мере) не измеряет.

а 7мс джитера на стандартном пакете ненормально в идеальном канале ( на столе). А в реальных условиях 30-50 мс ICMP two way в точка -точка при низкой загрузке канала и отсутствии помех на длинных пингах - норма для убнт.

Share this post


Link to post
Share on other sites
а 7мс джитера на стандартном пакете ненормально в идеальном канале ( на столе). А в рельных условиях 30-50 мс ICMP two way в точка -точка при низкой загрузке канала и отсутствии помех на длинных пингах - норма для убнт.

Где Вы увидели низкую загрузку канала, уже при 10Мбитах пинг на 2км не превышает 7мс, а джитер 2мс -- это уже много, для voip(h323), например, 7мс уже не допустимо.

Share this post


Link to post
Share on other sites

Вы немного неправильно поняли скрин, при нагрузке <40мбит пинг на моём мосте 0,87-3мс (средний 1мс), айвью отключен, ибо с включённым айрвью, при той-же нагрузке канала пинг будет 1-3мс, проверено. На скрине как-бы продемонстрировано какой "реальный" пинг под нагрузкой 95/5мбит. Всем любителям поспорить предлагаю провести эксперимент нагрузите канал под завязку без ограничивающих правил, и посмотрите на средний пинг, потом отключите айрвью на ap и st, и снова проверьте пинги под нагрузкой, даю гарантию, разница будет заметной. Как я понял это связано с тем, что с включённым айрвью пакеты маркируются и имеют приоритет.

Сорри если неясно изложил, или если мои слова покажутся бредом, поэтому допишу имхо

Share this post


Link to post
Share on other sites

блин, при чём здесь размер пакета?

на скрине пинг стандартными пакетами 64 байта...

 

Задержку в радио измеряют пингом 1500 байт. Т.к. пинг 64 байт покажет задержку для пакетов размером 64 байт, а данные передаются обычно пакетами большего размера. Поэтому и получается, что вроде бы пинг маленький, а скорость загрузки информации из интернета маленькая, или спидтест не показывает требуемую скорость.

Share this post


Link to post
Share on other sites

блин, при чём здесь размер пакета?

на скрине пинг стандартными пакетами 64 байта...

 

Задержку в радио измеряют пингом 1500 байт. Т.к. пинг 64 байт покажет задержку для пакетов размером 64 байт, а данные передаются обычно пакетами большего размера. Поэтому и получается, что вроде бы пинг маленький, а скорость загрузки информации из интернета маленькая, или спидтест не показывает требуемую скорость.

Может еще покажешь пруфы на подобную методику измерения, или это твое собственное умозаключение?

Share this post


Link to post
Share on other sites

пардон, а разве всякого рода аггрегации и прочие ухищрения по экономии эиртайма не влияют на пинг больше, чем размер icmp пакета?

Share this post


Link to post
Share on other sites

Если канал свободен, то запуская пинг размером 64 байта, он в радио и передастся кусочком 64 байта и вероятность доставки будет высокая. Если размер 1500, вероятность доставки уже ниже, т.к. больше времени идет передача.

 

Если канал загружен, то кусочек 64 байта влезает в свободное место посылки с помощью агрегации, естественно кусок в 1500 байт туда не влезает, поэтому передается уже опять с меньшей вероятностью доставки.

 

Кроме всего интервал надо ставить 100 или 50, а то и 20 мс. Пинги с интервалом в 1 секунду не несут никакой смысловой нагрузки.

Share this post


Link to post
Share on other sites

Если канал свободен, то запуская пинг размером 64 байта, он в радио и передастся кусочком 64 байта и вероятность доставки будет высокая. Если размер 1500, вероятность доставки уже ниже, т.к. больше времени идет передача.

 

Если канал загружен, то кусочек 64 байта влезает в свободное место посылки с помощью агрегации, естественно кусок в 1500 байт туда не влезает, поэтому передается уже опять с меньшей вероятностью доставки.

 

Кроме всего интервал надо ставить 100 или 50, а то и 20 мс. Пинги с интервалом в 1 секунду не несут никакой смысловой нагрузки.

Сколько % в реальном трафике пакетов размером 1500 и выше?

Share this post


Link to post
Share on other sites

Сколько % в реальном трафике пакетов размером 1500 и выше?

Пингом 1500 тестируется канал. Это размер обычного ethernet пакета, который далее пакуется на радиоинтерфейсе в фрейм A-MSDU ( 4096 байт )и более A-MPDU ( 64 байта). Тем самым устройства 802.11n правильно тестировать даже не размером ethernet пакета 1500 байт, а пакетами 4096 байт. Реальный трафик, какие бы мелкие пакеты не были, пакуется в 802.11n в эти фреймы и как они проходят в радио - и покажет этот пинг. То есть размером пакета пинга желательно достичь максимальной упаковки- это даст реальную задержку и реальную надежность ( потери пакетов) канала на длинных фреймах.

Share this post


Link to post
Share on other sites

Профиль реального трафика:

http://www.caida.org/data/passive/trace_stats/

1500 там как-то и не пахнет, средний размер пакета 700байт...

Да это коню ясно! Речь идет о тестировании wireless канала, который на реальном трафике работает на пакетах max 4096 байт. В реальной сети несколько мелких пакетов c Ethernet могут наполнить по максимуму этот фрейм.

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

ЗЫ

Вообще то утилита пинг не для этого придумана. Но для тестирования wireless канала она оказалась полезной. При этом простой пинг также применяется для проверки достижимости удаленного абонента. А вот длинными пакетами и флуд пингом можно также оценить задержку и надежность ( правда неточно, но сойдет). Короткий пинг для этого менее информативен.

Share this post


Link to post
Share on other sites
А в тесте чтобы получить адекватную оценку задержке и надежности канала этот фрейм также надо как то наполнить

Зачем? Это должна делать агрегация, необходимо и достаточно загрузить канал.

Не очень понимаю, от куда взялась длина 4096, это максимальный размер одного MSDU-саб-фрейма, если не ошибаюсь, но он может менятся, и если в сити нет поддержки Jumbo-frames, то они не достигают такой длины, или я не прав, при этом они "склеиваются" в один A-MSDU?

 

Наиболее полную информацию о канале можно получить на ubnt с помощью утилиты athstat...

Share this post


Link to post
Share on other sites

Зачем? Это должна делать агрегация, необходимо и достаточно загрузить канал.

Как ты собрался пингом 64 байт раз в секунду наполнить фрейм?

е очень понимаю, от куда взялась длина 4096, это максимальный размер одного MSDU-саб-фрейма, если не ошибаюсь, но он может менятся

Максимальный размер фрейма агрегации A-MSDU по стандарту 4096 или 8192 байт. Если пингать канал стандартным пакетом, то этот фрейм ходит по радио почти пустым. А вот если его заполнить - на что нужно время и передать полным, то вероятность искажения ( потери) длинного заполненного фрейма будет намного выше , чем короткого.

Ясно же, что задержка на стандартном пинге и длинном на убнт/мт отличаются в разы. Именно потому , что длинный пакет заполняет фрейм, на что нужно время.

Точно также микротик в Nstreme с агрегацией max 3200 байт и в 802.11 a/g и в "n" задержка стандартного пинга будет отличаться от длинного. Какой цифре задержки верить ? Ясно- задержке от длинного пинга.

А вот если пропингать проводную ЛВС то задержка на коротком и длинном пинге будет одинакова.

Тоже самое если пропингать канал точка-точка на Камбиум ePMP 1000, то там также в точка-точка не будет существенной разницы в задержке на длинном и коротком пинге ( разница будет 5 мс - длина фрейма ePMP), потому что в ePMP нет агрегации.

И кстати, от этой агрегации ( в ее неоптимальном размере и неоптимальном размещении CRC и ACK в фреймах) - причина половины всех бед убнт/мт. Поэтому тестировать канал на убнт/мт ,чтобы иметь представление о реальной задержке и надежности канала, надо именно длинными пингами. А тест стандартным пингом на убнт/mt- фейк, мало о чем говорит.

Share this post


Link to post
Share on other sites

Какой смысл сравнивать фиксированный фрейм с динамическим?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this