🚀 go-pugleaf

>   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.