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

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

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

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

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

8745a6da48f7f307b2e7220df904c35f.jpeg

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


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

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

 

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

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

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

что с ccq?

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


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

NewUse

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

57b97ae8428f9937a453b86cea34f09a.jpeg

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

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


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

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

 

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

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

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

что с ccq?

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

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

ЗЫ

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

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


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

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

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


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

Ппс, задержка и джитер убнт/мт зависит от степени агрегации пакетов ( а не от указанной цифры максимума агрегации в конфиге)

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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

 

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

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


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

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

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

 

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

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

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


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

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

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


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

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

 

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

 

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

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


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

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

 

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

 

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

ЗЫ

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

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


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

А в тесте чтобы получить адекватную оценку задержке и надежности канала этот фрейм также надо как то наполнить

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

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

 

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

Join the conversation

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

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

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

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

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

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

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