UA.PON v6.0

[Reanemator_ua 21]

как бы 7у.е это 150грн на 10 подключках 1500грн экономии.... поключили 20 абонов и заработали + до зп 3к грн

а свистопляски - поначалу и с бдкомом было тоже немало

 

Полностью согласен. Сейчас время не спокойное и каждая копейка на счету. Так что немного подождите и мы разберёмся с Форой.

На текущий момент китайцы прислали новую прошивку, которая решает проблему Opt 82. Тестирую...

[Reanemator_ua 21]

Прошивку проверил. Всё пофикшгено. Опция добавляется. Remote ID и Circuit ID нужную информацию показываю. К сожалению, данная прошивка не является даже бета релизом, а сделана, как говорится, на коленках, поэтому в массы пока не пойдёт - я её у себя придержу. Как торлько появится нормальная версия прошивки, выложу её на наш дроп и отпишусь

Відредаговано 2015-02-03 09:53:35 Reanemator_ua

[yury79 32]

Спасибо, будем ждать.

[Reanemator_ua 21]

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

[Den_LocalNet 1 474]

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760

epon sla downstream pir 30760 cir 30760

 

после 31-ой ону на ветке начали отваливаться ону с перерегистрацией

теперь описываю так

epon sla upstream pir 30760 cir 10240

 epon sla downstream pir 30760 cir 10240

 

не давать зарегистрироваться ону - странный механизм обработки ошибки

[wladd 382]

 

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760

epon sla downstream pir 30760 cir 30760

 

после 31-ой ону на ветке начали отваливаться ону с перерегистрацией

теперь описываю так

epon sla upstream pir 30760 cir 10240

 epon sla downstream pir 30760 cir 10240

 

не давать зарегистрироваться ону - странный механизм обработки ошибки

 

А вот это очень инетерсно!

Получается что ОНУ можето отваливаться в перерегистрацию в случае превышения CIR

Это требует проверки!!!

 

- у нас на стендах ни одного отвала за сутки. Может эти магические пере-регистрации связаны именно с превышением полосы?

 

Screep - расскажите, а у вас какие полосы CIR назначены на каждую ОНУ и сколько их в дереве?

Відредаговано 2015-02-03 13:01:20 wladd

[wladd 382]

OPT82 - готово

ACL - ждем

 

за поведением наблюдаем

Відредаговано 2015-02-03 13:03:10 wladd

[Den_LocalNet 1 474]

 

 

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760

epon sla downstream pir 30760 cir 30760

 

после 31-ой ону на ветке начали отваливаться ону с перерегистрацией

теперь описываю так

epon sla upstream pir 30760 cir 10240

 epon sla downstream pir 30760 cir 10240

 

не давать зарегистрироваться ону - странный механизм обработки ошибки

 

А вот это очень инетерсно!

Получается что ОНУ можето отваливаться в перерегистрацию в случае превышения CIR

Это требует проверки!!!

 

- у нас на стендах ни одного отвала за сутки. Может эти магические пере-регистрации связаны именно с превышением полосы?

 

Screep - расскажите, а у вас какие полосы CIR назначены на каждую ОНУ и сколько их в дереве?

 

может быть я не правильно выразился

звонит клиент и жалуется что нет интернетов

на ону пон порт мигает зеленым (онушни тогда еще были 1004В) - значит идет регистрация

смотрю логи, а оно его реконектит каждую секунду

ону цепляется, доходит до применения sla, вылетает с ошибкой и дисконектится... и так по кругу

начал рыть логи - оказывается такое было уже накануне несколько раз, но никто не жаловался

выходит проблема вылазила только когда в дереве собирались все ону в онлайне.

Відредаговано 2015-02-03 15:08:51 Den_LocalNet

[wladd 382]

если внимательно прочесть переписку - обсуждение того что тут было

унас есть два прецедента

 

Водном случае, человек наблдал отвал онушки после (но не значит вследствие)

того как наблдал не выдачу ДДМ.

 

