8

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)

6
  • On your Linux system, do you have a Broadcom wifi card driven by wl ? lspci -nn | grep -i net ; lsmod | grep wl Jan 7, 2014 at 18:59
  • @MariusMatutiae Both of my machines are macos. My local machine is a MacOS 10.8 and the server is mavericks server. Those commands do not exist on mac, and I don't know what the equivalent is. Jan 8, 2014 at 9:47
  • Are the two macs close to each other? Jan 8, 2014 at 10:26
  • They are both close to the router, connected via wifi. (30cm and 1m) Jan 8, 2014 at 10:57
  • Ok, try to see what happens to ping times if you move them further apart, let's say in two different rooms. Jan 8, 2014 at 11:02

2 Answers 2

5

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.

0

It is difficult to diagnose a problem with so little info. Here is a list of things you might do to improve your chance of diagnosing correctly your problem:

  1. clock a transfer of a large file (say 1GB). You can do it like this

    time scp largefile remore_user@remote_server:/home/remote_user
    
  2. Are you doing anything else in the meantime? Downloading something, using a vnc connection, performing an intense computation, updating either system or perhaps another system on the same LAN? It would be helpful to look at a picture of the output of one of a number of graphical system monitors, which detail CPU usage, traffic, and memory use, on either machine, as you are ssh'ing into the remote server.

  3. Do a traceroute of the server IP address from the local machine.

  4. look at the routing table of each system to make sure they are on the same subnet.

  5. check radio interference. In Linux, you can do this with the command:

    sudo iw dev wlan0 scan
    

    which will show the channel and signal strength of your wifi, as well as those of neighbouring networks.

  6. check ping times between client and server;

  7. change encryption algorithm;

  8. watch the logging process in detail. On the server, you need to start ssh not in daemon mode, but in Debug mode:

     /usr/sbin/sshd -Dd
    

    while on the client

     ssh -vvv remote_user@remote_server
    

    to check whether there is anything unusual.

Any of the above might provide useful insights. I am sure smarter people than I will be able to add checks to this very same list.

1
  • I added some of your diagnostics to my question. Jan 7, 2014 at 13:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .