Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!bbn.com!prost.bbn.com
From: tdonahue@prost.bbn.com (Tim Donahue)
Newsgroups: comp.realtime
Subject: Re: Real-time Harris (was Re: Real Time Risc)
Message-ID: <61753@bbn.BBN.COM>
Date: 26 Dec 90 18:08:40 GMT
References: <891@hrshcx.csd.harris.com>
Sender: news@bbn.com
Reply-To: tdonahue@prost.bbn.com (Tim Donahue)
Organization: BBN Advanced Computers, Inc.
Lines: 65
In-reply-to: steved@hrshcx.csd.harris.com (Steve Daukas)

In article <891@hrshcx.csd.harris.com>, steved@hrshcx (Steve Daukas) writes:
>...
>I don't remember the specific questions, but they were in
>response to some numbers I gave as follows:  5 usec interrupt 
>response time and less than 50 usec context switch times.  These
>numbers reflect response times for Harris' CX/RT and CX/UX
>Unix kernals running on the Night Hawk systems (M68030 and M88100
>based).

The main question was, "What exactly is meant by `interrupt response
time`?"  Since you've repeated the performance numbers here, I presume
you'd still like to stand by them, perhaps with some clarification.  I
think I understand that:

1. The processor is an MC88100 (or is a MC68030?)
2. The processor clock rate is unspecified (although I can find out what it
    is if I call the Marketing Department?)
3. The operating system is CX/RT (or is it CX/UX?)
4. The "interrupt response time" is 5 microseconds.
5. The interval corresponding to the "interrupt response time" begins when 
    the interrupt signal (the 88100 INT pin?) becomes active.

>Someone asked how this was accomplished.  Well,  I can't give away
>any secrets, but I will describe the general concepts:
>
>Essentially,  we've added some capability to the context switcher...
>...An example for device drivers is that SPL8 doesn't actually do what 
>you might think or are used to.

Sounds like Unix (CX/UX) is really running?

>An example real-world test follows:
>
>Using an external edge-triggered interrupt, a VME based DR11 interface, 
>and a scope, an experiment was set up to see the delta between the interrupt 
>and data available from the DR11.  This delta was much less than 50 usec.  
>So, this includes the interrupt response, handler, context switch, and 
>processing necessary for the DR11 to start sending data.  The CX/RT kernal 
>gives much less than 50 usec (the same number) consistantly...

Since there is a "context switch" mentioned in the above, I presume the
task running at the time of the interrupt is preempted, and another task
associated with the DR11 is scheduled.  Is this correct?  If so, how is
the "interrupt response time" separated from the "context switch time?"

I guess I still don't understand:

1. What time elapses between when the INT pin becomes active and the
    execution of the first instruction of an interrupt handler
    installed by the application. (Applications can install
    interrupt handlers?)
2. The state of the 88100 CPU when this instruction executes (i.e., is 
    shadowing enabled and have the pipelines been drained?) 
3. If your 88100 system has external 88200 CMMUs.  If so, are the
    data caches in use?
4. What is shortest interval between the execution of a system call in one
    task and the execution of the first instruction of a second, preempting
    task, made runnable by the execution of the system call (i.e., the 
    user-mode context switch time).
 
>Stephen C. Daukas              | sdaukas@csd.harris.com  
>Harris Corporation             | uunet!hcx1!misg!sdaukas  

Cheers,
Tim