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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
