JS> On Jun 13, 1997, Chris Holten wrote to Gary Gilmore:
 CH> Aw, I give up Gary, you are right you are a friggen expert.
 CH> Don't change a damn thing. I just hope everyone following
 CH> this thread doesn't take your word for it, and tries it for
 CH> themselves.
 JS> No problem there, Chris.  I've been working with modems/ports for about 
 JS> 12 years and your statements are correct.  Took me around a week to get 
 JS> my current system tweaked well enough to operate 
 JS> correctly with a 115200 DTE rate but it was worth every 
 JS> minute.  The difference is especially noticeable when 
 JS> browsing the web but I don't want to get too far off-
 JS> topic.  Heck, if I could lock at 230400 I would. The 
 JS> modems I use will handle it but (with one exception) 
 JS> nothing else seems to have that ability.  Neither 
Hmmm, browsing the web? My ISP, running sun sparc workstations with cisco 
routers only runs thier baud rate (not locked) at either 38400 or 57600 and 
don't use modem compression, so even though I lock at 115200, it doesn't do 
me a lot of good. I have read where digiboards, running with NT, can only 
lock at 38400 also. With My ISP, I don't get any compression. I guess just 
because an operator is running 120 or more modems, is no reason to assume 
they are experts. Lots of fidonet BBS sysops run with compression disabled 
because they get a bit better throughput when xfering compress files (2-3% 
better), but they don't get squat transferring text. I suspect some ISP's run 
with thier modem compression turned off either because they don't know any 
better or they do know better, but use it as a way of controlling and 
distributing thier limited bandwidth.
 JS> Maximus nor the one door I have installed has any 
 JS> problem with the 115200 DTE rate.
Hee Hee, almost 10 years ago, long before there were modems being used in the 
fidonet that could lock baud at 115200, I wrote a DOOR program that would run 
115200 baud simply because the fidonet "experts" told me that quickbasic 
would not do modem communications and would not run over 19200 baud at all 
and if I ran it at 19200 baud, it would drop characters. It was quite an 
educational experience. I had to test the program with a null modem cable 
between an 8mhz XT and an 8mhz 286. At that time 9600 baud was king, with 
many, if most 9600 baud modems not even being able to lock the baud over 
19200. Modems that could lock the baud at 38400 were really hi-tech at that 
time. Shoot, even with Quickbasic, the XT and AT did just fine with the baud 
set at 115200. No dropped characters, but nowhere near 115200 baud throughput 
either. That got me to experimenting. The computers, limited by the XT, just 
didn't have the horsepower to handle throughputs above 38,400 cps. I 
calculated that my 8mhz XT, CGA video, could only put charactors on the 
screen at about 12000 cps. That was the limiting factor, not the modems 
throughput. The 286, no multitasker present, CGA, would only put charactors 
on the screen at a max of about 26,000 cps. In that scenario, having a higher 
baud rate when displaying data to the screen just didn't matter. The 
bottleneck was the video display itself. I came to find out that using 
Desqview, even on 33 and 66mhz 486's has this vidoe bottleneck problem also. 
Turns out desqview is a -horribly- slow multitasker when doing screen writes, 
in most cases much much slower writing text to the screen than even 16 bit 
windows, so with a typical 386/486 desqview setup, locking the baud at rates 
higher than 38,400 really didn't make much difference in Desqview because 
Desqviews screen writes are so slow, that even on a 486, they can't do much 
more than 30,000-40,000 baud. A fidonet BBS sysop "testing" locked baud rates 
using Desqview, as many did, would have to come to the conclusion that it 
didn't matter above 38400 baud. I think the reason that fidonet sysops 
thought desqview was better, was because desqview didn't drop charactors like 
16 bit windows did. That was because desqview allowed the software to use 
buffered UART's where the stock 16 bit windows comm drivers prevented a DOS 
com program (fossil) from using 16550 buffered uarts, causing  dropped 
characters above 9600 baud. When 32 bit Windows comm drivers came out that 
supported 16550 buffered UART's, it turned out from my experience that 
Windows multitasked comm apps noticibly better than Desqview , with 
much higher throughputs than I -ever- got on the same computer with desqview. 
Although it worked best in Desqview, X00 by Ray Guinn was absolutely the 
sorriest FOSSIL driver to use in windows that there ever was and since it was 
the far and away the most popular FOSSIL to us with DV/DOS, I very much 
believe that when people tried running thier BBS in Windows, X00, because it 
just didn't work worth a hoot with most windows systems, made many fidonet 
Sysops think that you could not run a BBS in Windows, which was a totally 
wrong conclusion. Ray optimized X00 for Desqview and for some reason that 
caused it to totally hawg resources in Windows and bring every thing to a 
grinding halt. Using BNU or Opuscom FOSSIL in in Windows and learning a bit 
how windows does communications and how to set it up, made windows quite a 
bit better for running a BBS in than I ever found Desqview to be. Anyhoo 
point being was that when I was running my BBS in desqview, using X00 as the 
fossil, It really didn't matter whether I locked the baud at 38,400 or 
higher. Desqview and X00 just didn't have the horsepower to get much above 
30000cps throughput while writing to the screen on a 486-33 or 486-66 
computer, which is probably why the good ol boys that were running Desqview 
and X00 never thought it did any good to lock the baud above 38400. For them 
it didn't. For almost every one else, running almost any other multitasker, 
DDOS, OS/2, Windows, Windows 95, Windows NT, it does.
--- Maximus/NT 3.01b1
---------------