[AKim]

нас на х86 были проблемы с потерей пакетов, выяснилось из-за сетевухи intel pro 1000 т.к портов нужно много решили купить ccr (дешевле получается), не жалею, подправили конфиг сейчас 30% процы при гиге ната и 700 человеков онлайн шейпер. Тарифы от 30до 100мбитИзображение

прям щас крайний тариф http://www.speedtest...sult/4309532156

 

 

когда показываете загрузку микротика, показывайте и статистику по каждому ядру. А то общая статистика не даёт картины. Может у вас 5 ядер в полке, а остальные спят)

[apathy]

Может не в тему (покритикуйте), использую тик x86 с таким шейпером

Flags: X - disabled, I - invalid, D - dynamic 
0    name="First" target="" dst=ether1 parent=none packet-marks=client_First_traffic priority=7/7 queue=PCQ_First_up/PCQ_First_down limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s 
     total-queue=ethernet-default 

1    name="Gold+" target="" dst=ether1 parent=none packet-marks=client_Gold+_traffic priority=7/7 queue=PCQ_Gold+_up/PCQ_Gold+_down limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s 
     total-queue=ethernet-default 

2    name="GoldHappy" target="" dst=ether1 parent=none packet-marks=client_GoldHappy_traffic priority=8/8 queue=PCQ_GoldHappy_up/PCQ_GoldHappy_down limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 
     burst-time=0s/0s total-queue=ethernet-default 

3    name="YourDay" target="" dst=ether1 parent=none packet-marks=client_YourDay_traffic priority=3/3 queue=PCQ_YourDay_up/PCQ_YourDay_down limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 
     burst-time=0s/0s total-queue=ethernet-default 

4    name="Econom" target="" dst=ether1 parent=none packet-marks=client_Econom_traffic priority=2/2 queue=PCQ_Econom_up/PCQ_Econom_down limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0>
     total-queue=ethernet-default 

5    name="Current" target="" dst=ether1 parent=none packet-marks=client_Current_traffic priority=2/2 queue=PCQ_Current_up/PCQ_Current_down limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 
     burst-time=0s/0s total-queue=ethernet-default 

6    name="Unlim700" target="" dst=ether1 parent=none packet-marks=client_Unlim700_traffic priority=7/7 queue=PCQ_Unlim700_up/PCQ_Unlim700_down limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 
     burst-time=0s/0s total-queue=ethernet-default 

Это часть тарифов. В Mangle мечу конекты и пакеты. Заданы PCQ, ether1 канал от вышестоящего. Queue tree не использую.

[nuclearcat]

intel pro 1000 могла быть и PCI :) Тогда все упрется в потолок на 600М

[Monstreek]

она была pci-e, были проблемы с тем что при низком pps (менее 20 тысяч) и трафике менее 100 мбит/c начинались потери пакетов на внешних интерфейсах, отключение очередей, натов, других правил фаервола не помогали, потери были даже до ip адреса самого miktorik, в другой теме жаловались http://forum.nag.ru/forum/index.php?showtopic=101360 , советы по отключению HT, режимов энергопотребления и прочего успехов не дали

 

у себя на стенде пробовал на такой же сетевой карте Intel 82571EB при отсутствии трафика потерь нет, от 20 до 100 потери есть, от 100 и выше до 1000 потерь нет, заменил сетевую карту Intel 82576 и I350-T4 проблем уже не наблюдалось (на стенде, при живом трафике не проверял)

 

когда показываете загрузку микротика, показывайте и статистику по каждому ядру. А то общая статистика не даёт картины. Может у вас 5 ядер в полке, а остальные спят)

конечно нагрузка на некоторых ядрах в час пик подлетает к 95%, но другие тоже начинают загружаться и нагрузка распределяется не равномерно конечно, но нет простаивающих ядер

 

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

Изменено 23 апреля, 2015 пользователем Monstreek

[nuclearcat]

На линуксе такое отключается параметрами ядра. В микротике такой возможности не дадут. Ну и throttle rate - тоже. Хотя вероятно для CCR они эти параметры подкрутят, это пока платформа у них в фаворе. А как не в фаворе, так в новых релизах у нее начнется та же песня, как и у андроидных телефонов с прошивками от производителя, начнет тормозить больше и больше. И не со зла скорее всего, просто продукт не приоритетный, и скорее всего вылизывать прошивки под него перестанут. Но у андроидов все решается cyanogen и прочими бесплатными прошивками, а с Микротиком - бамбук.

 

