Como resposta parcial à minha própria pergunta, fiz melhorias significativas de confiabilidade por meio do seguinte:
Mudar o plugin do kernel tcp_congestion_control do padrão cúbico para bbr foi endereçado significativamente ao bufferbloat que, junto com uma conexão de rádio com perdas, está no centro do problema.
Isso exigiu o carregamento do módulo de kernel tcp_bbr e também a mudança do modelo de disciplina de enfileiramento net.core para enfileiramento justo para fornecer o ritmo para o módulo bbr.
Nos RPIs, os padrões são:
net.ipv4.tcp_congestion_control = cubic
net.core.default_qdisc = pfifo_fast
Os comandos para alterar isso em tempo de execução são:
modprobe tcp_bbr
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
Eu atualmente os executo a partir de um script chamado de /etc/rc.local. Eles podem ser facilmente tornados permanentes com modificações em modprode.d e sysctl.conf ou como um arquivo em sysctl.d.
O resultado é uma resposta muito mais suave em relação à ssh e à transferência em massa muito mais confiável, que ainda consegue recuperar rapidamente e ser concluída de forma confiável, retornando ao prompt de comando imediatamente (em vez de pausar em 100% por períodos prolongados - por exemplo 1 - 3 minutos antes de retornar como foi o caso com o controle de congestionamento cúbico).
O trade-off é a velocidade geral, porém a confiabilidade é mais importante. Por exemplo, a transferência de um arquivo 283k através do link de rádio usando scp agora resulta em:
100% 283KB 2.5KB/s 01:51
Este é um compromisso que eu estou feliz o suficiente por agora. No entanto, os processos de transferência em massa de longa duração ainda são problemáticos e, eventualmente, param e nunca são concluídos.
Por exemplo, o apt-get update, rodando por mais de uma hora (paralisando o arquivo de 11.7MB), requer retornos ocasionais através do terminal ssh para continuar rodando, e eventualmente diminuir a latência, embora não falhando todos juntos.
No seguinte raspar de tela, o processo durou mais de 1 hora, com alguns CRs a cada 10-15 minutos e um atraso de aproximadamente 5 minutos entre quando ^ C foi enviado versus o terminal respondendo:
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:~#
Rolando para a direita no dump acima pode ser visto o abismal através de colocar (até 16 e 32 bytes por segundo, em alguns casos).
Para remover as variáveis de ponta a ponta que também envolvem o link do satélite, o processo apt está realmente usando o RPI upstream como um cache do apt (que está atualizado), as transferências representam apenas o tráfego através do link de rádio.
Qualquer esclarecimento da comunidade sobre outras melhorias seria bem-vindo.