sftp performance problem, cured by TCP_NODELAY

[Miklos Szeredi]

> > So TCP_NODELAY is already set for interactive sessions.  I hadn't
> > noticed that.
> > 
> > It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_
> > makes sense for _interactive_ sessions.
> 
> It makes zero sense for interactive sessions - do you really want your
> keystrokes delayed?

Over really slow links yes, that is the correct thing to do.  Just
consider the immense overhead of sending a separate packet for each
keystroke.

However nowdays it probably doesn't make much difference either way.

But I do think that Nagle was invented exactly for the interactive
kind of traffic.

> > So it should be the other way round as it is currently.
> > 
> > But unconditionally setting TCP_NODELAY should at least cure the sftp
> > performance problem.  The patch in comment #9 looks fine.
> 
> We can look at turning Nagle off unconditionally after we get 4.3 out
> the door.

Fine.  But just delaying this problem for ever is not the solution.
And I can see posts from 2002 discussing exactly the same problem with
sftp performance.

People will try sftp and see that it's performance sucks, than they
will probably think it's because of the crypto overhead and never
bother to report it.  They'll just use ftp instead or live with the
slower download speeds.

And it's not just on slow machines.  I have a Pentum-M 1.6 and sftp
download speed is 50Mb/s over a 100Mb/s link, while scp can easily use
the full capacity.

> > Longer term I think you should consider adding "NoDelay" and maybe
> > "NoDelayInteractive" bool options, and _not_ setting nodelay on
> > interactive sessions by default.
> 
> No, we won't be adding any stupid button for people to push.

I don't agree with that, but it's your choice.

Miklos