Hi guys
We recenty got new Supermicros SYS-1029UX-LL1-S16 20 core servers for testing. We are running it with RedHat 7.4. In our testing we have observed that the system clock on these servers is running way too fast. Evidence of observation 1. Chrony We sync our servers using chronyd and the frequency for this one is something we havent seen anywhere. I am not sure that clock can be slewed to accommodate this much frequency offset. (SYS-1029UX-LL1-S16 is gaining 26 millisecond every second). > chronyc tracking Reference ID : xxxxxxxx Stratum : 4 Ref time (UTC) : Fri May 11 08:48:20 2018 System time : 0.000001912 seconds fast of NTP time Last offset : +0.000001952 seconds RMS offset : 0.000001457 seconds Frequency : 26814.393 ppm fast Residual freq : +0.134 ppm Skew : 0.124 ppm Root delay : 0.194362879 seconds Root dispersion : 0.000912781 seconds Update interval : 4.0 seconds Leap status : Normal It is taking forever to adjust clock rate to accomodate this much frequency difference. 2. PTPD We also tried running ptpd to sync time with max_offset_ppm = 1000 to adjust for maximum possible frequency difference, but this was also futile. > /var/run/ptpd2.event.log 2018-05-11 14:21:21.249612 ptpd2[113396].enp94s0 (info) (slv) TimingService.PTP0: acquired clock control *2018-05-11 14:21:49.976752 ptpd2[113396].enp94s0 (critical) (slv) Offset above 1 second (1.001336627 s). Clock will step.* 2018-05-11 14:21:48.975450 ptpd2[113396].enp94s0 (warning) (slv) Stepped the system clock to: 05/11/18 14:21:48.975425504 2018-05-11 14:21:49.169540 ptpd2[113396].enp94s0 (notice) (lstn_reset) Now in state: PTP_LISTENING 2018-05-11 14:21:51.022561 ptpd2[113396].enp94s0 (info) (lstn_reset) UTC offset is now 37 2018-05-11 14:21:51.022639 ptpd2[113396].enp94s0 (info) (lstn_reset) New best master selected: 88f031fffec32ec1(10.30.128.1)/0 2018-05-11 14:21:51.022788 ptpd2[113396].enp94s0 (notice) (slv) Now in state: PTP_SLAVE, Best master: 88f031fffec32ec1(10.30.128.1)/0 (IPv4:172.27.210.123) 2018-05-11 14:21:51.024175 ptpd2[113396].enp94s0 (notice) (slv) Received first Sync from Master 2018-05-11 14:21:52.057232 ptpd2[113396].enp94s0 (notice) (slv) Received first Delay Response from Master 2018-05-11 14:21:52.057246 ptpd2[113396].enp94s0 (notice) (slv) Received new Delay Request interval 1 from Master (was: 0) 2018-05-11 14:21:59.257989 ptpd2[113396].enp94s0 (notice) (slv) Servo: Going to slew the clock with the maximum frequency adjustment *2018-05-11 14:22:28.029476 ptpd2[113396].enp94s0 (critical) (slv) Offset above 1 second (1.011173248 s). Clock will step.* 2018-05-11 14:22:27.018337 ptpd2[113396].enp94s0 (warning) (slv) Stepped the system clock to: 05/11/18 14:22:27.18314450 2018-05-11 14:22:27.196373 ptpd2[113396].enp94s0 (notice) (lstn_reset) Now in state: PTP_LISTENING 2018-05-11 14:22:29.056742 ptpd2[113396].enp94s0 (info) (lstn_reset) UTC offset is now 37 2018-05-11 14:22:29.056797 ptpd2[113396].enp94s0 (info) (lstn_reset) New best master selected: 88f031fffec32ec1(10.30.128.1)/0 2018-05-11 14:22:29.056843 ptpd2[113396].enp94s0 (notice) (slv) Now in state: PTP_SLAVE, Best master: 88f031fffec32ec1(10.30.128.1)/0 (IPv4:172.27.210.123) 2018-05-11 14:22:29.063858 ptpd2[113396].enp94s0 (notice) (slv) Received first Sync from Master 2018-05-11 14:22:30.066198 ptpd2[113396].enp94s0 (notice) (slv) Received first Delay Response from Master 2018-05-11 14:22:30.066215 ptpd2[113396].enp94s0 (notice) (slv) Received new Delay Request interval 1 from Master (was: 0) Approximately every 40 seconds the clock has to be adjusted back 1 second to accomodate for the time gained which cannot be offset by the frequency adjustment. There is clearly nothing we can do using only frequency adjustment to accommodate a clock frequency this high. We also dont want the clock to go back in time because it can affect some of the mathematical calculations based on time difference which are written (not by me) on the premise that time moves only forward (which indeed it should :)). Would really appreciate any solutions to rectify this issue. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
