[Thumbgps-devel] Project clarification

[Dave Taht]

On Tue, Mar 13, 2012 at 8:08 PM, Dave Taht <dave.taht at gmail.com> wrote:
> On Tue, Mar 13, 2012 at 6:28 PM, Ron Frazier (NTP)
> <timekeepingntplist at 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 at thyrsus.com>  wrote:
>>>
>>>>
>>>> Mike Hord<mike.hord at 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 at 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