Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Feb 2003 11:59:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Feb 2003 11:59:28 -0500 Received: from wohnheim.fh-wedel.de ([195.37.86.122]:51167 "EHLO wohnheim.fh-wedel.de") by vger.kernel.org with ESMTP id ; Mon, 10 Feb 2003 11:59:27 -0500 Date: Mon, 10 Feb 2003 18:08:41 +0100 From: =?iso-8859-1?Q?J=F6rn?= Engel To: "Richard B. Johnson" Cc: Dan Parks , SA , linux-kernel@vger.kernel.org Subject: Re: interrupt latency ? Message-ID: <20030210170841.GC1973@wohnheim.fh-wedel.de> References: <20030210154304.GA1973@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.28i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2258 Lines: 50 On Mon, 10 February 2003 11:20:54 -0500, Richard B. Johnson wrote: > On Mon, 10 Feb 2003, [iso-8859-1] J?rn Engel wrote: > > > Write a simple handler for parport or so, that is called when line #1 > > toggles from low to high and responds by pulling line #2 from low to > > high. > > Now hook up a signal generator and an oszilloscope and measure the > > time from signal generation to the physical reaction. > > Yes, and you will find that you can replicate a square-wave, through > the hardware and software up to about 50 kHz with a 400 MHz Pentium > if you disconnect your network during the tests. > > My tests, several years ago, in the ISR simply XOR-ed a saved > copy of bit zero with `1` to toggle it and wrote it out the > data port. This would occur at every IRQ7, generated by hitting > bit 2 of the control port with a function generator. This should > produce a symmetrical /2 when you look at bit 0. You can line up > the starting 'high' of the function generator, with either a high or > low of bit one (because it's /2) and measure the time, which from > my notebook looks like 1.2 to 1.4 microseconds on a 400MHz machine. > > You can increase the interrupt rate until the machine is no longer > able to keep up. This usually occurs around 110 kHz or higher. 1.2us translates to 800kHz or 500 clock cycles. That is a good response time. 110kHz max rate translates to 3500 clock cycles for the complete interrupt path. This means that the return path takes six times longer to complete than the initialisation path. Odd. Somehow, I get this feeling that linux could still do better. 500 cycles is already better than the 2000 we observed, but most of that should come from the different architecture. An assembler interrupt handler that saves registers, tweaks a couple of bits, restores registers and gets the hell out of here should be in the order of 100 cycles, maybe less. Why is linux wasting all this time? J?rn -- Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/