[NikAlexAn]

пинга? раз в минуту

Счётчиков in/out на интерфейсе что в мегафон смотрит.

[AlKov]

мне до сих пор не ясно откуда дропы при установленном шейпере на 25М?

А своим абонентам Вы чем нарезаете скорости?

Кстати, проверьте, может у вас кто-то умудряется "помимо" ходить, банально по вашему недосмотру например, или ещё как.

[yKpon]

пинга? раз в минуту

Счётчиков in/out на интерфейсе что в мегафон смотрит.

каждые 5 мин

поставил раз в минуту

А своим абонентам Вы чем нарезаете скорости?

Кстати, проверьте, может у вас кто-то умудряется "помимо" ходить, банально по вашему недосмотру например, или ещё как.

абонентам режу через tc

мимо исключено, я опять опираюсь на дропы, которых быть не должно

Изменено 18 мая, 2015 пользователем yKpon

[AlKov]

А своим абонентам Вы чем нарезаете скорости?

Кстати, проверьте, может у вас кто-то умудряется "помимо" ходить, банально по вашему недосмотру например, или ещё как.

абонентам режу через tc

мимо исключено, я опять опираюсь на дропы, которых быть не должно

Ну не совсем "помимо", а например, из-за банальной ошибки/опечатки в "абонентском" правиле tc, "потребитель/и" могут создавать кратковременные "выбросы на всю катушку".

Вот тогда и будут дропы со стороны провайдера.

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

Попробуйте отключить всех абонентов, вместо них запустите одновременно несколько соединений (торрент, закачку, плюс ещё что-нибудь)

с "тестового абонента" на своём компе, пропустив его естественно, через абонентское tc правило. Выделите этому "тестеру" мегабит 20 и наблюдайте.

[yKpon]

Ну не совсем "помимо", а например, из-за банальной ошибки/опечатки в "абонентском" правиле tc, "потребитель/и" могут создавать кратковременные "выбросы на всю катушку".

Вот тогда и будут дропы со стороны провайдера.

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

Попробуйте отключить всех абонентов, вместо них запустите одновременно несколько соединений (торрент, закачку, плюс ещё что-нибудь)

с "тестового абонента" на своём компе, пропустив его естественно, через абонентское tc правило. Выделите этому "тестеру" мегабит 20 и наблюдайте.

дропы есть на 17-18 мегабитах, не вижу смысла мне что-то тестировать, нагружать торрентами, тестировать iperf и прочее, проблема явная и видна, повторюсь переключались к Мегафону с ТТК, было всё гарантировано обеспечено по всем параметрам, никаких дропов не было даже без шейпера

 

в общем они сейчас мне отписываются

Вывод то, что полисер «отсекает»

 

smena_cf@VLD-PE-MX960-2_re0> show policer 30M-xe-0/2/0.989-log_int-i

 

Policers:

 

Name Bytes Packets

 

30M-xe-0/2/0.989-log_int-i 27396641815 20942860

 

 

 

{master}

 

smena_cf@VLD-PE-MX960-2_re0> show policer 30M-xe-0/2/0.989-log_int-0

 

 

 

{master}

 

smena_cf@VLD-PE-MX960-2_re0> show policer 30M-xe-0/2/0.989-log_int-o

 

Policers:

 

Name Bytes Packets

 

30M-xe-0/2/0.989-log_int-o 64619929362 45188259

 

 

 

Настройки полисера стандартные по методике вендора:

 

 

 

set firewall policer 30M logical-interface-policer

 

set firewall policer 30M if-exceeding bandwidth-limit 30m

 

set firewall policer 30M if-exceeding burst-size-limit 15k

 

set firewall policer 30M then discard

[nuclearcat]

на 30м берст 15kbyte? П^здят. Это даже меньше минимума, 5ms (они поставили 4ms). Пусть очки протрут.

http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/general/policer-guidelines-burst-size-calculating.html

The following general guidelines apply to choosing a policer burst-size limit:

 

A burst-size limit should not be set lower than 10 times the maximum transmission unit (MTU) of the traffic on the interface to be policed.

