Re: Correlating *SAVF "records" to FTP job I/O count

Bill,

>The way I usually estimate the time required to send a file is as follows:
>
>1.  Multiply the object size by 8 to get the number is bits being sent.  In
>your case:
>               59,785,216 * 8 = 478,281,728
>
>2.  Calculate the number of seconds to send by dividing the number of bits
>by the connection speed (in bits/second):
>               478,281,728 / 50,000 = 9,566 seconds
>
>3.  Calculate the number of hours by dividing the total number of seconds by
>the number of seconds in an hour (3600):
>               9,566 / 3600 = 2.66 hours   (2 hours 40 minutes)

You are over simplifying it.  When using a sync modem or other
transmission scheme without start/stop bits, your step 1 is correct.
But for async connections, each byte sent has 1 start bit plus 0-2
stop bits (typically 1 stop bit).  For that matter, you can vary the
number of data bits (7-8) and parity bit.  Typically you now run async
with no parity bit, 8 data bits, and 1 stop bit.  So each byte
actually takes 10 bits (1 start + 8 data + 1 stop).

In the old days, that was one of the advantages with sync modems vs
async: the clocking was used to eliminate the start/stop bits so you
could get by transmitting fewer bits.  Then async protocols started
getting smarter and modems offered error correction and compression
on-the-fly.  I think some of the protocols even manage to strip the
start/stop bits, but add other overhead such as checksums and
compression info.  The amount of compression is naturally data
dependent, but you tend to more than make up for the start/stop bits
and in theory in a best-case scenario can get up to a 4x better
throughput vs the bps connection rate.  This is why you always want to
set your port speed higher than the connect rate.  Make sure the speed
to/from the modem is at least 2x your connect rate, preferably more.

However, using TCP/IP complicates it even more than this.  While the
above still applies to the physical async connection, you further need
to factor in the TCP packet overhead and other variables like Maximum
Transmission Unit, Maximum Segment Size, Receive Windows size, etc.

I'm no expert on how TCP works, and the nuances of how data is
formatted as it passes thru various connections.  But this link is a
starting point on some the factors involved, particularly as it
relates to dial-up connections:

 http://www.ultranet.com/~belleisl/mtu_mss_rwin.html

For transfers over an intranet, you can control the settings on all
the machines and routers in the connection, so you can tune it based
on your network needs.  On the internet, you have much less control,
and you want to avoid what is known as IP fragmentation.  One of the
benefits of IPv6 when it is implemented is that, unlike the current
IPv4, routers will not be allowed to perform fragmentation.  Only the
sending host can.  IPv6 also mandates the now optional "Path MTU
Discovery" procedure so a host can discover the minimum MTU along a
given path so it can calculate the optimum packet sizes for the
connection.  There is some discussion of this and related stuff at:

http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-02.txt

For a discussion on how to measure bandwidth and IP fragmentation
effects, try this link:

http://www.ics.hawaii.edu/~esb/prof/proj/imes/theory.html

Doug
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---