Xref: utzoo comp.unix.xenix:1993 comp.unix.microport:501
Path: utzoo!mnetor!uunet!ncc!alberta!ubc-cs!van-bc!sl
From: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Newsgroups: comp.unix.xenix,comp.unix.microport
Subject: Re: Do we need a serial I/O benchmark (BAUDSTONE)?
Message-ID: <1709@van-bc.UUCP>
Date: 15 Apr 88 04:53:15 GMT
References: <1974@ubc-cs.UUCP>
Reply-To: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Organization: Public Access Network, Vancouver, BC.
Lines: 38
Keywords: rs232 serial data communications benchmark

In article <1974@ubc-cs.UUCP> pajari@grads.cs.ubc.ca (George Pajari) writes:
>
>With all the discussions regarding performance of serial I/O
>cards (especially 'intelligent' vs 'smart' vs 'dumb' vs 'retarded')
>it would seem useful if we had a serial I/O benchmark (BAUDSTONE?)
>which could be used to compare boards.  The idea is that such

>Otherwise I would like to propose the following design for such a BAUDSTONE.
>The idea is to solicit comments (either over the net or mailed to me)
>so that a consensus :-) may be reached, a benchmark written (I'll
>volunteer if someone else hasn't/doesn't beat me to it), code distributed,
>and results collected and summarised (me again).

>
>Simultaneously, run a CPU loop program at low priority to detect host CPU
>consumption.

The program I use is the standard Dhrystone program. I also try and run it a
high priority to keep it running by preference. 

What this does is to allow me to see the amount of time lost to servicing 
interrupts (by the reduction in dhrystone ratings, eg for my current driver
on my callan going to a timer to empty the receive buffer reduces the dhrystone 
rating from 931 to about 920 due to overhead in the timer call).

I can also see the amount of overhead for non-interrupt time be seeing the
difference in real time, ie does the dhrystone go from 95% down to 85% or
processor usage or 65 to 75 seconds real time. 

This is a good idea. And the use of standard program such as dhrystone would
allow it to easily be implemented. All that needs to be developed is a set
of procedures to follow.

I also question whether 7bit, even parity is close to the norm of actual
use. How about simple straight forward 8bit, no parity.

-- 
{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532