> >>My personal stance is that 99 times out of ten, if an end-user
> >>application speeds-up when it sets TCP_NODELAY, it implies the end-user
> >>application is broken and sending "logically associated" data in
> >>separate send calls.
> >
> >
> > You tell me, is X protocol broken?
>
> Likely not - the discrete mouse events which are usually cited as the
> reason X needs TCP_NODLEAY are not logically associated. Hence that is
> the 100th situation out of 10 rather then the 99.
>
> > Is SFTP broken?
>
> Depends - is it writing logically associated data to the connection in
> more than one send call?
No. They are logically separate calls.
> > I don't think
> > SFTP more broken than any other network fs protocol. The slowdown
> > happens with a stream of WRITE requests and replies. If the requests
> > weren't acknowledged, there wouldn't be any trouble, but
> > acknowledgements do make sense for synchronous operation.
>
> Do you have some system call traces and/or packet traces we could look
> at? If the write requests and replies are each single send call they
> probably qualify as the "X exception"
Yes this is the case. It's the symmetric counterpart of a READ
message pair, where the request is small and the reply is large. In
that case the client needed TCP_NODELAY to solve the delayed ACK
interaction problem.
With the WRITE is the opposite, the request is large and the reply is
small, and now TCP_NODELAY is needed on the server.
In both cases the request and the reply are sent to the socket with a
single write() call.
To me it still looks like the use of Nagle is the exception, it has
already been turned off in the server for
- interactive sessions
- X11 forwarding
and it will need to be turned off for
- SFTP transport
- IP tunnelling
- ???
Is there any transported protocol where Nagle does make sense?
Miklos
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|