Is there a way to measure/report the overall latency in a tunneled SSH session?
My particular setup is:
- Client (OS X + wifi router + ADSL modem)
- Gateway SSH server exposed to Internet
- Internal SSH target to which I'm tunneling
I'm interested in seeing the latency between the console on my local machine and the final machine on which I have the session open.
See the
sshping
utility: https://github.com/spook/sshpingExample:
I skipped some steps suggested by @nicht-verstehen:
Where
python -m timeit
executes thetimeit
Python module.The
-s/--setup
option tellstimeit
which statement(s) to execute before each repeat.subprocess.Popen(["ssh", "user@host", "cat"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, bufsize=0)
launchesssh
- executingcat
on your host - as a child/subprocess, redirecting its IO streams to Python file-like objects.bufsize=0
makes sure no IO is buffered, which may cause IO waits.And for each loop:
p.stdin.write(b"z")
writes a single byte to the child (in turn through ssh tocat
).p.stdout.read(1)
reads a single byte from the child. The assertion around it tests whether that byte is the same as the one you wrote to it.Boils down to the same thing, but skips creating the named pipes (
mkfifo
). I noticed that the more loops you run, the faster each loop is. Control it using-n/--number
:python -m timeit --number 50 ...
Was trying to do this myself and came up with this. Probably there is a simpler way, but this is what I came up with.
First, prepare pipes which will be used to make the benchmarking program communicate through the SSH connection.
Then establish a connection in ControlMaster mode without executing any remote command. This allows us to authenticate with the host interactively. After the connection is established, SSH will just "hang" here in foreground.
In a parallel terminal, execute remote
cat
in background. It will be our echo server whose latency we will measure. Inputs and outputs are connected to FIFOs:And then benchmark a small program (send a byte to
up
FIFO, receive a byte fromdown
FIFO):The measure obviously shows the round-trip latency. If you need to repeat the experiment, run the last two commands (
ssh
andpython
) again.If something seems to go wrong, use SSH
-v
flag to get more debugging output.My idea was to use terminal query sequences for this; the advantage is that this can simply be run on the server, the disadvantage is that it measures terminal latency, not only the latency of the connection (but i guess, usually, your terminal's response time will be negligible compared to network delays)—maybe this is even what you mean with overall latency
(This uses "Device Code Query", all terminals that I've tried respond to this: xterm, alacritty, gnome-terminal. I cannot myself try this on MacOS. So YMMV, if this one doesn't, another of the requests that interrogate some information about the terminal might work, see http://web.archive.org/web/20190624214929/http://www.termsys.demon.co.uk/vtansi.htm)
I wrote a Bash script that repeatedly calculates ping-pong RTT/latency. The basic concepts are similar to what others have suggested. The main part does something along these lines:
I have to admit it works better than I expected :]
Example output for my
sshpingpong
:Example output of compact mode using
sshpingpong -L -c [email protected]
where "_" means the RTT was <100ms and e.g. "2" means the RTT was >=200 and < 300ms:The full script is available as Github gist.