Оптимизация работы PPP

[Dimka]

На FreeBSD 7.1 используется ppp для поддержки соединения с провайдером через PPPoE.

Суть в том, что на 100 Мбит/с сетке без ограничений по скорости предельная скорость колеблется лишь около 1,5 Мб/с при теоретическом потолке около 10-12 Мб/с. top показывает, что в процессе передачи данных со скоростью 1,5 Мб/с idle системы 0%, остальное всё уходит на system, interrupt (в основном и примерно поровну того и другого) и user (мало); время CPU целиком уходит на ppp.

Машина старая и хилая (PII, 266 МГц), RAM много.

Вопрос: кто занимался подобными вещами и знает, какие опции ppp можно отключать/включить, чтобы повысить производительность? (Экономией трафика можно пренебречь.)

[RXL]

Не знаю, сильно ли отличается текущая версия pppd от 2.4.1, с которой разбирался лет 6 назад. Принцип там, помнится, такой, что к терминалу (pty) цепляется дисциплина ppp, а процессу необходимо считывать данные из терминала. Соотв., производительность упирается в планировщик процессов - как быстро и как часто он передает управление pppd. Машинка действительно хилая. 1.5 МБ/с это минимум 1000 пакетов в секунду. Участие user-space тут наверняка является узким местом.

Попробуй поиграть сжатием: отключить совсем или поднять сжатие на максимум. Думаю, это может дать некоторый прирост.

[Sla]

может где-то установлено в конфигах ppp
set speed

[RXL]

Слав, эта опция имеет смысл только для ttyS.

[Dimka]

RXL, стоп, про pppd речь не шла. Речь про клиент (ppp), а не про сервер (pppd).

Про сжатие я уже тоже думал - попробую на досуге.

Про переключение процессов... понял про демон, понял про устройство, не понял, про какой процесс идёт речь, и между чем происходит переключение. Теоретически для уменьшения числа переключений можно было бы попробовать изменить приоритет, вот только чей?

[RXL]

pppd - симметричный протокол и соотв. симметричный демон. pppoe - плагин к нему.

[Dimka]

Выключение компрессии скорость чуть увеличило до 1.8 Мб/с, но, конечно, радикально вопрос не решило.

[Serg79]

Dimka, какая версия pppd? Недавно вышла версия 2.4.5 попробуй до нее обновится, вполне возможно что будут изменения в лучшую сторону.

[Dimka]

Код:

# pppd --version
pppd version 2.3 patch level 5

Какое было в дистрибутиве, таким и пользуюсь

Попробую поменять. Главное, чтобы стабильная была.

В портах тоже 2.3.

[Dimka]

Никакие версии ppp или pppoe погоды не делают, так как работают в user mode. В kernel mode работает демон mpd. Скорость возросла до 5.3-5.4 Мб/с, при этом idle 10%, interrupt 90%, остальное по нулям.

Можно ещё, конечно, с mtu поиграться, чтобы пакеты из локальной сети не приходилось резать и пересобирать для отправки в канал...

[RXL]

MTU, к сожалению, до 1500 не доведешь - распухший ethernet-пакет может не пройти.

[RXL]

Сейчас борюсь с pptp и нашел некоторые интересные аспекты, которые, Дим, могли и у тебя проявляться.

Например, pptp много писал в syslog, а тот часто сбрасывал строки в лог. Это существенно замедляло работу (до 40% ожидания io на P4 2.8 ГГц). Параметрами pptp подавил логирование (--loglevel 0) и проблема исчезла.
Писались в лог строки типа: accepting packet 877490 (expecting 877489, lost or reordered)

Далее, с MTU, а точнее с MSS в TCP боролся так (у меня не BSD, а Linux, но наверно и в BSD можно что-то подобное):

Код:

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x17/0x02 tcpmss match 1421:65535 TCPMSS set 1420

