[Kirk]

Любому человеку строящему канал по радио хотелось бы иметь следующую стабильность:

Стабильность скорости прокачки.

Стабильность пинга разным размером пакетов.

Независимость от внешних условий.

 

Хотел поговорить о двух моментах,которые подчеркнул на этом форуме:

-Ограничением скорости автоматического битрейта мы увеличиваем стабильность. В общем логично, но правильно ли я понимаю, что мы убираем всплески увеличения скорости и уменьшения времени пинга и все. Или есть еще какие то процессы. Речь конкретно о серии ubnt nano m2 и родственных на airmax 5.5.6. ПОЧЕМУ УВЕЛИЧИВАЕТСЯ СТАБИЛЬНОСТЬ?

Я не могу сказать, что сейчас что-то не устраивает, но мы используем каналы лишь на 10-15% с автобитрейтом без ручного ограничения и в принципе спокойно можем их зажать минимум в два раза, но надо ли. Линки есть и плохие и хорошие и прыжки пингов и даже потери пакетов и в половине случаев отсутствием видимости или препятствие в виде дерьевьев.

 

Попутно интересно, что происходит в таком случае: вот допустим ночь, все отлично, все летает, запас по прокачке в канале 90 процентов. Наступает день,шум. Прокачка падает процентов на 30-40. Упадет ли она пропорционально на более низком битрейте? Или изменения непропорциональны?

Допустим полоса 10, максбитрейт 65, отличное радио, текущий битрейт 65, прокачка симплекс 50М, пинги 2мс с всплесками до 10мс пакетом 2000б, тариф 11М.

Ставим ограничение макс битрейта mcs 12 или 11. Улучшится ли что-то? Ну допустим, стабильность пинга. Прокачивать допустим больше 15 не надо в дуплексе. Но надо иметь стабильный пинг в любое время дня и ночи.

 

Нужен ли запас в канале? Опять же не ясно как это в сязке с шейпером будет работать. Есть ли какие то принципы ограничения битрейта?

Может быть вне зависимости от того какой макс битрейт, запас останется за счет используемой полосы или он однозначно выбирается модуляцией? Или более низкая модуляция априори более стабильная?

 

Пример номер два. полоса 10, максбитрейт плавает 26-52/26-52, прокачка плавает до 7-10-15 в симплексе, пинг от 5-7 до 100 всплесками редкими, даже иногда с потерями, френеля нет, тариф 5-7М.

Поставлю ограничение автобитрейта mcs 12 или 11 или может какого-то др? и что я получу? Будет ли улучшение по пингу, изменения по прокачке? Не получу ли я более низкую прокачку? Не буду ли в моменты деградации по радио я иметь худшую картину нежели с ограничением на более высоком битрейте?

 

И я тут неоднократно спрашивал, но кто объяснит по спидтесту в вебморде у юбика......

Оно порой в дуплексе показывает одинаково, допустим 20/20, сразу после этого может допустим показать 5/35. А если запускать в симплексе то прокачку показывает четко одинаковую по tx и rx. Это глюк спидтеста? И кто чем пользуется в таком случае? Встроенный iperf? Или на какие параметры смотрит? Только на симплекс? Этого достаточно для оценки радио?

 

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

П.С. Отрезая скорости на юбиках делаете ли Вы запас, чтобы клиент в своих измерялках видел договорную скорость?

 

СПАСИБО!

Edited November 29, 2015 by Kirk

[rdc]

ПОЧЕМУ УВЕЛИЧИВАЕТСЯ СТАБИЛЬНОСТЬ?

ПО ДВУМ ПРИЧИНАМ:

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

- в момент перещёлкивания скоростей иногда возможны небольшие потери.

Поясните пожалуйста и есть ли разница где ограничить скорость - на юбике клиента на лане и влане или на микроте? Или если пакеты от юзера будут дропаться на микроте, то исходящий трафик от клиента все равно будет идти в полный рост?

Два примера:

- торренты по udp - когда шейпишь их со своей стороны, клиент шлёт полосу в полтора-два раза большую - в отличие от tcp, который адекватно замедлится.

- клиент поймал вирус, и его комп или роутер становится участником ботнета. когда ботнет начинает кого-то DDoS'ить, полоса от клиента будет идти максимальной, невзирая на шейп.

Зарезая же скорость на стороне клиента, обе проблемы решаются.

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

Разумеется. Накидываю процентов 15.

 

И ещё одна деталь - исходящую для физлиц совершенно не обязательно делать равной входящей.

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

А кто хочет больше - продавать на договорных условиях.

[Samgabial]

ПОЧЕМУ УВЕЛИЧИВАЕТСЯ СТАБИЛЬНОСТЬ?

