Baneff

Вот зачем вы так? Вас в детстве обижали? Характер испортился? Ведь ваш любимый Дебиан никто гавном не поливает, правда? Ну прямо как любимого котика ногой пнули. Некультурно, фи...

Вот наверное да, но я не пробовал и не буду, нас и на dummynet-е неплохо кормят. Что-то нетграф мне в своё время не лёг в руку, бывает такое. Конструктор-головоломка такая себе. Так что не буду плодить сущности ибо простота - залог здоровья .

Если вопрос ко мне, то я не сравнивал, лично я даже не знаю как конкретно на фре реализовать полисер, всегда использовал только шейпер. А что спидтест может показать? Это может быть важно? И то и другое ограничивает скорость, только разными методами. Так что думаю покажет одно и то-же.

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

Я не фанат линукса, что такое tc - не знаю. Мне сказали выше, что он аналог dummynet в линуксе, значит я неправильно понял. Там в обсуждении - я сказал где. Хотите конкретно - пожалуйста, просто не хотелось чтобы опять политический срач тут поднялся по поводу куда надо и куда не надо ходить. https://forum.nag.ru/index.php?/topic/153222-tc-centos-7-gruzyat-processor-pod-100/

Где тут речь была о пакетном фильтре? Он и на фре паралелится. Речь была о шейпере. Шейпер в tc многопоточный? Не делайте вид, что не понимаете разницы. И да, проще посоветовать человеку перейти на ratelimit и это не потому, что человек этот тупой, а потому что другого решения проблемы просто нет, по крайней мере там в обсуждении его никто не предложил.

Смеялся. Пару месяцев назад на известном вражеском форуме обсуждалась тема "tc + centos 7 грузят процессор под 100%". Так вот, это вам ничего не напоминает? И главная рекомендация - перейдите на ipt_ratelimit и оно попустит. )))

И, кстати, tc ваш параллелится?

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

Ха, та кокой же это шейпер? Пакеты дропать много ума не надо, так и на фре можно без всяких там нагрузок. Шейпер под Дебиан есть? Ну хоть что-то близкое по функционалу к dummynet ?

А шейпер для IPoE под дебианом как реализован? Имхо шейпинг - узкое место в софтовых брасах. Терминация, нат, файервол, птичка при наличии x520-DA2 на любой системе до 10 гиг прокачается юзерского трафика при современной средней длине пакета около 900 байт. Поскольку всё отлично паралелится, а процессоры многоядерные и память сейчас копейки стоят на вторичном рынке. У FreeBSD вижу единственное узкое место - лучший шейпер этой системы dummynet не параллелится и это заставляет искать не столько многоядерные системы, сколько системы с максимальным быстродействием на одно ядро. Конечно, при прави

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

Ну вы пошли в обход вместо того, чтобы разобраться в чём дело. Я тоже из своего опыта: за много лет никогда не возникало необходимости включать pf и нагрузка как бы давно не 600кбит/с. Большую роль играет правильность составления правил ipfw. Всё должно быть логично, всё что можно - паковать в таблицы, минимум правил. А я встречал конфигурации, где были тысячи правил, так чего ж удивляться. Вот, например ниже график загрузки процессора (зелёный) и отдельно dummynet (синий) на довольно таки нагруженной машинке на боевом дежурстве. Никаких костылей, всё штатно.

И ещё, на всякий случай напомню, что dummynet - это только одна из частей ipfw, которая занимается только шейпингом, всё остальное в ipfw прекрасно параллелится.

От же ж. Ну почему он ущербный? Однопоточность его - это единственный недостаток, который работе не мешает. Он и в один поток шейпит прекрасно. Чем шейпить-то будете?

А зачем такой венигрет? Зачем сразу и ipfw и pf ? Там у вас наверное еще много сюрпризов, по одному выдаёте нагора?

Вы там в соседней теме интересуетесь как посмотреть сколько pf кушает. У вас там ещё и pf есть? Извините за любопытство.

Уж много раз твердили миру... Лучшая система - это та, которую лучше всего знает ваш админ. Да хоть бы и Микротик, тоже есть специалисты, которые собаку на нём съели. Ну нравится им и всё, чего уж тут. Но что интересно, обычно именно приверженцы линуха особо агрессивны в форумах. Вот например специалисты по Junos или IOS вообще обычно помалкивают, хотя им точно есть что сказать