The amount of time to allow a burst of traffic at the full line rate of a policed interface should not be lower than 5 milliseconds.

The minimum and maximum values you can specify for a policer burst-size limit depends on the policer type (two-color, three-color, or hierarchical). For more information, see Policer Bandwidth and Burst-Size Limits.

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

Лично я ставлю RTT*2 к основным ресурсам (время реакции TCP на потери), правда у меня есть возможность использовать ECN и другие механизмы, чтобы TCP успел отреагировать.

[yKpon]

на 30м берст 15kbyte? П^здят. Это даже меньше минимума, 5ms (они поставили 4ms). Пусть очки протрут.

http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/general/policer-guidelines-burst-size-calculating.html

где 4мс?

 

кстати отзвонились сообщили что-то изменили просят проверить, ещё раз попрошу выхлоп

[AlKov]

на 30м берст 15kbyte? П^здят. Это даже меньше минимума, 5ms (они поставили 4ms). Пусть очки протрут.

http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/general/policer-guidelines-burst-size-calculating.html

 

где 4мс?

DS3 45 Mbps 5 ms 45,000,000 bps x 0.005 seconds x 1 byte / 8 bits = 28,125 bytes

Соотв. этому примеру считаем..

 

30000000 ("ваши" 30М) bps x S seconds x 1 byte / 8 bits = 15000 (показанный вашим провом burst-size-limit 15k).

Отсюда извлекаем S.

S = 15000 x 8 / 30000000 = 0.004 sec (т.е. 4 мс).

[yKpon]

парни спасибо

 

уже отписался в тех службу

 

какой нормальный буфер должен быть на моей полосе?

Изменено 27 мая, 2015 пользователем yKpon

[rdntw]

какой нормальный буфер должен быть на моей полосе?

 

18.75?

[yKpon]

18.75?

 

это минимальный, а по хорошему сколько

[rdntw]

а вообще при тарифе 30М слово "магистрал" тут неуместно кмк )

[AlKov]

18.75?

это минимальный, а по хорошему сколько

Я так думаю, это не вам решать, т.к. железка не ваша, а

The minimum and maximum values you can specify for a policer burst-size limit depends on the policer type (two-color, three-color, or hierarchical).

Или у вас с провайдером уже так? ;)

[nuclearcat]

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

Кстати, если уж говорим про минимумы, есть такое правило, когда скорость значительно меньше скорости интерфейса, и берст в виде speed*0.5ms, то минимальный берст отсчитывается от MTU интерфейса, обычно равен 10xMTU. (QOS-Enabled Networks: Tools and Foundations, стр. 114, и, http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/policer-mx-m120-m320-burstsize-determining.html)

НО. В данном случае, 5ms*speed - больше, чем правило с MTU. Т.е. уже заведомо ошибка. Но самое главное, опять же, это минимальные знания в "учебниках" по корпоративному QoS, написанных в лохматые годы, а в нарезании полосы клиентам нужно пользоваться здравым смыслом и современными реалиями.

 

Вот к примеру исследование, где явно доказывается, что для достижения вашей скорости burst должен быть не менее ~1.5Mbyte.

https://www.cnaf.infn.it/~ferrari/tfngn/cat6500/police/tcp/

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

[AlKov]

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

Именно так! Но клиент в этом участвовать совершенно не обязан.

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

ИМХО, в данном случае, клиенту необходимо согласовать с провайдером дату/время проведения работ в режиме "он-лайн", обеспечив при этом мониторинг со своей стороны.

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

Использование "почтовой" схемы - "мы кое-что подкрутили, проверьте.." - "..проверили, плохо..", не эффективно.

[NikAlexAn]

Кстати, если уж говорим про минимумы, есть такое правило, когда скорость значительно меньше скорости интерфейса, и берст в виде speed*0.5ms, то минимальный берст отсчитывается от MTU интерфейса, обычно равен 10xMTU. (QOS-Enabled Networks: Tools and Foundations, стр. 114, и, http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/policer-mx-m120-m320-burstsize-determining.html)

