sftp performance problem, cured by TCP_NODELAY

[Miklos Szeredi]

> >>>Done.  Can I now have my NODELAY please ;)
> >>
> >>Got a syscall and packet trace showing "the right thing" being
> >>done?-)
> > 
> > 
> > Can send it tomorrow.  But the best indication that it's right is
> > that the performance problem is gone.
> 
> Ah then you misunderstood what I was getting at, sorry. Although
> seeing the traces with TCP_NODELAY set would be interesting, I meant
> traces showing sftp behaving properly and still getting hit with
> delays attributable to the Nagle algorithm.

Sent off-list.

> > I don't know how far 4.3 is in the freeze state, but unconditionally
> > setting NODELAY seems quite safe.  It is bound to drastically improve
> > performance for many people, while any noticable performance
> > regression is highly unlikely.  But anyway I leave that to you guys to
> > decide.
> 
> HP-UX in 11.X decided to unconditionally disable Nagle in their
> telnetd.  They then discovered a whole slew of folks with "slow"
> clients that were then getting swamped by the thousands of tiny
> packets per second from a screen dump...they started dropping
> packets and thngs were worse than before. So I'd say that I do not
> agree with your assesment that noticable performance regression is
> highly unlikely.

Ah, but telnet generates interactive traffic, ssh is already broken
for that case.  

Now the interesting problem is non-interative traffic, for which ssh
is clearly broken in _some_ cases.  Others it's not broken: e.g. for
"scp" Nagle is totally irrelevant, because it only sends big packets
in one direction.

What else is there?  Port forwarding?  That is _usually_ done through
an interactive session, so again no difference.  

I really can't imagine Nagle helping all that much, when it's already
disabled (without people noticing) for the most important case of
interactive traffic.

Miklos