I downloaded the software and need someone to help to get more understanding of some folders:
1) many .guess and .sub files under ..\build_aux\ folder. Is this folder to store the building result? what do the .guess and .sub files use for?
2) Is the ..\m4\ folder support the libtool of GNU? For what purpose?
3) What is the information within folder ..\packagebuild\ ? What do they use for?
4) Is the ..\test\ folder used to put any PCAP file for testing only?
5) what does the folder ..\tools\ use for? What functions do this folder include?
Appreciate with someone who can clarify my questions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
1) and 2) project is using Autotools. All files *.ac, *.am, *.m4 are some helpers for this tools. After running autotools and make, it will generate some intermediate files like build_aux etc.
3) There are source files to build packages for several linux distributions - Red Head RPM and Gentoo ebuild. There will be nice to have also deb, etc.
4) Currently, test is used to place files used for testing before release. Tests are currently not complete nor automated but they are useful to reach same configuration all the time.
5) tools folder contains R and matlab scripts to manipulate with log files of PTPd and to evaluate e.g. precision.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Can you be more specific? What is your OS? What would you like to do? There is PTP standard API to manipulate with internals of PTPd using PTP management messages. I don't know, how will this work on the same machine and I also don't know the state of using Unix Domain Socket for this. There is a list of implemented structures, that can be manipulated https://sourceforge.net/p/ptpd/code/HEAD/tree/trunk/src/def/managementTLV/
You can also use libptpd to integrate PTPd into your application, but I thing that there is no documentation other then source codes.
2) Lower driver layer API is WIP. You can modify net.c and sys.c to implement your needs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This branch is based on an earlier 2.4 branch that uses LibCCK, which we intend to eventually have merged into the 2.4 trunk. You can see an example of the API in the main() of ptpd.c in the same branch:
There are also APIs to allow you to run the protocol in a separate thread so your higher-layer application is not blocked and can query the state of the ptpd clock safely. I'll try to add additional examples of different ways to use this API.
And as Jan said, the lower driver layer API is a work in progress (LibCCK).
Hope this helps,
Rick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The driver layer in my opinion is talking about the HW interace between the PTP stack and the lower adaption layer accessing to the hardware for transmitting or receiving the ptp messages. I'd like to know where is this part within the software package. With this defintion, is "sys.c" and "net.c" you mentioned in previous reply surely my answer?
For the application layer in my opinion, thinking about the user view of how to use the ptp stack. According to your reply, does it mean the ptpd only receives command to configure or use the ptpd in application view? Or other software interface for upper layer to integrate with the ptpd by other application?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lower API interface:
- in net.c, there is code for sending and receiving packets and also packet timestamps. In ptpd-2.4-wowczarek or ptpd-2.4-natinst branch, it is much more easier to add new transport, because of LibCCK API.
- in sys.c, there is code for manipulating with system time. If the time you use for timestamping is different from time, you use as sytem time (with hardware timestamping it is different), you should also look inside this file and modify appropriate functions. LibCCK API interface is currently WIP for this.
Higher API interface:
- You can use PTP management messages. These messages are standard and you can view and set all internals of all PTP devices in the network. You can use existing commercial GUIs or write your own. PTP management messages are not supported by all devices, but PTPd supports them. You can also use branch himanshu-2012/tools/ptpmanager/ or tomasz-2012/tools/MgmtMsgClient/ but I don't know the state of this.
- You can use ptp_api.h in natinst branch to integrate PTPd into your software and to read and write some of its internal parameters. After you close your gui application, PTP will also stops.
Jan
Last edit: Jan Breuer 2014-12-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think using UDS might be a good option too, depending on the application. I haven't looked in to it much, but it sounds like it could work well for accessing a running daemon through the same management interface other 1588 devices use. I believe this is the approach linuxptp is taking.
I do have some thoughts about it though. For instance, I'm wondering what the policy would be if a user needs to disable network 1588 management messages in ptpd (perhaps for security reasons) yet still wants another application on the same system (and perhaps only from the same user on a multi-user system) to be able to access it via UDS. I suppose that could be a special case which we could accommodate, hopefully in a way that keeps the code clean. I'm also thinking that management messages are somewhat limited in capability at the moment, and might require an application to do things like constantly poll for state changes. This may be acceptable for most applications, but maybe not as preferrable to some as just registering a callback. The embeddable API approach has some advantages in these regards.
I also see the API as a nice encapsulation mechanism that benefits the ptpd codebase internally. It would be nice if we could get to the point of having the core protocol lib & API and the CCK lib & API developed more, so that a PTP application (like the daemon itself) consisted of calling CCK and ptp_api APIs to set up hardware, register them with the protocol, then start, monitor, and control the protocol as necessary for the particular application. Right now, the protocol and various hardware interfaces are tightly coupled (but that's starting to change). I also think things like ptpd's NTP failover code could have benefitted from more modularity like this too, IMO.
As for ptp_api being thread safe, you're right that it is not completely thread safe yet. It should work for the case of the 1588 protocol running in one thread, and the application main thread or a separate individual worker thread calling the API asynchronously though. But, I haven't tried multiple threads calling the API asynchronously, and I know that multiple ptpd protocol threads running in the same process won't work yet. We would eventually like to support all these cases though.
Rick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the common way to use the ptpd via command line to configure and activate it? I can't find the complete command list of the ptp daemon. Is it within the software package or someone I can reference to get familiar how to use it?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Demun,
you can configure it via command line or via configuration file (prefered).
You can send several signals to the daemon to e.g. reload configuration from the file.
Everything is described in the documentation (man).
You can use extrenal utility like start-stop-daemon to handle starting and stopping it. You can also use init script packagebuild/rpm-rh/ptpd.init.
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I downloaded the software and need someone to help to get more understanding of some folders:
1) many .guess and .sub files under ..\build_aux\ folder. Is this folder to store the building result? what do the .guess and .sub files use for?
2) Is the ..\m4\ folder support the libtool of GNU? For what purpose?
3) What is the information within folder ..\packagebuild\ ? What do they use for?
4) Is the ..\test\ folder used to put any PCAP file for testing only?
5) what does the folder ..\tools\ use for? What functions do this folder include?
Appreciate with someone who can clarify my questions.
Hi,
1) and 2) project is using Autotools. All files *.ac, *.am, *.m4 are some helpers for this tools. After running autotools and make, it will generate some intermediate files like build_aux etc.
3) There are source files to build packages for several linux distributions - Red Head RPM and Gentoo ebuild. There will be nice to have also deb, etc.
4) Currently, test is used to place files used for testing before release. Tests are currently not complete nor automated but they are useful to reach same configuration all the time.
5) tools folder contains R and matlab scripts to manipulate with log files of PTPd and to evaluate e.g. precision.
Can someone share any detail documentation of API which related to:
1) API for Upper application layer to use the ptpd
2) API for Lower driver layer to adapt different hardware PTP module
Or someone can help me to clarify my questions? Thanks
1) Can you be more specific? What is your OS? What would you like to do? There is PTP standard API to manipulate with internals of PTPd using PTP management messages. I don't know, how will this work on the same machine and I also don't know the state of using Unix Domain Socket for this. There is a list of implemented structures, that can be manipulated https://sourceforge.net/p/ptpd/code/HEAD/tree/trunk/src/def/managementTLV/
You can also use libptpd to integrate PTPd into your application, but I thing that there is no documentation other then source codes.
2) Lower driver layer API is WIP. You can modify net.c and sys.c to implement your needs.
Demun,
I think the API defined in the ptpd-2.4-natinst branch is what you're looking for as an upper application layer API:
https://sourceforge.net/p/ptpd/code/HEAD/tree/branches/ptpd-2.4-natinst/src/ptp_api.h
This branch is based on an earlier 2.4 branch that uses LibCCK, which we intend to eventually have merged into the 2.4 trunk. You can see an example of the API in the main() of ptpd.c in the same branch:
https://sourceforge.net/p/ptpd/code/HEAD/tree/branches/ptpd-2.4-natinst/src/ptpd.c
There are also APIs to allow you to run the protocol in a separate thread so your higher-layer application is not blocked and can query the state of the ptpd clock safely. I'll try to add additional examples of different ways to use this API.
And as Jan said, the lower driver layer API is a work in progress (LibCCK).
Hope this helps,
Rick
Rick,
I didn't look into branches for a long time so I didn't know ptp_api files, nice.
It seems to me that they are not thread safe, are they?
Is it possible/plan to use UDS for simmilar purpose?
Jan
Hi Jan,
The driver layer in my opinion is talking about the HW interace between the PTP stack and the lower adaption layer accessing to the hardware for transmitting or receiving the ptp messages. I'd like to know where is this part within the software package. With this defintion, is "sys.c" and "net.c" you mentioned in previous reply surely my answer?
For the application layer in my opinion, thinking about the user view of how to use the ptp stack. According to your reply, does it mean the ptpd only receives command to configure or use the ptpd in application view? Or other software interface for upper layer to integrate with the ptpd by other application?
Thanks
Demun,
Lower API interface:
- in net.c, there is code for sending and receiving packets and also packet timestamps. In ptpd-2.4-wowczarek or ptpd-2.4-natinst branch, it is much more easier to add new transport, because of LibCCK API.
- in sys.c, there is code for manipulating with system time. If the time you use for timestamping is different from time, you use as sytem time (with hardware timestamping it is different), you should also look inside this file and modify appropriate functions. LibCCK API interface is currently WIP for this.
Higher API interface:
- You can use PTP management messages. These messages are standard and you can view and set all internals of all PTP devices in the network. You can use existing commercial GUIs or write your own. PTP management messages are not supported by all devices, but PTPd supports them. You can also use branch himanshu-2012/tools/ptpmanager/ or tomasz-2012/tools/MgmtMsgClient/ but I don't know the state of this.
- You can use ptp_api.h in natinst branch to integrate PTPd into your software and to read and write some of its internal parameters. After you close your gui application, PTP will also stops.
Jan
Last edit: Jan Breuer 2014-12-10
Hi Jan,
I think using UDS might be a good option too, depending on the application. I haven't looked in to it much, but it sounds like it could work well for accessing a running daemon through the same management interface other 1588 devices use. I believe this is the approach linuxptp is taking.
I do have some thoughts about it though. For instance, I'm wondering what the policy would be if a user needs to disable network 1588 management messages in ptpd (perhaps for security reasons) yet still wants another application on the same system (and perhaps only from the same user on a multi-user system) to be able to access it via UDS. I suppose that could be a special case which we could accommodate, hopefully in a way that keeps the code clean. I'm also thinking that management messages are somewhat limited in capability at the moment, and might require an application to do things like constantly poll for state changes. This may be acceptable for most applications, but maybe not as preferrable to some as just registering a callback. The embeddable API approach has some advantages in these regards.
I also see the API as a nice encapsulation mechanism that benefits the ptpd codebase internally. It would be nice if we could get to the point of having the core protocol lib & API and the CCK lib & API developed more, so that a PTP application (like the daemon itself) consisted of calling CCK and ptp_api APIs to set up hardware, register them with the protocol, then start, monitor, and control the protocol as necessary for the particular application. Right now, the protocol and various hardware interfaces are tightly coupled (but that's starting to change). I also think things like ptpd's NTP failover code could have benefitted from more modularity like this too, IMO.
As for ptp_api being thread safe, you're right that it is not completely thread safe yet. It should work for the case of the 1588 protocol running in one thread, and the application main thread or a separate individual worker thread calling the API asynchronously though. But, I haven't tried multiple threads calling the API asynchronously, and I know that multiple ptpd protocol threads running in the same process won't work yet. We would eventually like to support all these cases though.
Rick
Hi Rick,
thank you very much for the explanation.
I think, that it is possible to use Wojciech's ACL to disable management messages for some transport completely.
Jan
Hi,
Is the common way to use the ptpd via command line to configure and activate it? I can't find the complete command list of the ptp daemon. Is it within the software package or someone I can reference to get familiar how to use it?
Thanks
Hi Demun,
you can configure it via command line or via configuration file (prefered).
You can send several signals to the daemon to e.g. reload configuration from the file.
Everything is described in the documentation (man).
You can use extrenal utility like start-stop-daemon to handle starting and stopping it. You can also use init script packagebuild/rpm-rh/ptpd.init.
Jan