[Thumbgps-devel] Project clarification

[Thumbgps-devel] Project clarification

[Mike Hord]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

Hi guys-

Not speaking officially for SparkFun on this, I will say that there's been
some interest and discussion among the engineers here about it.

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?

Mike

[-- Attachment #2: Type: text/html, Size: 1006 bytes --]

Re: [Thumbgps-devel] Project clarification

[Eric S. Raymond]

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'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>

Re: [Thumbgps-devel] Project clarification

[tz]

A side note - Sparkfun has the Venus638 on a breakout board and it has
a PPS and even a "sync to UTC" so in 1Hz mode the first sentence start
bit is at a small fixed offset from UTC, so it has a few ways which
might make things easier downstream,.  I've been playing with them and
it is a reason I've suggested their use.

There also is some consideration that these things should be in some
kind of enclosure.  They may end up inside a router on a console port
though.  That is part of the spin-up.

Some milli-micro clarifications:

On Tue, Mar 13, 2012
 at 7:06 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 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).

Maybe LAN NTP can go 10uS - microseconds, but pool.ntp.org is more
like 10mS - milliseconds

> To bogon-check NTP, we need time sources with about 1us accuracy that
> are cheap enough to be deployable in flocks.

1uS - One Microsecond?

> ...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.)

1ms - One Millisecond goal?

Measuring an edge inside a kernel interrupt (linuxPPS) is probably
under 10uS, maybe well under as long as interrupts aren't disabled.
It would depend on the polling interval, but USB2.0 should have lower
latency.

Re: [Thumbgps-devel] Project clarification

[Dave Taht]

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

Re: [Thumbgps-devel] Project clarification

[Eric S. Raymond]

tz <thomas@mich.com>:
> On Tue, Mar 13, 2012
>  at 7:06 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > 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).
> 
> Maybe LAN NTP can go 10uS - microseconds, but pool.ntp.org is more
> like 10mS - milliseconds