параметры CIR/PIR - не проверены

 

В другом случае, человек наблдал не отдачу ДДМ, но отвал не наблюдал.

параметры CIR/PIR проверены

epon onu-config-template t2318
 cmd-sequence 1 epon sla upstream pir 1000000 cir 512
 cmd-sequence 2 epon sla downstream pir 1000000 cir 512

Всего около 35 ОНУ на ветке.

Мы собрали два стенда

 

КНР -  более 40 ОНУ NA-1001B  -нет отвалов ( да и ДДМ показывает больше суток)

Тута - 30*1501С + 10*NA-1001 + 2*NA-1001B  -не отвалов да и ДДМ показывает исправно

 

Версия:

Эпизод отваливающеся ОНУ может быть связан с превышемем CIR (напремер)

 

 

Тов Screep - пришлите ваши даные CIR/PIR и количество ОНУ.

 

Это конечно только версия, но мы так и ли иначе из гностических

представлений о мире должны найти причну эпизода и воспроизвести ее.

Відредаговано 2015-02-03 16:04:43 wladd

[skreep 2]

если внимательно прочесть переписку - обсуждение того что тут было

унас есть два прецедента

 

Водном случае, человек наблдал отвал онушки после (но не значит вследствие)

того как наблдал не выдачу ДДМ.

 

параметры CIR/PIR - не проверены

 

В другом случае, человек наблдал не отдачу ДДМ, но отвал не наблюдал.

параметры CIR/PIR проверены

epon onu-config-template t2318
 cmd-sequence 1 epon sla upstream pir 1000000 cir 512
 cmd-sequence 2 epon sla downstream pir 1000000 cir 512

Всего около 35 ОНУ на ветке.

Мы собрали два стенда

 

КНР -  более 40 ОНУ NA-1001B  -нет отвалов ( да и ДДМ показывает больше суток)

Тута - 30*1501С + 10*NA-1001 + 2*NA-1001B  -не отвалов да и ДДМ показывает исправно

 

Версия:

Эпизод отваливающеся ОНУ может быть связан с превышемем CIR (напремер)

 

 

Тов Screep - пришлите ваши даные CIR/PIR и количество ОНУ.

 

Это конечно только версия, но мы так и ли иначе из гностических

представлений о мире должны найти причну эпизода и воспроизвести ее.

 

На тій лінії, було 9 ону зареєстровано CIR/PIR 100000/15000 так десята викидала такі фортеля, правда ону бдком аніак та 1 шт фора.

 

На іншій голові все так само тільки онушок було 17 шт з такими ж параметрами CIR/PIR так все працює нормально 

 

Зробив там де спостерігався глюк CIR/PIR 100000/10000, ніби зареєструвалась онушка  нормально, буду спостерігати. Але є декілька гілок де64 онушки, мішанка бдком, аніак, фіком, тплінк,  там  CIR/PIR 100000/15000 і всі реєструються, аптайм порядку місяця у всіх де живлення не вимикали. Тому питання - то фора така "фортова"?

 

PS.

ДДМ не віддається (замічено) тоді коли sh ep ac видає

 

a0c6.ec00.fc94 auto_configured linkfault

або

a0c6.ec00.fc98 authenticated   notready

тоді з ону нічого не віддається, хоча трафік якийсь через ню біжить, але швидкість не піднімається більше 1-10мбіт\с і можливі втрати до 10%-15% потім вона рандомно починає перереєстровуватись поки не перезавантажити по живленню.

Відредаговано 2015-02-03 19:59:16 skreep

[Reanemator_ua 21]

Я пока не буду делать никаких выводов, но наш стенд из 64 ONU стоит уже 2 дня. никаких дерегистраций не происходит. Я выключал DBA совсем, ставил Cycle-time на 25000 и 50000, ставил динамический Cycle-time - всё работает.

 

Правда было замечено что при фиксированном Cycle-time 25000 TQ скорость от ОНУ в сторону ОЛТа не превышает 460 мбит/с. При установке динамического времени цикла скорость подпрыгнула до вполне нормальных 780 мбит/с.

 

