Есть линк от провайдера 200/200 Мбит/с. Используется тип подключения PPPoE. Линк вставлен в машину под управлением CentOS 6.6. Соединение настроено с помощью пакета rp-pppoe, но скорость выше 150 Мбит/с не поднимается. Как правило, вообще не выше 100 Мбит/с на download и ещё меньше на upload. Пробовал воткнуть линк в машину под управлением Win 8.1 - там всё отлично, есть 200/200 Мбит/с.
Сперва грешил на сетевуху (Qualcomm Atheros AR8151 v2.0 Gigabit). Поставил другую - тоже гигабитную TP-Link - та же история. Изначально rp-pppoe стоял версии 3.10-11, скачал с оф. сайта 3.11-12, собрал из исходников - безрезультатно.
Кто-нибудь в курсе, присутствуют ли в пакете rp-pppoe какие-либо ограничения по скорости и можно ли их преодолеть?

Во время пиковой прокачки какая загрузка процессора?

А вообще, для сервера противопоказаны любые сетевухи кроме интела..

(1) 45%
(2) Странное утверждение. Тем более, если учесть, что в PPPoE он клиентом выступает.

(2) Кстати (оффтопик, но по поводу сетевух Интел), есть у меня на одном сервере две интеловских сетевухи - 82579LM и 82574L. Так вот, на них периодически отваливались линки. Причём грешили этим обе (т.е., один линк поочерёдно пробовал использовать сперва на одной, затем на другой). Перепробовал все возможные драйверы - не помогло. Вставил D-Link DGE-560T - никаких проблем.

(3) Если два ядра, то 45% это полностью упор по быстродействию. И подходим как раз к (2) - не работает оффлоадинг в сетевухе. Нормально работающий оффлоадинг для линукса есть только у интела.

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

Опять же, любой оффлоадинг - это по сути "хак" стека tcp/ip, поэтому он должен особо тщательно тестироваться для работы на конкретном ядре под конкретную ОС. У интела такая возможность есть, а у какого-нибудь длинка или того хуже нонейма - вряд ли. Поэтому на сервере может быть или интел с оффлоадингом (при высокой нагрузке на сеть и для высокой скорости), или же тупая карточка без оффлоадинга типа rtl8139, где весь стек tcp/ip предоставляется ядром.

(5) Хорошо. Но я тестировал iperf'ом скорость через вторую сетевуху (тоже без TOE), которая смотрит в локалку - выдавало 500-600 Мбит/с.

(8) Да, похоже, вы уперлись в производительность по rp-pppoe, а оффлоадинг на сетевухе ни при чем. Он и не задействуется - pppoe работает поверх сырого эзернета, а не поверх tcp/ip.

Попробуйте часть нагрузки передать на ядро из юзерспейса.
http://norean.freecontrib.org/nakooki/SVN/snapshot/nakooki/0.3/docs/pppoe-HOW-TO.html

(9) Идея неплохая, я тоже над этим задумывался, только вот там уже и так всё включено, за исключением CONFIG_PPP_BSDCOMP. Правда, я так толком и не въехал, за что отвечает этот параметр, что это за BSD-компрессия.

-bash-4.1# grep -i ppp /boot/config-`uname -r`
CONFIG_HDLC_PPP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_PPPOL2TP=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set

(10) Как я понял, на новых линуксах достаточно загрузить модуль ядра командой "modprobe pppoe" и прописать её в автозагрузку через modprobe.d, а в /etc/ppp/options прописать "plugin rp-pppoe.so"

(11) Всё. Дошло. Неправильно статью прочитал. Нужно 'm' изменить на 'y'.
"This can be set to 'y' instead of 'm', according to your needs".
Спасибо за статью. Вечером попробую, а то чую, удалённо лучше этим не заниматься =)

(11) И через modprobe тоже попробую, спасибо.

(11) Всё получилось: http://www.speedtest.net/my-result/3992376409
Огромное спасибо!
Правда, пришлось немного повозиться - поначалу не получалось скомпиллить плагин. Я не сразу сообразил, что он ищет заголовки из исходников pppd. После того, как собрал pppd из исходников, заголовки встали по нужным путям, и плагин успешно скомпиллировался.

(14) А штатный бинарник из репозитория не заработал?

(15) Он без плагина идёт. Плагин нужно собирать из исходников, указывая конфигуратору параметр --enable-plugin

Здесь документация: http://werc.engr.uaf.edu/~ken/doc/rp-pppoe-3.8/KERNEL-MODE-PPPOE

Вот для версии 3.11: https://github.com/sklvjz/rp-pppoe-3.11/blob/master/doc/KERNEL-MODE-PPPOE

(16) Странно, у меня на centos 5.11 вполне идёт в пакете

#rpm -qf `locate rp-pppoe.so`
ppp-2.4.4-2.el5

А в чем глубинный смысл сборки ppp из исходников последней версии?

(19) А вот в пакете pppd я его искать не додумался =D
Ну ладно. Зато стоят теперь последние стабильные версии =)

(19) Глубинный смысл в том, что rp-pppoe при сборке плагина смотрит в исходники pppd и громко матерится, если их не находит на нужных местах. Я пробовал указать конфигуратору путь к исходникам, но этого оказалось мало. Скрипт компиляции ищет ещё разные заголовки, которые по разным путям расположены.

Мыши давились, кололись, но продолжали жрать кактус...

(22) Это вы о сборке из исходников?

(23) Это я о студенческой под(д)елке

(24) А что не так?

(24) Весь гугл работает на этой студенческой поделке. Вообще считаю, что работа с сетью в линуксе намного серьезнее сделана, чем в винде. Взять хотя бы вланы и стп, которые под виндой не заведешь, если производитель сетевухи не включил соответствующие функции в драйвер..
(20) Ну и зря. Я тоже раньше собирал из исходников, а после понял, что если какой-то пакет из репозитория работает - то не надо его трогать. В 99% случаев он собран правильно и оптимально, при пересборке в лучшем случае получим пару процентов выигрыша.

(26) Ну, под мою ЦентОСь в репозитории 11-й версии пакета rp-pppoe нет. А выигрыш в 11-й версии, например, такой, что она позволяет MTU 1500 для PPP. Правда, в моём случае, пожалуй, вы правы - ведь со стороны провайдера MTU всё равно 1492  =)