Discussion in 'Apple' started by Scott Eberl, Dec 27, 2004.

  1. Scott Eberl

    Scott Eberl Guest

    Not sure if others have noticed this but the included terminal.app with
    mac os x 10.3 seems very slow and laggy. I ssh into my webserver a lot
    from my powerbook and when typing sometimes it falls behind and then all
    of a sudden catches up. No other clients suffer this behavior so I'm
    guessing it's related to some setting on my mac or on terminal.app

    Anybody have this issue? How did you fix it or did you switch terminal

    Any advice welcomed!
    Scott Eberl, Dec 27, 2004
    1. Advertisements

  2. Scott Eberl

    Ian Gregory Guest

    I use terminal.app extensively and spend several hours a day
    working over an ssh connection. There are times when I have
    experienced the behaviour you describe but have always put it
    down to network or remote server problems and can't say I have
    seen it any less often from other clients. If it was a problem
    with terminal.app you might expect to see the same behaviour
    when editing a local file for example, but I never have.
    Ian Gregory, Dec 27, 2004
    1. Advertisements

  3. Scott Eberl

    Dave Seaman Guest

    I have noticed this on occasion, but since it is intermittent, I suspect
    it is more likely either a network problem or a system load problem
    rather than a Terminal problem.
    Dave Seaman, Dec 27, 2004
  4. It's far more likely that this is due to network delays between you and
    your web server, or else slowness on the server itself. Have you
    noticed any slowdown when working locally?
    Tom Harrington, Dec 28, 2004
  5. Scott Eberl

    Bob Harris Guest

    I have experienced this only when remotely connected to work (never
    local) so I also assume it is network related, like maybe a message has
    been dropped (missed), and until it times out and a retry is done,
    everything is stalled.

    I am also suspecting that maybe it is related to activities that cause
    Terminal.app to do a screen clear. For example, if I am working in Vim
    on the remote system, and I execute a shell command, when the shell
    command finishes, and Vim repaints the screen, I am more likely to have
    the stall. Other terminal windows connected to the same remote host are
    still working fine.

    Bob Harris
    Bob Harris, Dec 28, 2004
  6. Scott Eberl

    David C. Guest

    This has nothing to do with terminal, but everything to do with ssh.

    The ssh program is an encrypted version of rsh. (Similarly, slogin
    is an encrypted rlogin.) These programs operate on principles
    similar to the telnet protocol. Every time you type a character, it
    is sent to the remote system, which echoes the character back to
    you. If the network is slow (or if either computer is busy), you
    will notice a lag. This is not a big.

    You'll notice the same thing with any ssh client on any operating
    system. You sometimes also notice it with straight (non-encrypted)
    rsh/rlogin/telnet clients, if the network/server is loaded.

    Unless you're seeing the same lag when accessing local programs (that
    is, not connected to a remote system), I wouldn't worry about this.

    -- David
    David C., Dec 29, 2004
  7. Scott Eberl

    David C. Guest

    Definitely rsh or network related.
    These kinds of activities transmit much more data over your link than
    you may think. And with every TCP/IP packet being encrypted, any
    delays (due to a slow network or a slow computer) will be magnified.

    -- David
    David C., Dec 29, 2004
  8. Much, much more than you may think.

    Vi (vim) sets the transmission to "raw mode" (at least
    it used to do so many years ago). This essentially
    translates to one packet (and one TCP ack) per character
    transmitted under certain circumstances.

    One character of payload, 40 (give or take) bytes of
    headers, in a 128 byte packet. Then the ACK into
    yet another small packet. That's maybe 256 bytes to
    place a character on your screen. If one of those
    ACKS gets lost in the network, it may take several seconds
    (or sometimes minutes) to force a retransmit.
    "Vim" is not a good thing to be running across
    a network because of this.

    [Obligatory War Story]
    Many years ago, I did an X.25 driver for a client.
    In this case, they wanted to run X.25 over TCP/IP.
    The driver worked fine, but my client then got a
    complaint from one user that their networking bills
    were outrageous.

    It seems that, at the time (maybe still, I dunno),
    the carriers in Europe were charging by the packet.
    Since each character typed into Vi/Vim was essentially
    two packets (one transmit, one recieve- to paint the
    character on the screen), those folks using vi/vim
    across the network were paying a very high premium!
    [End obligatory War Story]

    Nick Landsberg, Dec 29, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.