From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by huchra.bufferbloat.net (Postfix) with ESMTP id B581E20069D for ; Tue, 13 Mar 2012 21:02:31 -0700 (PDT) Received: from [192.168.83.5] (c-76-97-152-51.hsd1.ga.comcast.net [76.97.152.51]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M24nL-1SSUYg1PUh-00tOVU; Wed, 14 Mar 2012 00:02:30 -0400 Message-ID: <4F601854.30209@c3energy.com> Date: Wed, 14 Mar 2012 00:02:28 -0400 From: "Ron Frazier (NTP)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 CC: thumbgps-devel@lists.bufferbloat.net References: <20120313230612.GA24800@thyrsus.com> <4F5FF42B.9060900@c3energy.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:KvGBj3HuzbkgxKLu1vqYSREKuReiJlLXs2QGESRI2kK B/REDNpxMAONYozHxpHp3/cGoXgaFDWFNSrM6HKQeBMT1im3Xt a2oeGLbQJQwABZqMwXxeZ4QLxAT74G7+jyDuHCBk9jiyr6pzew 0R9vMozigRvEH7egnbpzxVVWcbNx5ZSB/83f1Q/yDrgWglOi1a YQm/RNCSEj3msw2D+0HGUBQfts26vLyEkIJmCMGhrM7/2QUCFy cM8GBWbjd8VFcRsemrJvHrwwfLT2+ybADRIg7V05p68j2sS9zH cVMjG+XVFhcwN01p0GBPSamRDtuSrgvNiPOkWH+8VdZzaPctfP h00/NPOawigX1d3VhOqQ= Subject: Re: [Thumbgps-devel] Project clarification X-BeenThere: thumbgps-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 04:02:32 -0000 On 3/13/2012 11:42 PM, Dave Taht wrote: > On Tue, Mar 13, 2012 at 8:08 PM, Dave Taht wrote: > >> On Tue, Mar 13, 2012 at 6:28 PM, Ron Frazier (NTP) >> wrote: >> >>> On 3/13/2012 9:10 PM, Dave Taht wrote: >>> >>>> On Tue, Mar 13, 2012 at 4:06 PM, Eric S. Raymond wrote: >>>> >>>> >>>>> Mike Hord: >>>>> >> >>> 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