[kayot]

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

Выбрасывайте. В линуксах RPS/RFS параллелят на любых сетевках.

[BETEPAH]

Да, оказывается в CentOS 6.2 появилась интересная штука как RPS/RFS. Каюсь, впервые про это услышал.

Но топик начинался про микротик и серверное железо и мне доказывали, что тик параллелить не умеет. Я показал, что умеет, даже с таким количеством очередей как 82574.

[NiTr0]

Да, оказывается в CentOS 6.2 появилась интересная штука как RPS/RFS.

Она появилась в 2.6.35 ядре. Летом 2011-го года :)

 

Но топик начинался про микротик и серверное железо и мне доказывали, что тик параллелить не умеет. Я показал, что умеет, даже с таким количеством очередей как 82574.

Скрином на 82576?

Параллелить умеет только 6-я бета, как уже здесь говорили.

[BETEPAH]

Как же я устал... Я показывал скрин когда 82574 стояли и тик 5.21 версии, знал бы что троллить будете, то запилил бы ещё скрин с загрузкой по ядрам.

Не нравится микротик - не ешьте. Но троллить перестаньте.

Она появилась в 2.6.35 ядре. Летом 2011-го года :)

И что? Я не ядродрочер, я просто поставил оборудование уже очень давно, когда о гигабите даже не помышляли и оно просто работает не чихая несколько лет.

[BETEPAH]

До меня после RPS/RFS только счас допёрло, что мы о разных вещах говорим. Короче, кого не устраивает в тике перекос по ядрам, повторюсь, ставьте многоочередные сетевухи и будет вам счастье. Даже при наличии такого старья как 82574L.

[kayot]

До меня после RPS/RFS только счас допёрло, что мы о разных вещах говорим. Короче, кого не устраивает в тике перекос по ядрам, повторюсь, ставьте многоочередные сетевухи и будет вам счастье. Даже при наличии такого старья как 82574L.

Как-то не стыкуется. "Многочередные сетевки" и "даже при наличии такого старья как 82574L".

Современные бзди и линуксы могут размазывать нагрузку софтверно на любых картах, хоть на rtl8139. И это работает для любой ситуации.

Сетевки с очередями же работают не всегда. Банальный пример - pppoe BRAS, на нем толку от умных сетевок нет(не IP-трафик)

[BETEPAH]

kayot

1. Здесь задавался вопрос про микротик, а не про линукс.

2. Я уже ответил, что не знал про новые технологии в линуксе, поэтому я нитро недопонимал, но это к теме топика не имеет отношения.

3. 82574 можно тоже назвать "многоочередные", потому что как минимум у них две раздельных очереди, 1 на приём и 1 на отдачу.

4. В микротике старое ядро линя, но несмотря на это, если кому надо тик юзать, достаточно взять "многоочередные сетевухи" и распределить прерывания про процам. Не будет сильных перекосов по нагрузке. У меня на старом бордере именно так и работало на 82574.

5. У автора топика в сетевухе вообще очередей нету, вот он и удивляется перекосам.

Изменено 27 февраля, 2013 пользователем BETEPAH

[kayot]

tx очередь дает нулевую нагрузку, все эти очереди на старых чипах - самовнушение.

[NiTr0]

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

Если бы была ТХ очередь - что, перекос бы волшебным образом исчез? :)

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

[Zmeyko]

Гм, пожалуй, спрошу тут - вроде самая подходящая тема.

Есть хотелка клиента - сервер pptp на 900 подключений. Как расчитать, какое х86 железо нужно под RouterOS для такой нагрузки?

Трафик через тоннели - централизованная файлопомойка (ftp, webdav), частота обмена\количество файлов небольшое, скажем, пара десятков от каждого клиента за рабочий день.

И, главное - оно взлетит вообще?

Дальше файлопомойки vpn клиентам ходить не надо.

[Saab95]

PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи.

[Zmeyko]

PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи.