Неравномерная нагрузка ядер - явный признак того, что начнутся(если уже не начались) подземные стуки. Так как траффик распределяется по tuple (dst-src ip + dst-src port), то у вас просто некоторые виды траффика будут дропаться, так как упрутся именно в это ядро 95%. И это соединение будет ходить именно по этому ядру. Т.к. скажем у кучи юзеров в один прекрасный момент перестанет надежно работать любимая игрушка, и врядли вы сможете эту проблему как-то найти (пинг и прочее будут другим tuple ,и всё будет прекрасно). И это еще вы видите только загрузку ядер, а в многоядерной архитектуре микротика весьма немало узких мест. К примеру такого понятия как производительность контроллера памяти - он не мониторит.

К сожалению у меня не сохранилось наглядного примера(графиков), когда я не имел мониторинга, и не знал о реальной картине неравномерности загрузки ядра, и именно с такими симптомами и столкнулся, когда жалуются на приложение, я смотрю на загрузку, вижу что большинство ядер 60%, а парочка под 90%, ну думаю - еще десяточка есть, все норм. И в суммарном обьеме на интерфейсе дропается 0.1% траффика, тоже вроде очень немного, думал - подождет до апгрейда сервера. Потом один клиент с игрушкой просто в сердцах сказал, что его задолбал хреновый сервис, и его игруха периодически то тормозит, то не работает вообще. Я начал копать, сделал ему bypass этого сервера, и опа - все нормально. Копался вечь вечер, выровнял ядра (нашел ошибку, не так хешировал RPS), и клиент на следующий же день написал - что все отлично стало работать. Кстати тюнингом параметров довел до того, что и при неравномерности не дропает, а буферизует.

 

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

У микротика в новых версиях конечно иногда фиксят баги, но еще и добавляют в два раза больше. В итоге и начинается прыгание по версиям, в надежде найти золотую середину. Не работа, а рулетка какая-то. Некоторые говорят - "ставь 5-ю ветку", ну блин дело в том, что у Микротика это не стабильная ветка, а та ветка, на которую они тупо забили, да, новых багов вносят немного, и больше фиксят (относительно новых багов, но меньше фиксов - относительно текущей ветки) и портируют некоторые изменения(с багами), если совсем уж припекло, но никто отдельно поддержкой "стабильных" версий не занимается.

[Saab95]

А что, на микротике уже не надо рулить буферы шейперов и сетевых интерфейсов? По умолчанию у шейпера вообще 10 пакетов или 50 в буфере, этого мало.

[kosmich7]

у меня микротик на CCR стоит, натит, шейпит 1200+ абонентов. Шейпер ничего не съедает, загрузка в пик 50% (чуть больше гига трафик). До этого три года работало на тазик микротике, поменяли из-за нехватки сетевух и энергопотребления.

Не долго он поработал :-)

Суть проблемы

[Online69]

проблемы на x86 начались в сентябре после замены сетевухи с двух головой на четырех, т.к трафик вырос. Сейчас на CCR всё отлично)

[kosmich7]

А что, на микротике уже не надо рулить буферы шейперов и сетевых интерфейсов? По умолчанию у шейпера вообще 10 пакетов или 50 в буфере, этого мало.

Можеш показать годовые графики 1036 который в качестве pppoe браса пережовует от ~600Мбит и суммарно вход/исход ~130-140К пакетов ?

[Saab95]

Можеш показать годовые графики 1036 который в качестве pppoe браса пережовует от ~600Мбит и суммарно вход/исход ~130-140К пакетов ?

 

Годового нет, если за полгода, когда уперлись в гиг интерфейса, поставили еще один микротик и скорость через каждый уменьшилась в 2 раза.

[nuclearcat]

А что, на микротике уже не надо рулить буферы шейперов и сетевых интерфейсов? По умолчанию у шейпера вообще 10 пакетов или 50 в буфере, этого мало.

