[ntp:questions] like a kid with a new toy (PPS jitter)

Dave Hart davehart at gmail.com
Thu Feb 5 22:23:51 UTC 2009


On Feb 5, 9:33 pm, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Dave Hart wrote:
> > Looking at the last 800 loopstats lines for the refclock, representing
> > a bit more than 3 hours of 16s polls, the offsets in microseconds look
> > like
>
> > -79.497    min
> > -26.961    mean
> > 20.565     max
> > 17.381     stddev
>
> > The jitter (us)
>
> > 1.907      min
> > 7.974      mean
> > 35.64      max
> > 4.651      stddev
>
> > How does that look to more jaded PPS eyes?
>
> Pretty bad actually: After a day or so you should see 0-5 us offset and
> jitter.

I hope, but I'm not optimistic.  This is PPS on Windows without kernel
support, so the timestamp comes after the OS has noticed the state
change of the CD line and passed that news along to ntpd.  A spot
check of recent peerstats lines looks consistent with the stats above.

> > The refclock is a Garmin GPS 18x LVC connected to a dual PII 400 via
>
> I have one of those! (A Dell?)

Yes, PowerEdge 2300.  It uses 9G and 18G drives on a SCSI RAID
controller.  A whole gig of RAM ;)  I had a dual-400 410 workstation
as well, it's been long retired.

> It might work even better in single-cpu mode if it is a dedicated ntp
> server.

It's running with a patch to lock the main and timer threads to the
2nd CPU using SetThreadAffinity.  I haven't tried locking the async I/
O thread as well, but I will now.  It's also running with a patch to
the interpolation code which is more selective about baseline counter/
time pairs it uses.  There is a faster server on the same LAN I could
try as well, but I figured slower is better for understanding how bad
the user-mode PPS implementation is.

Cheers,
Dave Hart




More information about the questions mailing list