Date: Tue, 23 Apr 2002 15:59:47 -0400 From: utsl@quic.net To: Nate Williams <nate@yogotech.com> Cc: hackers@FreeBSD.ORG Subject: Re: sendfile() in tftpd? Message-ID: <20020423195947.GA22950@quic.net> In-Reply-To: <15557.43312.713502.540548@caddis.yogotech.com> 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> <15557.43312.713502.540548@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 23, 2002 at 12:34:24PM -0600, Nate Williams wrote: > [ 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. This is an issue with TCP in your situation. You're playing with network equipment TCP wasn't designed for, and noticing that TCP isn't anywhere near perfect. It's relatively simple (see OSI before you disagree...), and optimized for common network technology at the time it was designed. (And sometimes those optimizations work...) There are things it doesn't fit well. A connection-less reliable datagram protocol might have been a better choice for http, for example. > > 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. :) Probably true, but the better solution is to find something else (or make something else) that doesn't completely suck like TFTP does. > 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. I suspect that you might be better off solving your lossy network issues with a layer under IP, rather than tinkering with the protocols that sit on top. Maybe a module for netgraph that does some retransmit handshaking optimized for your particular needs. ---Nathan 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?20020423195947.GA22950>