From: "Ron Frazier (NTP)" <timekeepingntplist@c3energy.com>
Cc: thumbgps-devel@lists.bufferbloat.net
Subject: Re: [Thumbgps-devel] Project clarification
Date: Wed, 14 Mar 2012 00:02:28 -0400 [thread overview]
Message-ID: <4F601854.30209@c3energy.com> (raw)
In-Reply-To: <CAA93jw7TbcF3Kf=4W4wqaZm+Qk72kfO9RGYFt=3jy_x-uOBDtw@mail.gmail.com>
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
next prev parent reply other threads:[~2012-03-14 4:02 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
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) [this message]
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=4F601854.30209@c3energy.com \
--to=timekeepingntplist@c3energy.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