Gamabunta Posted July 4, 2014 · Report post Имеется мост на 2хNanoBridge M5, заинтересовали новые нанобимы 400, и микротики sxt, в течении ближайшей недели планирую поставить пакинг из микротиков на этот мост, что должно решить проблему с ппс (знаю что у бимов те же проблемы). На сегодня в час пик ~80/10мбит и соответственно ппс ~8k/8k, если будет не хватать, к осени думал ставить ещё один мост на бриджах, которые лежат в качестве запаски, но задумался о переходе на новую платформу... Вопрос к знающим, что даст переход на микротики/бимы, конкретно в плане пингов (приведите цифры) под нагрузкой на 100дуплексе, если текущий мост работает так: Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 4, 2014 · Report post В п2п у НБ с ппс-ом проблем нет: включите агрегацию на максимум и будет Вам счастье. если текущий мост работает так: А что такой джитер большой? Да и задержка... у меня не более 7мс под нагрузкой.. что с ccq? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Gamabunta Posted July 4, 2014 · Report post NewUse Агрегация включена: ccq колеблется в зависимости от нагрузки 98.8-100% Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 4, 2014 · Report post а top в час-пик что показывает? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
slv700 Posted July 4, 2014 · Report post В п2п у НБ с ппс-ом проблем нет: включите агрегацию на максимум и будет Вам счастье. если текущий мост работает так: А что такой джитер большой? Да и задержка... у меня не более 7мс под нагрузкой.. что с ccq? У тебя так ,а у меня не так.... У всех по разному. Ппс, задержка и джитер убнт/мт зависит от степени агрегации пакетов ( а не от указанной цифры максимума агрегации в конфиге) и не зависит от мощности проца ( бриджа или бима). А это в свою очередь зависит от профиля трафика, дальности, и главное помех ( внешних ) и от своего собственного сигнала -переотражений в NearLOS. Поэтому, если нанобридж не тянет по ппс, то замена ни на нанобим, ни мт не помогут. ЗЫ Повышение максимального размера фрейма агрегации в условиях помех делает и ппс и скорость только хуже. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted July 4, 2014 · Report post УБНТ просто по PPS не тянет, нужно увеличить мту на нем, увеличить мту на железках и включить упаковку. Микротик нормально пропускает через себя транзитом по радио под 60-90 тысяч пакетов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 4, 2014 · Report post Ппс, задержка и джитер убнт/мт зависит от степени агрегации пакетов ( а не от указанной цифры максимума агрегации в конфиге) при загруженной магистрали джитер менее 2мс, а никак не 7(можно глянуть athstat, но при ccq 99-100 -- помехи маловероятны)... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
slv700 Posted July 4, 2014 · Report post при загруженной магистрали джитер менее 2мс, а никак не 7(можно глянуть athstat, но при ccq 99-100 -- помехи маловероятны)... Пусти пинг 1500 и 2097 байт. Увидишь свои 2 мс... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 4, 2014 · Report post Пусти пинг 1500 и 2097 байт. Увидишь свои 2 мс... блин, при чём здесь размер пакета? на скрине пинг стандартными пакетами 64 байта... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
slv700 Posted July 4, 2014 · Report post Пусти пинг 1500 и 2097 байт. Увидишь свои 2 мс... блин, при чём здесь размер пакета? на скрине пинг стандартными пакетами 64 байта... Если ты дашь пинг по кабельной сети или на нормальном беспроводном оборудовании, то задержка не будет зависеть от размера пакета . А вот на убнт/мт - будет. Поэтому задержка на стандартном пинге в 64 байта на вайфай -это фейк, что известно, уже лет так 15 всем. Ставь минимум 1470 байт, а лучше 4097 байт ( +1 к размеру A-MSDU -длина которого 5.2 мс ) -это будет правильный результат. А свои 2 мс задержки впаривай пионерам убнт. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 4, 2014 · Report post Если ты дашь пинг по кабельной сети или на нормальном беспроводном оборудовании, то задержка не будет зависеть от размера пакета . А вот на убнт/мт - будет. Поэтому задержка на стандартном пинге в 64 байта на вайфай -это фейк, что известно, уже лет та 15 всем. Ставь минимум 1470 байт, а лучше 4097 байт ( +1 к размеру A-MSDU -длина которого 5.2 мс ) -это будет правильный результат. А свою 2 мс задержки впаривай пионерам убнт. Какая разница в каких "попугаях" мерить качество канала на одном и том же оборудовании? Сейчас ведь речь не идёт о сравнении? 7мс джитера при стандартном размере echo-icmp пакета это НЕ нормально для UBNT. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
slv700 Posted July 4, 2014 · Report post Если ты дашь пинг по кабельной сети или на нормальном беспроводном оборудовании, то задержка не будет зависеть от размера пакета . А вот на убнт/мт - будет. Поэтому задержка на стандартном пинге в 64 байта на вайфай -это фейк, что известно, уже лет та 15 всем. Ставь минимум 1470 байт, а лучше 4097 байт ( +1 к размеру A-MSDU -длина которого 5.2 мс ) -это будет правильный результат. А свою 2 мс задержки впаривай пионерам убнт. Какая разница в каких "попугаях" мерить качество канала на одном и том же оборудовании? Сейчас ведь речь не идёт о сравнении? 7мс джитера при стандартном размере echo-icmp пакета это НЕ нормально для UBNT. Стандартным пингом 64 байта качество канала на вайфай никто ( специалисты по крайней мере) не измеряет. а 7мс джитера на стандартном пакете ненормально в идеальном канале ( на столе). А в реальных условиях 30-50 мс ICMP two way в точка -точка при низкой загрузке канала и отсутствии помех на длинных пингах - норма для убнт. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 4, 2014 · Report post а 7мс джитера на стандартном пакете ненормально в идеальном канале ( на столе). А в рельных условиях 30-50 мс ICMP two way в точка -точка при низкой загрузке канала и отсутствии помех на длинных пингах - норма для убнт. Где Вы увидели низкую загрузку канала, уже при 10Мбитах пинг на 2км не превышает 7мс, а джитер 2мс -- это уже много, для voip(h323), например, 7мс уже не допустимо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Gamabunta Posted July 4, 2014 · Report post Вы немного неправильно поняли скрин, при нагрузке <40мбит пинг на моём мосте 0,87-3мс (средний 1мс), айвью отключен, ибо с включённым айрвью, при той-же нагрузке канала пинг будет 1-3мс, проверено. На скрине как-бы продемонстрировано какой "реальный" пинг под нагрузкой 95/5мбит. Всем любителям поспорить предлагаю провести эксперимент нагрузите канал под завязку без ограничивающих правил, и посмотрите на средний пинг, потом отключите айрвью на ap и st, и снова проверьте пинги под нагрузкой, даю гарантию, разница будет заметной. Как я понял это связано с тем, что с включённым айрвью пакеты маркируются и имеют приоритет. Сорри если неясно изложил, или если мои слова покажутся бредом, поэтому допишу имхо Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted July 5, 2014 · Report post блин, при чём здесь размер пакета? на скрине пинг стандартными пакетами 64 байта... Задержку в радио измеряют пингом 1500 байт. Т.к. пинг 64 байт покажет задержку для пакетов размером 64 байт, а данные передаются обычно пакетами большего размера. Поэтому и получается, что вроде бы пинг маленький, а скорость загрузки информации из интернета маленькая, или спидтест не показывает требуемую скорость. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SSD Posted July 6, 2014 · Report post блин, при чём здесь размер пакета? на скрине пинг стандартными пакетами 64 байта... Задержку в радио измеряют пингом 1500 байт. Т.к. пинг 64 байт покажет задержку для пакетов размером 64 байт, а данные передаются обычно пакетами большего размера. Поэтому и получается, что вроде бы пинг маленький, а скорость загрузки информации из интернета маленькая, или спидтест не показывает требуемую скорость. Может еще покажешь пруфы на подобную методику измерения, или это твое собственное умозаключение? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ChargeSet Posted July 6, 2014 · Report post пардон, а разве всякого рода аггрегации и прочие ухищрения по экономии эиртайма не влияют на пинг больше, чем размер icmp пакета? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted July 7, 2014 · Report post Если канал свободен, то запуская пинг размером 64 байта, он в радио и передастся кусочком 64 байта и вероятность доставки будет высокая. Если размер 1500, вероятность доставки уже ниже, т.к. больше времени идет передача. Если канал загружен, то кусочек 64 байта влезает в свободное место посылки с помощью агрегации, естественно кусок в 1500 байт туда не влезает, поэтому передается уже опять с меньшей вероятностью доставки. Кроме всего интервал надо ставить 100 или 50, а то и 20 мс. Пинги с интервалом в 1 секунду не несут никакой смысловой нагрузки. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SSD Posted July 7, 2014 · Report post Если канал свободен, то запуская пинг размером 64 байта, он в радио и передастся кусочком 64 байта и вероятность доставки будет высокая. Если размер 1500, вероятность доставки уже ниже, т.к. больше времени идет передача. Если канал загружен, то кусочек 64 байта влезает в свободное место посылки с помощью агрегации, естественно кусок в 1500 байт туда не влезает, поэтому передается уже опять с меньшей вероятностью доставки. Кроме всего интервал надо ставить 100 или 50, а то и 20 мс. Пинги с интервалом в 1 секунду не несут никакой смысловой нагрузки. Сколько % в реальном трафике пакетов размером 1500 и выше? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
slv700 Posted July 7, 2014 · Report post Сколько % в реальном трафике пакетов размером 1500 и выше? Пингом 1500 тестируется канал. Это размер обычного ethernet пакета, который далее пакуется на радиоинтерфейсе в фрейм A-MSDU ( 4096 байт )и более A-MPDU ( 64 байта). Тем самым устройства 802.11n правильно тестировать даже не размером ethernet пакета 1500 байт, а пакетами 4096 байт. Реальный трафик, какие бы мелкие пакеты не были, пакуется в 802.11n в эти фреймы и как они проходят в радио - и покажет этот пинг. То есть размером пакета пинга желательно достичь максимальной упаковки- это даст реальную задержку и реальную надежность ( потери пакетов) канала на длинных фреймах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 7, 2014 · Report post Профиль реального трафика: http://www.caida.org/data/passive/trace_stats/ 1500 там как-то и не пахнет, средний размер пакета 700байт... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
slv700 Posted July 7, 2014 · Report post Профиль реального трафика: http://www.caida.org/data/passive/trace_stats/ 1500 там как-то и не пахнет, средний размер пакета 700байт... Да это коню ясно! Речь идет о тестировании wireless канала, который на реальном трафике работает на пакетах max 4096 байт. В реальной сети несколько мелких пакетов c Ethernet могут наполнить по максимуму этот фрейм. А в тесте чтобы получить адекватную оценку задержке и надежности канала этот фрейм также надо как то наполнить. Это можно сделать двумя способами, либо увеличить размер пакета пинга до 1500байт и выше ( заполнить фрейм хотя бы наполовину) или запустить пинг мелкими пакетами, но чаще,например, флуд пинг. Тестируйте канал flood пингом - это даст более точную оценку надежности канала и задержкам. ЗЫ Вообще то утилита пинг не для этого придумана. Но для тестирования wireless канала она оказалась полезной. При этом простой пинг также применяется для проверки достижимости удаленного абонента. А вот длинными пакетами и флуд пингом можно также оценить задержку и надежность ( правда неточно, но сойдет). Короткий пинг для этого менее информативен. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NewUse Posted July 7, 2014 · Report post А в тесте чтобы получить адекватную оценку задержке и надежности канала этот фрейм также надо как то наполнить Зачем? Это должна делать агрегация, необходимо и достаточно загрузить канал. Не очень понимаю, от куда взялась длина 4096, это максимальный размер одного MSDU-саб-фрейма, если не ошибаюсь, но он может менятся, и если в сити нет поддержки Jumbo-frames, то они не достигают такой длины, или я не прав, при этом они "склеиваются" в один A-MSDU? Наиболее полную информацию о канале можно получить на ubnt с помощью утилиты athstat... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
slv700 Posted July 7, 2014 · Report post Зачем? Это должна делать агрегация, необходимо и достаточно загрузить канал. Как ты собрался пингом 64 байт раз в секунду наполнить фрейм? е очень понимаю, от куда взялась длина 4096, это максимальный размер одного MSDU-саб-фрейма, если не ошибаюсь, но он может менятся Максимальный размер фрейма агрегации A-MSDU по стандарту 4096 или 8192 байт. Если пингать канал стандартным пакетом, то этот фрейм ходит по радио почти пустым. А вот если его заполнить - на что нужно время и передать полным, то вероятность искажения ( потери) длинного заполненного фрейма будет намного выше , чем короткого. Ясно же, что задержка на стандартном пинге и длинном на убнт/мт отличаются в разы. Именно потому , что длинный пакет заполняет фрейм, на что нужно время. Точно также микротик в Nstreme с агрегацией max 3200 байт и в 802.11 a/g и в "n" задержка стандартного пинга будет отличаться от длинного. Какой цифре задержки верить ? Ясно- задержке от длинного пинга. А вот если пропингать проводную ЛВС то задержка на коротком и длинном пинге будет одинакова. Тоже самое если пропингать канал точка-точка на Камбиум ePMP 1000, то там также в точка-точка не будет существенной разницы в задержке на длинном и коротком пинге ( разница будет 5 мс - длина фрейма ePMP), потому что в ePMP нет агрегации. И кстати, от этой агрегации ( в ее неоптимальном размере и неоптимальном размещении CRC и ACK в фреймах) - причина половины всех бед убнт/мт. Поэтому тестировать канал на убнт/мт ,чтобы иметь представление о реальной задержке и надежности канала, надо именно длинными пингами. А тест стандартным пингом на убнт/mt- фейк, мало о чем говорит. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ChargeSet Posted July 7, 2014 · Report post Какой смысл сравнивать фиксированный фрейм с динамическим? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