Буферы шейперов/интерфейсов - это даже не тюнинг, а предварительный engineering системы под определенное количество траффика. Причем буфер рассчитывается соответственно допустимой задержке, у меня к примеру несколько "правил" - на критичных к задержке абонентах - допустимая задержка не более 1-5% от его минимального RTT(но не менее 1-5ms) к критическим ресурсам. К некритичным - до 10%. Естественно по разным категориям траффика - задержка тоже разная.

Т.е. возьмем из воздуха усредненные параметры, а не с реальных клиентов, скажем у требовательного клиента на канале 200Mbps и минимальном RTT в мир (в Ливане) 40ms, допустимая задержка буферизации на оборудовании 2ms = итого ~50кбайт, или в среднем 100 пакетов (avg packet size 500). Микротик на таких буферах пакеты теряет, там вообще не особо покрутишь параметры системы, в итоге оно может и будет работать, но задержка будет плавать.

Кто-нить вообще мониторит forwarding latency на Микротике? Ооочень сомневаюсь, скорее просто молятся, лишь бы пакеты не дропало и не тормозило :)

[kosmich7]

Saab95 Это рррое брас ? Не вижу ппс и онлайн подключений ? А почему в выходные провалы ?

1036 бордер до 2G NAT трафа 250-300Кппс тоже можеш показать ?

 

Мне тик тоже нравится, но при критичных нагрузках и без них, шаг в лево, шаг в право, просто на ровном месте system rebooted because of kernel failure.

[Saab95]

Мне тик тоже нравится, но при критичных нагрузках и без них, шаг в лево, шаг в право, просто на ровном месте system rebooted because of kernel failure.

 

Они сейчас в новой тестовой прошивке допилили НАТ, он теперь работает в разы быстрее, чем раньше.

 

Буферы шейперов/интерфейсов - это даже не тюнинг, а предварительный engineering системы под определенное количество траффика. Причем буфер рассчитывается соответственно допустимой задержке, у меня к примеру несколько "правил" - на критичных к задержке абонентах - допустимая задержка не более 1-5% от его минимального RTT(но не менее 1-5ms) к критическим ресурсам. К некритичным - до 10%. Естественно по разным категориям траффика - задержка тоже разная.

Т.е. возьмем из воздуха усредненные параметры, а не с реальных клиентов, скажем у требовательного клиента на канале 200Mbps и минимальном RTT в мир (в Ливане) 40ms, допустимая задержка буферизации на оборудовании 2ms = итого ~50кбайт, или в среднем 100 пакетов (avg packet size 500). Микротик на таких буферах пакеты теряет, там вообще не особо покрутишь параметры системы, в итоге оно может и будет работать, но задержка будет плавать.

Кто-нить вообще мониторит forwarding latency на Микротике? Ооочень сомневаюсь, скорее просто молятся, лишь бы пакеты не дропало и не тормозило :)

 

Я ставлю большие буфера, например 1000, 5000, 10000 и т.п. если абонент не превышает лимит, у него задержка маленькая, если грузит на полную, она увеличивается до 100-200 и более мс. Тогда он звонит с жалобой а ему в ответ говорят что он загружает канал на всю. В следующий раз уже не звонят, когда видят высокую задержку, а разбираются сами со своими закачками.

 

Saab95 Это рррое брас ? Не вижу ппс и онлайн подключений ? А почему в выходные провалы ?

1036 бордер до 2G NAT трафа 250-300Кппс тоже можеш показать ?

 

Нет, это шейпер с натом, PPPoE на других микротиках.

[nuclearcat]

Я ставлю большие буфера, например 1000, 5000, 10000 и т.п. если абонент не превышает лимит, у него задержка маленькая, если грузит на полную, она увеличивается до 100-200 и более мс. Тогда он звонит с жалобой а ему в ответ говорят что он загружает канал на всю. В следующий раз уже не звонят, когда видят высокую задержку, а разбираются сами со своими закачками.

А я ставлю буфер поменьше, НО с equal stream balancing. И даже если у клиента стоит закачка windows update, в игрушке у него по прежнему великолепный пинг.

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

Если клиент грузит канал в полочку, это не повод бить его батогом и делать его интернет полным отстоем. Но микротик по другому не умеет

[Saab95]

