On Jun 18, 2008, at 9:59 AM, Rolf wrote:

> The point is, that with UDP there is no ACK process, and thus latency
> does not play a part in the bandwidth calculation.

Wrong, usually.  Without some sort of ACK process, you tend to lose  
reliability.  With TFTP (which someone mentioned, and which runs over  
UDP) there is an ACK for every packet, and NO WINDOWING, so TFTP is  
usually MUCH slower than (tcp based) FTP, which only needs an ACK per  
window.  I'm not too familiar with other UDP based file transfer  
protocols (NFS, ?), but common sense says they all have some sort of  
ACK strategy, or a fast transmitter would never be able to send to a  
slow receiver.

You're correct that TCP transfers are frequently limited by latency  
to a bandwidth of (windowsize-in-bits / latency), although some of  
your details were misleading.  (for instance, it's relatively  
uncommon for a TCP to ACK *every* packet.)  The biggest thing you can  
do to improve speed may be to figure out how to tune your window  
size.  TCP supports window sizes up to 64k based on the original  
protocol, and extensions for "window scaling" support much larger  
window sizes via "window scaling."  I'm pretty sure that there is a  
windows tool that allows you to increase the default window size...

For multiple small file transfers, there are some algorithms in TCP  
that are supposed to ensure fair use of shared bandwidth ("slow  
start") that will slow down transfers a bit.

BillW

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist