I've been using ptpd-2.3.1-rc3 and have discovered an issue with SIGUSR1 support when the ptpd2 is running in -m mode. If it has been in master then switches back to slave when a higher priority master comes online, I'm sending ptd2 SIGUSR1 and sometimes it doesn't actually reset the clock. Most of the time it does, but sometimes it will switch back into master mode then back to slave and the clock ends up not being reset.
Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Need to give this a test or five. Sending a SIGUSR1 when in master state should have no effect. The clock step should only happen when PTPd is in slave state.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sending SIGUSR1 when it is in slave mode. For some reason after the software has been running for a while it looses the ability to sync to ofm. When it has stopped working, after SIGUSR1 it transitions back into master state briefly before returning to slave.
Steve
Here is the log file output.
2015-05-21 09:53:53.446810 ptpd2[1285].eth0 (notice) (slv) Now in state: PTP_SLAVE, Best master: ec4670fffe0051ca(unknown)/01
2015-05-21 09:53:54.446706 ptpd2[1285].eth0 (notice) (slv) Received first Sync from Master
2015-05-21 09:53:54.447029 ptpd2[1285].eth0 (alert) (slv) Servo: -18020 seconds offset detected, will take 10011.1 hours to slew
2015-05-21 09:53:55.409516 ptpd2[1285].eth0 (notice) (slv) Received first Delay Response from Master
2015-05-21 09:53:55.409531 ptpd2[1285].eth0 (notice) (slv) Received new Delay Request interval 1 from Master (was: 0)
2015-05-21 09:54:01.457417 ptpd2[1285].eth0 (warning) (slv) SIGUSR1 received, stepping clock to current known OFM
2015-05-21 14:54:22.343987 ptpd2[1285].eth0 (warning) (slv) Stepped the system clock to: 05/21/15 14:54:22.343968425
2015-05-21 14:54:22.469054 ptpd2[1285].eth0 (notice) (lstn_reset) Now in state: PTP_LISTENING
2015-05-21 14:54:24.336589 ptpd2[1285].eth0 (notice) (mst) Now in state: PTP_MASTER, Best master: 000105fffe1077fe(unknown)/01 (self)
2015-05-21 09:54:05.446407 ptpd2[1285].eth0 (info) (mst) Set kernel UTC offset to 35
2015-05-21 09:54:05.446474 ptpd2[1285].eth0 (info) (mst) New best master selected: ec4670fffe0051ca(unknown)/01
2015-05-21 09:54:05.446501 ptpd2[1285].eth0 (notice) (slv) Now in state: PTP_SLAVE, Best master: ec4670fffe0051ca(unknown)/01
2015-05-21 09:54:06.445949 ptpd2[1285].eth0 (notice) (slv) Received first Sync from Master
2015-05-21 09:54:06.446243 ptpd2[1285].eth0 (alert) (slv) Servo: -18020 seconds offset detected, will take 10011.1 hours to slew
2015-05-21 09:54:07.391950 ptpd2[1285].eth0 (notice) (slv) Received first Delay Response from Master
2015-05-21 09:54:07.391967 ptpd2[1285].eth0 (notice) (slv) Received new Delay Request interval 1 from Master (was: 0)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been using ptpd-2.3.1-rc3 and have discovered an issue with SIGUSR1 support when the ptpd2 is running in -m mode. If it has been in master then switches back to slave when a higher priority master comes online, I'm sending ptd2 SIGUSR1 and sometimes it doesn't actually reset the clock. Most of the time it does, but sometimes it will switch back into master mode then back to slave and the clock ends up not being reset.
Any thoughts?
Hi Steve,
Need to give this a test or five. Sending a SIGUSR1 when in master state should have no effect. The clock step should only happen when PTPd is in slave state.
OK - it does happen only in slave state, an error is generated when it's attempted in any other state.
What does the log file say when it's not resetting the clock?
I'm sending SIGUSR1 when it is in slave mode. For some reason after the software has been running for a while it looses the ability to sync to ofm. When it has stopped working, after SIGUSR1 it transitions back into master state briefly before returning to slave.
Steve
Here is the log file output.
2015-05-21 09:53:53.446810 ptpd2[1285].eth0 (notice) (slv) Now in state: PTP_SLAVE, Best master: ec4670fffe0051ca(unknown)/01
2015-05-21 09:53:54.446706 ptpd2[1285].eth0 (notice) (slv) Received first Sync from Master
2015-05-21 09:53:54.447029 ptpd2[1285].eth0 (alert) (slv) Servo: -18020 seconds offset detected, will take 10011.1 hours to slew
2015-05-21 09:53:55.409516 ptpd2[1285].eth0 (notice) (slv) Received first Delay Response from Master
2015-05-21 09:53:55.409531 ptpd2[1285].eth0 (notice) (slv) Received new Delay Request interval 1 from Master (was: 0)
2015-05-21 09:54:01.457417 ptpd2[1285].eth0 (warning) (slv) SIGUSR1 received, stepping clock to current known OFM
2015-05-21 14:54:22.343987 ptpd2[1285].eth0 (warning) (slv) Stepped the system clock to: 05/21/15 14:54:22.343968425
2015-05-21 14:54:22.469054 ptpd2[1285].eth0 (notice) (lstn_reset) Now in state: PTP_LISTENING
2015-05-21 14:54:24.336589 ptpd2[1285].eth0 (notice) (mst) Now in state: PTP_MASTER, Best master: 000105fffe1077fe(unknown)/01 (self)
2015-05-21 09:54:05.446407 ptpd2[1285].eth0 (info) (mst) Set kernel UTC offset to 35
2015-05-21 09:54:05.446474 ptpd2[1285].eth0 (info) (mst) New best master selected: ec4670fffe0051ca(unknown)/01
2015-05-21 09:54:05.446501 ptpd2[1285].eth0 (notice) (slv) Now in state: PTP_SLAVE, Best master: ec4670fffe0051ca(unknown)/01
2015-05-21 09:54:06.445949 ptpd2[1285].eth0 (notice) (slv) Received first Sync from Master
2015-05-21 09:54:06.446243 ptpd2[1285].eth0 (alert) (slv) Servo: -18020 seconds offset detected, will take 10011.1 hours to slew
2015-05-21 09:54:07.391950 ptpd2[1285].eth0 (notice) (slv) Received first Delay Response from Master
2015-05-21 09:54:07.391967 ptpd2[1285].eth0 (notice) (slv) Received new Delay Request interval 1 from Master (was: 0)
Never-mind. I'm pretty sure it was my fault.
Seeing the slow slewing alert (will take x hours to slew) I was wondering if you didn't have clock:no_reset configured.