Tool to measure ssh latency ("sshping") ?

[Jan Schermer]

You are of course right, but maybe also wrong. This is why I recommended looking into multiplexing. If a regular SSH connection was used, there would be too much jitter caused by e.g. DNS cache expiring, randomness diminishing, fork()ing a new SSHD process (and the whole stack of PAM/systemd session/whatever), I think we all know that hiccups happen.
Then such test just needs to be modified to use that multiplexing, and only then it’s worthwhile to do any tuning (like disabling/enabling Nagle’s algorithm depending on what the RPC payloads would be, or tuning tcp windows etc.).

But I also have a nagging question of “is this a good idea?” in my head. This whole approach of using cat on a file and calling it RPC seems a bit naive, just like something I would do for some simple project, but not something that would be scalable or reliable or worthwhile asking a mailing list about :-))

Jan

> On 28. 7. 2023, at 1:56, John Hawkinson <jhawk at alum.mit.edu> wrote:
> 
> 
> Moving back towards the original question, at least a little bit, it is probably the case that Roland (the OP) does not want to measure the startup overhead of an SSH connection, so notional "time echo test | ssh user at host" solutions are unhelpful and actively misleading. The measurement needs to be done after the SSH connection is set up. Also, because of how TCP works, it's probably wise to think about how much data is being transferred. The timing for an RPC that transfers 100-byte query/responses will come out quite differently than one that transfers 100-megabyte query/responses (or asymmetric variants thereof), even when averaged over time, because of slow start and congestion windows and similar issues (and also because path/packet loss characterics may vary with packet size). So any measurement framework needs to keep that in mind and understand what the data size requirements are for whatever the test is simulating.