Этот ответ, вероятно, слишком поздно, чтобы помочь ФП, поэтому следующее для потомков.
Узкое место, вероятно, не имеет ничего общего с mbuffer, но с тем фактом, что данные отправляются через ssh-шифрованное соединение. Другими словами, узким местом является скорость, с которой однопоточный процесс ssh может зашифровать трафик на отправляющем хосте и расшифровать его на принимающем хосте.
Для вашей цели, вероятно, лучше использовать опцию -O mbuffer для отправителя и опцию -I для получателя. Это заставляет mbuffer отправлять данные напрямую по незашифрованному каналу TCP, что продвигает вашу сеть настолько сильно, насколько позволяют ОС, драйверы и оборудование.
Это двухэтапный процесс, потому что вам нужно запустить mbuffer как на принимающем, так и на принимающем узле, например так:
Сначала запустите mbuffer на приемнике. Он будет прослушивать соединение через порт, заданный параметром -I (5567 - это просто пример; выберите свой собственный номер порта):
ssh $outputTarget mbuffer -I 5567 \>$outputDir/$filename
Затем инициируйте перевод на отправителя:
mbuffer -i "$currentFile" -O $outputTarget:5567
Как указано выше, принимающий процесс mbuffer, работающий на $ outputTarget, будет прослушивать и принимать TCP-соединение от любого, кто подключается к этому сокету, а не только от отправляющего процесса mbuffer, запущенного на шаге 2. Таким образом, вы должны помнить о том, что mbuffer, при использовании таким образом, не так безопасен, как ssh, не только потому, что нет шифрования данных, но и потому, что нет способа быть уверенным, что предполагаемый отправитель является только один инициирует соединение с портом прослушивания получателя. Если кто-то не сканирует порт вашего приемника или иным образом не знает, что вы делаете, и не пытается использовать вас, последнее предостережение редко бывает проблематичным. Отсутствие шифрования, с другой стороны, вполне может быть пробой в зависимости от варианта использования.
