On May 31, 1:18 pm, "David J Taylor" <[email protected] part.nor-this.co.uk.invalid> wrote: > [email protected] wrote: > > Just a quick follow up. Dave has supplied me with some updated code > > and this seems to be working OK on my machine now. It appears that > > most of the issue I was seeing was corrected when I turned serial port > > buffering off. At this point I am using the Atom (PPS) driver on > > Windows since the Oncore driver is not working at this time. > > Thanks for reporting back. Good of Dave to find time to help, and good > that we are gradually extending the Windows support in NTP. My thanks to > all that are helping. > > David
Of course this is still all very new on Windows and it will take time to mature. So I was not real surprised when I couldn't get it to work initially. Hopefully others will test this and if they have any issues will work with Dave to fix them. On Windows I am now seeing sub-millisecond offsets once things stabilize. This takes about 2 hours. This is not nearly as good as what I see on Linux with my heavily tweaked system. It reports sub- microsecond offsets after it has stabilized and this typically happens in less than 15 minutes. Jitter is higher than what I see on Linux at around 10us to 15us compared to 1us on Linux. But it is a big improvement over the time keeping on Windows with no PPS device where I was typically having offsets in the 5ms to 15ms range using hand selected public time servers (using only pool servers I would expect this to be 15ms to 30ms). The other thing I ran into is that I had some issues keeping the PPS selected by NTP. This is not a Windows specific issue. I was using near by (IE. low latency) public stratum 1 servers and the offsets clustered so close together that the PPS was an outlier much of the time. I "fixed" this by only using one of the stratum 1 servers and designating it as the "prefer" peer. Then using additional pool servers which the intention that these would be more likely to end up being outliers because they would have higher latency, offsets and jitter. And that this would increase the likely hood that the PPS would not be an outlier. This seemed to work. I also had to increase the mindisp setting otherwise it would take a long time for ntp to start using the PPS. In some ways the Atom driver is flawed in that it makes some assumptions about how the PPS is related to the prefer peer and also assumptions about the viability of the PPS itself based on that assumed relationship. In my case the PPS is from a timing device that is configured to monitor the quality of the PPS and to disable the PPS is it is not working correctly (TRAIM and position hold are turned on). The flaw is that the driver makes the assumption that the PPS is trustworthy if the prefer peer is working but is otherwise not to be trusted. This may be true for some combinations like a NMEA GPS with an always on PPS pulse where the NMEA GPS is the prefer peer. But if the prefer peer is an external NTP server then the viability of the prefer peer does not tell us anything about the quality of the PPS source and the assumption breaks down. The flip side is that with a device like a timing Oncore the PPS can be setup to only appear if things are working correctly and under those conditions the prefer peer tells us nothing about the quality of the PPS. These are not fatal flaws but users need to understand these limitations to get the most of of this driver. I don't know how to solve this issue other then that it would go away for me if the Oncore driver was working on Windows (IE is it not an issue for me on Linux). Hopefully this will happen at some point soon. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