Так вот хотелось бы точнее знать, сколько вешать. Если не в граммах, то хотя бы в килограммах. Есть какие-то формулы? Железо какое - из HCL только (весьма и весьма древнючего, как справедливо замечено)?

[Saab95]

Поставьте 2 железки. Нет смысла ставить мощный сервер, т.к. если он сломается ничего работать не будет. Есть данные о нормальной работе 300-400 PPTP подключений, но там трафика не более 200мбит. Если объемы трафика будут не большие, клиенты будут подключаться без шифрования, то можно попробовать завести все на одну, может и заработает. В то же время по PPPoE аналогичная железка держит 1000 и более клиентов.

[^rage^]

Гм, пожалуй, спрошу тут - вроде самая подходящая тема.

Есть хотелка клиента - сервер pptp на 900 подключений. Как расчитать, какое х86 железо нужно под RouterOS для такой нагрузки?

Трафик через тоннели - централизованная файлопомойка (ftp, webdav), частота обмена\количество файлов небольшое, скажем, пара десятков от каждого клиента за рабочий день.

И, главное - оно взлетит вообще?

Дальше файлопомойки vpn клиентам ходить не надо.

лучше взять свежие (linux & accel-ppp) || ( freebsd & mpd ), либо идите в бетатестеры 6й версии routeros.

[^rage^]

PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи.

а чем помогут "нормальные сетевухи" в случае с gre(которым является по факту pptp)?

Изменено 2 мая, 2013 пользователем ^rage^

[Saab95]

PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи.

а чем помогут "нормальные сетевухи" в случае с (которым является по факту pptp)?

 

С PPTP ни чем, однако нет смысла на встроенных сидеть.

[SmalleR]

PPTP ресурсоемкий протокол, поэтому 900 подключений на одной железке могут и не взлететь. Обычно берут Intel i3 и 2 гига памяти двумя планками, нормальные сетевухи.

а чем помогут "нормальные сетевухи" в случае с (которым является по факту pptp)?

 

С PPTP ни чем, однако нет смысла на встроенных сидеть.

 

Помогут отсутствием потерь.

[Be_HaPPY]

Если что, моя проблема решилась покупкой CCR-1036-12G.

Установка микротика на современное железо (Xeon E5620, PCIE Intel Pro/1000) тоже ни к чему хорошему не привела - на больших нагрузках все равно появлялись дропы.

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

[Saab95]

Что бы дропов не было нужно буфера на интерфейсах подобрать или вообще отключить. В зависимости от сетевухи разное поведение.

[^rage^]

Что бы дропов не было нужно буфера на интерфейсах подобрать или вообще отключить. В зависимости от сетевухи разное поведение.

о каких именно буферах речь?

[Saab95]

Что бы дропов не было нужно буфера на интерфейсах подобрать или вообще отключить. В зависимости от сетевухи разное поведение.

о каких именно буферах речь?

 

Queues -> Interface Queues, на роутербордах по умолчанию вообще программный буфер не используется, а на компе устанавливается Ethernet Default, если буфер отключить то количество дропов намного уменьшается. Конечно тут зависит от оборудования, на некоторых сетевых нужно отключать буфер, на других наоборот увеличивать, подбирается опытным путем.

 

Попробуйте на CCR вместо only-hardware-queue поставить pfifo=100 и сразу пойдут потери.

[^rage^]

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.

[Saab95]

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. Видимо тут какой-то косяк в переходе между буфером сетевой карты и программным.

[BETEPAH]

Были дропы, но после смены дефолтного ethernet-default на multi-queue-ethernet-default, увеличения в нем queue-size до 500 пакетов и обновления на 6.0rc13, все дропы пропали, чего и вам желаю.

[kiano]

Хотелось бы апнуть тему, прошло почти 5 лет, микротик серьезно допилили routeros, кто поделится своими наработками?

Для многих не новость, но проблема 2гб озу уже решается давно, многопоточность сетевух (82599 например) тоже