From: tz <thomas@mich.com>
To: esr@thyrsus.com
Cc: thumbgps-devel@lists.bufferbloat.net
Subject: Re: [Thumbgps-devel] Project clarification
Date: Tue, 13 Mar 2012 19:30:07 -0400 [thread overview]
Message-ID: <CAFv7OigZ5-o4Sz=KqZHKa3OKvUfY-g3eV7z1ibr6tGbuPKSADw@mail.gmail.com> (raw)
In-Reply-To: <20120313230612.GA24800@thyrsus.com>
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.
next prev parent reply other threads:[~2012-03-13 23:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-13 21:46 Mike Hord
2012-03-13 23:06 ` Eric S. Raymond
2012-03-13 23:30 ` tz [this message]
2012-03-14 1:18 ` Eric S. Raymond
2012-03-14 1:10 ` Dave Taht
2012-03-14 1:28 ` Ron Frazier (NTP)
2012-03-14 1:53 ` Eric S. Raymond
2012-03-14 3:08 ` Dave Taht
2012-03-14 3:42 ` Dave Taht
2012-03-14 4:02 ` Ron Frazier (NTP)
2012-03-14 4:32 ` Eric S. Raymond
2012-03-14 12:44 ` tz
2012-03-14 2:28 ` tz
2012-03-14 2:46 ` Dave Taht
2012-03-14 3:05 ` tz
2012-03-14 4:36 ` Patrick Maupin
2012-03-14 5:00 ` Eric S. Raymond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFv7OigZ5-o4Sz=KqZHKa3OKvUfY-g3eV7z1ibr6tGbuPKSADw@mail.gmail.com' \
--to=thomas@mich.com \
--cc=esr@thyrsus.com \
--cc=thumbgps-devel@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox