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 ECA2420027E for ; Tue, 13 Mar 2012 16:06:31 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 1000) id 2772540617; Tue, 13 Mar 2012 19:06:13 -0400 (EDT) Date: Tue, 13 Mar 2012 19:06:13 -0400 From: "Eric S. Raymond" To: Mike Hord Message-ID: <20120313230612.GA24800@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] Project clarification 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: Tue, 13 Mar 2012 23:06:32 -0000 Mike Hord : > Can someone please clarify for me exactly what the aim is, however? I've > been unable to find a cohesive problem statement anywhere. From what I've > gathered, the idea seems to be to use the GPS timebase to provide a far > better gauge of time-of-flight (I'm not a network engineer; I don't know > what the real term would be) of a packet from one location on the internet > to another than current methods can provide. > > I'm also thinking the idea is to distribute many of these so that the > time-of-flight can be mapped and pinch points (created by filtering, > throttling, or simply poor or undersized pipelines) can be spotted and > fixed (by whatever means are appropriate for the given problem). > > Am I right? That is almost correct. Dave Taht and I are the instigators here; I'm what passes for the project manager (this being a volunteer group), so I'll try to explain our objectives a bit more fully and Dave may chime in. This project is an offshoot of the anti-bufferbloat effort; Dave is one of the principals in that and I'm trying to help. Yes, the instrumental goal is to measure packet latencies better, and the key point is that we *can't use NTP as a timebase*, because (a) we want to use NTP rawstats to measure propagation, and (b) bufferbloat effects may be compromising NTP by violating some statistical assumptions it relies on. The one bit that you don't have quite right is "filtering, throttling, or simply poor or undersized pipelines". No, the quarry we're after is latency spikes induced by over-buffering and poor queue-management. We think that can *masquerade* as these other things you mention, so we want an independent check on it. Yes, we want to deploy around a hundred instrumented routers (more would be better) which puts heavy pressure on the maximum per-unit deployment costs. Dave and I are members of the Internet's engineering cadre - both pretty old-school, going back to the 1980s. But thinking about this problem has led us to some realizations that are of clear interest to people outside that group, which is why several people who aren't Internet cadre have already joined up to help. Notably, we seem to have identified an underserved market niche in time service. One the one hand, ordinary GPS can yield time-service accuracy down to a second with jitter on the close order of a hundred milliseconds. This is not as good as NTP, which is generally believed accurate to 10us (but may not be - that's part of what we want to check). On the other hand, laboratory-grade time service (GPS-constrained rubidium oscillators and the like) offers accuracy to tens of nanoseconds albeit at an extremely high price tag (on the order of $10K per unit). As you can see, there's very a large price and performance gap between vanilla GPS and lab-grade time services. To bogon-check NTP, we need time sources with about 1us accuracy that are cheap enough to be deployable in flocks. It turns out that a lot of people could use these - network delay tomography like we want to do is one application, driving an NTP Stratum 1 timeserver is another, and we've got one observer from the New Zealand Coast Guard who has been saying that they'd like to buy a boatload of such widgets for field operations. In theory, 1PPS from a GPS plus the relatively small drift over one second of a computer clock crystal ought to suffice for this accuracy regime. In practice, 1PPS is unavailable in GPSes priced and configured so we can deploy a hundred of them. Thus the thumbgps project. We've got people blue-skying about lots of different designs of varying degrees of elaboration. The product concept Patrick Maupin (our principal hardware designer) is focusing on is a device the size and shape of a thumb drive that delivers GPS info *and* PPS over USB. (USB would add some jitter due to polling latency but, we think, not enough to bust our 1ms goal.) One such product actually exists, so we know it's possible, but the price is highway robbery - $950 for what's essentially *one additional PCB trace* relative to a $23 Taiwanese GPS dongle. Our ideal outcome would be that 1. We design, prototype, qualify, and document a thumb GPS 2. We publish the schematics and docs as an open-source design. 3. Sparkfun, or some outfit like Sparkfun, fabs the result and sells them at a per-device cost that isn't prohibitive for the bufferbloat project's 100-unit deployment. We understand that you can't commit Sparkfun to this plan. Indeed it would be foolish to do so if you could, as this project is just spinning up. But you wanted a clear statement of our objectives, and this is it. -- Eric S. Raymond