Как сделать PPP надежным по сравнению с убытками радиомодемами с использованием параметров ядра PPPD и TCP на Debian?
Я просто цитирую openSUSE wiki здесь:
Проект Factory является кодовой базой разработки для openSUSE Tumbleweed.
Существует постоянный поток пакетов, поступающих в Factory. Не существует заморозки; поэтому репозиторий Factory не гарантированно является не гарантируется полная стабильность и не предназначен для использования людьми. Основные системные пакеты проходят автоматизированное тестирование через openQA.
Когда автоматизированное тестирование завершено и репозиторий находится в согласованном состояние, репозиторий синхронизируется с зеркалами загрузки и публикуется как openSUSE Tumbleweed. Обычно это происходит один или два раза в неделю.
Фабрика в основном используется как внутренний термин для разработчиков дистрибутива openSUSE. разработчиков, и целевой проект для всех вкладов в openSUSE основную кодовую базу.
Опытным пользователям, разработчикам и соавторам openSUSE рекомендуется использовать скользящий релиз Tumbleweed.
Консервативным пользователям, которым просто нужна работающая система ("если не сломалось, не чини"), рекомендуется остановиться на текущем стабильном релизе.
Leap - текущий стабильный релиз.
Достаточно ясно и лаконично для меня.
В качестве частичного ответа на мой собственный вопрос я добился значительных улучшений надежности за счет следующего:
Изменение подключаемого модуля ядра управления tcp _перегрузкой _с кубического по умолчанию на bbr значительно устранило раздувание буфера, которое наряду с радиосоединением с потерями лежит в основе проблемы.
Это потребовало загрузки модуля ядра tcp _bbr, а также изменения модели организации очередей net.core на справедливую организацию очередей, чтобы обеспечить синхронизацию модуля bbr.
Для RPI значения по умолчанию::
net.ipv4.tcp _перегрузка _control=cubic
net.core.default _qdisc=pfifo _быстрый
Команды для изменения этого во время работы -::
modprobe tcp_bbr
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
Сейчас я запускаю их из сценария, вызываемого из /etc/rc.local. Их можно легко сделать постоянными, изменив modprode.d и sysctl.conf или в виде файла в sysctl.d.
Результатом является гораздо более плавный ответ по ssh и гораздо более надежная массовая передача, которая, несмотря на задержку, быстро восстанавливается и надежно завершается, немедленно возвращаясь в командную строку (, а не приостанавливаясь на 100% в течение длительных периодов времени. -например, 1 -за 3 минуты до возвращения, как в случае кубического управления перегрузкой ).
Компромиссом -является общая скорость, однако надежность важнее.Например, передача файла размером 283 КБ по радиоканалу с использованием scp теперь приводит к:
100% 283KB 2.5KB/s 01:51
Это компромисс, которым я пока вполне доволен. Тем не менее, длительные процессы массовой передачи по-прежнему проблематичны и в конечном итоге останавливаются и никогда не завершаются.
Например, apt -get update работает более часа (зависает на файле размером 11,7 МБ ), требует периодического возврата каретки через ssh-терминал для продолжения работы и в конечном итоге зависает до очень длительная задержка, хотя и не все вместе.
В следующем скрин-скрине процесс длился более 1 часа, с несколькими CR каждые 10 -15 минут и задержкой примерно в 5 минут между отправкой ^C и ответом терминала:
root@priotdev2:~# apt-get update
Get:1 http://mirror.internode.on.net/pub/raspbian/raspbian stretch InRelease [15.0 kB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]
Get:4 http://archive.raspberrypi.org/debian stretch/main armhf Packages [145 kB]
Get:5 http://archive.raspberrypi.org/debian stretch/ui armhf Packages [30.7 kB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
23% [3 Packages 270 kB/11.7 MB 2%] 2,864 B/s 1h 6min 15s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
29% [3 Packages 1,263 kB/11.7 MB 11%] 131 B/s 22h 2min 19s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
60% [3 Packages 5,883 kB/11.7 MB 50%] 16 B/s 4d 4h 13min 58s
60% [3 Packages 5,902 kB/11.7 MB 51%] 1,531 B/s 1h 2min 38s
66% [3 Packages 6,704 kB/11.7 MB 58%]
66% [3 Packages 6,704 kB/11.7 MB 58%]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
66% [3 Packages 6,735 kB/11.7 MB 58%]
66% [3 Packages 6,735 kB/11.7 MB 58%]
66% [3 Packages 6,745 kB/11.7 MB 58%] 32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%] 32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]
66% [3 Packages 6,745 kB/11.7 MB 58%]
66% [3 Packages 6,746 kB/11.7 MB 58%] 230 B/s 5h 55min 46s
66% [3 Packages 6,747 kB/11.7 MB 58%] 148 B/s 9h 12min 47s^C
root@priotdev2:~# ^C
root@priotdev2:~#
root@priotdev2:~#
Прокрутив вправо приведенный выше дамп, можно увидеть ужасную пропускную способность (до 16 и 32 байт в секунду в некоторых случаях ).
Чтобы удалить конечные переменные с -по -, которые также включают спутниковый канал, процесс apt фактически использует восходящий RPI в качестве кэша apt (, который обновлен ), передачи представляют только трафик по радиоканалу.
Будем рады любым советам сообщества по дальнейшим улучшениям.