Hi Steve,

 SH> I use to run Ezycom BBS on 1 line on my 486DX33 8 meg RAM.
 SH> Now I run EZYCOM BBS (2 nodes) with DESQVIEW - both modems 28800

 IS> might need to optimise your DV setup a bit for comms.  You may want to
 IS> run Ticks 1:1 or 2:2 or thereabouts, though a 486dx33 should have an
 IS> easy time running 2 BBSs.

 SH> What's the difference with 1:1 or 2:2 ticks?  Is 1:1 better?

It depends on your setup, and my experience is with tuning slower hardware;
a week or so browsing the DESQVIEW echo, assuming it's still happening,
would likely answer such questions, and more.  There are other settings
(from DV SETUP) that may be effecting your communications, but this really
isn't the place, and besides it's years since I changed anything here ..


 SH> Does it use more memory?

No.  What it does is allocate time (in 18th sec units) to the foreground
task, and each of the background tasks.  1:1 will see each task being
serviced more often, for less long.  It's usually a tradeoff between
responsiveness and (with comms tasks) not missing out on servicing buffered
data flow.  On your 486dx33 it's probably not as relevant as, say, your
'optimise communications' setting, and maybe some stuff to do with EMS
buffers .. ask the experts.

 SH> In regards to 16500, yes I do have 16550 UART serial card,
 SH> specifically for the BBS. The card is set up correctly and my fossil
 SH> driver settings are in my AUTOEXEC.BAT file are....

 SH> BNU /P=2 /L1=38400 /L2=38400

That sets default 1K receive and transmit buffers per port.  Try increasing
your recieve buffers to at least 2K and see it that doesn't help.  I use:

\qemm\loadhi /R:1 \dos\sys\BNU /F /P:2 /L:0=38400 /Z2 /R:4095 /T:512

though you shouldn't need that much receive buffering unless you're running
bidirectional mailer protocols, such as Janus or Hydra.

You may find the /Z2 switch helps; with the default the UART won't
interrupt the CPU for (here BNU's) servicing until it's received 14 of the
16 bytes in its FIFO, which only leaves 2 character times (about 0.5
millisecond at 3400cps) of interrupt latency before losing some data -
which can happen with some disk caches, or any other TSRs that may disable
interrupts for a while.

With /Z2, receive interrupts occur when the FIFO is half full (8 bytes), so
up to 8 more characters can come in, if servicing happens to be delayed,
before any loss.  The only cost is a slightly higher rate of interrupts,
but still only 1/8 as often as you'd get with an 8250A/16450 UART; easy for
a 486dx33.

 SH> Now I have since found this UPLOAD buffering/error problem only
 SH> happens if I use one modem to logon to another BBS while my other
 SH> modem is online running one node on the BBS.
 SH> Result: I get errors when I try to upload to the other BBS.

Hmm, what comms program are you using for logging on to the other BBS?  Is
it 'DV aware'?  Some of them are real pigs when it comes to not releasing
their unused CPU time .. have you tried Ralf Brown's (free) RBcomm, which
is designed to be very light on a DV-type system?  Keep transmit buffers
small.

 SH> Also if I logon to my own BBS (all from the one PC) I get many
 SH> heaps of errors uploading.

 SH> However, if someone else remotely logs on to my BBS, they can upload
 SH> fine.

I've done task-to-task transfers here at close to the port speed (38400)
using Binkley and Maximus, on a 386sx16, so if the programs are sharing the
CPU ok you should be having an easy time of it on yours.

 IS> many of them sysops. Issues like where you load your FOSSIL and some
 IS> QEMM settings may be relevant.

 SH> My BNU fossil is loaded before DV     How do I optimise DV for comms?

That's where I load it.  Do you use BNU /C to recapture the 14h vector
before starting your comms tasks?  Are you running all comms tasks in
non-swappable windows?  Lookup 'optimise communications' in your DV manual
re running the SETUP program.  There's more than one school of thought on
using that ..

Anyway, try the bigger Rx buffer and /Z2, and if that's no help, I'd
definitely think it worth your while to follow DESQVIEW for a few weeks.

Cheers, Ian

--- MaltEd 1.0.b5