Vladimir Thanks for the links.
What I see is replacing the crystal on a PC-based NTP server with an OCXO. I believe that most people are already using Rb clocks in NTP servers. The question of interest is what is possible in the client. We have run a lot of 1588 tests with various crystals and various network scenarios, with both HW and SW timestamps, and with a proprietary clock recovery algorithm. Based on these tests I think that maintaining 1 us for realistic networks and pure SW timestamps is not realistic, even when the client has a decent local oscillator. I will try running a few tests with standard NTPv4 and report to the list. Y(J)S -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Vladimir Smotlacha Sent: Friday, April 01, 2011 11:43 To: [email protected] Subject: [TICTOC] NTP server oscillator issue Hello, I'd like to contribute to the discussion about improving computer clock accuracy, that started yesterday at TICTOC meeting. According to our experiments and evaluation of our NTP servers, very important issue is computer oscillator stability. I replaced the quartz 14.318 MHz at mainboard by a OCXO. We use this hacks in more than 10 servers, both NTP and Time-stamp authorities. We reached system clock accuracy few microseconds (PPS disciplined server) resp. less than 100 microseconds (Stratum-2 with primary NTP in the same LAN). Note: it is objective time offset measurement outside the system. Offset reported in NTP log loopstats provides better numbers. Some of these results are described in Cesnet technical reports http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/ and http://www.cesnet.cz/doc/techzpravy/2008/time-stamp-authority/ regards, Vladimir Smotlacha _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
