Re: [Thumbgps-devel] Project clarification

[Dave Taht <dave.taht@gmail.com>]

On Tue, Mar 13, 2012 at 4:06 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Mike Hord <mike.hord@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 LIKE your description!

I also agree that things are confusing, this project was stalled out
for 9 months before it hit erics blog (after being locked in his
basement trying to make anything work for a week), and now this
list...

A couple notes to tack onto esr's notes -

0) We've been trying to get something better than ntp or
gps-without-pps for a while now... the more accurate this can be made,
the smaller the error bars for time of flight. Right now the error
bars are in the half a diameter of the internet range (170ms)

1) jg and I were involved in olpc and one of my long term other
projects has been to finish spreading the internet around the world.
Doing that in many places gets hard. I was working on mesh networks,
and having small gpses actually on routers on the poles/trees/etc
would have helped a lot on finding the devices again. (this is
something of project creep, see 3). In the long run (after this
project!) I'm thinking something 'smile plug'-like+gps.

I note that in that long run perhaps the gps feature will become
integral to outdoor wireless, as it has entered at least one product
line already: http://www.ubnt.com/rocketmgps

2) Having reliable time on or near boot down there is good (kerberos
needs 5 minutes, dnssec an hour, dhcp and routing daemons have time
dependencies), particularly as the reason for a boot is usually a
power failure that has taken out a sizeable chunk of the network.

3) While cbbd was originally conceived of as a way to fact-check ntp
beyond the edge, and be able to take a harder look at the data ntp was
filtering out, there seem to be other uses that we're blue-skying
about (I mentioned weather stations as one, gps+crypto as another), to
try and come up with something more unique.

4) But we circle back to trying to get down to 1ms resolution, or
better, on the other side of the network edge, as the core goal.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net