О, линуксятники набежали ))) . Чего вы обижаетесь? Хорош ваш линух, хорош, зачем спорить? Но вам же сказали ясно, у человека FreeBSD, так уж сложилось, и эта тема не по линух и не про то, что круче. Иш как возбудились, услышав об однопоточном dummynet , но он хоть и однопоточный, но есть и работает прекрасно, вместе с быстрыми и удобными многопоточными ipfw и ядерным nat-ом. А по делу, то как работала фря, так и работает несмотря на крики и вопли "рок-н-ролл мёртв". Старый конь борозды не испортит. Я 20+ лет на фре и менять ничего не собираюсь, надеюсь доживу уже с ней. Если бы речь шла о выбо

Ну во первых - да, в эру анлимов особого смысла следить за трафиком юзеров не вижу ни для себя ни для самих юзеров. Если им надо - пусть сами считают, есть чем, слава Богу. Ну если провайдер особо жадный, то да, можно отслеживать и отстреливать наиболее потребляющих. Некоторые так делают, но каналы сейчас дешёвые, я считаю проще забить и забыть ибо сам подсчёт, контроль и отстрел тоже денег и нервов стОит. Другое дело - если по какой-то причине требуется детализация и архивирование трафика. Тогда - да, проблема. Любой коллектор даст большую нагрузку. Во вторых, методы есть. Например при схеме

Да, это тоже проходили, конечно убрать ipcad . Надо было сразу огласить весь список. Лично я не против варианта "всё в одном", но некоторые вещи таки не стОит. А оно надо вообще, траффик мониторить? Кроме того есть и другие методы.

Ещё добавлю по поводу измерения нагрузки на ядра и процессы. Да, есть штатный top и в портах есть atop удобный и логи пишет. Есть в портах ещё какие-то утильки подобные. Но в своё время писали в форумах, что они неправильно показывают загрузку. Не знаю правильно или неправильно, сравнивать лень было, но была поставлена задача нарисовать с помощью системы mrtg (есть в портах) точно правильный график общей средней загрузки по всем ядрам и процессам и отдельно, как самый критичный, график загрузки dummynet. Оказалось, что самая первичная и самая точная информация о загрузке выдается в системных п

Отвечу тут на обращение в личку, может ещё кому пригодится. По поводу привязки процессов к ядрам. к ядрам. По состоянию на FreeBSD 11 . В 12 и 13 возможно что-то поменялось, не знаю, надо проверять. Наши эксперименты привели к отрицательному результату: попытка привязать dummynet или прерывания к ядрам ничего не улучшили, а может даже и ухудшили ситуацию. Система сама достаточно хорошо рапределяет нагрузку по ядрам в автомате, без ручного управления, поэтому в результате мы от привязки отказались. По поводу dummynet есть в нюансы. Во первых, надо учитывать, что dum

Ну сам-то ipfw сильно систему не грузит, это надо специально постараться. Если там максимум несколько десятков правил с правильной логикой последовательности и с упаковкой данных в таблицы, то всё будет ок. Штатный ядерный NAT тоже не должен создавать большой нагрузки по идее. А вот штатный шейпер dummynet может легко пригрузить, да. Ну и потом систему грузит не так скорость, как кол-во пакетов в сек pps, котрые через систему пролетают? То есть если летит куча мелких пакетов, то это грузит больше. Но это ж азы, я так, на всякий случай.

Это фантастика какая-то. Ищите узкое место ибо 500мбит/с должно даже на одной встроенной карт работать, а не то что на лагге из 4-х интеловских карт. Смотрите загрузку процессора поядерно (top может показівать неверно!), смотрите есть ли потери пакетов, смотрите, какой именно процесс садит производительность, смотрите действительно ли приём и передача пакетов равномерно распределяются по физическим интерфейсам. Роутинг - это что? Есть BGP или просто статика? Нат, шейпер, файервол вполне могут садить всё. На чём сделано? Штатно, на ipfw? Ой, да тут столько вариантов может быть, что даже тяжело