Timing in SSH
Apparently, in its neverending quest to save battery, Apple is powering down the wifi system between packets, which means a delay when new packets arrive or need to be sent. This doesn’t materially affect file transfers or streaming because the packets keep coming, but it plays havoc with intermittent communication like a terminal session.
Pistos’s solution was to set up two connections: one that keeps up a constant, albeit low volume, flow of bytes between the Mac and whatever was connected to it; and another for what he really wanted to do. I took his solution and turned it into this short shell script[…]
[…]
A better question might be why Apple is trying to save battery life on a Mac that doesn’t run on battery.
Previously:
3 Comments RSS · Twitter
@Doekman It seems to be a macOS issue because other users encountered the problem when connecting to a Mac from another Mac and from Windows.
I wonder if setting `ClientAliveInterval 1` in the iMac’s `sshd_config` would help?
“Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client.”
In this case you’d probably want to tweak `ClientAliveCountMax` as well, since its default value of 3 might be too sensitive to network interruptions if `ClientAliveInterval` is set to 1:
“The default value [of `ClientAliveCountMax`] is 3. If `ClientAliveInterval` is set to 15, and `ClientAliveCountMax` is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Setting a zero `ClientAliveCountMax` disables connection termination.”
Another thing I’ve discovered is that if Location Services are enabled, my MBP will occasionally scan for nearby WiFi networks, disrupting things like Steam in-home streaming; perhaps that’s also having a detrimental effect.
