Date: Tue, 23 Apr 2002 12:34:24 -0600 From: Nate Williams <nate@yogotech.com> To: utsl@quic.net Cc: Nate Williams <nate@yogotech.com>, hackers@FreeBSD.ORG Subject: Re: sendfile() in tftpd? Message-ID: <15557.43312.713502.540548@caddis.yogotech.com> In-Reply-To: <20020423182839.GA22074@quic.net> References: <Pine.LNX.4.44.0204231521120.24266-100000@scribble.fsn.hu> <3CC59C44.13013A1E@mindspring.com> <15557.40442.852602.681416@caddis.yogotech.com> <20020423182839.GA22074@quic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ TFTP performance is poor ] > > > USE TFTP to get a tiny image up, and then go TCP. > > > > > > Going to TCP soon assumes that you have a lossless medium in order to > > transmit packets over. If you're using a lossy medium, TFTP (and other > > UDP based protocols) can kick their butt because of TCP's assumption > > that packet loss is a function of congestion, which is often not the > > case in lossy mediums such as wirless. :( > > tftp in particular probably won't, because it uses the same packet > window concept as TCP, but with the window set to 1. Actually, it still tends to kick TCP's butt in very lossy networks, because or resends and other vaguaries of TCP. We've done benchmarks, and when packet loss gets bad, TCP backoff algorithm (which causes window size shrinkage *and* increases in resend delays) cause TCP to slow to a crawl. We've found that TFTP's timeouts tend to work better, although it may be more an issue of having the lower overhead vs. TCP. > It is a protocol that is braindead by design, in order to be simple to > implement. It was never pretended that performance was a design goal. Completely agreed on that point. Another point worth mentioning is that it's rather trivial to add in some extensions to TFTP (that are backwards compatible) to speed it up by increasing the window size to even 2 packets. We were able to do that and it almost halved the transfer times. :) However, it required slight modifications on the part of the sender, and the ability to recognize when the double window size modification had to be disabled because certain (very slow) pieces of hardware couldn't handle even the slight speedup of packets. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15557.43312.713502.540548>