Так или иначе, я дерегистрировал Форы и заново регистрировал, сбрасывал конфиг ЕПОН порта, чтобы все ОНУ одновременно зарегались. При этом регистрация 64 ОНУ проходит секунд за 30, при том что пластиковые, что металлические ФОРЫ регистрируются не последними, а мелькают среди BDCOM-ов. Это говорит, что с MPCP у них никаких проблем не наблюдается. На ночь поставили IPERF между ПК, подключённого к пластиковой ФОРЕ, и ПК, подключённого к ГЕ порту ОЛТа. В результате 10 часового теста в режиме полного дуплекса ОНУ не отвалилась и выдала вполне симметричную скорость 651/609 мбит/с

 

Мне остаётся только продолжать тест и попробовать ещё больше нагрузить PON чип. Кроме того я ожидаю поступления на наш склад партии пластиковых ФОР - тогда смогу поставить больше ФОР в ветку, убрав часть BDCOM-ов.

[wladd 382]

1. about the de-regist bug, our side didn't repeated yeat. it running > 30 hours, still stable.
it is still hard to tell why the de-regist problem appears, until it repeated.

may be the optical modual problem, which means it is the hardware problem of a specific, standalone device.

 

2. about the opt82, it should be OK, tested in all cases, e.g: tag/untag mode, all works. and we're ready to release you with new firmware.

 

3. What we can report to community now time?

 

1) opt82 problem is solved. 2) we're trying to re-display the bug problem, but no luck. > 30 hours elapsed, still stable,

I  didn't meant our onus of no any statability problems; however as more test time elapsed, higher probability of problems

of standalone/few devices, or even mightbe the OLT optical moduals.

 

if we still couldn't repeat the bug, i guess we need more information of this problem. e.g: in case of it appears, what the

optical power it is?what the probability of this bug? is there any special usage of that device?

did  all devices appended under the same pon port rised the bug? or even could you please recycle the problem device,

and open up the box, so that we can check the circuite board....

 

3. about the ACL, might take more RD resource, the deadline mightbe delay, will be 2-10.

 

Попытаемся сегодня по максимуму нагрузить дерево.

Відредаговано 2015-02-04 09:21:27 wladd

[MONAX_SM 0]

Спасибо вам большое. Классная книга. Я заказал себе такую, на вашем сайте. Буду ждать, когда приедет. Я в PONE  новенький. Много чего не понимаю. Хочу спроектировать GPON, но пока не понимаю топологию сети и как строят такие сети.

[Reanemator_ua 21]

В результате 86000 секунд прогона IPERF-ом в режиме FULL-DUPLEX TCP трафика через 2 ONU FORA NA-1001B (2 ПК подключёны к 2 Форам, 2 других - к GE портам ОЛТа), обе ОНУшки стабильно отработали. Суммарная скорость 2 потоков, пропущенных через ОЛТ, - 730/670 mbps. У меня закончились идеи, как можно нагнуть ФОРу и заставить её дерегистрироваться. Разве что дождаться поступления новой партии ФОР и включить в дерево их побольше.

 

Мы так и не собрали статистику. Продано около 1000 ОНУ. Пока мы услышали о проблеме от 2-3 клиентов - это около 10-30 ОНУ. Где все остальные ? Неужели ещё не ставили форы "в бой"? 

[Zolks 24]

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358
Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

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

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

[Reanemator_ua 21]

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

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

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

[Zolks 24]

 

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

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

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

 

А разве вторая конструкция это не полисер тоже?

Я думал что единственная разница в том, что первая конструкция режет скорость на UNI портах, а вторая на EPON порту ОНУ.

[yury79 32]

 

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

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

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

 

Ну почему же, если сделать один единственный тариф, допустим 50М за ххх грн., то проще будет обрезать скорость на каждой ОНУ, без включения шейпера. А без шейпера и ресурсов оборудования надо поменьше. Пока я не слышал, что б так делали, ну а дальше посмотрим.

