AKim Опубликовано 23 апреля, 2015 · Жалоба нас на х86 были проблемы с потерей пакетов, выяснилось из-за сетевухи intel pro 1000 т.к портов нужно много решили купить ccr (дешевле получается), не жалею, подправили конфиг сейчас 30% процы при гиге ната и 700 человеков онлайн шейпер. Тарифы от 30до 100мбитИзображение прям щас крайний тариф http://www.speedtest...sult/4309532156 когда показываете загрузку микротика, показывайте и статистику по каждому ядру. А то общая статистика не даёт картины. Может у вас 5 ядер в полке, а остальные спят) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
apathy Опубликовано 23 апреля, 2015 · Жалоба Может не в тему (покритикуйте), использую тик 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 не использую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 23 апреля, 2015 · Жалоба intel pro 1000 могла быть и PCI :) Тогда все упрется в потолок на 600М Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Monstreek Опубликовано 23 апреля, 2015 (изменено) · Жалоба она была 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 23 апреля, 2015 · Жалоба На линуксе такое отключается параметрами ядра. В микротике такой возможности не дадут. Ну и throttle rate - тоже. Хотя вероятно для CCR они эти параметры подкрутят, это пока платформа у них в фаворе. А как не в фаворе, так в новых релизах у нее начнется та же песня, как и у андроидных телефонов с прошивками от производителя, начнет тормозить больше и больше. И не со зла скорее всего, просто продукт не приоритетный, и скорее всего вылизывать прошивки под него перестанут. Но у андроидов все решается cyanogen и прочими бесплатными прошивками, а с Микротиком - бамбук. Неравномерная нагрузка ядер - явный признак того, что начнутся(если уже не начались) подземные стуки. Так как траффик распределяется по tuple (dst-src ip + dst-src port), то у вас просто некоторые виды траффика будут дропаться, так как упрутся именно в это ядро 95%. И это соединение будет ходить именно по этому ядру. Т.к. скажем у кучи юзеров в один прекрасный момент перестанет надежно работать любимая игрушка, и врядли вы сможете эту проблему как-то найти (пинг и прочее будут другим tuple ,и всё будет прекрасно). И это еще вы видите только загрузку ядер, а в многоядерной архитектуре микротика весьма немало узких мест. К примеру такого понятия как производительность контроллера памяти - он не мониторит. К сожалению у меня не сохранилось наглядного примера(графиков), когда я не имел мониторинга, и не знал о реальной картине неравномерности загрузки ядра, и именно с такими симптомами и столкнулся, когда жалуются на приложение, я смотрю на загрузку, вижу что большинство ядер 60%, а парочка под 90%, ну думаю - еще десяточка есть, все норм. И в суммарном обьеме на интерфейсе дропается 0.1% траффика, тоже вроде очень немного, думал - подождет до апгрейда сервера. Потом один клиент с игрушкой просто в сердцах сказал, что его задолбал хреновый сервис, и его игруха периодически то тормозит, то не работает вообще. Я начал копать, сделал ему bypass этого сервера, и опа - все нормально. Копался вечь вечер, выровнял ядра (нашел ошибку, не так хешировал RPS), и клиент на следующий же день написал - что все отлично стало работать. Кстати тюнингом параметров довел до того, что и при неравномерности не дропает, а буферизует. У меня куча клиентов сидит на линуксе, а дешевые циски делают самую тяжелую работу(и аппаратно - надежнее всяких микротиков и линуксов), и самое главное не цена, а вдумчивый тюнинг, стабильное, проверенное ядро с багфиксами. У микротика в новых версиях конечно иногда фиксят баги, но еще и добавляют в два раза больше. В итоге и начинается прыгание по версиям, в надежде найти золотую середину. Не работа, а рулетка какая-то. Некоторые говорят - "ставь 5-ю ветку", ну блин дело в том, что у Микротика это не стабильная ветка, а та ветка, на которую они тупо забили, да, новых багов вносят немного, и больше фиксят (относительно новых багов, но меньше фиксов - относительно текущей ветки) и портируют некоторые изменения(с багами), если совсем уж припекло, но никто отдельно поддержкой "стабильных" версий не занимается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 23 апреля, 2015 · Жалоба А что, на микротике уже не надо рулить буферы шейперов и сетевых интерфейсов? По умолчанию у шейпера вообще 10 пакетов или 50 в буфере, этого мало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kosmich7 Опубликовано 24 апреля, 2015 · Жалоба у меня микротик на CCR стоит, натит, шейпит 1200+ абонентов. Шейпер ничего не съедает, загрузка в пик 50% (чуть больше гига трафик). До этого три года работало на тазик микротике, поменяли из-за нехватки сетевух и энергопотребления. Не долго он поработал :-) Суть проблемы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Online69 Опубликовано 24 апреля, 2015 · Жалоба проблемы на x86 начались в сентябре после замены сетевухи с двух головой на четырех, т.к трафик вырос. Сейчас на CCR всё отлично) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kosmich7 Опубликовано 24 апреля, 2015 · Жалоба А что, на микротике уже не надо рулить буферы шейперов и сетевых интерфейсов? По умолчанию у шейпера вообще 10 пакетов или 50 в буфере, этого мало. Можеш показать годовые графики 1036 который в качестве pppoe браса пережовует от ~600Мбит и суммарно вход/исход ~130-140К пакетов ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 24 апреля, 2015 · Жалоба Можеш показать годовые графики 1036 который в качестве pppoe браса пережовует от ~600Мбит и суммарно вход/исход ~130-140К пакетов ? Годового нет, если за полгода, когда уперлись в гиг интерфейса, поставили еще один микротик и скорость через каждый уменьшилась в 2 раза. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 24 апреля, 2015 · Жалоба А что, на микротике уже не надо рулить буферы шейперов и сетевых интерфейсов? По умолчанию у шейпера вообще 10 пакетов или 50 в буфере, этого мало. Буферы шейперов/интерфейсов - это даже не тюнинг, а предварительный engineering системы под определенное количество траффика. Причем буфер рассчитывается соответственно допустимой задержке, у меня к примеру несколько "правил" - на критичных к задержке абонентах - допустимая задержка не более 1-5% от его минимального RTT(но не менее 1-5ms) к критическим ресурсам. К некритичным - до 10%. Естественно по разным категориям траффика - задержка тоже разная. Т.е. возьмем из воздуха усредненные параметры, а не с реальных клиентов, скажем у требовательного клиента на канале 200Mbps и минимальном RTT в мир (в Ливане) 40ms, допустимая задержка буферизации на оборудовании 2ms = итого ~50кбайт, или в среднем 100 пакетов (avg packet size 500). Микротик на таких буферах пакеты теряет, там вообще не особо покрутишь параметры системы, в итоге оно может и будет работать, но задержка будет плавать. Кто-нить вообще мониторит forwarding latency на Микротике? Ооочень сомневаюсь, скорее просто молятся, лишь бы пакеты не дропало и не тормозило :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kosmich7 Опубликовано 24 апреля, 2015 · Жалоба Saab95 Это рррое брас ? Не вижу ппс и онлайн подключений ? А почему в выходные провалы ? 1036 бордер до 2G NAT трафа 250-300Кппс тоже можеш показать ? Мне тик тоже нравится, но при критичных нагрузках и без них, шаг в лево, шаг в право, просто на ровном месте system rebooted because of kernel failure. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 24 апреля, 2015 · Жалоба Мне тик тоже нравится, но при критичных нагрузках и без них, шаг в лево, шаг в право, просто на ровном месте 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 на других микротиках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 24 апреля, 2015 · Жалоба Я ставлю большие буфера, например 1000, 5000, 10000 и т.п. если абонент не превышает лимит, у него задержка маленькая, если грузит на полную, она увеличивается до 100-200 и более мс. Тогда он звонит с жалобой а ему в ответ говорят что он загружает канал на всю. В следующий раз уже не звонят, когда видят высокую задержку, а разбираются сами со своими закачками. А я ставлю буфер поменьше, НО с equal stream balancing. И даже если у клиента стоит закачка windows update, в игрушке у него по прежнему великолепный пинг. Угадайте, в условиях конкуренции вашего решения, когда у клиента при каждой закачке апдейта с телефона или винды, кого-либо в доме, будет отваливаться игруха(и он будет слушать ваши сказки про не грузить канал), или у меня - когда у него всегда пинг ровный (если конечно не влупит совсем уж много закачек) - к кому он пойдет? Если клиент грузит канал в полочку, это не повод бить его батогом и делать его интернет полным отстоем. Но микротик по другому не умеет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 24 апреля, 2015 · Жалоба А я ставлю буфер поменьше, НО с equal stream balancing. И даже если у клиента стоит закачка windows update, в игрушке у него по прежнему великолепный пинг. Угадайте, в условиях конкуренции вашего решения, когда у клиента при каждой закачке апдейта с телефона или винды, кого-либо в доме, будет отваливаться игруха(и он будет слушать ваши сказки про не грузить канал), или у меня - когда у него всегда пинг ровный (если конечно не влупит совсем уж много закачек) - к кому он пойдет? Если клиент грузит канал в полочку, это не повод бить его батогом и делать его интернет полным отстоем. Но микротик по другому не умеет Для этого есть PCQ, если выдать каждому абоненту шейпер на его основе с классификатором по портам и IP адресам, все его закачки отбалансируются внутри общего ограничения. Но так как у нас основная масса клиентов беспроводные, и вечерами каналы перегружены, это решение не совсем подходит. Клиенты никуда не будут уходить, т.к. нет альтернатив, у сотовых все еще хуже. На оптических сетях используется PCQ, там проблем с задержкой нет при полной утилизации полосы, если он грузит на всю закачкой, то пинги увеличиваются с примерно 2-3мс до 10-20, сильно это картину не портит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kosmich7 Опубликовано 24 апреля, 2015 · Жалоба Нет, это шейпер с натом, PPPoE на других микротиках. Тогда 1036 бордер до 2G NAT трафа 250-300Кппс тоже можеш показать ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
apathy Опубликовано 24 апреля, 2015 · Жалоба Если про это, то до конца понять не могу к чему это применимо? *) 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; Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 25 апреля, 2015 · Жалоба Для этого есть PCQ Единственная крутая быстро настраиваемая штука для домашних роутеров. На x86 микротик работал более менее до 1-1.3 гигабита, а потом неумение тика распределять прерывания вылилось во всякие штуки, о которых говорил ядерный кот. В итоге переполз на линукс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AKim Опубликовано 25 апреля, 2015 · Жалоба На x86 микротик работал более менее до 1-1.3 гигабита, а потом неумение тика распределять прерывания вылилось во всякие штуки, о которых говорил ядерный кот. а что за процессор стоял? У меня в час пик через шейпер прокачивает максимум 650 мбит суммарно. Пришлось отключить шейпер пока что. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 27 апреля, 2015 · Жалоба Кажется xeon восьмиядерник. Никаких шейперов, только BGP и NAT. Если шейперы, было бы намного хуже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 27 апреля, 2015 · Жалоба Кажется xeon восьмиядерник. Никаких шейперов, только BGP и NAT. Если шейперы, было бы намного хуже. Старый или новый? Если железо серверное старое, то пусть там будет хоть 16 ядер, на задачах роутинга его обойдет современный i3. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 30 апреля, 2015 · Жалоба Вот счас спецом посмотрел, стояли 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 перестал работать, поставил линукс и забыл тик как страшный сон. Чего и всем советую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 30 апреля, 2015 · Жалоба Если не получается распределить прерывания, то надо отключить многопроцессорность. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 30 апреля, 2015 · Жалоба Я полгода чего-то тюнил, версии тика подбирал, всё бесполезно. Я за пол года с нуля освоил BSD неплохо так :) Если не получается распределить прерывания, то надо отключить многопроцессорность. И что это даст? Останется одно ядро которое будет в полку? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 30 апреля, 2015 · Жалоба поставил линукс и забыл тик как страшный сон. Чего и всем советую. +100500 Микротик исключительно как клиентское барахло, и ни как не провайдерское! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...