Good point - AND I guess it would also need to take into account a few ms of processing time too, perhaps? (i.e. time taken from read of data, to parse it and update the clock - probably not a great deal of time involved, but if the clock needs to be accurate to a fraction of ms, then it might be significant?) Also thanks - now I have a good use for my windows hardware :-D Cheers!
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Jason Hecker (Up & Running Tech) Sent: Wednesday, 1 July 2015 3:28 PM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] Leap Second NTP bug?
Without seeing the AT command set to pull the GPS data off, just be wary that when you parse the time (and location if need be) data that you only do so when the signal is valid/not-void. When the GPS isn't locked it's time tends to be free running or plain wrong. I made a GPS based NTP server for AAHL in Geelong once that used the GPSD/NTPD combo with PPS on the serial port for their secure LAN - it worked very well. I have had no issues with the SNTP Client on Microtik boxes getting their time off Windows Server either.