Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use a mac os laptop over a typical (i.e. crappy) wireless home network and connect to work over a VPN. I ssh into the linux (ubuntu) desktop I have in my office at work. (When I say, "I ssh": I click on a button that tells me it is going to use 'ssh', and a "Terminal" window opens and logs into my desktop.)

Frequently (up to a few times a day) when I'm using 'vim', 'vim' will stop responding, and a minute or two later, the connection to my desktop will break, and Terminal will tell me the connection is broken. I frequently have multiple Terminal windows open to my desktop at a time, and only the Terminal window where I am using 'vim' will break. The other windows remain connected and usable.

Recently I was using tcpdump to trace the packets going back and forth, and I captured a trace where my vim session hung and exited. A couple minutes before the outage, packets from my desktop arrived with steadily shrinking window sizes until we reached zero and the connection broke a bit later.

I could almost understand this is I had, say, entered insert mode and started typing characters while the desktop was hung and I had filled up the window by typing while my desktop was screwed up. The starting window size was around 12,500 and each character I type seems to generate a 48 byte packet, so somewhere around 250 characters might fill up a tcp buffer.

However, when vim hangs, it is more like I do a page-down (control-f), then enter insert mode, then start typing a few characters. My commands and characters are echoed indicating that vim is receiving and processing the characters.

I'm not clear on where the tpc buffer sits between the socket and 'vim'. Presumably a tty driver is actually picking up characters from the tcp buffer, echoing them back to me, and handing them up to vim, and handing the output from vim back to me. But all of these actions would pull bytes out of the tcp buffer and the window size wouldn't go to zero.

What am I not understanding about how the software stack works, and why would my window size go to zero, and how can I work around or fix the problem?

Bonus questions:

1) Why does my desktop set the window size to around 12,500 instead of around 64K?

2) When using tcpdump on the mac, I get no output if I use the "host hostname", "host ipaddress", or "port 22" expressions (where 'hostname' and 'ipaddress' are replaced with the name or ip address of my desktop). If I don't specify one of these expressions, I get lots of output, and the output clearly contains the hostname, ipaddress, or port that I had specified on the command line. Is there something special on the mac where tcpdump doesn't work? Is there a standard way of screwing up the command line, and I'm confused about what I'm asking tcpdump to do?

thanks, Cs

share|improve this question

migrated from Jan 23 '12 at 4:01

This question came from our site for professional and enthusiast programmers.

Have you tried runing vim inside a GNU Screen session? To do this, enter screen at the console, which provides you with a shell inside a screen session. – artistoex Jan 13 '14 at 17:41

First off, the TCP Window size is not a buffer, its an acknowledgement threshold. The node receiving traffic will only send an ACK packet every x Packets. In a reliable network, this number should be as large as possible for throughput - the tradeoff being that if some data is lost, the entire window must be retransmitted... The usually causes the TCP stack to reduce the window size incrementally to avoid having to retransmit so much data in the event of a future packet loss. There is a component related to available memory (receive buffers), but in modern systems this is mostly irrelevant. Wikipedia

The underlying cause of this issue is likely a poor network connection. VPNs can frequently have high latency and/or packet loss, as can wireless networks. As an experiment, does the problem improve/resolve if you connect via hardline instead of wireless?

share|improve this answer

You must log in to answer this question.

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