From owner-freebsd-current Thu Nov 2 00:54:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA22182 for current-outgoing; Thu, 2 Nov 1995 00:54:13 -0800 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA22177 for ; Thu, 2 Nov 1995 00:54:10 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id AAA10537; Thu, 2 Nov 1995 00:52:44 -0800 From: "Rodney W. Grimes" Message-Id: <199511020852.AAA10537@GndRsh.aac.dev.com> Subject: Re: Time problems To: uhclem%nemesis@fw.ast.com (Frank Durda IV) Date: Thu, 2 Nov 1995 00:52:43 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: from "Frank Durda IV" at Nov 1, 95 08:36:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 978 Sender: owner-current@FreeBSD.org Precedence: bulk > > [3]Bruce Evans writes: > [3]Perhaps the 8254 clock is being accessed too fast. Try adding some delays > [3]before each inb() and outb() in clock.c:getit(). Count to 100 or so to > [3]get at least 1 usec delay. > > Uh, I don't think this will work as you expect on a Pentium or a P6. It is > too easy for the parallel integer unit(s) to execute the inb/outbs in one > unit and do the nice delay loop in the other, thus wrecking your timing delay. > On the Pentium and up you must force these types of "timed" instruction > sequences to be done sequentially. > > Execution Time is no longer linear.... :-) ... I suggest you go read the book again, IN and OUT instructions are ``serailization'' instuctions. All code between them will have _completed_ execution before the external cycle runs. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD