[unknownameorg]

Проблема с пингами во время активности одного из клиентов.

 

Стоит РокетМ2 Титаниум с 90 градусной антенной, на титаниум коннектится 5-6 клиентов, титаниум работает в режиме моста никакого роутинга и шейпинга не накручивали, клиенты (гриды) работают в режиме роутинга все , никаких шейперов на них не накручено, проблема заключается в след., когда один(любой) из клиентов начинает качать что либо при прокачке канала начиная с 500 кбит\с и выше вплоть до максимальных 4000 кбит\с на клиента, начинается проблема у остальных соседних клиентов в виде подъема пингов до самого рокета и до внешних ресурсов, например пинги до рокета при "тихом" эфире примерно 1-2 мс не более, но когда кто то начинает что то смотреть в ХД или качать, то пинги подпрыгивают аж по 400 мс и более. Базовая станция работает уже более 2 лет, все было норм, но это началось примерно 3-4 мес назад.

 

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

 

 

[rdc]

Какая загрузка процессора во время возникновения проблемы?

[Adim]

галочку изоляция клиентов апнуть и убавляйте мощьность

[Unker]

Гриды у абонентов все в одной поляризации или в разных стоят? Если в одной, то у Вас один чеин простаивает на базе.

[NewUse]

Установите шифрование WPA2.

[[anp/hsw]]

но когда кто то начинает что то смотреть в ХД или качать, то пинги подпрыгивают аж по 400 мс и более

Вы не находите, что HD (который 10 мегабит, например), и канальная скорость в 16 мегабит (включая накладные расходы) как-то не сочетаются?

 

Где у вас идет нарезка скорости? в ядре или на CPE?

 

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

Вот поменяйте полосу на 20мгц, и выложите скрины уже с нею.

 

А также вывод команды "athstats wifi0" из telnet.

[slv700]

дин(любой) из клиентов начинает качать что либо при прокачке канала начиная с 500 кбит\с и выше вплоть до максимальных 4000 кбит\с на клиента, начинается проблема у остальных соседних клиентов в виде подъема пингов до самого рокета и до внешних ресурсов, например пинги до рокета при "тихом" эфире примерно 1-2 мс не более, но когда кто то начинает что то смотреть в ХД или качать, то пинги подпрыгивают аж по 400 мс и более. Базовая станция работает уже более 2 лет, все было норм, но это началось примерно 3-4 мес назад.

 

У Вас идет превышение емкости сектора по пропускной способности. Считаем. Емкость убнт в 20 Мгц в малтипойнт -30-40Мбит/c, в одном чейне ( гриды)-15-20М, в 5 Мгц ( ширина канала у Вашей базы)- 3.5-5 Мбит/c. Эта емкость вероятно уже загружена при обычной работе клиентов. Ясно дело, что если кто то начинает что то дополнительно качать или смотреть -идет перегруз емкости сектора убнт. Увеличивайте ширину канала.

[[anp/hsw]]

Емкость убнт в 20 Мгц в малтипойнт -30-40Мбит/c, в одном чейне ( гриды)-15-20М

Как-то вы неверно считаете, у меня в одном чейне на 20мгц (канальная 65) получается 45 мегабит.

И это не единичный случай, у нас примерно 70% баз работают в одной поляризации.

 

У ТС же при канальной 16 реальных будет 10, и мне кажется, что проблема его связана с нарезкой скоростей на CPE, тогда UDP трафик попрет всей мощью засирая емкость базы, и будет отброшен лишь на шейпере CPE.

[slv700]

' timestamp='1408092708' post=1005263]

Как-то вы неверно считаете, у меня в одном чейне на 20мгц (канальная 65) получается 45 мегабит.

И это не единичный случай, у нас примерно 70% баз работают в одной поляризации.

Точка-точка может и получится 45М в одном чейне в 20 Мгц (90М- в двух), малтипонт на 8+ клиентах этого нет -делите на 2.5-3. Если это (45Мбит/c емкость сектора убнт в малтипойнт в одном чейне) есть у Вас -выложите скрин.

[[anp/hsw]]

есть у Вас -выложите скрин.

Прошу тогда написать сюда методику тестирования, а то будете как в прошлый раз менять условия по 10 раз, когда увидите скрин.

