> > This time the problem is that the ssh server only sets TCP_NODELAY for
> > interactive (tty) sessions or if X11 forwarding is enabled. Neither
> > of which are true for the use of the sftp subsystem. This hurts
> > upload performance for sftp/sshfs.
> >
> > I'm not sure why this hasn't cropped up earlier. Were there any
> > TCP_NODELAY related changes in the sshd code recently?
> >
> > Is there a reason not to enable NODELAY unconditionally? Any reason
> > why the server end is different from the client (where NODELAY is now
> > uncoditionally enabled) in this respect?
>
> I suspect that past discussions might be interesting reads - should be
> an an archive somewhere I suspect.
>
> 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? Is SFTP broken? 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.
You could probably design a protocol that weren't prone to this sort
of problem, but likely that would make it more complex.
Miklos
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|