[nos-bbs] My response - JNOS not being a race car, having stress problems.

[Maiko Langelaar (ve4klm)]

Hi all,

I personally do not want everyone on this list to be distracted or scared
away from using JNOS to it's full potential, just because of a few recent
observations and comments, which if misread, will leave new and potential
NOS users with a not so great impression of what it is truly capable of.

> domain.txt has the characteristic of (self?) destruction from unknown
> causes at this time. It is likely a program instability ...

Why is it "likely" a program instability ? This stuff has been running
for YEARS, and hardly changed over that time. It's more or less proven
to work way before I even got involved in it.

> This is a suggestion to NOT try to get the "last ounce" of performance
> from jnos installation because jnos is not a race car.

I don't think that's fair, and anyone reading this (new JNOS users in
particular) are not going to get the best impression from reading this.

You may be surprised to learn that JNOS is indeed a race car, BUT like
all vehicles, if you load it down too much, it slows down. I'm sure if
one has a kick ass machine, that will definitely help things out. I've
run JNOS (in DOS) as a router that had uptimes of over a month, I know
of people that have had uptimes of over half a year. No application
servers running of course, just packet switching more or less.

> It is my opinion that jnos has an internal processing logic problem that
> manifests itself only under "stress".

How can you conclude that this is an internal problem. Perhaps you meant
inherit in the design ? Skip, any system can be put under stress. Read
further below.

> As nos users it is probably enough that we be aware.

Actually, I think as NOS users, it would be best to read the following info
to help one understand in part, how the NOS kernel works. The following info
has been put together after consulting with people who's knowledge of NOS
extends way beyond that of most people, including myself - here goes !!!

Most of the comments have to do with NOS on DOS, but the jist can be taken
to any O/S for that matter. Let me add that running JNOS on LINUX actually
removes alot of the possible stress causers that DOS could bring on, for
instance, the availmem(). That's not an issue in LINUX !

--------- INFO SNIPPETS BELOW ------------

   Actually, it depends on what kind of "stress" is being applied. The
   worst stress that DOS-NOS experiences is when new processes are spawned
   to handle connections for application sockets. The more "user" connections
   there are to NOS, the more processes there are and the more "stressed"
   the machine becomes.

   Any machine which experiences a high degree of memory fragmentation
   within NOS during the normal course of its uptime is being "over-
   taxed".  Remember:  NOS on a DOS platform, for all its good (and
   bad) points, with its non-pre-emptive multitasking capabilities,
   does not even begin to approach the functionality of a pre-emptive
   multitasking operating system like UNIX.

   Real multitaskers are "pre-emptive", meaning they will interrupt the
   current machine task to service another one if necessary. NOS is *not*
   pre-emptive, but rather, "looks like" a multitasking system because it
   is constantly polling a "ready process" linked list looking for processes
   that are ready to run. It does this through the magic of pwait(), which
   as you know contains the context switching call, and psignal(), which
   are the heart and soul of the NOS "kernel". This was ingeniously devised
   by Phil Karn, KA9Q in an effort to devise a TCP/IP packet switching
   program that required being "aware" of multiple threads that work ok
   on a DOS platform.  The idea was that each process would get a time
   slice when it was "ready to run".

   THIS IS AN IMPORTANT POINT - NOS performs best when it has the fewest
   number of processes running and it performs worst when it has the most
   number of processes running.  The relationship is directly proportional.

   Well, it *does* make a difference.  If you've got 3-4 users FTPing
   files to you simultaneously or doing things on your mailbox and each
   of their processes get "ready to run" simultaneously, you have a pretty
   slow NOS.  Guaranteed!

   What NOS does best is NOT application services, but rather, switching
   packets.  If left alone to simply switch packets (like a good router) it
   shines an incredible light and you can stress it by blasting all sorts
   of traffic at it and it will dutifully route it and switch it through.
   No new processes are required to have NOS do this.  So this kind of
   stressing has little impact because the single network() process handles
   all of it.

   BUT "user" application stress is a whole other ball of wax...

   How many telnet, FTP and SMTP connections can joe user make before
   availmem() gets dangerously close to the 'memory threshold' setting
   and the program slows down to a garbage collecting crawl. Well of course
   NOS is going to "stress out" under these conditions. The applications are
   all add ons and people want to have everything under the hood of the same
   car. Eventually, NOS says, "enough".

   <HUMOR>
   "When you put a load on Windows machines, do they seem to bog down? When
   your specialized Apache Web Server is at a peak in serving processes due
   to so many clients trying to view your web pages and the I/O excessive on
   the box, does it bog down?" In more layman's terms... if it takes you 20
   minutes in an empty vehicle to drive up Mt. Washington but with a 1 ton
   load it takes you 40 minutes would it be safe to say the 1 ton load slows
   down the vehicle?
   </HUMOR>

   I have a system that is living proof of the less processors the better.
   There's no mailbox, no smtp, no http... it just switches packets where
   they need to go. Uptimes are in terms of over half a year.

-------------------------

Anyways, that's all from me on this. I'm tired ...

Cheers to all,

Maiko