RH> Some time ago you explained (in this area?) why a COM-
 RH> port should not be set (lock) to a speed higher than 
 RH> absolutely necessary. Could you repeat your arguments, 
 RH> please, I lost your message.

For starters,  the 8250 uart is not rated at anything higher than 19200
bps.  Just today,  I was doing a null-modem file transfer between two side
by side computers,  and even as "low" as 38400 caused bad zmodem
packets.

rs232 "noise" issues aside,  here's some old notes on the topic:

 Area Os2bbs, Msg#476, Aug-03-93 12:57:34
    From: Steve Mane
      To: Peter Fitzsimmons
 Subject: SIO drivers ALERT!!!

 PF> It depends a little bit on your modem,  but I would say so.
 PF> Try it and let us know.

     I did just that, and would you know it...I did a test of downloading the
 same two files from the same BBS under both locked conditions.  One file was
 an .INF format file, the other was a .ZIP compressed file.  Both were around
 230k in length.

      The connection was 14,400bps v.32, using a 386DX-40 running Os/2 2.1GA
 using PMComm 2.01.

      First with the port locked at 57,600, the .INF file got an average of
 1630cps, and the .ZIP file got an average of 1530cps.

      Second with the port locked at 19,200, the .INF file got an average of
 1650cps, and the .ZIP file got upwards of 1580-1600cps.

      Needless to say I'm keeping the port locked at 19,200 instead of 57,600.

 ------------------------------------------------------------------------------

 Area Toros2, Msg#300, Dec-07-93 16:19:20
    From: Peter Fitzsimmons
      To: Matthew Stein
 Subject: BinkleyTerm v2.58

  PF> I just don't understand what everyone's obsession
  PF> is with these much higher
  PF> than necessary locked rates!

  MS> How high is too high?

 Too high is anything above the next-highest rate than the uncompressed
 maximum throughput of your modem.   I don't want to hear anyone whining about
 compression;   there are very few (virtually NO fidonet bbs's) that send a
 statistically significant amount of uncompressed mail.

 An example.  My modem (a plain old v.32/v.42bis),  at very best,  can do
 about 1100 cps.  Usuing a simple formula (which is not accurate but close
 enough,  since we round up to the next standard bps rate) where each
 character requires 10bits to send,  I want to lock at 11,000 bps
("baud" as
 many people incorrectly call it).   There is no such standard rate as 11000,
 so I lock at 19200.

 Vince Perriello was kind enough to come up with this chart (which is more
 accurate,  and takes into account the overhead of a good file transfer
 protocol):

  VP> Transfer Rate    Lock Rate
  VP> -!--!--!--!--    -!--!--!-
  VP> 0-863            9600
  VP> 864-1727         19200
  VP> 1728-3455        38400
  VP> 3456-5183        57600
  VP> 5184-10367       115200

  If you are borderline (1700 say),  and even occasionally jump up to the
  next bracket (1740 for example),  you will still want to lock one down
  (19200 in this case),  since your overall system efficiency will be
  increased by doing this.  This is especially so if you use the computer
  for someone else at the same time,   or have more than one modem hooked
  up to it.

 Now, assuming that no local noise is introduced by going to 38400 (and that
 is a pretty big assumption for most),  there was some wisdom in doing this
 under DOS.  Getting the bytes out of the PC and buffered in your modem as
 fast as possible meant you could get on with something else;   this is not a
 problem under OS/2,  since it can overlap i/o.

 Indeed,  because the application locked at 19200 will make fewer calls to the
 device driver (an expensive operation,  which requires a privilage level
 switch from rinf 3 to ring 0,  then back again),  it can (and probably will)
 run faster than the one locked at 38400.   I get a lot of arguments about
 this;  and I also get a lot of messages like this:

 ------------------------------------------------------------------------------

 Area Os2com, Msg#104, Apr-18-94 11:27:56
    From: Gerry Rozema
      To: Keith Medcalf
 Subject: 16-Bit Com Driver

  KM> All you need is a fixed version of the mode command.  All 16x50
  KM> UARTS support data rates up to 880Kbps.  (Actually, even the 8250
  KM> supports 880Kbps)  Only brain-dead developers at IBM have decided
  KM> to limit your ability to use the hardware for which you have paid


     The folks wrote drivers that support the RATED values for the chips they
 are targetted, this is as it should be.  FYI, to run a 16550 at 880kb will
 require an input clock well above it's rated maximum.  Temperature related
 breakdown of the substrate is inevitable.  FYI, it's easy to induce a silicon
 breakdown on a uart.  Put it in a warm room (~32deg c) and run it at 115kb
 continuously for an extended period.  Plot a graph of the error rate over
 time, you'll see an exponential curve developing that heads off into the
 stratosphere after a few weeks.


--- Maximus/2 2.02p1