Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!rutgers!bellcore!faline!thumper!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.microport
Subject: Re: 286 serial port woes
Keywords: UNIX 286, uucp
Message-ID: <8793@alice.UUCP>
Date: 19 Jan 89 02:23:47 GMT
References: <11871@netsys.COM> <13736@ico.ISC.COM>
Reply-To: debra@alice.UUCP ()
Distribution: na
Organization: AT&T, Bell Labs
Lines: 40

In article <13736@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>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.
>
Sure, there is nothing magic in Xenix that makes the AT run faster than
physically possible.
In /usr/sys/conf/master you find a list of all device drivers and their
priorities. The standard rule is to have the serial ports highest, and then
the clock. Reason is simple: a lost interrupt from a serial port means that
you lose an event external to your computer, i.e. an input character. You
want to avoid that at all cost. The same is almost true for the clock, but
one generally cares less about a lost clock tick. (I've never had my system
lose time, but i've seen that happen to other systems.)
All other events are more or less recoverable. A lost interrupt from the disk
is a bit annoying because you have to time out and ask for the same info again
but nothing is permanently lost. The parallel port idem. Interrupt driven
drivers, combined with polling for timeouts goes a long way.
The keyboard is very slow, so interrupts won't be lost easily on that device.

I've played with these priorities, and there isn't too much you can do wrong
that will slow down the system dramatically or crash it. The only effect you
can get is that if the serial ports do not get the highest priority they
start losing characters, which should be no surprise.

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------