Смысл простой: для работы без потерь на каждой модуляции нужно обеспечить определенный SNR (соотношение сигнал/шум, см. вложенный файл).

Если это соотношение не выдерживается - идут потери. Оборудование UBNT регулярно пытается переключить работу на максимальную указанную модуляцию (вернее data rate), и если растут ошибки - снижает модуляцию и повторяет битые пакеты. Отсюда периодический рост задержек. При этом, если используете агрегацию - задержки больше. И, конечно, переповторы занимают свою часть полосы пропускания, уменьшая общий эффективный трафик.

В случае, когда известно, что на рабочей частоте периодически появляется помеха с определенным уровнем, можно прикинуть SNR, добавив 3 дБ на запас, и ограничить data rate сверху, чтобы минимизировать потери.

 

Speedtest UBNT - UDP-тест, не учитывает потери.

Для TCP-теста большими пакетами в несколько потоков (например, в пять) параметры iperf можно сделать такими:

Сервер: iperf –s –w 64k

Клиент: iperf –c <ip сервера> –w 64k –P 5 –t 60 -r (или -d для дуплекса)

Или speedtest.net - тоже TCP-тест.

 

Мы для настройки работы радиоканала нагружаем его TCP-трафиком и добиваемся работы с CCQ>95% на максимальных модуляциях.

 

Поясните пожалуйста и есть ли разница где ограничить скорость

В условиях дефицита полосы шейпить нужно на исходящем (Egress) интерфейсе.

Мы на CPE UBNT перед установкой настраиваем шейпер на 1 Мбит/с. Исключения нужны одному клиенту из ста.

[slv700]

Если это соотношение не выдерживается - идут потери.

Ключевая проблема ubnt - требуемое соотношение сигнал/помеха ( CINR) для той или иной модуляции не выдерживается. То есть по идее Airmax протокол ubnt должен был бы постоянно измерять отношение CINR в канале ( путем измерения потерь в канале) и выставлять соответствующую рабочую модуляцию( это называется Link adaptation, как это например делает Камбиум ;-) ), но вот ubnt Airmax этого не то что вообще не делает, но делает это неадекватно. Ubnt при выборе модуляции ( data rate) ориентируется на измерение своего CCQ ,который каким то образом все же связан с Packet Error Rate,но неадекватно , так что можно считать Link adaptation у ubnt нет.

Как следствие, и здесь я соглашусь с Samgabial, при работe ubnt на неадекватной CINR модуляции в канале идут потери пакетов, которые снижают скорость ( особенно TCP/IP) и увеличивают задержку и джиттер. Зарезая сверху data rate предотвращается работа ubnt на высоких модуляциях, заведомо неадекватных текущему CINR, что предотвращает потери в канале и повышает стабильность. Важен вопрос какие конкретно модуляции в текущих условиях зарезать сверху, что даст большую скорость и меньшую задержку ? Более высокий data rate c большими потерями пакетов или более низкий data rate c меньшими потерями? Найти компромисс в этом вопросе можно на оборудовании убнт только тестами, причем пакетами TCP (OOKLA speed test или MT BT тест TCP, которые учитывают потери пакетов). UDP тесты , а также встроенные тесты ubnt ( это тоже UDP) а также загрузка канала UDP торрентом не дают адекватной оценки пропускной способности канала, потому как UDP трафик не учитывает потери пакетов. Проблема состоит в том, что текущие условия, в частности помехи, а зачастую и сигналы постоянно меняются, поэтому такие измерения скорости и ручную корректировку зарезанных сверху data rate надо делать постоянно ( регулярно), что есть большой геморрой, особенно если линков не один десяток.

[slv700]

-второй момент про шейпер.

Шейпер надо делать на точке доступа на MAC уровне -у ubnt Wireless Traffic Shaping, Incoming Traffic Limit, Outgoing Traffic Limit. На другом оборудовании это может назваться типа User MIR Profile. Когда MIR шейп делается на MAC уровне, то неважно, если Tx клиента ограничивается на Rx стороне точки доступа. Но проблема на убнт в другом, если сеть малтипойнт, то на AP невозможно ограничивать -Wireless Traffic Shaping для каждого клиента , поэтому это приходится делать на каждом клиенте по отдельности, что очень неудобно. Поэтому шейпер часто делют на роутере Микротик, но уже на IP уровне. Это гораздо хуже чем на MAC, потому что не учитываются дропы на MAC уровне,и шейпер по IP на Микротике, стоящем рядом с AP Ubnt, Upload трафика от абонента - неэффективен. В Download он работает хорошо, но в upload при больших потерях пакетов такой IP шейпер плохо работает. Кроме того, IP шейпер надо ставить рядом с каждой точкой доступа, если это делать где то в точках агрегации трафика через несколько хопов от точек доступа ubnt, тогда в сети будет полный хаос.

