If you set the sliders to 0, you simply tell the UART to trigger an
interrupt as soon as it recieves *any* data, which puts an unnecessary
load on the system (this might not be too bad) and definitely will
slow down communications. Setting the send buffer to 0 in particular
is pointless - there is no chance of having a buffer overflow while
sending.
Bottom line, do this: set the transmit buffer to 16 and leave it - it
will never cause a problem. Leave the recieve buffer at the default
setting, which triggers an interrupt at 8 or 10 (not sure). That
leaves plenty of time for the system to respond before the buffer
overflows, without slowing down the communications too much. If the
system is having overrun problems with that setting, lowering it one
notch might help, but a 386/25 with 4 megs is more than fast enough to
respond to that setting, so if there are overflow problems, they
probably lie elsewhere.
One other thing - comm overrun errors are *extremely* uncommon in
Win95 - they were much more common in Win31, and the approach to solve
them is quite different (I can post a summary if anyone is
interested), but mostly comes down to Win31's comm driver being pretty
clueless. If you have a Win95 user getting disconnected, think IRQ
conflict - that's about 80% of all the problems I see.
Barry
On 16 Jan 97 at 10:15, Brian Moore wrote:
> Looked at the accounting files to see reason for disconnection? I'm
> willing to bet it says "Lost Carrier" and that these systems are
> running Windoze, especially Win95.
>
> Deep down in the modem control panel for Win95 there are a pair of
> slider bars for buffer size. Cut the buffers down to 0. Yes, LOGIC
> says this should make matters worse, not better, but MS is not
> logical. Read the help files on those sliders if you think it's
> bassackwards.
>
> > On Wed, 15 Jan 1997 "Geoffrey Ellison" wrote:
> >
> > > Configuration Note:
> > > We are using PM2e30's with radiusd (not user tables) running on
> > > a Linux server. Each PM port has a USR Sportster 33.6 modem
> > > attached to it.
> > >
> > > The problem is this: Some users report that they are being
> > > disconnected in the middle of continuous activity, not idle
> > > time. Our PM's are set to disconnect after 20 mins of idle time
> > > but it seems some people are being disconnected during periods
> > > of activity, such as downloads. Has anyone experienced this kind
> > > of problem? Any ideas?
> >
> > Geoff
> >
> > i'm seeing the same situation with the same setup, excepting the
> > modems, [using Microcom QX rack mounted Deskport v.34's] Radius
> > v1.16 - Linux v1.2 13 [CND v1.0] and not being amused by it;]
> >
> > Paul
>
>
Barry Hemphill EasyNet Inc.
System Administrator Cambridge, Ontario, Canada
ubu@easynet.on.ca (519)654-9999 fax(519)654-0301
The typical Nintendo game involves controlling a little man running
around a maze while numerous powerful and inexplicably hostile forces
try to destroy him. In other words, it's exactly like real life.
-- Dave Barry