Date: Tue, 23 Apr 2002 14:07:32 -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.48900.773726.309492@caddis.yogotech.com> In-Reply-To: <20020423195947.GA22950@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> <15557.43312.713502.540548@caddis.yogotech.com> <20020423195947.GA22950@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. > > 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...) Yer' preachin to the choir here. :) > There are things it doesn't fit well. A connection-less reliable > datagram protocol might have been a better choice for http, for example. You mean like TTCP? Unfortunately, it wasn't available, and because of inertia, it will probably never happen. :( > > > 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. Because it's used so rarely, having it suck every once in a while isn't so bad. TFTP is well supported natively in lots of hardware platforms, so rather than re-inventing the wheel over and over again, we chose to continue using what other vendors have used, but we 'optimized' it for our situation. That's called 'good engineering' in my book. :) > > 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. Actually, I disagree. IP is all about routing, and since we still want packets routed correctly, something on top of IP *is* the best solution. (Check out your OSI model. :) In any case, even writing my own 'RDP' (Reliable Datagram Protocol) on top of IP was massive overkill. It means messing around with the stack on every OS used in the product (which includes Windoze). Most of the stacks are *NOT* written with extensibility in mind, even assuming you can get your hands on the source code. The amount of resources (both in terms of finding people with enough expertise as well as the time to do proper testing) to do such a task is beyond the scope of almost any hardware vendor. Been there, done that, only going to do it again if it makes sense... 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.48900.773726.309492>