Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!ginosko!uunet!ficc!karl
From: karl@ficc.uu.net (Karl Lehenbauer)
Newsgroups: comp.unix.i386
Subject: Re: _UNIX_Today!_
Message-ID: <6153@ficc.uu.net>
Date: 13 Sep 89 12:34:38 GMT
References: <16054@vail.ICO.ISC.COM> <966@utoday.UUCP> <9468@chinet.chi.il.us> <127@psitech.UUCP>
Organization: Ferranti International Controls
Lines: 44

In article <127@psitech.UUCP>, david@psitech.UUCP (david Fridley) writes:
> ...For now lets call it the wait for echo test.

> What does this show? Well first off, it shows that UNIX is not a real time
> operating system because the results for this test are far lower than the real
> baud rate.  

I don't think that shows that Unix is not a realtime OS, although of course
Unix (System V) isn't one until V/4.0.

>It also shows things like the latency time of the task switching
> facility, and the raw speed of the machine.  

Correct.  And it shows the overhead and latency of getting characters through
the interrupt handler and into a task.

>The real feature of this test
> is the reality of it, I know the difference between 9600 baud, and 2400 baud.

A couple "unreal" things about it:  One, input in your test is guaranteed not
to overrun because you don't output a character to the port until you read
the previous one.  In "real life," reading from a Trailblazer or null-modem
to another computer at 9600 or 19200 bps, Unix systems all too often have
trouble reading that stuff without getting overruns.  Perhaps a test where
a second computer generates the data so the computer under test can have
underruns could be used.

Second, your benchmark (from the way you have described it) passes the 
characters around one at a time.  The overhead for processing characters
on a per-character basis is much higher than for making requests for a
number of characters with a defined limit and timeout.  These options have
been available in System V for a long time (Xenix, too.)  They are setup
within the VMIN and VTIME fields (and some bit) of the termio structure
you diddle with ioctl.  The performance improvements come from fewer task
switches and maybe from the system being able to pass many characters into
your address space at once.  Hopefully uucico uses this.  Chuck Forsberg's
x,y,zmodem programs certainly do.

> Other bench marks could be how long it takes to ... backup your 320 megabyte 
> hard disk onto diskettes.

You must be a masochist.
-- 
-- uunet!ficc!karl	"Have you debugged your wolf today?"