mirror of
https://github.com/sshuttle/sshuttle.git
synced 2025-04-27 12:49:31 +02:00
man page for the --no-latency-control option.
This commit is contained in:
parent
a30c4d7ccb
commit
d9b1bb52e5
20
sshuttle.md
20
sshuttle.md
@ -1,6 +1,6 @@
|
|||||||
% sshuttle(8) Sshuttle 0.44
|
% sshuttle(8) Sshuttle 0.46
|
||||||
% Avery Pennarun <apenwarr@gmail.com>
|
% Avery Pennarun <apenwarr@gmail.com>
|
||||||
% 2010-12-31
|
% 2011-01-25
|
||||||
|
|
||||||
# NAME
|
# NAME
|
||||||
|
|
||||||
@ -109,6 +109,22 @@ entire subnet to the VPN.
|
|||||||
if you use this option to give it a few names to start
|
if you use this option to give it a few names to start
|
||||||
from.
|
from.
|
||||||
|
|
||||||
|
--no-latency-control
|
||||||
|
: sacrifice latency to improve bandwidth benchmarks. ssh
|
||||||
|
uses really big socket buffers, which can overload the
|
||||||
|
connection if you start doing large file transfers,
|
||||||
|
thus making all your other sessions inside the same
|
||||||
|
tunnel go slowly. Normally, sshuttle tries to avoid
|
||||||
|
this problem using a "fullness check" that allows only
|
||||||
|
a certain amount of outstanding data to be buffered at
|
||||||
|
a time. But on high-bandwidth links, this can leave a
|
||||||
|
lot of your bandwidth underutilized. It also makes
|
||||||
|
sshuttle seem slow in bandwidth benchmarks (benchmarks
|
||||||
|
rarely test ping latency, which is what sshuttle is
|
||||||
|
trying to control). This option disables the latency
|
||||||
|
control feature, maximizing bandwidth usage. Use at
|
||||||
|
your own risk.
|
||||||
|
|
||||||
-D, --daemon
|
-D, --daemon
|
||||||
: automatically fork into the background after connecting
|
: automatically fork into the background after connecting
|
||||||
to the remote server. Implies `--syslog`.
|
to the remote server. Implies `--syslog`.
|
||||||
|
Loading…
Reference in New Issue
Block a user