Re: [gpsd-dev] Mysteriously vanishing bugs don't make me happy

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

> Yo Greg!
>
> On Mon, 04 Nov 2013 16:14:27 -0500
> Greg Troxel <address@hidden> wrote:
>
>> 
>> Have people been seeing jitter low enough that microsecond
>> quantization looks like a real issue?
>
> Yes.  I now see +/- 400 nSec jitter on chrony socket.  I could do better
> on a dedicated time server.  Best I can do with SHM is currently about
> +/- 2 uSec.

I don't follow why this is different.  Isn't it all about
sample-to-sample repeatability of obtaining the system clock
(timecounter) at the edge?  WHy does it matter how it's conveyed to
chronyd?

>> What kind of clock stability
>> and sync hardware does it take to get to that point?
>
> I have a SiRF III, and KPPS on an eight core Xeon server ruinning irqbalance.

What baud rate, and is that just PPS on DCD, with timestamping in the
receive interrupt?  I guess the secret is that your machine is unloaded
so one of those cores is always ready to take the status change
interrupt without being stuck in a critical section.  Still, I'm
surprised it's that low, and you're only 3dB better than where you'd be
with 1 us resolution.  That's enough to make ns resolution worthwhile,
but it also sems most people won't quite need it (for now, with
DCD-on-serial).

Then, there's the questions of the unmodeled latecny beyond the jitter,
and how the time gets used to timestamp other events.  Which I suspect
blows past 1 us.  Still, not enough to cavalierly give away 0.5 us.


I tested a GR601-W on a modern 4-core box with NetBSD 6.  I think I am
seeing delays of a few hundred us to a bit over 1 ms, relative to a s1
one Ethernet hop away.   This is what I'd expect; some base delay when
the clocks line up plus a delay in [0us, 1000 us), more or less.
So I'd recommend 700 us for the default fudge for USB PPS, absent better
measurements.

pgpr8PsQSzT_T.pgp
Description: PGP signature