kayot Опубликовано 26 февраля, 2013 · Жалоба Вот вы покажите мне параллелность нагрузки на лине, на сетевухах, у которых вообще очередей нету, хотя бы таких как на 82574. Тогда я сразу выброшу тик и соберу бордер на реалтек 8139 и центосе. Выбрасывайте. В линуксах RPS/RFS параллелят на любых сетевках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 26 февраля, 2013 · Жалоба Да, оказывается в CentOS 6.2 появилась интересная штука как RPS/RFS. Каюсь, впервые про это услышал. Но топик начинался про микротик и серверное железо и мне доказывали, что тик параллелить не умеет. Я показал, что умеет, даже с таким количеством очередей как 82574. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 26 февраля, 2013 · Жалоба Да, оказывается в CentOS 6.2 появилась интересная штука как RPS/RFS. Она появилась в 2.6.35 ядре. Летом 2011-го года :) Но топик начинался про микротик и серверное железо и мне доказывали, что тик параллелить не умеет. Я показал, что умеет, даже с таким количеством очередей как 82574. Скрином на 82576? Параллелить умеет только 6-я бета, как уже здесь говорили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 26 февраля, 2013 · Жалоба Как же я устал... Я показывал скрин когда 82574 стояли и тик 5.21 версии, знал бы что троллить будете, то запилил бы ещё скрин с загрузкой по ядрам. Не нравится микротик - не ешьте. Но троллить перестаньте. Она появилась в 2.6.35 ядре. Летом 2011-го года :) И что? Я не ядродрочер, я просто поставил оборудование уже очень давно, когда о гигабите даже не помышляли и оно просто работает не чихая несколько лет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 26 февраля, 2013 · Жалоба До меня после RPS/RFS только счас допёрло, что мы о разных вещах говорим. Короче, кого не устраивает в тике перекос по ядрам, повторюсь, ставьте многоочередные сетевухи и будет вам счастье. Даже при наличии такого старья как 82574L. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 27 февраля, 2013 · Жалоба До меня после RPS/RFS только счас допёрло, что мы о разных вещах говорим. Короче, кого не устраивает в тике перекос по ядрам, повторюсь, ставьте многоочередные сетевухи и будет вам счастье. Даже при наличии такого старья как 82574L. Как-то не стыкуется. "Многочередные сетевки" и "даже при наличии такого старья как 82574L". Современные бзди и линуксы могут размазывать нагрузку софтверно на любых картах, хоть на rtl8139. И это работает для любой ситуации. Сетевки с очередями же работают не всегда. Банальный пример - pppoe BRAS, на нем толку от умных сетевок нет(не IP-трафик) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 27 февраля, 2013 (изменено) · Жалоба kayot 1. Здесь задавался вопрос про микротик, а не про линукс. 2. Я уже ответил, что не знал про новые технологии в линуксе, поэтому я нитро недопонимал, но это к теме топика не имеет отношения. 3. 82574 можно тоже назвать "многоочередные", потому что как минимум у них две раздельных очереди, 1 на приём и 1 на отдачу. 4. В микротике старое ядро линя, но несмотря на это, если кому надо тик юзать, достаточно взять "многоочередные сетевухи" и распределить прерывания про процам. Не будет сильных перекосов по нагрузке. У меня на старом бордере именно так и работало на 82574. 5. У автора топика в сетевухе вообще очередей нету, вот он и удивляется перекосам. Изменено 27 февраля, 2013 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 27 февраля, 2013 · Жалоба tx очередь дает нулевую нагрузку, все эти очереди на старых чипах - самовнушение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 27 февраля, 2013 · Жалоба У автора топика в сетевухе вообще очередей нету, вот он и удивляется перекосам. Если бы была ТХ очередь - что, перекос бы волшебным образом исчез? :) И да, уже говорили: на пппое никакого толку от многоочередных сетевух нет. Все сливается в одну очередь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zmeyko Опубликовано 30 апреля, 2013 · Жалоба Гм, пожалуй, спрошу тут - вроде самая подходящая тема. Есть хотелка клиента - сервер pptp на 900 подключений. Как расчитать, какое х86 железо нужно под RouterOS для такой нагрузки? Трафик через тоннели - централизованная файлопомойка (ftp, webdav), частота обмена\количество файлов небольшое, скажем, пара десятков от каждого клиента за рабочий день. И, главное - оно взлетит вообще? Дальше файлопомойки vpn клиентам ходить не надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 30 апреля, 2013 · Жалоба PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zmeyko Опубликовано 1 мая, 2013 · Жалоба PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи. Так вот хотелось бы точнее знать, сколько вешать. Если не в граммах, то хотя бы в килограммах. Есть какие-то формулы? Железо какое - из HCL только (весьма и весьма древнючего, как справедливо замечено)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 1 мая, 2013 · Жалоба Поставьте 2 железки. Нет смысла ставить мощный сервер, т.к. если он сломается ничего работать не будет. Есть данные о нормальной работе 300-400 PPTP подключений, но там трафика не более 200мбит. Если объемы трафика будут не большие, клиенты будут подключаться без шифрования, то можно попробовать завести все на одну, может и заработает. В то же время по PPPoE аналогичная железка держит 1000 и более клиентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 2 мая, 2013 · Жалоба Гм, пожалуй, спрошу тут - вроде самая подходящая тема. Есть хотелка клиента - сервер pptp на 900 подключений. Как расчитать, какое х86 железо нужно под RouterOS для такой нагрузки? Трафик через тоннели - централизованная файлопомойка (ftp, webdav), частота обмена\количество файлов небольшое, скажем, пара десятков от каждого клиента за рабочий день. И, главное - оно взлетит вообще? Дальше файлопомойки vpn клиентам ходить не надо. лучше взять свежие (linux & accel-ppp) || ( freebsd & mpd ), либо идите в бетатестеры 6й версии routeros. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 2 мая, 2013 (изменено) · Жалоба PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи. а чем помогут "нормальные сетевухи" в случае с gre(которым является по факту pptp)? Изменено 2 мая, 2013 пользователем ^rage^ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 2 мая, 2013 · Жалоба PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи. а чем помогут "нормальные сетевухи" в случае с (которым является по факту pptp)? С PPTP ни чем, однако нет смысла на встроенных сидеть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SmalleR Опубликовано 3 мая, 2013 · Жалоба PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи. а чем помогут "нормальные сетевухи" в случае с (которым является по факту pptp)? С PPTP ни чем, однако нет смысла на встроенных сидеть. Помогут отсутствием потерь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Be_HaPPY Опубликовано 4 мая, 2013 · Жалоба Если что, моя проблема решилась покупкой CCR-1036-12G. Установка микротика на современное железо (Xeon E5620, PCIE Intel Pro/1000) тоже ни к чему хорошему не привела - на больших нагрузках все равно появлялись дропы. А вот тестирование CCR показало, что при полностью загруженных 3-х интерфейсах загрузка железки копеешная и дропы отсутствуют. Но всплыли другие проблемы (например, с шейпером и стабильностью). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 мая, 2013 · Жалоба Что бы дропов не было нужно буфера на интерфейсах подобрать или вообще отключить. В зависимости от сетевухи разное поведение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 4 мая, 2013 · Жалоба Что бы дропов не было нужно буфера на интерфейсах подобрать или вообще отключить. В зависимости от сетевухи разное поведение. о каких именно буферах речь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 мая, 2013 · Жалоба Что бы дропов не было нужно буфера на интерфейсах подобрать или вообще отключить. В зависимости от сетевухи разное поведение. о каких именно буферах речь? Queues -> Interface Queues, на роутербордах по умолчанию вообще программный буфер не используется, а на компе устанавливается Ethernet Default, если буфер отключить то количество дропов намного уменьшается. Конечно тут зависит от оборудования, на некоторых сетевых нужно отключать буфер, на других наоборот увеличивать, подбирается опытным путем. Попробуйте на CCR вместо only-hardware-queue поставить pfifo=100 и сразу пойдут потери. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 4 мая, 2013 · Жалоба Queues -> Interface Queues, на роутербордах по умолчанию вообще программный буфер не используется, а на компе устанавливается Ethernet Default, если буфер отключить то количество дропов намного уменьшается. Конечно тут зависит от оборудования, на некоторых сетевых нужно отключать буфер, на других наоборот увеличивать, подбирается опытным путем. вообще-то это не о буферах, а очереди на интерфейсе ;) дропы потому что так ведет себя дисциплина на интерфейсе(Every packet that cannot be enqueued (if the queue is full), is dropped. Large queue sizes can increase latency, but utilize channel better). Попробуйте на CCR вместо only-hardware-queue поставить pfifo=100 и сразу пойдут потери. вообще-то linux(и микротик в частности) почти ничего не знает о аппаратных tx-очередях в рамках tc(если не считать net/sched/sch_mq.c), а pfifo=100 - это всего лишь fifo-очередь 100 пакетиков, которая быстро переполняется и ессно всё что не влезло в очередь дропается. я бы заменил pfifo на red. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 мая, 2013 · Жалоба Queues -> Interface Queues, на роутербордах по умолчанию вообще программный буфер не используется, а на компе устанавливается Ethernet Default, если буфер отключить то количество дропов намного уменьшается. Конечно тут зависит от оборудования, на некоторых сетевых нужно отключать буфер, на других наоборот увеличивать, подбирается опытным путем. вообще-то это не о буферах, а очереди на интерфейсе ;) дропы потому что так ведет себя дисциплина на интерфейсе(Every packet that cannot be enqueued (if the queue is full), is dropped. Large queue sizes can increase latency, but utilize channel better). Попробуйте на CCR вместо only-hardware-queue поставить pfifo=100 и сразу пойдут потери. вообще-то linux(и микротик в частности) почти ничего не знает о аппаратных tx-очередях в рамках tc(если не считать net/sched/sch_mq.c), а pfifo=100 - это всего лишь fifo-очередь 100 пакетиков, которая быстро переполняется и ессно всё что не влезло в очередь дропается. я бы заменил pfifo на red. И толку, можно указать хоть 10000 пакетов все равно будут дропы, можно поменять на другие типы, например PCQ. Видимо тут какой-то косяк в переходе между буфером сетевой карты и программным. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 5 мая, 2013 · Жалоба Были дропы, но после смены дефолтного ethernet-default на multi-queue-ethernet-default, увеличения в нем queue-size до 500 пакетов и обновления на 6.0rc13, все дропы пропали, чего и вам желаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kiano Опубликовано 10 апреля, 2018 · Жалоба Хотелось бы апнуть тему, прошло почти 5 лет, микротик серьезно допилили routeros, кто поделится своими наработками? Для многих не новость, но проблема 2гб озу уже решается давно, многопоточность сетевух (82599 например) тоже Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...