[LinuxPPS] LinuxPPS comparable to FreeBSD here

[Miroslav Lichvar]

On Fri, Jun 18, 2010 at 11:36:54AM -0700, Hal V. Engel wrote:
> On Friday 18 June 2010 01:23:22 am Miroslav Lichvar wrote:
> > You might also want to try chrony which uses a linear regresion model.
> > It usually performs better than both PLL and FLL.
> 
> Looking at the chrony email lists I see that you have been working on it.  In 
> particular I noticed that you created a set of temperature compensation 
> patches.  Are these based on the work of Mark Martinec 
> http://www.ijs.si/time/temp-compensation/ ?

I have read it when I was working on the patch. A slightly different
approach is used in chrony though. The corrections are independent
from polling interval, so you can make use of a low resolution
mainboard sensor with long NTP polling intervals. The idea is that
reading temperature is cheaper than querying an NTP server. With
reference clocks it probably won't be very useful.

> Also I notice that refclock support was added to chrony earlier this
> year.  This appears to be limited to three types of refclocks PPS,
> SHM and SOCK.  Are there plans to add more drivers?  For example,
> the NTP NMEA and Oncore drivers are probably the most widely used
> drivers by members of this list and it would be nice to have these
> devices supported natively. 

A basic NMEA driver, so we would have at least some functionality
without gpsd, would be very nice. It's on my todo list, but I don't
know when I'll get to it. Patches are welcome :).

As for binary protocols, I'm not sure if it's worth duplicating the
effort with gpsd. If there are some time specific features missing in
gpsd, maybe it would be better to try implementing them there first?

Anyway, I'm considering getting one of the Oncore receivers sold on
eBay, I'd really like to try out the 100Hz PPS mode.

> Windows on my machine and on Windows the ntp refclock support is
> limited so I have to use the PPS driver with my Oncore.  This does
> work but not nearly as well as the native driver (slow to fully sync
> up,  larger offsets and requires the use of external servers).

I think in chrony a native driver wouldn't necessary improve the
performance. The PPS driver can be locked to the SHM driver which
means the PPS samples are used immediately as gpsd starts sending
the samples decoded from NMEA or binary messages. With poll 2, it's
usually able to get 1us sync in less than one minute.

I can write a short chrony+LinuxPPS+gpsd howto if anyone is
interested.

-- 
Miroslav Lichvar