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 389FC200370 for ; Thu, 15 Mar 2012 10:57:39 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 1000) id 5C1D740617; Thu, 15 Mar 2012 13:57:17 -0400 (EDT) Date: Thu, 15 Mar 2012 13:57:17 -0400 From: "Eric S. Raymond" To: "Ron Frazier (NTP)" Message-ID: <20120315175717.GB3870@thyrsus.com> References: <4F62022C.6020901@c3energy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F62022C.6020901@c3energy.com> 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] USB handshake signals and Linux 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: Thu, 15 Mar 2012 17:57:39 -0000 Ron Frazier (NTP) : > I have a question about GPSD. I have nothing against it, but why is > it necessary to use it at all? I have NTPD running on both Windows > and Linux, and reading my GPS. GSPD isn't available on Windows as > far as I know. What does using GPSD get me that running without it > does not? For timing purposes the GPS emits two things we're interested in: time report sentences and 1PPS state changes on the DCD or RI line (since it's a USB interface that would actually be USB events emulating those changes). Something has to interpret those. GPSD can already do that and is well tested. If we drop GPSD, then we have to write our own dedicated service daemon or in-kernel support. That would be seriously complicated and involve a lot of headachy debugging. Also, we'd then probably be stuck with supporting only a single device type. By the time you've upgraded a non-GPSD service daeomon so it can handle either NMEA or (say) SiRF binary, you'll have rewritten most of GPSD. The way the time-delivery pipeline works under Linux is that GPSD uses the GPS take to write on a shared-memory segment that NTPD reads. The GPSD code that handles 1PPS interpretation and the handoff to shared memory is complicated and nasty, without question the most obscure part of the GPSD codebase. Trust me when I tell you that you do *not* want to try to duplicate this - debugging it is a stone bitch. -- Eric S. Raymond