I'm noticing that lsh seems terribly laggy when used for an interactive shell. Looking at the source I don't see the TCP_NODELAY socket option set anywhere. Perhaps this could be added (possibly only for an interactive shell if that can be determined) ?
I did try to add it to the setsockopt call in io.c myself to see if it'd help, but for whatever reason it doesn't want to build after I make any edits - something to do with the abstraction stuff I guess.
IINM, TCP_NODELAY on setsockopt isn't a "don't make this socket needlessly slow" option. I believe it's a "kernel, I know someone was using this port recently, but please let me listen on it right away anyway" option.
If you're seeing lag, I'd guess either your network is laggy, or lsh just has some algorithm choices that could be reevaluated, or too deep nesting of functions or something like that.
On Thu, 2003-08-07 at 10:51, Pete Naylor wrote:
I'm noticing that lsh seems terribly laggy when used for an interactive shell. Looking at the source I don't see the TCP_NODELAY socket option set anywhere. Perhaps this could be added (possibly only for an interactive shell if that can be determined) ?
I did try to add it to the setsockopt call in io.c myself to see if it'd help, but for whatever reason it doesn't want to build after I make any edits - something to do with the abstraction stuff I guess.
Dan Stromberg wrote...
IINM, TCP_NODELAY on setsockopt isn't a "don't make this socket needlessly slow" option. I believe it's a "kernel, I know someone was using this port recently, but please let me listen on it right away anyway" option.
My understanding of the TCP_NODELAY option is that it disables the Nagle algorithm. Rather than wait for the buffer to fill to the MSS length before flushing the packet, the packet is sent immediately.
Are you thinking of SO_REUSEADDR perhaps?
If you're seeing lag, I'd guess either your network is laggy, or lsh just has some algorithm choices that could be reevaluated, or too deep nesting of functions or something like that.
I believe TCP_NODELAY is used by telnet, openssh etc to improve responsiveness for remote shells. My network is not laggy as openssh, telnet etc work great. It's possible that the default algorithm used by lsh is behind the delays, but I think setting TCP_NODELAY is a reasonable thing to try since lsh seems to be the odd-one-out in this regard. As I said, I'd like to test it myself but when I edit io.c something breaks in the abstraction stuff which I have no clue about.
On Thu, 2003-08-07 at 11:59, Pete Naylor wrote:
Dan Stromberg wrote...
IINM, TCP_NODELAY on setsockopt isn't a "don't make this socket needlessly slow" option. I believe it's a "kernel, I know someone was using this port recently, but please let me listen on it right away anyway" option.
My understanding of the TCP_NODELAY option is that it disables the Nagle algorithm. Rather than wait for the buffer to fill to the MSS length before flushing the packet, the packet is sent immediately.
Are you thinking of SO_REUSEADDR perhaps?
Sorry, yes I was.
If you're seeing lag, I'd guess either your network is laggy, or lsh just has some algorithm choices that could be reevaluated, or too deep nesting of functions or something like that.
I believe TCP_NODELAY is used by telnet, openssh etc to improve responsiveness for remote shells. My network is not laggy as openssh, telnet etc work great. It's possible that the default algorithm used by lsh is behind the delays, but I think setting TCP_NODELAY is a reasonable thing to try since lsh seems to be the odd-one-out in this regard. As I said, I'd like to test it myself but when I edit io.c something breaks in the abstraction stuff which I have no clue about.
OK.
Pete Naylor pete@geckoworks.com writes:
I believe TCP_NODELAY is used by telnet, openssh etc to improve responsiveness for remote shells. My network is not laggy as openssh, telnet etc work great. It's possible that the default algorithm used by lsh is behind the delays, but I think setting TCP_NODELAY is a reasonable thing to try since lsh seems to be the odd-one-out in this regard. As I said, I'd like to test it myself but when I edit io.c something breaks in the abstraction stuff which I have no clue about.
With the patch at URL:http://soua.net/io.c.diff, I can at least build (this is for the CVS-version, but I don't think anythings happened). [BTW; it seems I need to include netinet/tcp.h to get TCP_NODELAY, which I think I shouldn't, I wonder why].
Anyway, IIRC, you might also want to look at your terminal settings (min and time in stty) if TCP_NODELAY doesn't help.
/Pontus
-
Dan Stromberg -
Pete Naylor -
Pontus Skoeld