[slv700]

' timestamp='1408096434' post='1005286']

есть у Вас -выложите скрин.

Прошу тогда написать сюда методику тестирования, а то будете как в прошлый раз менять условия по 10 раз, когда увидите скрин.

Да не надо менять условия, а нужно делать правильно. Методика тестирования сетей БШД известна. В Вашем случае предоставьте скрины дневной загрузки сектора с ethernet порта базы и скрины где видно количество клиентов, сигналы, дальности и data rate.

[[anp/hsw]]

Да пожалуйста. Только теперь извольте не менять условия.

 

 

Сейчас начнется ваше бурление насчет того, что "как так, на дневном графике нет 45 мегабит!". Да, нет. ибо это график реального дневного трафика, а не тестов. Зато он всеравно больше ваших дурацких "предсказаний".

Я бы сделал тесты, но вы сказали, что не будете менять условия :)

Но на всякий случай, Speedtest тоже прилагается.

[slv700]

' timestamp='1408097780' post='1005293']

Да пожалуйста. Только теперь извольте не менять условия.

 

 

Сейчас начнется ваше бурление насчет того, что "как так, на дневном графике нет 45 мегабит!". Да, нет. ибо это график реального дневного трафика, а не тестов. Зато он всеравно больше ваших дурацких "предсказаний".

Я бы сделал тесты, но вы сказали, что не будете менять условия :)

Но на всякий случай, Speedtest тоже прилагается.

Вы понимаете разницу 45 Мбит/с загрузка сектора, о которой шла речь, и предъявленный Вами спидтест скорости доступной на клиента 40 Мбит/c, которую Вы получили во время текущей загрузки сектора 0.5-3 Мбит/c ( это сильно !!!) ? Да у Вас на такой загрузке 90% клиентов неактивно, Ваш тест скорости -это практически тест точка-точка, про что я Вам и говорил.

Неактивны клиенты и не генерят трафик? Ок, не вопрос. Возьмите и запустите одновременно на 8 клиентах торрент по закачке файлов со скоростью 5-7 Мбит/c на каждом из этих клиентов. Тогда посмотрим насколько клиенты могут загрузить сектор.

Интересует также расклад клиентов по дальностям. Не запускайте тесты нагрузки сектора на клиентах, находящихся от базы ближе 500 метров.

ЗЫ

Я заявляю ( и это известно специалистам), что емкость убнт точка-точка в 20 Мгц в двух чейнах 90 Мбит/c, в одном 45 Мбит/c. В малтипойнт на 8+ клиентах , скорость ( емкость сектора по пропускной способности) надо делить минимум на два и больше в зависимости от условий LOS/NearLOS.

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

[[anp/hsw]]

Вы понимаете разницу 45 Мбит/с загрузка сектора, о которой шла речь, и предъявленный Вами спидтест скорости доступной на клиента 40 Мбит/c, которую Вы получили во время текущей загрузки сектора 0.5-3 Мбит/c ( это сильно !!!) ? Да у Вас на такой загрузке 90% клиентов неактивно, Ваш тест скорости -это практически тест точка-точка, про что я Вам и говорил.

Меняете условия, да? :)

 

 

Неактивны клиенты и не генерят трафик? Ок, не вопрос. Возьмите и запустите одновременно на 8 клиентах торрент по закачке файлов со скоростью 5-7 Мбит/c. Тогда посмотрим насколько клиенты могут загрузить сектор.

Ой, опять меняете, надо же!

 

Интересует также расклад клиентов по дальностям. Не запускайте тесты нагрузки сектора на клиентах, находящихся от базы ближе 500 метров.

Вот, опять вас за руку поймал!

 

Да не надо менять условия, а нужно делать правильно. Методика тестирования сетей БШД известна. В Вашем случае предоставьте скрины дневной загрузки сектора с ethernet порта базы и скрины где видно количество клиентов, сигналы, дальности и data rate.

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

 

Точка-точка может и получится 45М в одном чейне в 20 Мгц (90М- в двух), малтипонт на 8+ клиентах этого нет -делите на 2.5-3

На графике 36 мегабит UL+DL на реальной загрузке на 11 клиентах. На сколько там делим, не подскажите?

[slv700]

