From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vx0-f171.google.com (mail-vx0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5453420024C for ; Mon, 12 Mar 2012 13:44:02 -0700 (PDT) Received: by vcbfl15 with SMTP id fl15so8633284vcb.16 for ; Mon, 12 Mar 2012 13:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pRgbgEaMHizbo06ynvnqdAbhj3MEZnZjKie3wnP8ZH8=; b=Zk87pkGSeSRIzCjWjTW0DWKjlE1gueurl0HNWZEqlj2NxcxKK7qB5OdrN8j5neM3uN 7cA3LRtGOHC7b8ci4C1EehIFvX7KZodlwRsO21dgfvulbPbW9jU8YtgLMyvMpnPIA1qp MpWl+RBdgiC0vNAN+PtAnyToZZ6mM/AzVqePrdZX76hNQCThfHO6Tx7QsnAfxo00psXX K51dVhMj+hltb9Ja0YrNxrtUNNf+0iuLCQAYTYYpvXlzv/e6GBti6HY5pxW4kpKi0M7f tu0obc74R2z+3aWSa0TngaLBT3JYb4wZUZkc/NBPhPeWmCMFQCcdoSpV6Yi7mPjFxf8l T1XQ== MIME-Version: 1.0 Received: by 10.52.93.138 with SMTP id cu10mr15464908vdb.86.1331585040880; Mon, 12 Mar 2012 13:44:00 -0700 (PDT) Received: by 10.220.140.132 with HTTP; Mon, 12 Mar 2012 13:44:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Mar 2012 15:44:00 -0500 Message-ID: From: Patrick Maupin To: tz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: thumbgps-devel@lists.bufferbloat.net Subject: Re: [Thumbgps-devel] Jitter and latency in a linux system might be a problem. Minimal BoM crosspost. 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: Mon, 12 Mar 2012 20:44:02 -0000 On Mon, Mar 12, 2012 at 2:09 PM, tz wrote: > The PPS change detect thread in gpsd might have latency problems if > the kernel is busy and/or it isn't a high priority - a plain userland > program shows about 1mS jitter - a loop with the ioctl to block until > a pin-change followed by gettimeofday will vary over about a 1000 uS > band on my dual-core netbook. I thought sub-ms wasn't really necessary. Sub-us would be useful in a testbench for characterizing devices to make sure they meet ms... > I'm not sure how much of the jitter might be due to =A0the USB latency > to detect an interrupt condition at the far end, but USB 2.0 ought to > be fairly fast. That really depends on how the scheduler is set up. A driver can request 'x' interrupts per second. But then there will be latency inside the USB part as well. > =A0However it might debounce or otherwise delay the > detection of a serial line change to eliminate noise That latency should be fairly fixed. But we can measure it with a test set= up. > But to state the problem clearly, you want the clock to have 100nS > accuracy, Where was that listed as a requirement? I think there's some misunderstanding here. > but there is no way in userland and/or USB to get better > than 1mS jitter even if the edges going into a serial device are > precise. Which is probably good enough. > Any SkyTraq GPS (I have the Venus 624 and 628, and their GLONASS/GPS > modules), the "$" character in the first sentence can be synced to the > UTC second and comes out at a fixed delay from the PPS edge, just over > 1mS to stop bit with no visible jitter so technically it would be as > accurate as the PPS itself, and the latency could be compensated for. That's useful. With a testbench we can test this, and with a small CPLD in conjunction with such a module and a serial to USB converter, we might even be able to make this work over USB by wiggling CTS or DSR. In other words, if we find a module without PPS, but *with* accurate first-character message timing, we can wiggle a modem control line when the first character starts to force an immediate USB interrupt response, rather than waiting on the entire message plus some extra latency, which is what the USB chip would normally do. > At 115kBaud there will be over 500mS of serial silence before the $, > so it can be detected fairly easily, perhaps even in a Linux-PPS > interrupt timestamp (if $, grab temp timestamp, if temptimestamp is > over 500mS from last timestamp, update - treat as PPS). =A0If the > CTS/DCD line switch ioctl jitter is acceptable, this is about the same > and requires no modifications. Right. > Also using just the NMEA mode in an unmodified GPSD, the latency error > for the time was very consistent - about 17 mS with the standard > sentence set, =A0there will be slightly more jitter since it invokes the > PPS routine after the final sentence in the NMEA set > (GPGGA/GSA/GSVx3/GPRMC), the sentences vary in length. =A0If you just > counted the characters (they are a continual burst), you could divide > by the baud rate to get the position of the start bit of the '$', but > it would likely have the same userland or USB jitter. It would be nice if you could backtrack like this. Wouldn't need any extr hardware. > Perhaps a possibility would be an external clock that you could > trigger a capture-time event when the packet arrived and read out > slower. =A0The external timer could be synced to UTC and very precise > (I've played with syncing signals from an Atmel chip to PPS), so the > internal ntp synced clock might just be approximate. =A0It doesn't fix > the kernel jitter but would act like an external precise and accurate > stopwatch. I think there are a lot of really good possibilities, but the first thing to do is a hardware-assisted testbench to take accurate measurements, so we know the source and size of all the latencies in the system. I haven't heard back from esr about what he thinks of this approach, though, so I am reluctant to start work on anything until we have some consensus on the idea that we should grab several devices and USB modules and USB chips and see how well they really operate. > Does this have to be an actual router, or could it sit on the network > right at the gateway? =A0If you just need to measure "router-to-router", > it might be easier to use something like an arduino with ethernet > shield and emit a UDP or ICMP packet EXACTLY at the UTC second > (assuming no ethernet collisions, but a good switch should be able to > avoid them). =A0 There are embedded servers inside what appear to be > large ethernet connectors which are fairly inexpensive. =A0Perhaps a UTC > synchronized pingbot - ping it and it will do the echo exactly at the > UTC second. =A0Two pingbots could measure to well under 1mS precision > and accuracy. =A0Basically an embedded system that would only know UDP, > but you could tell it to send a packet to a destination, but it would > do so within microseconds of the PPS. and tag anything in and/or > return an echo with the incoming timestamp, e.g. over a command line > interface: This is an interesting idea. I had wondered about ethernet, but the idea of setting up anything NTPish on a tiny micro seemed daunting. I like the idea of such a UDP request/response mechanism. > Assuming you compile GPSD with PPS on CTS it might be done with the > following three main parts: I think we should compile a list of ways to build acceptable units. But I really believe that to do so, we ought to test all the components... > The SkyTraq PPS is accurate to 60nS mainly due to the 16Mhz internal cloc= k rate. Have you checked that over days? I'm intrigued by the graph that I just saw of things going haywire. > Even if you get a $30 GPS unit you would have to break it open and do > some soldering under a stereo microscope, assuming you can attach the > PPS to DCD or CTS or another pin easily. Absolutely. But esr's stated end product (which I think should be possibly part of our range of solutions) is a tiny USB key. I found that one for $23, and it's particularly noteworthy because I've seen pictures of it disassembled on the internet and it appears to have everything we need except one blue wire. I've also seen others on Amazon for $19. There's no way you could buy all the parts that cheaply.