NOS updates

[karn%ka9q.bellcore.com%ucsd.edu@Sdsc.BITnet (Phil Karn)]

Happy New Year everyone.  My holiday was quite productive, as I've been
making quite a few enhancements to NOS. An updated copy is on flash in
the usual place (anonymous FTP, /pub/ka9q/src.arc and /pub/ka9q/net.exe).

There's quite a bit of work in this release. Let me see if I can remember
it all:

1. The major new feature is per-session screens. When you create a new
session, you create a new "screen" along with it. The command interpreter
also has a screen of its own. If you hit F-10 to escape back to command
mode, the session screen is saved and the command screen is restored.
When you later go back to your session, it will reappear exactly as it
was when you hit F-10.

It was necessary to add a few prompts to the session code to give you
a chance to read a session screen before the session ends.

One known bug. I still rely on nansi.sys (or whatever) to do the actual
screen driving. Because it may have internal state I can't save and resore
easily when switching screens (e.g., the current character color) you may
find that the current character attributes "follow" you when you switch
screens.

2. I've rewritten the asynch output subsystem in an attempt to minimize
the time spent in interrupt service. There is now an asynch output task
in addition to the input task that was already there, and it does some of
the work that used to be done at interrupt time. My timings showed that
the majority of the interrupt service time was spent servicing transmit
interrupts, as much as 500 microseconds on my 25 MHz 386. The new code cuts
this to about 155 microseconds max, much better but not perfect. The output
driver allowed me to simplify some output code in nrs and slip.

I moved the "inbuf" and "outbuf" routines that I had written in assembler
for the 3c501 Ethernet controller over to pcgen.asm, and I now use outbuf
for driving the 16550 transmitter fifo. It shaves about 30 microseconds off
my transmit service routines. Not much, but every little bit counts.
(Besides, I spent a lot of time writing those routines, and they've gone to
waste ever since I gave away my 3c501s!) My 16550s don't seem to have any
problem taking data at that speed from my 386, so I think there should be no
problem with these routines.

I also found an old item on the net from someone with considerable
experience programming the PC serial ports, and he suggested that the 8259
interrupt controller be rearmed at the beginning of an interrupt service
instead of at the end. Because the 8259 is edge triggered, it was apparently
possible for an interrupt to be missed if a character arrives between the
time the device is serviced and the 8259 is rearmed at the end of the
interrupt service routine.  I made this change, but it's hard to know if it
makes any difference. The drivers all still work, but I'd be interested in
knowing if they're any better on fast SLIP links.

And last, but not least, I modified the 8250 input driver. Originally,
whenever the interrupt handler received one or more characters, it
issued a psignal() to wake up the slip task. To eliminate the overhead of
the psignal(), which can take a hundred or so microseconds on my
machine, from the interrupt service routine, I moved the psignal()
call to a new function that gets called by the timer task on each clock
tick. The only disadvantage of this approach is that there may be up to
a 55 millisecond delay before the system realizes that a SLIP packet
has arrived.

3. There's a "more" command for reading files inside NET. It understands
the 'q', space and cr responses to the --More-- prompt, and they have the
same meanings as in the UNIX more command.

4. The local "dir" command was reimplemented to use the "more" command just
described. Basically, it creates a temp file with the directory output,
invokes the "more" command on it, and then deletes it.

5. I had to reimplement the "more" feature on command output. It isn't as
nice as the "more" command. You can only go to the next page; you can't
abort output, but you can switch screens. (It was a real bitch getting
just this much working.)

6. I redid the domain response processing code. It should now be
considerably faster at processing replies that contain many extra records,
especially when domain.txt is large. (The earlier code reread the entire
domain.txt file for each incoming record, looking for duplicates. The new
code reads the domain.txt file only once, comparing each entry to all of the
incoming records.)

7. I added a few TCP SNMP variables that appeared in the new version 2 MIB.
These show up as tcpInErrs and tcpOutRsts in the tcp status command.

8. The storage allocator keeps a histogram on allocation request sizes,
broken down by binary powers of two. Not that interesting to casual users,
but I've been considering alternative allocation algorithms, so these
stats are useful to me.

9. The "rip merging" function was reimplemented. It now works properly;
the old code didn't always reject redundant entries, depending on the
order in which they appeared in an incoming RIP packet.

10. There is a new socket address family: AF_LOCAL. Both stream and
datagram sockets are supported. These are basically local loopback
sockets, useful for interprocess communication. All session console I/O
is now based on them.

11. Each session and process now have standard input and output sockets.
When a new process is created, it inherits its parent's I/O sockets.
New sessions, however, create new I/O sockets so that they can keep their
console I/O separate from the other sessions.

12. All tasks write their output using tprintf(), which automatically goes
to the output socket stream. A new display task reads the output stream of
the current session and displays it on the screen.  Ordinary printfs are
still used for trace messages, so they'll come out on whatever screen is
current. I haven't decided exactly how to redo these yet. Note that when a
session is put in the background, it is not actually frozen; it continues to
write to its output stream until the high water mark is reached. This level
is a certain number of bytes (currently 2K); this does not correspond to any
number of screen lines. The good news is that big ftp sessions running in
the background won't spoil your other sessions; the bad news is that if
you've stacked up a bunch of FTP commands, you need to switch over to the
FTP session window occasionally to keep it from stopping because of the
output messages invoking flow control.

13. There's the beginnings of a stdio-like buffered I/O package on top
of the socket library. It's not done yet, but what's there is enough
to support the session I/O functions.

14. There was some consolidation of the session and application data
structures which allowed me to simplify some client application code.

15. There's a general purpose "stopwatch" facility for timing critical
sections of code (like interrupt service routines). In the code I've
uploaded, timer 0 times the receiver interrupt handler, and timer 1 times
the transmit interrupt handler. I'd be interested in some typical figures
for various PCs. (Please let me know the CPU type and clock speed, memory
wait states, and whether you're using 8250s or 16550s.)

16. There's the beginnings of an "ifconfig" command for configuring
interfaces. It's not done yet, but much of it does work. When it's all
done I'll remove the superfluous arguments from the various "attach"
commands, but until then your existing autoexec.net files should work.

Have fun!

Phil