On Feb 8, 12:12 pm, Chris <[email protected]> wrote:
> I'd be very interested to know your implementation in windows for > capturing the PPS pin. I'm currently using a FreeBSD box and syncing > windows boxes around it, but I'd much rather be able to sync my > windows servers directly to the device for a few of the critical > servers. Any chance you'd share your methods, or at least give some > hints? I'm well versed in the Windows API, so that shouldn't be a > problem. I just assumed that you'd need a kernel driver for this sort > of syncing. Well, a modified serial driver that would timestamp CD transitions would be ideal and would give better results than I'm getting. That's not really practical unless you can start with Microsoft's existing serial.sys code (it may be in the DDK, I don't know). What I've done is patch ntpd serial code for Windows to better emulate unix tty line discipline, where a read returns at each end of line. I've done this using WaitCommEvent and dcb.EventChar set to CR. The sources (a few days old) and binaries (very recent) for my patched ntpd for Windows are on http://davehart.net/refclock/ The PPS implementation (hack) fell out of this design. Instead of waiting for just the event character, the code always waits for changes to the CD line. When it transitions on, a timestamp is taken. When a serial refclock next reads a line from the serial port, instead of timestamping the arrival of the CR, the PPS-on-CD timestamp is used instead if one has been taken since the last line was read. So this makes any serial refclock with PPS on the CD line act as a PPS- controlled refclock. It is not the preferred design, of course, because it's not getting a timestamp at interrupt time, and also because there is a move to get PPS functionality out of individual refclock drivers and use the separate ATOM refclock for the PPS aspect. Now my change doesn't use any PPS functionality in the reflclock driver, it just causes the reflock to appear to complete reading a line of text at the time of the PPS signal. It sounds like you might want to share the PPS signal among several hosts with only one getting the serial data pins connected. In that case, what you really need is a bit of work to provide a PPS-only refclock on Windows, presumably using the ATOM driver. I'm sure it can be done, it's just a matter of doing it cleanly enough to be accepted into the ntp reference implementation. Are you contemplating bringing just PPS to the Windows boxes or PPS+serial? The binares on http://davehart.net/refclock/ have other patches as well as the serial code. They should behave better on Vista machines (assuming -M on the command line as defaulted by Meinberg's installer) by disabling nanokernel-like interpolation when it can't possibly work well. Other Windows machines should benefit from changing the interface to return the (possibly synthesized) time of day to the portable ntp code from timeval / microsecond resolution to timespec / nanosecond resolution. The interpolation calculates the time internally using Win32 units of 100 ns, so-called hectonanoseconds, but without my patch always rounds off the tenths-of-a-microsecond component before returning it to the portable ntpd code. That allowed one machine I tested on to go from precision=-20 to -21, which is an exponent of 2, so from about a microsecond to about 500 nanoseconds. Additionally the interpolation scheme is marginally improved by filtering outlying samples of time/counter correlations. The biggest downside is the patched binaries are chatty to the eventlog/ntp.log, particularly about the filtering. I encourage anyone using ntpd on windows to give them a whirl and report back. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
