Erik Anderson: > UDT is not a replacement for TCP or UDP - it is a data transfer protocol > built on top of UDP, with some additional TCP-like features to aid in data > integrity (negative ACKs to be specific). > I understand that UDT isn't part of the kernel, but am not sure why you disagree with the term replace. Here's an exchange I found on a forum. The UDT author replies to the question with 3 paragraphs. "Can you provide some data on how the protocol overhead compares to TCP?" The UDT packet header is 4 bytes longer than TCP (UDT/UDP/IP headers vs TCP/IP headers). Since UDT is at user space, it uses more CPU (up to 2x, especially at low throughput: the design of UDT makes it more efficient at higher throughput) and also likely more memory buffers are required (exact number is application specific but usually it should not require significant more buffers). The TCP's throughput usually suffers significantly from packet loss over long distance links due to its congestion control algorithm. UDT has a new algorithm that can overcome the problem. I am not recommending completely replacing TCP with UDT. Instead, I think UDT can be a nice alternative as a user option or when TCP connections cannot be setup (e.g., due to firewall) or perform too poorly. ------------ end of UDT author's reply ------------- Perhaps the person who suggested I consider UDT was thinking about the long distance links the UDT author mentions there. Currently I have one location to serve the world... > I've never used UDT, so I can't speak specifically about it. In general, > though, my feelings on technologies like this is that they're great to > consider, if and only if they would solve a specific problem you're having. > This isn't something you'd want to put into production just for the fun of > it. If you have a very high-speed network, say 10Gbps+, and you're > schlepping a *lot* of data around, it may be worth implementing. I don't have a 10Gbps network or a specific problem yet. I'm wanting to be prepared for future traffic like Noah got ready for a flood he was warned about. I'm also thinking about using nginx instead of apache. >From what I've read -- http://blog.zhuzhaoyuan.com/ nginx is faster with static pages and that's all I have at the moment. Nginx is smaller in terms of disk space so that's in its favor. -- Brian Wood Ebenezer Enterprises - in G-d we trust. http://webEbenezer.net (651) 251-9384 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20130302/424c52a9/attachment.html>