Belogaj, Dmitrij
2016-08-16 12:57:22 UTC
Dear Richard Cochran,
dear Linuxptp-devel members,
First of all, thank You, Richard, for the amazing product! The set of tools and the ptp4l daemon provide invaluable help in 1588 integration into a system.
My name is Dmitrij Belogaj, I am an application engineer at Intel, and right now I am struggling with an issue on a "master-only ordinary clock" (MOOC) system.
Somehow I am already familiar with the linuxptp source code and try to adapt it to our needs.
Couple of days ago I got stuck at one issue, for which I found a quick-hack solution. However, I would like to understand why You have implemented the code exactly how it is now.
Maybe, there are some reasons unobvious for me.
You all know the "phc2sys -a -r" call to automatically synchronize the clocks across the system including the CLOCK_REALTIME.
Now imagine please a MOOC system with one PHC and the CLOCK_REALTIME. The PHC is the reference clock used by 1588 master for timestamping. The PHC itself is synchronized to the GPS by HW means. Now, I want to synchronize the CLOCK_REALTIME to the PHC. However, when I start "phc2sys -a -r", I get "nothing to synchronize" message.
During source code analysis I've found the function reconfigure(node) in the phc2sys.c. In the LIST_FOREACH(...) loop there are counted source and destination clocks. Since the PHC is a PS_MASTER clock, it's being counted as a destination clock:
switch (c->state) {
case PS_FAULTY:
case PS_DISABLED:
case PS_LISTENING:
case PS_PRE_MASTER:
case PS_MASTER:
case PS_PASSIVE:
pr_info("selecting %s for synchronization", c->device);
dst_cnt++;
break;
case PS_UNCALIBRATED:
src_cnt++;
break;
case PS_SLAVE:
src = c;
src_cnt++;
break;
}
Since there is neither PS_SLAVE nor PS_UNCALIBRATED clocks in the system, but only the master PHC and the CLOCK_REALTIME, the phc2sys rejects synchronizing them.
Without long speculations I have moved the PS_MASTER case next to PS_SLAVE like this:
switch (c->state) {
case PS_FAULTY:
case PS_DISABLED:
case PS_LISTENING:
case PS_PRE_MASTER:
case PS_PASSIVE:
pr_info("selecting %s for synchronization", c->device);
dst_cnt++;
break;
case PS_UNCALIBRATED:
src_cnt++;
break;
case PS_SLAVE:
case PS_MASTER:
src = c;
src_cnt++;
break;
}
and the CLOCK_REALTIME has synchronized to the PHC immediately without problems.
And now, I have the question mentioned above: what was the reason to hard-code the PS_MASTER to the destination clocks? I agree that in Boundary Clock systems the master side is a driven one, and exactly the slave side (with this highest clock quality) is a driving one, the reference one. But on the MOOC system the choice is pretty limited to the master PHC only.
How do You think, would it be correct to add handling for the MOOC case to the code? Let's say, if after the LIST_FOREACH() loop the src_cnt remains 0, but there is a PS_MASTER clock found, it should be taken as a source.
Maybe, You see some pitfalls here?
Thank You in advance.
Best regards,
Dmitrij Belogaj
dear Linuxptp-devel members,
First of all, thank You, Richard, for the amazing product! The set of tools and the ptp4l daemon provide invaluable help in 1588 integration into a system.
My name is Dmitrij Belogaj, I am an application engineer at Intel, and right now I am struggling with an issue on a "master-only ordinary clock" (MOOC) system.
Somehow I am already familiar with the linuxptp source code and try to adapt it to our needs.
Couple of days ago I got stuck at one issue, for which I found a quick-hack solution. However, I would like to understand why You have implemented the code exactly how it is now.
Maybe, there are some reasons unobvious for me.
You all know the "phc2sys -a -r" call to automatically synchronize the clocks across the system including the CLOCK_REALTIME.
Now imagine please a MOOC system with one PHC and the CLOCK_REALTIME. The PHC is the reference clock used by 1588 master for timestamping. The PHC itself is synchronized to the GPS by HW means. Now, I want to synchronize the CLOCK_REALTIME to the PHC. However, when I start "phc2sys -a -r", I get "nothing to synchronize" message.
During source code analysis I've found the function reconfigure(node) in the phc2sys.c. In the LIST_FOREACH(...) loop there are counted source and destination clocks. Since the PHC is a PS_MASTER clock, it's being counted as a destination clock:
switch (c->state) {
case PS_FAULTY:
case PS_DISABLED:
case PS_LISTENING:
case PS_PRE_MASTER:
case PS_MASTER:
case PS_PASSIVE:
pr_info("selecting %s for synchronization", c->device);
dst_cnt++;
break;
case PS_UNCALIBRATED:
src_cnt++;
break;
case PS_SLAVE:
src = c;
src_cnt++;
break;
}
Since there is neither PS_SLAVE nor PS_UNCALIBRATED clocks in the system, but only the master PHC and the CLOCK_REALTIME, the phc2sys rejects synchronizing them.
Without long speculations I have moved the PS_MASTER case next to PS_SLAVE like this:
switch (c->state) {
case PS_FAULTY:
case PS_DISABLED:
case PS_LISTENING:
case PS_PRE_MASTER:
case PS_PASSIVE:
pr_info("selecting %s for synchronization", c->device);
dst_cnt++;
break;
case PS_UNCALIBRATED:
src_cnt++;
break;
case PS_SLAVE:
case PS_MASTER:
src = c;
src_cnt++;
break;
}
and the CLOCK_REALTIME has synchronized to the PHC immediately without problems.
And now, I have the question mentioned above: what was the reason to hard-code the PS_MASTER to the destination clocks? I agree that in Boundary Clock systems the master side is a driven one, and exactly the slave side (with this highest clock quality) is a driving one, the reference one. But on the MOOC system the choice is pretty limited to the master PHC only.
How do You think, would it be correct to add handling for the MOOC case to the code? Let's say, if after the LIST_FOREACH() loop the src_cnt remains 0, but there is a PS_MASTER clock found, it should be taken as a source.
Maybe, You see some pitfalls here?
Thank You in advance.
Best regards,
Dmitrij Belogaj