Xref: utzoo comp.unix.microport:450 comp.unix.xenix:1907
Path: utzoo!mnetor!uunet!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.unix.microport,comp.unix.xenix
Subject: Re: RAM disk
Message-ID: <918@nuchat.UUCP>
Date: 10 Apr 88 01:42:44 GMT
References: <802@spdcc.COM>
Organization: Public Access - Houston, Tx
Lines: 36

From article <802@spdcc.COM>, by dyer@spdcc.UUCP:
> Needless to say, none of this deserves to be mentioned in the same breath
> as losing characters at 9600 baud.  [...]

true

> If Microport drops characters, it's because of problems in their kernel

true

> (undoubtedly too frequent or inappropriate spl() calls sprinkled throughout)

Surprisingly enough, this is apparently false.  Not the their mask
scheme makes any sense, just that it isn't the immediate cause of
this particular problem.

Seems their serial driver is ignoring input in favor of output when
it has a choice.  Given the short fifo on these stupid serial chips
(what is it, one, maybe two frames?) that is a major loss.

Prove it to yourself: run kermit (or some other telecom/terminal
emulation) on a loopback.  At speeds that it can handle well
on off-site links it drops character on a loopback.  Why? not
because the interrupts are comming at twice the rate - it can
handle two off-site links.  Its because of the strong temporal
coincidence between the two ports.  outgoing port finishes sending
and incoming port finishes receiving simultaneously.  both interrupt.
outgoing port wins, gets another charcter to write, and the
incoming frame gets lost.  The driver probably would work
if they hadn't also screwed up and spent too much time under
an spl().       sigh.

-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947