' timestamp='1408099496' post=1005305]

На графике 36 мегабит UL+DL на реальной загрузке на 11 клиентах. На сколько там делим, не подскажите?

Дальности до клиентов какие?

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

Никто не менят условия, но надо понимать цель тестирования и условия проведения тестов.

Получить 36М на одном клиенте при отсутствии загрузки и неактивности большинства клиентов или в точка-точка -проблемы нет.

Вы же понимаете о чем идет речь. Всем же известно что не тянет убнт в малтипойнт больше 30-40Мбит/c в 20 Мгц в двух чейнах. Один чейн все делит на два. И сами понимаете какие должны быть условия тестирования, обеспечивающие одновременную нагрузку клиентов ( которые не слышат друг друга, это к вопросу о дальности) в малтипойнт, поскольку если их не соблюдать, то тесты вырождаются в точка-точка. Не надо хитрить и предъявлять фуфел.

[[anp/hsw]]

Дальности до клиентов какие?

500м-4км

[[anp/hsw]]

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

Тогда возьмите левую часть графика (29 мегабит UL+DL). Там поменьше, но опять же намного больше ваших прогнозируемых "делите на три".

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

На ваших графиках тоже непонятно, один там клиент или несколько. И интервалы вообще 15-минутные. Но мы играем по правилам, которые уже менять запрещено.

Так что да, мой ответ корректен, а вы полностью продули, и пытаетесь выкрутиться. Признайте уже :)

[slv700]

' timestamp='1408125479' post=1005443]

И так уже понятно, что вы со своим камбиумом не чисты на руку.

Причем тут Камбиум? Высказывайте свои вопросы и претензии в теме Камбиум, в том числе когда выкладываются скрины работы сети ePMP.

Вы сказали про загрузку сектора 45Мбит/c на убнт в одном чейне? Никаких правил менять не надо. Просто предъявите доказательства такой загрузки сектора, а не тест скорости одного клиента. Разницу между этими вещами, надеюсь, объяснять не надо?

[slv700]

Если вернуться к проблеме TC, то в Вашей ( anp/hsw )сети эта проблема также скоро проявится.

Посмотрим точнее на Ваш график. В 00.00 в момент максимальной загрузки сектора несколькими клиентами имеем 0.5 Мбайт/c up и 2.5 Мбайт/c down. В сумме 3Мбайт/c или 24 Мбит/c ( а не 29 Мбит/c, что впрочем особой разницы не дает). Для канала в 5 Мгц -это было бы 6 мбит/c,= 1.5 up, 4.5 down- то есть было бы практически то же самое, что я сказал про сеть ТC ( загрузка 3.5-5 Мбит/c). Те самым, если бы Вы также как и ТС работали бы в 5 Мгц, то при загрузке торрентом свыше 1-2 Мбит/с с ближнего клиента 500м Вы бы имели точно такую же картину - увеличение задержки вплоть до потери пингов на дальнего клиента 4 км.

У Вас поскольку канал шире 20 Мгц эта проблема проявится на загрузке 4-8 мбит/c хотя бы на одном клиенте в момент средней загрузки сектора 24 Мбит/c -такой как у Вас на графике в 00.00. Сейчас Вашу сеть спасает то,что среди десятка клиентов Вашей базы в часы наибольшей загрузки одновременно активны несколько из них. Увеличится количество клиентов до 15-20, увеличится число одновременно активных клиентов в час пик и Вы получите точно такую же проблему как у TC.

 

Я могу ошибаться в цифрах загрузки трафиком процентов на 20% , даже пусть 30%, ( все же это прикидочные цифры), но то что Вашу одночейновую убнт сеть при дальнейшем увеличении количества клиентов и их активности на тарифах > 5мбит/c ждут такие же проблемы как у ТС, имеющие место из за перегруза емкости сектора, -это точно.

[kosmich7]

Я могу ошибаться в цифрах загрузки трафиком процентов на 20% , даже пусть 30%, ( все же это прикидочные цифры), но то что Вашу одночейновую убнт сеть при дальнейшем увеличении количества клиентов и их активности на тарифах > 5мбит/c ждут такие же проблемы как у ТС, имеющие место из за перегруза емкости сектора, -это точно.

К слову.

