[Thumbgps-devel] Project clarification

Eric S. Raymond esr at thyrsus.com
Tue Mar 13 19:06:13 EDT 2012


Mike Hord <mike.hord at sparkfun.com>:
> 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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



More information about the Thumbgps-devel mailing list