home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!olivea!hal.com!decwrl!csus.edu!netcom.com!royg
- From: royg@netcom.com (Roy H. Gordon)
- Newsgroups: comp.sys.ibm.pc.misc
- Subject: Re: ProComm 2.4.3 Kermit up/down-load times
- Message-ID: <z3gn7sr.royg@netcom.com>
- Date: 30 Aug 92 21:15:10 GMT
- References: <92243.062901IP25179@portland.caps.maine.edu>
- Organization: Netcom - Online Communication Services (408 241-9760 guest)
- Lines: 21
-
- > When I download in Kermit using ProComm 2.4.3, the estimated time for the
- > process shown in the pop-up 'window' is always half of the actual time re-
- > quired. Do I have some untapped potential here that I'm missing? Or is
- > the program just a taco short of a combination platter?
-
- When I tried to figure this out (I noticed it too) it seemed to me
- that the estimated transfer time was based on the baud rate as
- specified in the dialing directory entry, not the actual connect rate.
- The dialing directory baud rate should be the maximum possible DTE rate,
- e.g., allowing for all compression, etc., which is how I had it
- specified. Transfers at this maximum possible rate are very unlikely,
- as other threads in this group have revealed. Therefore, actual time
- will almost always be more than estimated time.
-
- This is particularly true when transfering compressed files, e.g,
- zipped files, as, according to what I've read (someone correct me here
- if I'm wrong), there will be little added benefit from v.42bis
- compression and actually negative benefit from MNP5.
-
- Of course, this explanation won't work if the baud rate in your dialing
- directory entry is the same as the connect speed.
-