Memory loss (NOS's, not mine)

[dlf@phx.mcd.mot.com (Dave Fritsche)]

I've been running G1EMM's NOS now for a little over 24 hours with RSPF
blazing away, and I've run out of memory.

I started out by compiling the sources so that I could "turn off" all
the things that are never used around here, and "turn on" only those
drivers that are necessary.  I have disabled HOPCHECK, RIP, NRS, NNTP,
DIALER, LZW, PPP, & VJCOMPRESS.  When I first start it running, before
kicking SMTP, or starting any other sessions, a "mem stat" shows about
130k coreleft.  By comparison, KA9Q's system at the same point used to
show about 190k-210k free.

The problem is that in the first 24 hours of operation, the 130k free
dropped to 6k free.  At this point, there were no memory allocation
failures reported in the "mem stat".  After another 8 hours, the system
was down to about 60 bytes free, and 80 or 90 alloc fails.  I guess I'm
wondering if this behaviour is considered normal?  What begins happening
to the system at this point?  Is a crash immanent?  My course of action
was to exit from NOS and re-start it.  In retrospect, I wish I had let
it run to see what it would end up doing.

I'm running this on an 8088 "true-blue" PC, with 640k of RAM, DOS 3.3,
the ANSI console driver, and a serial-line network called The $25 Network.
So to start with, I should have a relatively large amount of RAM for NOS
to play in (the $25 network is a 20k tsr).  But at this rate, it looks
like I'd need to re-boot about once a day.  I figure I must be missing
something.  I know there are folks out there that are firing up shells
and BM from within NOS, and I don't see how that would be possible in my
case, except just after startup (fortunately I don't need to, since the
harddisk is networked to my 386sx system).  I'm not using the "multitask"
feature or spawning any other DOS tasks from within NOS.

One last observation is that when someone connects to the Mbox, about
20k more memory disappears.  Even though I only have 3-5 Mbox connects
average per day, each one eats up a lot of RAM.  Isn't this RAM being
reused for the next Mbox connect?  I understand that fragmentation
of the available RAM occurs, and I assume that is why each mailbox
session lops another large chunk of memory off the pile.

Maybe one solution would be to add the "old" Mbox code back into the
source base, and stick a #define in config.h so that a compile-time
selection of either the "stripped down" or "full blown" Mbox can be
included.  Personally, I and most of the others in my area have no
need for all the memory-hungry functionality in the current Mbox.

Any insight into these memory problems would be appreciated.

73 . . . Dave Fritsche (wb8zxu)
dlf@phx.mcd.mot.com (Tempe, AZ)