ssh em seu modo de sessão interativa normal encaminha todos os caracteres (exceto sua fuga, geralmente ~ ) para o host remoto, incluindo ^S ^Q . (Qualquer coisa na extremidade de uma conexão SSH / TCP / IP é 'remota' para esse propósito, mesmo localhost / loopback ou LAN virtual.) Se você tiver um 'long' (atraso de propagação) e / ou 'fat' ( largura de banda) pipe - e loopback é definitivamente gordo - a quantidade de dados que pode ser em vôo para você antes que o host remoto receba e atue no ^S é provavelmente mais do que um VT100 pode armazenar em buffer, já que foi projetado de volta os dias em que a conexão era um fio real menor que 50 'para RS-232, ou um modem de modulação direta de um bit por vez como 103 ou 212A.
Se você usar ssh com argumentos para executar um comando no host remoto (não em uma sessão interativa), o manuseio do terminal (e ^S ^Q ) permanecerá no SO local, o que deve responda rápido o suficiente. Obviamente, isso restringe a interação que você pode fazer com o (s) host (s) remoto (s). Por padrão, ele também sobrecarga SSH (keyexchange e autenticação) para cada comando, que pode ser mais caro e mais lento, mas com versões não antigas, você pode configurar um processo mestre com -M que compartilha o transporte (e custo de configuração de transporte) em vários processos de trabalho.
A única outra solução que vejo é não executar coisas remotas que produzem resultados demais muito rápido; por exemplo, canalize as coisas para more ou less ou similar, talvez até com LINES configuradas para menos de 24. Ou grave uma saída grande para um arquivo temporário e procure-o com vi ou similar.