НО. В данном случае, 5ms*speed - больше, чем правило с MTU. Т.е. уже заведомо ошибка. Но самое главное, опять же, это минимальные знания в "учебниках" по корпоративному QoS, написанных в лохматые годы, а в нарезании полосы клиентам нужно пользоваться здравым смыслом и современными реалиями.

В приведённой Вами выше цитате и 5мс привязывается к "full line rate of a policed interface", я эту строчку понял так что burst должен быть не меньше чем 5мс трафика на скорости интерфейса.

[yKpon]

победа!

 

проблему решили, что сделали не знаю, но предполагаю что увеличили burst

теперь чётко 30 мегабит, без шейпера пакеты немного теряются при топе, но скорость держит

до 11 без шейпера, видно что пакеты дропаются

в 11 включил шейпер на 28М

 

вот как то так, сейчас напишу им всё таки выпрошу что они изменили

 

всем спасибо за подсказки и поддержку =)

Изменено 28 мая, 2015 пользователем yKpon

[Smoke]

щасьте!

 

проблему решили, что сделали не знаю, но предполагаю что увеличили burst

теперь чётко 30 мегабит, без шейпера пакеты немного теряются при топе, но скорость держит

до 11 без шейпера, видно что пакеты дропаются

в 11 включил шейпер на 28М

 

вот как то так, сейчас напишу им всё таки выпрошу что они изменили

 

всем спасибо за подсказки и поддержку =)

Перфекто! это гораздо лучше чем бегать от магистрала к магистралу не понимая что происходит.

[yKpon]

всё таки нет, burst оставили тот же

В данном случае настройка стандартная и проведена вендором с учетом пропускной способности порта.

 

В данном случае все сводится к тому, что в з/о МегаФон проблем не было.

 

Все ограничения корректны.

 

На линии перегрузок нет.

[Smoke]

всё таки нет, burst оставили тот же

В данном случае настройка стандартная и проведена вендором с учетом пропускной способности порта.

 

В данном случае все сводится к тому, что в з/о МегаФон проблем не было.

 

Все ограничения корректны.

 

На линии перегрузок нет.

Поправили дуплекс на транзитном свиче :)

[darkagent]

не хотят признавать свои косяки, да уж.

[yKpon]

Рано радовались, канал загружен на половину, прут потери

[yKpon]

заунывная песня продолжается

сайты почти не открываются, форум еле открылся

 

моё желание общаться с ТП закончилось, дальнейшие шаги? жалоба руководству?

[yKpon]

их ответ

 

smena_cf@VLD-PE-MX960-2_re0> show policer | match xe-0/2/0.989

 

30M-xe-0/2/0.989-log_int-i 80387966634 60259516

 

30M-xe-0/2/0.989-log_int-o 102479719135 71709327

 

 

 

{master}

 

smena_cf@VLD-PE-MX960-2_re0> show policer | match xe-0/2/0.989

 

30M-xe-0/2/0.989-log_int-i 80387966634 60259516

 

30M-xe-0/2/0.989-log_int-o 102480801706 71710069

 

 

 

{master}

 

smena_cf@VLD-PE-MX960-2_re0> show policer | match xe-0/2/0.989

 

30M-xe-0/2/0.989-log_int-i 80387966634 60259516

 

30M-xe-0/2/0.989-log_int-o 102481830984 71710775

 

 

 

smena_cf@VLD-PE-MX960-2_re0> ping 46.232.207.195 rapid count 1000 size 1472

 

PING 46.232.207.195 (46.232.207.195): 1472 data bytes

 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

--- 46.232.207.195 ping statistics ---

 

1000 packets transmitted, 1000 packets received, 0% packet loss

 

round-trip min/avg/max/stddev = 5.495/6.254/349.579/10.939 ms

[darkagent]

моё желание общаться с ТП закончилось, дальнейшие шаги? жалоба руководству?

с этого надо было начинать ;) тогда и общение с ТП становится более продуктивным ;)