Я заявляю ( и это известно специалистам)

камбиум не умеет ни 5 ни 10Мгц, проблема ТС вероятно из-за убитого эфира, и отвратительных уровнях аирмакса как следствие.

Нужен аирвид с сектора, и нескольких клиентов, а так будет вангование продолжаться.

2slv в одном чейне в 10Мгц убнт до 30мбит раздает на 20-25абонентов, необходимо придерживаться нескольких простых правил, уверен вам они известны.

[slv700]

Все эти цифры имеет вероятностную природу- к слову ;-).

Имеет значение не сколько абонентов подключено, а сколько абонентов активы в каждый момент времени. Мои цифры справедливы для 8+ таких абонентов.

При переподписке 1 к 4 это в среднем 32 подключенных абонента. Но по-любому 1/4 это вероятностная цифра, поэтому мы говорим о том, что активны 8+ если в среднем подключено от 24 до 42 клиентов ( плюс минус 8)

Max cкорость в малтипойнт ( емкость сектора) при 8+ одновременно качающих клиентах будет такой как без агрегации пакетов 802.11n, а именно в двух чейнах в 20 Мгц - 54 Мбит/c- но это в идеальных условиях LOS.

Соотношение скорости 1 к 2 в одном и двух чейнах- это справедливо для условий LOS. Если NearLOS -то может быть и 1.5 и меньше в зависимости от того какой LOS. В самом худшем случае это 1:1. Если мы говорим о малтипойнт, то не все клиенты имеют LOS и не все имеют NearLOS.

Кроме того NearLOS понижают реальную скорость даже при высоких сигналах и data rate.

Поэтому база в двух чейнах при 24-42 клиентах будет иметь max 27-54 Мбит/c в зависимости от условий LOS - в среднем max 30-40 Мбит/c на 30 подключеных клиентах при переподписке 1 к 4.

База в одном чейне max 13-27 Мбит/c в зависимости от условий LOS , в среднем 15-20Мбит/c на 30 подключенных клиентах при переподписке 1 к 4.

При уменшении ширины канала с 20 до 10 и 5 Мгц, все делится на 2 и 4 независимо от условий LOS и количества активных клиентов.

Все цифры справедливы если ВСЕ клиенты работают на максимальных модуляциях и без помех.

[[anp/hsw]]

Я могу ошибаться в цифрах загрузки трафиком процентов на 20% , даже пусть 30%, ( все же это прикидочные цифры), но то что Вашу одночейновую убнт сеть при дальнейшем увеличении количества клиентов и их активности на тарифах > 5мбит/c ждут такие же проблемы как у ТС, имеющие место из за перегруза емкости сектора, -это точно.

Конечно ждут. При количестве CPE ближе к 30-40, тогда и переключим на два чейна. Там, кстати, только CPE 11, а самих клиентов несколько больше (около 30), и раз они такой трафик генерят, значит прогнозировать можно. Вы видимо вообще ниразу не провайдер, раз с таким рвением рассуждаете о трафике, который никогда не видели. Netflow вам прислать, что-ли :)

А треть от 45 (что будет 15) это никак не 30% вашей ошибки.

[Saab95]

Что за сказки? Микротик в NV2 в режиме A выдает 40-45 мегабит, а тут убнт на канальных 65 выдает 40? Такого не бывает. В многоточке обычно раздают около 20-30 мегабит при равномерной работе клиентов в полосе 20мгц. Естественно если 1-2 клиента качают много, а остальные совсем ничего, можно увидеть красивые графики под 60 и более мегабит, но стоит попытаться одновременно передавать данные с 10-15 абонентов с нормальной скоростью (хотя бы мегабита 2-3) как пропускная способность опускается до тех же 20-30.

[unknownameorg]

athstats wifi0

667781 recv error interrupts

2 recv eol interrupts

11491 global txmit timeout interrupts

1101 carrier sense timeout interrupts

22931454 # packets sent on the interface

2365 tx failed

2365 tx failed 'cuz too many retries

6409637 tx frames with no ack marked

30442562 tx frames with short preamble

570185 tx frames with an alternate rate

20250803 total frames received

685340 rx ack frames

47706 rx too short frames

335 rx invalid frames from mcast src

46 tx rssi of last ack

