> There's no harm in locking the port at 115200.  A lot of HTML
 > (in fact, most of it) is highly compressible, and would benefit
 > by having the higher speeds.
 LL>       Off to a bad start, and it gets even worse....  If the UARTs
 LL> aren't capable of the speed, locking at a higher speed can cause the 
port 
 LL> to drop bits.  This is most noticable on a file 
 LL> transfer using a protocol such as ZModem where you will 
 LL> see a lot of CRC errors and resends.  I say noticable 
 LL> because it will happen in other places, but you won't 
 LL> see it or the retransmission (such as TCP) is masked 
 LL> from the user.  Retransmissions will actually make the 
 LL> transfer rate slower than if you had locked at a lower 
 LL> rate.  If the hardware is capable, then in most cases 
 LL> there is no harm.
Most, if not all modern UARTS are capable of 115200.  Heck, even the 16550 
(not the 16550A) on my old PS/2 model 80 machine is easily capable of 115200 
without dropping any characters.  And that PS/2 machine is *10* years old.
This dropped character phenemenon only happens when people insist on using 
their 14.4k or 28.8k modems with their older 16450 serial cards.  It works 
half the time, but the other half the time, weird things happen.
 LL> buffers.
 > X2 connections.  I've seen X2 connections up to 51.3k, and I
 > certainly wouldn't even think of driving a modem running that
 > fast with a measly 57600bps link -- you'd be getting buffer
 > ovverruns if you even tried that (while you're surfing to a fast
 > site).  And buffer overruns are not pleasant things to deal with
 > (the only solution, usually, is to either raise the locked port
 > speed, or lower the speed of the modem itself).
 LL>       Buffer overruns are dealt with through hardware handshaking.
 LL> It's not a function of the locked port rate.  You should lock your port 
I've seen situations where the data transmission from the remote site 
actually overruns the buffers inside the modem, making the hardware 
handshaking totally useless.  When stuff is coming off the remote server at 
115k, being compressed down to 40kbps, and going over an X2 link, it doesn't 
take very long for that small buffer to get full.
 LL> at a speed higher than your expected transfer rate.  It 
 LL> does little good to lock your port at 115k (although it 
 LL> probably won't hurt either) if your ISP is locking at 
 LL> 38.4k.  I personally lock my V34 Courier at 115k and 
 LL> occasionally see 110k transfers downloading newsgroups 
 LL> from Sprint.  But I have also dealt with an ISP that 
 LL> had VFC (it's been a while) modems on a 19.2 terminal 
 LL> server.  19.2k was all you were going to get....
One of my IP (actually a local college) providers uses old DECservers which 
lock the attached USR Sportster 33.6k modems at 19.2, but in reality, because 
LAT is so inneficient, they only get 14.4k speeds.  (the term servers aren't 
smart enough to run their own PPP, so the PPP has to be run on a VAX system).
The other providers in town use 56k uplinks to the internet, but also expect 
15 users to share that common 56k uplink.  With that little bit of bandwidth, 
why even bother installing 33.6k modems?  
I'll just be glad when we all don't have to use clunky old modems anymore.  
Sure, my Courier V.Everything's been a nice modem, but it's damm slow, even 
when it's downloading at it's top speed (I'm used to using a T1-connected 
ethernet connection).
--- Maximus/2 3.01
---------------