А я ставлю буфер поменьше, НО с equal stream balancing. И даже если у клиента стоит закачка windows update, в игрушке у него по прежнему великолепный пинг.

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

Если клиент грузит канал в полочку, это не повод бить его батогом и делать его интернет полным отстоем. Но микротик по другому не умеет

 

Для этого есть PCQ, если выдать каждому абоненту шейпер на его основе с классификатором по портам и IP адресам, все его закачки отбалансируются внутри общего ограничения. Но так как у нас основная масса клиентов беспроводные, и вечерами каналы перегружены, это решение не совсем подходит. Клиенты никуда не будут уходить, т.к. нет альтернатив, у сотовых все еще хуже. На оптических сетях используется PCQ, там проблем с задержкой нет при полной утилизации полосы, если он грузит на всю закачкой, то пинги увеличиваются с примерно 2-3мс до 10-20, сильно это картину не портит.

[kosmich7]

Нет, это шейпер с натом, PPPoE на других микротиках.

Тогда

1036 бордер до 2G NAT трафа 250-300Кппс тоже можеш показать ?

[apathy]

Если про это, то до конца понять не могу к чему это применимо?

*) ipv4 fasttrack fastpath - accelerates connection tracking and nat for marked connections (more than 5x performance improvement compared to regular slow path conntrack/nat) - currently limited to TCP/UDP only;
*) added ~fasttrack-connection~ firewall action in filter/mangle tables for marking connections as fasttrack;
*) added fastpath support for bridge interfaces - packets received and transmitted on bridge interface can go fastpath (previously only bridge forwarded packets could go fastpath);
*) packets now can go half-fastpath - if input interface supports fastpath and packet gets forwarded in fastpath but output interface does not support fastpath or has interface queue other than only-hw-queue packet gets converted to slow path only at the dst interface transmit time;

[BETEPAH]

Для этого есть PCQ

Единственная крутая быстро настраиваемая штука для домашних роутеров.

На x86 микротик работал более менее до 1-1.3 гигабита, а потом неумение тика распределять прерывания вылилось во всякие штуки, о которых говорил ядерный кот.

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

[AKim]

На x86 микротик работал более менее до 1-1.3 гигабита, а потом неумение тика распределять прерывания вылилось во всякие штуки, о которых говорил ядерный кот.

 

а что за процессор стоял?

 

У меня в час пик через шейпер прокачивает максимум 650 мбит суммарно. Пришлось отключить шейпер пока что.

[BETEPAH]

Кажется xeon восьмиядерник. Никаких шейперов, только BGP и NAT. Если шейперы, было бы намного хуже.

[Saab95]

Кажется xeon восьмиядерник. Никаких шейперов, только BGP и NAT. Если шейперы, было бы намного хуже.

 

Старый или новый? Если железо серверное старое, то пусть там будет хоть 16 ядер, на задачах роутинга его обойдет современный i3.

[BETEPAH]

Вот счас спецом посмотрел, стояли 2 штуки таких:

model name      : Intel(R) Xeon(R) CPU           X5560  @ 2.80GHz

Старый, нет?

Только вы или читать не умеете, или не хотите читать те строки, где не я один неоднократно говорили, что проблема router os в неумении распределять прерывания. Одно ядро могло быть загружено на 10%, а соседнее на 100% Из-за этого была куча дропов. И не надо говорить про тюнинг буферов. Я полгода чего-то тюнил, версии тика подбирал, всё бесполезно.

Кстати, пробовал тик на новом сервере, где 2 таких проца:

model name      : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz

Вроде новый?

Только там наблюдалась точно такая же картина с прерываниями, но вдобавок ко всему pptp перестал работать, поставил линукс и забыл тик как страшный сон. Чего и всем советую.

[Saab95]

Если не получается распределить прерывания, то надо отключить многопроцессорность.

[Ivan_83]

Я полгода чего-то тюнил, версии тика подбирал, всё бесполезно.

Я за пол года с нуля освоил BSD неплохо так :)

 

Если не получается распределить прерывания, то надо отключить многопроцессорность.

И что это даст?

Останется одно ядро которое будет в полку?

[telecom]

поставил линукс и забыл тик как страшный сон. Чего и всем советую.

+100500

Микротик исключительно как клиентское барахло, и ни как не провайдерское!