5425152837 total number of bytes received

25159252430 total number of bytes transmitted

rssi of last ack[ctl, ch0]: 20

rssi of last ack[ctl, ch1]: 46

47 rx rssi from histogram [combined]

rssi of last rcv[ctl, ch0]: 20

rssi of last rcv[ctl, ch1]: 47

529200 beacons transmitted

1912 periodic calibrations

Antenna profile:

[0] tx 0 rx 28002947

[1] tx 22929089 rx 0

2 hw resets was done

2/2 stuck beacon resets

 

11n stats

22795394 total tx data packets

65161 tx when h/w queue depth is low

22730181 tx pkts when h/w queue is busy

265834877 tx schedule ac queue empty

24 tx bars sent

1467572 tx unaggregated frame completions

85 tx unaggregated excessive retries

7407001 tx aggregated completions

22795150 tx block ack window advanced

487821 tx block ack window retries

22795150 tx block ack window additions

22795150 tx block ack window updates

22795150 tx block ack window advances

487821 tx retries of sub frames

24 tx excessive retries of sub frames

1402411 tx frames not aggregated

21327548 tx aggr good completions

96 tx aggr excessive retries

487939 tx aggr unacked subframes

282867 tx aggr old frames requeued

2233532 tx aggr: h/w long retries

28002947 rx pkts

18945248 rx aggregated packets

763185 rx non qos-data frames

43 rx sequence resets

637969 rx old packets

50936 rx duplicate pkts

16936941 rx block ack window advanced

17493158 rx pkt completions

80838 rx pkt sequences skipped on timeout

180723 rx indications due to timeout

576 draining tid buf queue on error

80 draining tid buf queue on node cleanup

133 buffers drained from pending tid queue

65 tid paused

65 tid resumed

TXQ[1]:BE tx(qmap tx/stopped) 23252649(22764868/60091) xretry 419 fifoerr 0 filtered 0 no buffs 0 drains 206

TXQ[2]:VI tx(qmap tx/stopped) 20886(0/0) xretry 0 fifoerr 0 filtered 0 no buffs 0 drains 0

TXQ[3]:VO tx(qmap tx/stopped) 14066363(43957/0) xretry 2184 fifoerr 0 filtered 0 no buffs 0 drains 27

6M suc: 2 rtr: 2 prob: 0 [ 4 0 0 0]

MCS0 suc: 282 rtr: 290 prob: 0 [ 284 924 2056 4112]

MCS1 suc: 520 rtr: 479 prob: 8 [ 647 1132 8200 1010024]

MCS2 suc: 2272 rtr: 1253 prob: 6 [ 1119 8200 496812 1213264]

MCS3 suc: 29018 rtr: 8987 prob: 13 [ 8157 496812 606632 22899560]

MCS4 suc: 310550 rtr: 99615 prob: 89 [ 496580 606632 11449780 8281272]

MCS5 suc: 587031 rtr: 258447 prob: 494 [ 596398 11449780 4140636 0]

MCS6 suc: 5464077 rtr: 1741058 prob: 1177 [11440570 4140636 0 0]

MCS7 suc: 1958257 rtr: 552771 prob: 2044 [ 4132714 0 0 0]

MCSB suc: 0 rtr: 0 prob: 0 [ 0 0 0 3628]

MCSC suc: 1 rtr: 0 prob: 0 [ 0 0 1814 2086452]

MCSD suc: 47 rtr: 9 prob: 0 [ 0 1814 1043226 0]

MCSE suc: 4459 rtr: 447 prob: 0 [ 1814 1043226 0 0]

MCSF suc: 518013 rtr: 37362 prob: 1 [ 1043225 0 0 0]

Times finished on series [8304265 536137 31400 2806]

Xretries on probes 0, on regular tp 79

0.01 tx unaggregated excessive retry percent

30.15 tx aggregated long retry percent

0.00 tx aggregated excessive retry percent

2.14 tx aggregate subframe retry percent

0.00 tx aggregate subframe excessive retry percent

[[anp/hsw]]

но стоит попытаться одновременно передавать данные с 10-15 абонентов с нормальной скоростью (хотя бы мегабита 2-3) как пропускная способность опускается до тех же 20-30.

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

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