Right, I typoed the prefix - 1 millisecond is the goal.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [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@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.
>
>    

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

Re: [Thumbgps-devel] Project clarification

[Eric S. Raymond]

Ron Frazier (NTP) <timekeepingntplist@c3energy.com>:
> 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?

The latter. Total range of 2ms.

This is believed to be achievable because the data sheet for the ZTI
Z050 (the only existing USB thumb GPS with PPS) promises 1ms in the way
you seem to mean it.  

Their claim is credible given that PPS is guaranteed accurate within
50ns. The default USB polling rate of 125Hz implies polling latency of
8msec, but it's possible to jack that up by a factor of 8 within the
USB spec, and I'm certain that's what ZTI's timing software is doing.
That would produce a polling interval of 1ms, neatly matching their
accuracy claim.  The additional 50ns jitter (6 magnitudes down) and
the handful of us required for processing on the host side (3
magnitudes down) would vanish compared to this.

If I'm misunderstanding ZTI's accuracy claim, it's possible we might
get the tighter 500us range.  We'll test.

Either figure will do for Dave's intended use, which is network
delay tomography where the feature size is likely to be about 10
milliseconds.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Project clarification

[tz]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

Anyone remember Metricomm?  The interner from the light-poles.  I still
have two (user) modems.  They all had their gps coordinates as part of
their connect data.

A Low-cost, versatile, 'hacker' gps would be welcome many places

On Mar 13, 2012 9:10 PM, "Dave Taht" <dave.taht@gmail.com> wrote:

> 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.

[-- Attachment #2: Type: text/html, Size: 925 bytes --]

Re: [Thumbgps-devel] Project clarification

[Dave Taht]

On Tue, Mar 13, 2012 at 7:28 PM, tz <tz2026@gmail.com> wrote:
> Anyone remember Metricomm?  The interner from the light-poles.  I still have
> two (user) modems.  They all had their gps coordinates as part of their
> connect data.
>
> A Low-cost, versatile, 'hacker' gps would be welcome many places

I did a lot of work on mosquitonet, which was based on those (Very cool) radios.

from:

http://www.rage.net/wireless/diary.html

04/18/98: "We plug greg's ricochet into screamingslave and tweak and
hack and get a connection that stays up (mostly). It's connected to a
cell nearly 20 miles away! (this is on a device rated for .3 miles)

The wonderful service of ml.org provides us a stable domain name for
our unstable ip addresses. Now we have mail, basic web service, and
the ability to get to our machines at home from anywhere. Yea! It's
very s l o w, however, 400-800 ms turnaround time. Ugh. Going up and
down confuses the ip_masquarading code in linux 2.0.30 terribly.
Ultimately we just live with a conventional web proxy and ssh into the
main box to get to the outside world.

Fired off an email to ricochet telling them of our amazing success,
they don't believe us, greg put up our chart of the line of sight
modems we detected.

http://www.rage.net/cells.gif "


Yes the GPS feature was darn useful then and darn useful today.

...

While I'm often quite happy with what happened with wireless after
those good ole days...

I sometimes sadly think the structure of today's wireless APs is my fault.
And so do some other people.

http://the-edge.blogspot.com/2010/10/who-invented-embedded-linux-based.html

What we'd done then with one access point, and published widely,
became the standard AP.

What we hadn't published, that are everpresent-ly discussed in the
emails that got unearthed as part that court case - things like real
dns, and a web proxy, and bandwidth management - are what never made
the marketplace.

And the lesson learned in 96-98 from the behavior of tcp over such
unreliable wireless links has led to such massive overkill today as to
further break tcp. A little ARQ goes a long way....

> On Mar 13, 2012 9:10 PM, "Dave Taht" <dave.taht@gmail.com> wrote:
>
>> 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.



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

Re: [Thumbgps-devel] Project clarification

[tz]

A few other observations:

Many of the SoCs used in the cheap routers have other on-chip
perhpherals which can get us past the USB.  I think I can get an
Atmega to be a time-source synced to UTC.

We could send an event OUT the USB host and timestamp it at the
device, returning when it saw it - this might be more accurate if this
is more granular than polling.

We don't know yet if LinuxPPS - kernel interrupt driven timestamping
is needed, but will probably be much more precise.

No one has suggested turning this into a time peripheral, but that
might be easier - if a microcontroller could be synced and made
accurate enough (varactor like the old Heathkit clocks?) then all the
gettime calls could go out to our device and get precise time.  Of
course the kernel could sync its time easily as well.

There are faster than PPS, e.g. the Garmin 18LVx-5Hz has 5 pulses per
second, at each 200mS interval, one of the 5 is the precise UTC, the
others are precise too.

The Sparkfun module plus either active antenna that goes with it makes
it easy to receive GPS - having a dongle with a small strip antenna
that you have to fiddle a lot with to get a good signal defeats the
purpose.  The magnetic mounts with long cables make things easy.  We
haven't talked much about antennas, but it is important.

Re: [Thumbgps-devel] Project clarification

[Dave Taht]

On Tue, Mar 13, 2012 at 6:28 PM, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> On 3/13/2012 9:10 PM, Dave Taht wrote:
>>
>> On Tue, Mar 13, 2012 at 4:06 PM, Eric S. Raymond<esr@thyrsus.com>  wrote:
>>
>>>
>>> Mike Hord<mike.hord@sparkfun.com>:

> 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?

Heh. Good question.

As good as it is possible to get without having to have rubidium
clocks embedded in the stick?

Better than 10ms is desirable, and the 1ms is something of an
arbitrary goal. Nyquist theorem applies, and then there's slop/noise
elsewhere in the system that will start cropping up (interrupt
latency, etc)

Trying to clearly identify problem hops from multiple sides is
dependent on the 'distance' inherent in the underlying technology. If
we wanted to identify problems on a single 10GigE ethernet segment,
that's measured in *ns*. We don't, thankfully.

First hop out of a router is generally 1ms, same for wireless. Cable
is in the 2ms-8ms range. DSL, up to 60ms, same for wimax...

So < 5ms would be the outside goal, and anything less than that - so
long as it can be thoroughly catagorized - is a bonus.

Continental US distances are 60-100ms...




>
> 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
>
>
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel



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

Re: [Thumbgps-devel] Project clarification

[Dave Taht]

On Tue, Mar 13, 2012 at 8:08 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Tue, Mar 13, 2012 at 6:28 PM, Ron Frazier (NTP)
> <timekeepingntplist@c3energy.com> wrote:
>> On 3/13/2012 9:10 PM, Dave Taht wrote:
>>>
>>> On Tue, Mar 13, 2012 at 4:06 PM, Eric S. Raymond<esr@thyrsus.com>  wrote:
>>>
>>>>
>>>> Mike Hord<mike.hord@sparkfun.com>:
>
>> 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?
>
> Heh. Good question.
>
> As good as it is possible to get without having to have rubidium
> clocks embedded in the stick?

Ooh! OOh! I found an americium clock for only 13.99!

http://www.cafepress.com/randumbshirts.327160457

> Better than 10ms is desirable, and the 1ms is something of an
> arbitrary goal. Nyquist theorem applies, and then there's slop/noise
> elsewhere in the system that will start cropping up (interrupt
> latency, etc)

I kind of realized I wasn't being as clear as I might like.

right now the jitter and delay is well over 10ms on all the gps
devices we've got our hands on, so it's the most noisy source of
'stable' time there is, and the internal system clock, as corrected by
ntp, does better.

Take the blox gps chip that I'm half in love with. It can - with
tweaking, do a 15ns pulse -

but everything after that you attach to that signal - microcontroller,
usb bus, basic interrupt latency in the os,  userspace response time,
response to load, etc - will add additional jitter. And all that has
to be measured.

So starting with the least jitter possible and fixing it at every step
of the way out of the chip is what would happen, which is why it's
hard to specify (right now, without having a stable time source to
play with at all - which I'm trying to aquire btw) whether .5 or 1ms
jitter will affect things all that much.

I did a lot of work with linux-rt back in the day, and with threaded
interrupts it was possible to do really intense audio work with about
2.8ms sample period on high end (for the day) hardware.

While much of the linux-rt code has made it into the mainline, that
feature hasn't, and the box I'm mostly playing with runs at 680Mhz. I
don't know what it's interrupt latency actually is...




>
> Trying to clearly identify problem hops from multiple sides is
> dependent on the 'distance' inherent in the underlying technology. If
> we wanted to identify problems on a single 10GigE ethernet segment,
> that's measured in *ns*. We don't, thankfully.
>
> First hop out of a router is generally 1ms, same for wireless. Cable
> is in the 2ms-8ms range. DSL, up to 60ms, same for wimax...
>
> So < 5ms would be the outside goal, and anything less than that - so
> long as it can be thoroughly catagorized - is a bonus.
>
> Continental US distances are 60-100ms...
>
>
>
>
>>
>> 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
>>
>>
>> _______________________________________________
>> Thumbgps-devel mailing list
>> Thumbgps-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/thumbgps-devel
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net



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

Re: [Thumbgps-devel] Project clarification

[Ron Frazier (NTP)]

On 3/13/2012 11:42 PM, Dave Taht wrote:
> On Tue, Mar 13, 2012 at 8:08 PM, Dave Taht<dave.taht@gmail.com>  wrote:
>    
>> On Tue, Mar 13, 2012 at 6:28 PM, Ron Frazier (NTP)
>> <timekeepingntplist@c3energy.com>  wrote:
>>      
>>> On 3/13/2012 9:10 PM, Dave Taht wrote:
>>>        
>>>> On Tue, Mar 13, 2012 at 4:06 PM, Eric S. Raymond<esr@thyrsus.com>    wrote:
>>>>
>>>>          
>>>>> Mike Hord<mike.hord@sparkfun.com>:
>>>>>            
>>      
>>> 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?
>>>        
>> Heh. Good question.
>>
>> As good as it is possible to get without having to have rubidium
>> clocks embedded in the stick?
>>      
> Ooh! OOh! I found an americium clock for only 13.99!
>
> http://www.cafepress.com/randumbshirts.327160457
>
>    
>> Better than 10ms is desirable, and the 1ms is something of an
>> arbitrary goal. Nyquist theorem applies, and then there's slop/noise
>> elsewhere in the system that will start cropping up (interrupt
>> latency, etc)
>>      
> I kind of realized I wasn't being as clear as I might like.
>
> right now the jitter and delay is well over 10ms on all the gps
> devices we've got our hands on, so it's the most noisy source of
> 'stable' time there is, and the internal system clock, as corrected by
> ntp, does better.
>
> Take the blox gps chip that I'm half in love with. It can - with
> tweaking, do a 15ns pulse -
>
> but everything after that you attach to that signal - microcontroller,
> usb bus, basic interrupt latency in the os,  userspace response time,
> response to load, etc - will add additional jitter. And all that has
> to be measured.
>
> So starting with the least jitter possible and fixing it at every step
> of the way out of the chip is what would happen, which is why it's
> hard to specify (right now, without having a stable time source to
> play with at all - which I'm trying to aquire btw) whether .5 or 1ms
> jitter will affect things all that much.
>
> I did a lot of work with linux-rt back in the day, and with threaded
> interrupts it was possible to do really intense audio work with about
> 2.8ms sample period on high end (for the day) hardware.
>
> While much of the linux-rt code has made it into the mainline, that
> feature hasn't, and the box I'm mostly playing with runs at 680Mhz. I
> don't know what it's interrupt latency actually is...
>
>
>
>    

Hi Dave,

What you just said reminded me think of something.  A couple of years 
ago, I was doing research into microcontrollers and thought I might be 
designing an audiovisual product.  That never happened, but I ran across 
FreeRTOS, as in Free Real Time Operating System.  I have no idea if it 
would be relevant to what you all are doing, but I thought I'd pass the 
link along.

http://www.freertos.org/

To give an idea of what can be done with off the shelf non PPS USB 
technology, my GlobalSat BU-353 is capable of giving me time offsets 
from it's perception of true time of + / - 6 ms.  The problem is that 
its perception of true time, the NMEA sentences, wander 120 ms or so 
over a period of a few days.  I've been told that you can get + / - 400 
us with PPS emulation through a USB - serial converter.  I hope to test 
that theory soon.

Sincerely,

Ron

>    
>> Trying to clearly identify problem hops from multiple sides is
>> dependent on the 'distance' inherent in the underlying technology. If
>> we wanted to identify problems on a single 10GigE ethernet segment,
>> that's measured in *ns*. We don't, thankfully.
>>
>> First hop out of a router is generally 1ms, same for wireless. Cable
>> is in the 2ms-8ms range. DSL, up to 60ms, same for wimax...
>>
>> So<  5ms would be the outside goal, and anything less than that - so
>> long as it can be thoroughly catagorized - is a bonus.
>>
>> Continental US distances are 60-100ms...
>>
>>
>>
>>
>>      
>>> 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

Re: [Thumbgps-devel] Project clarification

[Eric S. Raymond]

Dave Taht <dave.taht@gmail.com>:
> So < 5ms would be the outside goal, and anything less than that - so
> long as it can be thoroughly catagorized - is a bonus.

Yeah, that's *exactly* how I figure it, too, Nyquist's Theorem and all.
I set 1ms as a goal because the ZTI dongle does that and I think I
know how (jacking USB polling frequency to max), but you're right - for the
delay tomography we can live with anything < 5ms.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Project clarification

[Patrick Maupin]

On Tue, Mar 13, 2012 at 10:05 PM, tz <tz2026@gmail.com> wrote:

> We could send an event OUT the USB host and timestamp it at the
> device, returning when it saw it - this might be more accurate if this
> is more granular than polling.

I was definitely thinking of this when thinking of building the
FPGA-based timestamp-everything unit.  You're right that if we're
willing to write USB device firmware, a lot of opportunities to gain
tighter tolerances present themselves.  This would be even more true
if we pick a highspeed device.

Another simple thing we could do with basic serial units is to loop
back RTS to CTS so you can calculate round-trip time to put an upper
bound on inbound delay.

If we really want to consider our own firmware, we might consider
something like nuttx running on either an Atmel part or an NXP
LPC3131.  Olimex has an NXP development board for $90.

Re: [Thumbgps-devel] Project clarification

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> If we really want to consider our own firmware, we might consider
> something like nuttx running on either an Atmel part or an NXP
> LPC3131.  Olimex has an NXP development board for $90.

Let's do the simple thing first.  If we can pull accuracy down to around 1-2ms
without custom firmware - which I think is achievable - I don't think the
extra NRE for custom firmware can be justified.

OTOH, that route starts to look more attractive if the Mark I thumbGPS
works and we start thinking more seriously about a Mark II device with
Dave's environmental sensors on it.

What each of you with a differing speculative design (or family of
designs) ought to do is name it so we can avoid confusing each other
in discussion.  

I hereby claim the name "Plain Jane" for the concept where we build 
a straight-up USB thumb with PPS, using a commodity GPS module with
TTL serial outlet mated to a PL2303 or similar commodity USB-to-serial
converter, no custom firmware.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Project clarification

[tz]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

The FTDI using CTS is showing a 1mS at most jitter with my venus 638 pps
signal in my userland tests.  The start bit offset is worse but the jitter
seems similar.
On Mar 14, 2012 12:32 AM, "Eric S. Raymond" <esr@thyrsus.com> wrote:

> Dave Taht <dave.taht@gmail.com>:
> > So < 5ms would be the outside goal, and anything less than that - so
> > long as it can be thoroughly catagorized - is a bonus.
>
> Yeah, that's *exactly* how I figure it, too, Nyquist's Theorem and all.
> I set 1ms as a goal because the ZTI dongle does that and I think I
> know how (jacking USB polling frequency to max), but you're right - for the
> delay tomography we can live with anything < 5ms.
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel
>

[-- Attachment #2: Type: text/html, Size: 1495 bytes --]