[Reanemator_ua 21]

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Я всегда клиентам говорю, что на ONU есть шейпер, подразумевая SLA. Но на самом деле это никакой не шейпер. SLA определяет, какую пропускную способность (гарантированную (CIR) и пиковую (PIR)) может иметь ONU. Эта информация учитывается на стороне OLT-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ уже практически исчерпала значение PIR - в этом случае ОЛТ примет решение о выделении меньшего кванта времени, чем просит ОНУ. В итоге в буфере ОНУ пакеты будут накапливаться до тех пор, пока буфер не переполнится, а как результат - опять потеря пакетов.

[Reanemator_ua 21]

Новая прошивка для FORA NA-1001B, решающая проблему с Option 82, выложена на дроп https://www.dropbox.com/sh/r35rr8qrh7dxygv/AABZRUkALVmufqJEHD6BmRmya?dl=0.

Напомню, UImage шьём через веб морду, архив jffs2_fs.tar.gz - через CLI OLT-а (как говорится, кому как больше нравится).

[Abram 98]

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Нет.

Полисинг тупо дропает пакеты, которые не влазят в rate-limit.

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

 

Вообще - да, шейпер более толерантен к TCP, но глубже ethernet кадров обычно не лезет и сам по себе о TCP (как и о всём остальном) знать не знает.

Відредаговано 2015-02-05 12:19:40 Abram

[Zolks 24]

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Я всегда клиентам говорю, что на ONU есть шейпер, подразумевая SLA. Но на самом деле это никакой не шейпер. SLA определяет, какую пропускную способность (гарантированную (CIR) и пиковую (PIR)) может иметь ONU. Эта информация учитывается на стороне OLT-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ уже практически исчерпала значение PIR - в этом случае ОЛТ примет решение о выделении меньшего кванта времени, чем просит ОНУ. В итоге в буфере ОНУ пакеты будут накапливаться до тех пор, пока буфер не переполнится, а как результат - опять потеря пакетов.

т.е. как я и говорил:

1. Шейпера на ОНУ нет. Только полисинг.

2. epon onu port 1 ctc rate-limit позволяет резать скорость на UNI портах ОНУ (если у вас 4-х портовая ОНУ - вы сможете резать скорость на каждом порту отдельно, без общего ограничения на EPON порту)

3. epon sla downstream/upstream режет скорость на EPON порту ОНУ (вне зависимости от кол-ва UNI портов и ограничений на них).

    т.е. если применить

    epon sla downstream pir 55000 cir 15000

    и

    epon onu port 1 ctc rate-limit 55000 ingress

    epon onu port 2 ctc rate-limit 55000 ingress

    epon onu port 3 ctc rate-limit 55000 ingress

    epon onu port 4 ctc rate-limit 55000 ingress

 

    то суммарно все четыре порта ОНУ не смогут прокачать больше 55Мбит/с

 

P.S. Возможно попутал ingress/egress ... Но не суть важно.

[yury79 32]

Новая прошивка для FORA NA-1001B, решающая проблему с Option 82, выложена на дроп https://www.dropbox.com/sh/r35rr8qrh7dxygv/AABZRUkALVmufqJEHD6BmRmya?dl=0.

Напомню, UImage шьём через веб морду, архив jffs2_fs.tar.gz - через CLI OLT-а (как говорится, кому как больше нравится).

Спасибо, будем пробовать.

[passer 67]

FEC Fora умеет?

[KaYot 3 709]

 

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Нет.

Полисинг тупо дропает пакеты, которые не влазят в rate-limit.

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

 

Вообще - да, шейпер более толерантен к TCP, но глубже ethernet кадров обычно не лезет и сам по себе о TCP (как и о всём остальном) знать не знает.

 

Можно сказать проще - полисер, это шейпер с буфером нулевого размера. Больше никакой разницы нет.

Ну а TCP скорость потока регулирует автоматом в любом случае, с ростом числа дропнутых(и перезапрошенных) пакетов.