[Thumbgps-devel] Project clarification

[Ron Frazier (NTP)]

On 3/13/2012 9:10 PM, Dave Taht wrote:
> On Tue, Mar 13, 2012 at 4:06 PM, Eric S. Raymond<esr at thyrsus.com>  wrote:
>    
>> 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 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.
>
>    

I'd like to get a further minor clarification on the project goal.  Do 
you want your time reading to be within plus or minus 1 ms of UTC, for a 
total range of 2 ms?  Or do you want it to be within plus or minus 500 
us of UTC, for a total range of 1 ms?

Sincerely,

Ron


-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com