SSH on a local machine is slow with Mac os X server
I have a local machine and a mac osx server (mavericks).
I can open a ssh session on the server from the local machine:
user> ssh [email protected]
serveruser@myserver>
However, the ssh connection is very slow. It is as slow as my internet connection. There is no difference between a remote ssh connection to a remote server, and this local ssh connection. And every 10-20 seconds, I have a 1-2 second lag spike, where the terminal doesn't respond, and then I see my actions after a few seconds.
How can this local connection be affected by my internet speed ?
- Note: When using screen sharing, the quality and delay are really bad, so I might have the same problem (the connection going through the internet instead of just locally)
- Note2: The 2 machine are connected via wifi to a router. If I copy files from one machine to another, the speed is about 20MB/s. So the local connection is quite good.
Edit: Some of the test that @MariusMatutiae suggested:
# very inconsistent ping times.
➜ ~ ping 10.0.0.34
PING 10.0.0.34 (10.0.0.34): 56 data bytes
64 bytes from 10.0.0.34: icmp_seq=0 ttl=64 time=142.699 ms
64 bytes from 10.0.0.34: icmp_seq=1 ttl=64 time=571.248 ms
64 bytes from 10.0.0.34: icmp_seq=2 ttl=64 time=193.275 ms
64 bytes from 10.0.0.34: icmp_seq=3 ttl=64 time=211.617 ms
64 bytes from 10.0.0.34: icmp_seq=4 ttl=64 time=28.381 ms
64 bytes from 10.0.0.34: icmp_seq=5 ttl=64 time=337.638 ms
64 bytes from 10.0.0.34: icmp_seq=6 ttl=64 time=78.221 ms
64 bytes from 10.0.0.34: icmp_seq=7 ttl=64 time=100.819 ms
64 bytes from 10.0.0.34: icmp_seq=8 ttl=64 time=11.514 ms
64 bytes from 10.0.0.34: icmp_seq=9 ttl=64 time=141.167 ms
64 bytes from 10.0.0.34: icmp_seq=10 ttl=64 time=166.168 ms
^C
--- 10.0.0.34 ping statistics ---
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.514/180.250/571.248/150.814 ms
# trying google for comparison
➜ ~ ping www.google.com
PING www.google.com (173.194.113.176): 56 data bytes
64 bytes from 173.194.113.176: icmp_seq=0 ttl=52 time=28.173 ms
64 bytes from 173.194.113.176: icmp_seq=1 ttl=52 time=65.306 ms
64 bytes from 173.194.113.176: icmp_seq=2 ttl=52 time=33.831 ms
64 bytes from 173.194.113.176: icmp_seq=3 ttl=52 time=24.287 ms
64 bytes from 173.194.113.176: icmp_seq=4 ttl=52 time=24.642 ms
64 bytes from 173.194.113.176: icmp_seq=5 ttl=52 time=36.327 ms
64 bytes from 173.194.113.176: icmp_seq=6 ttl=52 time=26.143 ms
64 bytes from 173.194.113.176: icmp_seq=7 ttl=52 time=25.572 ms
^C
--- www.google.com ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 24.287/33.035/65.306/12.878 ms
# traceroute seems direct
➜ ~ traceroute 10.0.0.34
traceroute to 10.0.0.34 (10.0.0.34), 64 hops max, 52 byte packets
1 10.0.0.34 (10.0.0.34) 150.568 ms 4.263 ms 2.603 ms
I couldn't start sudo /usr/sbin/ssd -Dd, error is:
Bind to port 22 on :: failed: Address already in use. Cannot bind any address.
$> sudo lsof -i :22
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
launchd 1 root 34u IPv6 0xb1ed5bcf5a84.... 0t0 TCP *:ssh (LISTEN)
launchd 1 root 35u IPv4 0xb1ed5bcf5a84.... 0t0 TCP *:ssh (LISTEN)
$> sudo kill 1 # machine restarts. I'm not a smart man...
And I couldn't scp, it says: scp: /home/server_user/: Operation not supported (remote login is enabled on server)
Solution 1:
This may or may not apply, but I'm putting it out there because my issue is similar, and I found a workaround.
For connections going into my Mac (such as SSH), I was experiencing lag/latency. For example, I would type into the shell (command line), and my keystrokes would not appear until maybe 200 to 600 milliseconds later, and they'd all come through in a burst. This happened all the time, and was infuriating.
In this forum thread, I read that
[Apple/OSX is] powering down the wireless between packets
Eventually, I came around to using this as a solution (run this on the same client computer that you are SSHing from):
ssh username@macservername 'while true; do echo -n .; sleep 0.1; done' > /dev/null
This establishes a constant stream of bytes flowing through the network connection from client to Mac, tricking the Mac into not putting the wifi to sleep.