Synchronize several cRIOs with a Windows PC in a domain

[nathand]

I have several cRIOs (actually sbRIOs), all modern ones running Linux, on a private network. Also on this private network is a Windows PC that provides a user interface and data logging. How can I use the Windows PC as a time source for the cRIOs? The Windows PC is also connected, through a second ethernet port, to a domain, and it needs to continue to use the domain as its own time source, so I don't want to (and possibly can't) disable the Windows time service, which means I can't install another NTP server on it because they both need access to the same UDP port. I don't need a high level of synchronization so I'm trying to avoid buying dedicated time server software.

My backup plan is to add a command on the user interface that sends the Windows machine's idea of the current time, and sets the sbRIO to that value, which is probably good enough for our use, but it would be nice if I could get this to happen automatically without additional code.

[JÞB]

You might not like this... Did you deal with cooling and airflow specs?  Timebase drift is often a cooling issue to keep the clocks from altering temp coefficients.

Sounds uncanny but,... I recommend double checking it anyway.

[rolfk]

While temperature can of course influence the crystal used to create the clock timebase for the realtime clock, it is by far not the only reason. Each crystal has an accuracy and every device without regular synchronization will eventually have a timebase drift. Just disable the Wifi, GPS, and data on your mobile for a few days and observe the drift it will experience!

And yes modern mobile devices can also use the GPS clock as a synchronization source, since that clock is actually just as accurate as any of the atom clock driven time servers.

What I don't understand is that the Time Synchronization service would block the installation of a NTP server on the Windows machine because of port conflicts. The Time Synchronization Service is in the first place an NTP client which tries to connect to a number of well known NTP servers on the internet. As client, it does not need any specific local port to bind to, but can use any free port for that. It does need to connect to the well known NTP port (UDP 123) on the NIST or whatever server, but that is an entirely different story. So unless the Time Synchronization Service also implements a local NTP server itself, it should not block the well known NTP port. but if it also would implement an NTP server, you would not need to look for an alternate solution, would you!