William Chops Westfield wrote:
> 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
>
>   

You can also look at jumbo frames if both end points support it.
Some intel based NIC's can transfer ~16KB in a packet.

Really your not going to see much performance gain on a 100mbit connection.
When you get to Gig-E then all this stuff starts to matter more.

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