ЗЫ

Ограничивать upload CPE в сети ubnt крайне желательно. Дело в том, что шедулер Airmax плохо отрабатывает Upload и один клиент с высоким аплоад трафиком ( если его не ограничить) может завалить всю раздачу убнт.

ЗЫ2

В заключении сего ликбеза, скажу -это ubnt детка ! ;-). И советую всем провайдерам переходить на Камбиум ePMP, у которого НЕТ описанных выше проблем.

[Kirk]

И все же есть ли инструмент для удобного изменения убнт cpe настроек в одном интерфейсе?

Как я заметил помимо всех перечисленных минусов, при ограничении скорости на микротике над Ап, мы получаем деградацию скоротсных характеристик у клиента при деградации радио.

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

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

 

Как все же посоветуете быть с верхним ограничением битрейта? Стоит ограничивать или нет? Если ограничивать, то как выбирать модуляцию? Закладывать какой то определнный запас между тарифом и верхней границей модуляции?

Допустим полоса 10, тариф 5. Как выбрать модуляцию? Если этих данных недостаточно, то какие вводные данные нужны еще и как их использовать?

Надо ли стараться модуляцию сделать как можно более низкой? Приближенной к тарифу? Будет ли давать каждая более низкая модуляция бОльшую стабильность?

Edited November 29, 2015 by Kirk

[NewUse]

Как все же посоветуете быть с верхним ограничением битрейта? Стоит ограничивать или нет? Если ограничивать, то как выбирать модуляцию? Закладывать какой то определнный запас между тарифом и верхней границей модуляции?

Допустим полоса 10, тариф 5. Как выбрать модуляцию? Если этих данных недостаточно, то какие вводные данные нужны еще и как их использовать?

Надо ли стараться модуляцию сделать как можно более низкой? Приближенной к тарифу? Будет ли давать каждая более низкая модуляция бОльшую стабильность?

 

Выбираете максимальную модуляцию, при которой под нагрузкой ССQ не проседает ниже 95%

[slv700]

Выбираете максимальную модуляцию, при которой под нагрузкой ССQ не проседает ниже 95%

CCQ -весьма приблизительно характеризует качество канала ( величину потерь пакетов). Что такое 95%, значит ли это 5 % потерь пакетов? Так на таких потерях канала не живет.

[NewUse]

Что такое 95%, значит ли это 5 % потерь пакетов? Так на таких потерях канала не живет.

Это в попугаях, но экспериментально установлено, что при данном пороге канал работает нормально, с удовлетворительным джитером (не выше 3мс для 5.3.2, для других не тестировал).

[slv700]

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

Допустим полоса 10, тариф 5. Как выбрать модуляцию? Если этих данных недостаточно, то какие вводные данные нужны еще и как их использовать?

Надо ли стараться модуляцию сделать как можно более низкой? Приближенной к тарифу? Будет ли давать каждая более низкая модуляция бОльшую стабильность?

Реальная скорость в канале зависит не только от data rate, но и от потерь в канале. Так что реальная скорость на data rate скажем 130 Mbps ( MCS15) при определенных потерях может быть меньше, чем скорость на скажем data rate 78Mbps ( MCS12). Поэтому в данном случае модуляции MCS13-15 надо ограничивать, так как толку от работы на них нет, только будет хуже. Как это заранее это ограничение определить ? Да никак, поскольку потери PER на убнт неизвестны, но даже если бы они были известны, то посчитать скорость на основе data rate и PER практически невозможно. Тоже самое касается задержки. Нет никаких данных, по которым можно было бы предсказать( посчитать) реальную скорость, то есть зависимость скорости от data rate и потерь не формализуема. Это можно сделать только практическими измерениями, то есть тестами. Просто ставите модуляцию ( data rate) и измеряете скорость, и потом выбираете из всех возможных максимальную модуляцию, дающую максимальную скорость и приемлемую задержку. Все остальные более высокие модуляции зарезаете.

При этом в системах с поддержкой link adaptation типа ePMP или wimax совершенно определенно можно сказать какая будет реальная скорость на той или иной рабочей модуляции ( data rate) не зависимо от уровня помех. Дело в том что PER/BER в таких системах всегда известен ( его автоматически обеспечивает система при любой помехе ), например, BER 10-4. Для такой системы измеряют скорость для каждой модуляции data rate c постоянным BER 10-4 и составляют таблицу соответствия Throughput vs MCS ( data rate). Такую зависимость можно формализовать в виде формулы, полученной эмпирическим путем ( с помощью тестов), в том числе добавить в эту формулу параметр -количество клиентов на сектор. Скажем для ePMP можно посчитать (предсказать) какая будет реальная скорость ( пропускная способность канала)в зависимости от модуляции и количество клиентов на сектор и это формализовано в например в Link Calculator.

А как это соотносится с тарифом? Скажем дали вы клиенту MIR 5 Mbps. Это значит , что в вашей сети ( со всеми выставленными шейперами и ограничениями data rate) и текущими количеством клиентов на сектор, этот клиент, измерив свою скорость например OOKLA speedtest.com в час пик ( вечером после 19.00), должен увидеть цифру своего тарифа - скорость не менее 5 Mbps. Если он этого не будет видеть хотя бы в одном из сделанных подряд двух-трех тестов, то значит он платит за услугу, которую не получает, со всеми вытекающими от этого последствиями. Вы как провайдер не должны доводить загрузку сектора до величины, когда клиенты перестанут получать скорость согласно тарифу. Для этого вы при инсталляции клиента и периодически в процессе эксплуатации должны измерять ( вычислять) доступную клиенту скорость. В случае убнт это очень трудно делать, поскольку как я сказал выше, реальная скорость в канале убнт СПЕ непредсказуема. Повысилась помеха, все ограничения data rate стали неадекватными ( поплыли) и какая будет реальная пропускная способность сектора и каждого клиента сказать невозможно, можно только предусмотреть какой то запас на такие колебания, величина которого опять же для убнт непредсказуема, это может быть и 15% и 50%. Вообщем убнт сеть не может самостоятельно адаптироваться к изменению условий ( в частности к помехам), птица пролетела, снег выпал, листва на деревьях появилась и все может рухнуть. Поэтому и получается , что эксплуатация коммерческой сети убнт -сущий ад!

[slv700]

становлено, что при данном пороге канал работает нормально, с удовлетворительным джитером (не выше 3мс для 5.3.2,

ССQ 95% означает, что помех нет или сигнал настолько мощнее помехи, что он не замечает этой помехи. Конечно если нет помех и нет потерь, то посчитать скорость vs data rate вполне можно. Но ведь проблема же в том, что люди вынуждены ограничивать data rate при помехах. Вы предагаете критерием выбора data rate ( адаптивной модуляции) при помехах сделать ССQ 95%? Предложите ubnt это cделать, чтобы Airmax автоматически ставил рабочую модуляцию по критерию ССQ> 95%. Если бы это было так просто и это работало, то это давно бы уже сделали.

[Kirk]

Как все же посоветуете быть с верхним ограничением битрейта? Стоит ограничивать или нет? Если ограничивать, то как выбирать модуляцию? Закладывать какой то определнный запас между тарифом и верхней границей модуляции?

Допустим полоса 10, тариф 5. Как выбрать модуляцию? Если этих данных недостаточно, то какие вводные данные нужны еще и как их использовать?

Надо ли стараться модуляцию сделать как можно более низкой? Приближенной к тарифу? Будет ли давать каждая более низкая модуляция бОльшую стабильность?

 

Выбираете максимальную модуляцию, при которой под нагрузкой ССQ не проседает ниже 95%

 

Это когда мы хотим получить максимально стабильную скорость... а если у меня канал на 50-80 процентов избыточен?

Я готов переходить на гораздо более низкие модуляции. Но вопрос, будет ли стабильней пинг и прокачка при появлении помех, чем на более высоких модуляциях и значит ли это, что на низких модуляциях мне нужен запас в канале меньше?

 

И кстати, в течении какого времени Вы тестируете канал? айрмакс штука не особо расторопная. до стабилизации параметров?

 

Разумеется. Накидываю процентов 15.

 

И ещё одна деталь - исходящую для физлиц совершенно не обязательно делать равной входящей.

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

А кто хочет больше - продавать на договорных условиях.

 

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

Это интересный момент, потому что никогда не идет речь о тарифной загрузке в обе стороны в одну еденицу времени.

 

Если продавать симметричную услугу, то с отдачей так уже не покатит. Другое дело, а кто это действительно использует.

[rdc]

Я заявляю хомячкам даже не симплекс, а только входящую. Симметричный канал даю юрикам.

[kravtai]

В условиях дефицита полосы шейпить нужно на исходящем (Egress) интерфейсе.

 

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

[Samgabial]

В условиях дефицита полосы шейпить нужно на исходящем (Egress) интерфейсе.

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

 

У нас реализован VLAN на клиента. На СРЕ VLANы заводим на WLAN-интерфейсах (типа, WLAN0.43), на них и настраиваем шейпер на Egress.