В обычном режиме интерактивного сеанса ssh перенаправляет все символы (кроме экранирующего символа, обычно ~) на удаленный хост, включая ^S ^Q (Все, что находится на дальнем конце соединения SSH/TCP/IP, является «удаленным» для этой цели, даже локальный хост / шлейф или виртуальная локальная сеть.) Если у вас есть «длинный» (задержка распространения) и / или «толстый» (полоса пропускания) канал - и шлейф определенно толстый - объем данных, которые могут быть переданы вам до того, как удаленный хост получит и начнет действовать ^S , вероятно, больше, чем может буферизовать VT100, так как он был спроектирован еще в те дни, когда соединение было фактическим отрезком провода менее 50 'для RS-232 или с прямой модуляцией по одному биту за раз модем вроде 103 или 212А.
Если вы используете ssh с аргументами для запуска команды на удаленном хосте (не интерактивного сеанса), тогда обработка терминала (и ^S ^Q) остается в локальной ОС, которая должна реагировать достаточно быстро. Очевидно, что это ограничивает взаимодействие, которое вы можете выполнять с удаленными хостами. По умолчанию он также выполняет издержки SSH (обмен ключами и аутентификация) для каждой команды, что может быть дороже и медленнее, но в не древних версиях вы можете настроить основной процесс с -M который разделяет транспорт (и стоимость настройки транспорта) с несколько рабочих процессов.
Единственное другое решение, которое я вижу, состоит в том, чтобы не запускать удаленные объекты, которые производят слишком много вывода слишком быстро; например, передать вещи в more или less или подобное, возможно, даже с LINES, установленным на меньше чем 24. Или запишите большой вывод во временный файл и просмотрите его с помощью vi или аналогичного.
