We run a slightly older version of ptpd (2.0) and we run it with options that
the slave "do not reset the clock if offset is more than 160 micro sec" AND also
the slave "do not accept delay values of more than 160 micro secs"
How do we know that the slave is actually rejecting time that are 160 micro secs different than the previous time pkt received from master?
How do we interpret the log files?
What does these timestamp mean? 07:02:04:208852 and the next one is 07:02:08:208741. Does it mean that the time got updated to 07:02:08:208741 ?
Additional info: We have two log files.
One called sync log and has two simple columns. Any idea about what these columns are?:
I have also noticed that the ptpd logfile always has 4th column as 0.000000000.
e.g. 2014-02-13 07:02:04:208852, slv, e83935fffeee9dcc/01, 0.000000000 <--
But going by the IEEE-1588 implementation logic, this is
one way delay = (Master2Slave difference + Slave2master difference)/2. This should not be 0.000000000.
Can some one Please help me!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Columns of the log file are described in the first line of the output.
Synclog is sequence number followed by receipt timestamp, for sync messages.
maxDelay works on delaySM (Slave to master), derived from delay request-> delay response. Doesn't work because one-way and delaySM are zero (columns 4 and 6). You were pointing at delayMS (master to slave, based on sync).
owd = 0 => you are not receiving Delay Responses. This is why columns 4 and 6 have all zero values. one way delay is not computed.
when it rejects a value, it will log a message.
Also the more you're trying to draw attention to your posts, the higher the chances they will be ignored.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for the explanation. Going by your above notes, Can you please let me know
5. Why am I Not receiving the Delay Response messages? When I take the tcpdump and plug the pcap in wireshark, I see the Delay Responses pkt coming from the master clock.
6. I do not see any rejection message in the log. Does it mean that it is deliberately using the data to update slave system clock although it is getting over 160 microsec delay values from master? (note that I have set the value to 160 microsec in "do not accept delay values of more than 160 micro secs" )
I will stay away from bothering you. We are running this config in a production box and I have no way to get to the bottom of the mistry behind this unless I get some info from you.
My apology again.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I / we are still willing to help, all I meant was that we do this in our spare time so trying to rush us has no effect. We reply when we get a chance and we would like people to appreciate that.
As to your further questions:
I can't answer this, this is down to your system. For some reason one-way delay is not being computed. If you can see the responses coming in, maybe the problem is somewhere else.
Correct. If it's not giving messages that it's ignored, it may not be ignoring them. But it also looks like it has nothing to ignore, because delaySM is not populated.
Run ptpd in debug mode, I think in 2.0 you have to edit the makefile and add -DPTP_DEBUG or -DPTPD_DEBUG to the CFLAGS. Then run PTPd -H or -h to check the parameter used for debug, it should be multiple -d or multiple -D: -ddddd or -DDDDD. Then the log should provide some clues.
I would still upgrade to 2.3 if I were you; 2.3 should compile fine on systems where 2.0 works.
Regards
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We run a slightly older version of ptpd (2.0) and we run it with options that
the slave "do not reset the clock if offset is more than 160 micro sec" AND also
the slave "do not accept delay values of more than 160 micro secs"
Additional info: We have two log files.
One called sync log and has two simple columns. Any idea about what these columns are?:
476 1391249056208799000
477 1391249060208903000
478 1391249064209000000
................
The other file is a ptpd log file with following data:
timestamp, state, clock ID, one way delay, offset from master, slave to master, master to slave, drift
2014-02-13 07:02:04:208852, slv, e83935fffeee9dcc/01, 0.000000000, 0.000489000, 0.000000000, 0.000188000, 13270
2014-02-13 07:02:08:208741, slv, e83935fffeee9dcc/01, 0.000000000, -0.000293000, 0.000000000, 0.000398000, 12977
Note: previous offset 0.000489000 and current offset -0.000293000. This is over 160 micro secs.
................. Other lines truncated...............
2014-02-13 07:07:04:212207, slv, e83935fffeee9dcc/01, 0.000000000, 0.000325500, 0.000000000, 0.000119000, 13091
2014-02-13 07:07:08:212150, slv, e83935fffeee9dcc/01, 0.000000000, -0.000189000, 0.000000000, 0.000259000, 12902
Note: previous offset 0.000325500 and current offset -0.000189000. This is over 160 micro secs.
................. Other lines truncated...............
2014-02-13 07:08:56:209317, slv, e83935fffeee9dcc/01, 0.000000000, 0.000002500, 0.000000000, 0.000002000, 12499
2014-02-13 07:09:00:234015, slv, e83935fffeee9dcc/01, 0.000000000, 0.010466500, 0.000000000, 0.020931000, 22965
2014-02-13 07:09:04:210819, slv, e83935fffeee9dcc/01, 0.000000000, 0.009655000, 0.000000000, 0.001621000, 32620
2014-02-13 07:09:08:208885, slv, e83935fffeee9dcc/01, 0.000000000, -0.002635000, 0.000000000, 0.003649000, 29985
Note: previous offset 0.009655000 and current offset -0.002635000. This is over 160 micro secs.
................. Other lines truncated...............
I have also noticed that the ptpd logfile always has 4th column as 0.000000000.
e.g. 2014-02-13 07:02:04:208852, slv, e83935fffeee9dcc/01, 0.000000000 <--
But going by the IEEE-1588 implementation logic, this is
one way delay = (Master2Slave difference + Slave2master difference)/2. This should not be 0.000000000.
Can some one Please help me!!
Also the more you're trying to draw attention to your posts, the higher the chances they will be ignored.
Thank you very much for the explanation. Going by your above notes, Can you please let me know
5. Why am I Not receiving the Delay Response messages? When I take the tcpdump and plug the pcap in wireshark, I see the Delay Responses pkt coming from the master clock.
6. I do not see any rejection message in the log. Does it mean that it is deliberately using the data to update slave system clock although it is getting over 160 microsec delay values from master? (note that I have set the value to 160 microsec in "do not accept delay values of more than 160 micro secs" )
I will stay away from bothering you. We are running this config in a production box and I have no way to get to the bottom of the mistry behind this unless I get some info from you.
My apology again.
Thanks
Hi,
I / we are still willing to help, all I meant was that we do this in our spare time so trying to rush us has no effect. We reply when we get a chance and we would like people to appreciate that.
As to your further questions:
Run ptpd in debug mode, I think in 2.0 you have to edit the makefile and add -DPTP_DEBUG or -DPTPD_DEBUG to the CFLAGS. Then run PTPd -H or -h to check the parameter used for debug, it should be multiple -d or multiple -D: -ddddd or -DDDDD. Then the log should provide some clues.
I would still upgrade to 2.3 if I were you; 2.3 should compile fine on systems where 2.0 works.
Regards
Wojciech