Path: utzoo!attcan!uunet!lll-winken!ames!ncar!ico!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.unix.microport
Subject: Re: 286 serial port woes
Summary: choices among correct, fast, simple
Keywords: UNIX 286, uucp
Message-ID: <13736@ico.ISC.COM>
Date: 18 Jan 89 19:43:14 GMT
References: <11871@netsys.COM>
Distribution: na
Organization: Interactive Systems Corp, Boulder, CO
Lines: 51

In article <11871@netsys.COM>, len@netsys.COM (Len Rose) writes:
> I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg
> of ram. Can't reliably sustain a uucp transfer at speeds
> greater than 2400 baud...
>...I despise Xenix yet it seems that SCO Xenix runs rings around
> V/AT on the same hardware. 

We did some measurements and some tests on Xenix serial I/O a fair while
ago.  We found that it was fast at the async stuff but there were other
problems--like the clock losing a lot of time.  It looked as if they were
playing some tricks with keeping interrupts off or juggling priorities to
put serial I/O highest.  I don't recall the details (nor do I know if it's
still that way) but it was clear that there was some "fudging" going on.

> My question is: Is V/AT really this bad,and if so, how can they
> still be in business? I am sure the hardware isn't the blame since
> Xenix performs "acceptably" give the fact that it's just a 286.

Don't be so sure the hardware isn't to blame!  If you're actually taking an
interrupt per character, you have a horrendous amount of overhead.  The
interrupt has to stack a bunch of stuff, and since the processor doesn't
have any useful interrupt handling in itself, you have to go fiddle with
the interrupt controllers (8259's) which are agonizingly slow and none too
bright.  If you miss the juggling on reprogramming the 8259 vs interrupt
enable, you can set yourself up to get a second serial interrupt before you
get out of the first one--so you overflow the kernel stack and die
horribly.  There's a 286 processor bug that causes a one-instruction window
where interrupts aren't really disabled; this takes another dozen
instructions to sort out and clean up.  This is all before you ever get
around to doing anything with the incoming character.

I suspect it's possible to make things a lot faster by treating serial I/O
as a very special case in interrupt handling, queuing characters and
processing them in bunches, etc.  I don't know how much of this Xenix does,
but I have fought the battle of trying to make AT async I/O fast, and it
really is hampered by the hardware.


What can you do about it?  For one, get some good serial hardware.  The
idea of having one character of buffering (or you might call it none at
all--it's only the holding register) as the standard serial ports do is
just plain dain bramaged.  You need to be able to hold off the serial I/O
to handle other interrupts (disk, clock) without dropping characters.
The serial driver is presumably smart enough to check for more input having
arrived before it leaves the interrupt routine--this will save the complete
interrupt latency.  (As you crank up the serial speed, you see the time in
the kernel go up in proportion, then drop suddenly--because it starts
getting two characters in on every interrupt cycle.)
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...A friend of the devil is a friend of mine.