From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by huchra.bufferbloat.net (Postfix) with ESMTP id A922420024C for ; Mon, 12 Mar 2012 14:08:47 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 1000) id 906E140617; Mon, 12 Mar 2012 17:08:31 -0400 (EDT) Date: Mon, 12 Mar 2012 17:08:31 -0400 From: "Eric S. Raymond" To: tz Message-ID: <20120312210831.GA17895@thyrsus.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) Cc: thumbgps-devel@lists.bufferbloat.net Subject: Re: [Thumbgps-devel] Jitter and latency in a linux system might be a problem. Minimal BoM crosspost. X-BeenThere: thumbgps-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: esr@thyrsus.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:08:48 -0000 tz : > The PPS change detect thread in gpsd might have latency problems if > the kernel is busy and/or it isn't a high priority - a plain userland > program shows about 1mS jitter - a loop with the ioctl to block until > a pin-change followed by gettimeofday will vary over about a 1000 uS > band on my dual-core netbook. If you really need 100nS, you might > need to use the kernel PPS, preferably with a dual core or better CPU > so the interrupt can capture the nanosecond timer reliably. We don't need 100ns. Our target accuracy is 1ms. This simplifies things a lot. -- Eric S. Raymond