Date: Mon, 4 Apr 2005 09:58:16 -0400
From: Joe Korty <joe.korty@ccur.com>
To: P@draigBrady.com
Cc: Jonathan Lundell <linux@lundell-bros.com>,
       LKML <linux-kernel@vger.kernel.org>
Subject: Re: x86 TSC time warp puzzle
Message-ID: <20050404135816.GA2876@tsunami.ccur.com>
Reply-To: joe.korty@ccur.com
References: <p06230505be73a5c345c7@[10.2.3.6]> <425101EA.7080001@draigBrady.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <425101EA.7080001@draigBrady.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1238
Lines: 31

On Mon, Apr 04, 2005 at 09:59:22AM +0100, P@draigBrady.com wrote:
> Jonathan Lundell wrote:
> >Well, not actually a time warp, though it feels like one.
> >
> >I'm doing some real-time bit-twiddling in a driver, using the TSC to 
> >measure out delays on the order of hundreds of nanoseconds. Because I 
> >want an upper limit on the delay, I disable interrupts around it.
> >
> >The logic is something like:
> >
> >    local_irq_save
> >    out(set a bit)
> >    t0 = TSC
> >    wait while (t = (TSC - t0)) < delay_time
> >    out(clear the bit)
> >    local_irq_restore
> >
> > From time to time, when I exit the delay, t is *much* bigger than 
> >delay_time. If delay_time is, say, 300ns, t is usually no more than 
> >325ns. But every so often, t can be 2000, or 10000, or even much higher.
> >
> >The value of t seems to depend on the CPU involved, The worst case is 
> >with an Intel 915GV chipset, where t approaches 500 microseconds (!).


Add nmi_watchdog=0 to your boot command line.
-
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/