From owner-freebsd-hackers Mon Jul 14 16:11:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA20618 for hackers-outgoing; Mon, 14 Jul 1997 16:11:29 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20600; Mon, 14 Jul 1997 16:11:18 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA01616; Mon, 14 Jul 1997 17:11:13 -0600 (MDT) Message-Id: <199707142311.RAA01616@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Bob Bishop cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency In-reply-to: Your message of "Mon, 14 Jul 1997 23:26:41 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 17:11:13 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >> A digital output port and an oscilloscope, logic analyser or something > >> similar. Any other (ie non-hardware) method is just inviting confusion. > [...] > >... and the 4th > >CPU could service the real INTs almost as fast as they occur. > ^^^^^^ > |||||| > > As I was saying... :-) but for this scheme that delay is irrelevant, as I can time exactly the difference from the point that the '4th CPU' sends the INT via the APIC bus and the time the ISR is completed. think of the 4th CPU as a very intelligent IO APIC that can record (once tied to specific software) all the timings of the INT events. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD