BDCOM epon sla

[toxaNaSvyazi 0]

Добрый вечер форумчане! Помогите разобраться с тривиальной задачей.

Предоставляем абоненту VLAN 220 Мбит/с. Один из его сегментов включен в нашу сеть через гигабитный порт коммутатора D-Link, а другой через ONU picotel:

 

   Switch# show epon interface epON 0/1:7 onu ctc basic-info 

   ONU Vender ID       : PICO

   ONU MODEL ID        : E210

   Hardware Version    : V1.0    

   Software Version    : V1.2.6          

   Firmware Version    : 0x00000001

 

   received power(DBm): -22.4

 

   Switch#show version 

   BDCOM P3310C Software, Version 10.1.0D Build 33463

 

На ветке PON не более десяти абонентов и у всех стоят ONU picotel. 

Чтобы дать гарантированные 220 мб/с были выполнены следующие команды на OLT:

 

   epon sla upstream pir 230400 cir 225280

   epon sla downstream pir 230400 cir 225280

 

В результате клиент получил желаемую скорость канала, но по его словам выросли задержки с 1 мс до 10 мс. С чем это связано? 

 

 

[xspirit 15]

С параметром epon dba hardware cycletime

[Kto To 602]

Не советую ставить cir такой высокий.

cir ставьте 10% от заявленой скорости не больше, а pir ставьте уже какой нужен. Хотя что это какой-то супер нужный абонент который должен (в ущерб другим подключеным на данном дереве) всегда получать своих 220 мегабит.

[toxaNaSvyazi 0]

С параметром epon dba hardware cycletime

В конфиге имеем:

epon dba hardware cycletime 25000 discovery-frequence 60 discovery-length 1024

Есть смысл поиграться со значением cycletime?

 

Не советую ставить cir такой высокий.

cir ставьте 10% от заявленой скорости не больше, а pir ставьте уже какой нужен. Хотя что это какой-то супер нужный абонент который должен (в ущерб другим подключеным на данном дереве) всегда получать своих 220 мегабит.

Пожалуй прислушаюсь к вашему совету, но у меня остаётся ещё 1 вопрос по cir. Может ли большое значение cir быть причиной увеличения задержки в 10 раз?

[RockManX 9]

ох не советую через sla это делать, это вам не шейпер

у меня по тестам даже с pir 30760 свободно 800+ мегабит проходит через раз

если онушка поддерживает, можно

epon onu port 1 ctc rate-limit 230400 ingress

epon onu port 1 ctc rate-limit 230400 egress

юзнуть, а sla выставить например 1000000/15625

пикотель скорее всего команду проигнорируется, надо старые бдсм родные искать

 

а так, если есть возможность, советую резать скорость на железке выше, если она это поддерживает, будет гараздо более надёжно

пинги возможно потому и растут, что скорость режется не там и не так как надо

[xspirit 15]

 

 

В результате клиент получил желаемую скорость канала, но по его словам выросли задержки с 1 мс до 10 мс

 

А вы со своей это утверждение проверяли? Я бы не стал верить клиенту на 100%))))

[toxaNaSvyazi 0]

ох не советую через sla это делать, это вам не шейпер

у меня по тестам даже с pir 30760 свободно 800+ мегабит проходит через раз

если онушка поддерживает, можно

epon onu port 1 ctc rate-limit 230400 ingress

epon onu port 1 ctc rate-limit 230400 egress

юзнуть, а sla выставить например 1000000/15625

пикотель скорее всего команду проигнорируется, надо старые бдсм родные искать

 

а так, если есть возможность, советую резать скорость на железке выше, если она это поддерживает, будет гараздо более надёжно

пинги возможно потому и растут, что скорость режется не там и не так как надо

 

Спасибо, учтём. 

 

 

В результате клиент получил желаемую скорость канала, но по его словам выросли задержки с 1 мс до 10 мс

 

А вы со своей это утверждение проверяли? Я бы не стал верить клиенту на 100%))))

 

 

Проверили: запустили пинг с клиентской onu до свитча, и действительно, задержки периодически прыгают с 1мс до 10-18 мс    Но связано это с тем, что свитч медленно обрабатывает ip пакеты (или проц у него слабый, или обработка icmp ставится в последнюю очередь - поправьте меня здесь). Клиент точно также мерял пинг между своими свитчами. Попросили его проверить пинг между ПК/серверами/роутерами. Проверил - пинг не поднимается выше 1,8 мс, всё ок. 

Итого:

1. Увеличение cir/pir не оказывает никакого влияния на задержку.

2. Не проверяйте задержки в канале путём пинга с/на коммутатор.

[xspirit 15]

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