Cliff Cliff, You are correct that the simple "file size * 8 / BW" isn't always appropriate. I would venture to say that at 64 kbps, you aren't likely to have many of the below problems, but it's good to have an understanding of the issues regardless.
1. RTT: In all likelihood, we're dealing with FTP/TCP/IP. TCP requires that data be acknowledged before the send window (who's size is dictated by the reported receive window from the distant end) collapses. If the RTT is great, the entire send window will be "in flight" and a cease in further transmission will be necessary until acks catch up. How much data is in flight can be given by "BW/8 * RTT" (BW/8 because the window is in bytes). So in your case, you would need a window size of 64,000/8 * .510 = 4,080. You could do some packet capture to ensure that your average window size meets that minimum requirement, but it's probably a safe assumption that your circuit doesn't yet meet the definition of a long fat pipe or long fat network. If you start bumping up the bandwidth, you need to be thinking about this issue. 2. Window size: Same as above. If the window size is too small for the size of the pipe, capacity will go idle. 3. Overhead of HDLC: Or whatever layer 2 encapsulation is being used. It's usually only on the order of a couple % and doesn't figure in very prominently. 4. MTU size: This has to do with some congestion control/avoidance features of typical TCP implementations. Slow start is notorious for affecting throughput at the start of a transaction. If the transaction is very short, full capacity is never realized. Slow start essentially dictates that a sender transmit one segment and wait for an ack, then send two segments and wait for an ack, and so on. Better to send one 1.5 kB segment and wait than it is to send one 512 byte segment and wait - especially where RTT is on the order of half a second!. 5. Link BW: Pretty strait forward I would think. Hopefully that helps a little. The above is a pretty light treatment of some pretty heavy stuff. There are several RFCs you might want to look into. Howard Berkowitz was talking about a new one the other day. 3390 I think it was. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57163&t=57158 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