Смысл: для всех TCP пакетов с флагом SYN, если MSS более 1420, принудительно установить MSS 1420 (что равно MTU - 40).
Это нужно для тех случаев, когда IP пакеты имеют флаг DF (don't fragmentaion).

[Dimka]

Я пока обнаружил положительный момент mpd по сравнению с ppp - надёжность. Бывает, что связь обрывается, провайдер перегружает свой сервер или какие-то работы на линии проводит. В этих случаях у меня ppp зависал и соединение не восстанавливал ни при каких параметрах. Доходило до того, что по cron вешал скрипт, который ежеминутно проверял и в случае необходимости убивал ppp, запуская заново. mpd таким не страдает и восстанавливает соединение после любых пауз.

[RXL]

У меня pppd сам рестартует: параметры: permanent maxfail 0

[Serg79]

Странно слышать что pppd зависает. Он постоянно шлют KeepAlive, и в случаи чего завершает свою работу.

[RXL]

Serg79, у Димки FreeBSD - может там как-то иначе работает, чем в Linux-е.

[Serg79]

Да ладно RXL все то же самое, только обвязку в виде Makefile сделали что бы можно было из портов собирать.

[Dimka]

Serg79, там старый ppp


Комментарий для тех, кто пойдёт моим путём и будет использовать mpd.

Есть маленькая тонкость. Вызывала у меня вопросы странная ситуация, когда половина сайтов не открывалась или открывалась с гигантсткой задержкой (минут 10-15). Сперва грешил на DNS - очень странно он себя вёл, заявлял, что ответы с forward сервера ненадёжные, опрашивал secondary сервер и т.д.

Но тут нашёл иное объяснение. mpd по какой-то причине не обрабатывает длинные IP-пакеты, и они банально теряются. Лечится добавлением в конфиг параметра:

Код:

set iface enable tcpmssfix

В остальном пока полёт нормальный. Если ещё что-то будет - напишу.

[RXL]

Dimka, это проблема с DF и MTU туннеля < 1500. Как и с любым другим туннелирующим протоколом, основанным на пакетном транспортном протоколе. Если бы для транспорта использовался TCP, то проблемы бы не было. Я тоже это лечил:
https://forum.shelek.ru/index.php/topic,23196.msg226250.html#msg226250

Еще интересный факт: снифер мне показал, что одни сайты задают MSS равный возможностям интерфейса - тогда пакет, при проходе через зауженный канал, можно фрагментировать, а другие - много-много больше (например, 2000 или 5000) и уже при передаче через интерфейс самого сайта он фрагментируется и, как следствие, выставляется DF. А некоторые сайты используют MSS, равный возможностям канала, но DF все равно выставляют. Чудеса...
Во всех случаях коррекция MSS в SYN-пакетах лечит проблему.

[Dimka]

MTU 5000... Вроде как на всяких FDDI и прочих высокоскоростных линиях большие MTU.

Но за всё надо платить После этого изменения конфигурации скорость упала до 4.5-4.6 Мб/с. Расклад по ресурсам: user 0%, system 2%, interrupt 85%, idle 13%.

[RXL]

Дим, не MTU, а MSS! Уровень TCP.
Типично, заголовок IP+TCP занимает 40 байт. Максимальный размер пакета = MSS + 40. Если он больше MTU, то фрагментируется. Если в заголовке IP стоит DF, то он отбрасывается.

[Dimka]

RXL, я лишь про то, что выбор MSS зависит от MTU. Большие MSS имеют смысл на линиях с большим MTU.

[RXL]

https://forum.shelek.ru/index.php/topic,23196.msg226888.html#msg226888
Снифер показывает, что многие сайты выбирают MSS не по MTU. Вероятно это оптимизация сетевой подсистемы, чтобы меньше пакетов обрабатывать (полагаю, что фрагментация на выходе интерфейса происходит уже после всех фильтров).

Сейчас попробовал, но не смог повторить эксперимент.