I haven't done testing on this code in about 6 months, but last time I tried it the default peer-to-peer mode didn't work well at all and seems to be buggy, and I haven't tested ethernet mode.
So as far as I know, the only one that works well is using it with -h.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-e run in ethernet mode (level2)
This is not implemented in mainline. Idea of using level 2 and not UDP/IP is to make messages shorter. This can help messages to be faster transferred across the network.
-h run in End to End mode
There are two possibilities to measure path delay - P2P and E2E.
E2E is same as in version 1 and uses DelayReq, DelayResp messages
P2P is little bit more complicated and uses PDelayReq, PDelayResp and PDelayRespFoloowUp messages
In theory P2P should be more precise, because it is possible to measure delay from node A to node B separately in both directions. This is not possible in E2E.
In this implementation, both delay mechanisms are handled almost same so there is no difference in precision.
So DON'T use Layer 2 mode and use delay mechanism that is supported by other devices on the network. If you use only computers with PTPd and common switches use E2E.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started some work on ethernet mode, which should be easy on FreeBSD, and probably not too terrible to implement on Linux. At the moment that work is delayed so I can get a bunch of other patches in. I may also delay the ethernet work until after I unify the two protocols (1 and 2) so we have a single daemon supporting both protocols.
Peer to peer mode is not more precise, it is present in order to protect against temporary loss of the master, and is intended for cell tower deployments. I have not tested the P2P mode extensively as my application for PTPd is best served by end to end mode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-06-22
Tnx for the replies, things are a lot clearer for me right now :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Can anyone explain how the PTPd works if it is run with the following options:
-e run in ethernet mode (level2)
-h run in End to End mode
I don't really understand how the forementioned options affect the PTP syncronization, so any explanation will be usefull.
Tnx in advance! :)
I haven't done testing on this code in about 6 months, but last time I tried it the default peer-to-peer mode didn't work well at all and seems to be buggy, and I haven't tested ethernet mode.
So as far as I know, the only one that works well is using it with -h.
-e run in ethernet mode (level2)
This is not implemented in mainline. Idea of using level 2 and not UDP/IP is to make messages shorter. This can help messages to be faster transferred across the network.
-h run in End to End mode
There are two possibilities to measure path delay - P2P and E2E.
E2E is same as in version 1 and uses DelayReq, DelayResp messages
P2P is little bit more complicated and uses PDelayReq, PDelayResp and PDelayRespFoloowUp messages
In theory P2P should be more precise, because it is possible to measure delay from node A to node B separately in both directions. This is not possible in E2E.
In this implementation, both delay mechanisms are handled almost same so there is no difference in precision.
So DON'T use Layer 2 mode and use delay mechanism that is supported by other devices on the network. If you use only computers with PTPd and common switches use E2E.
I started some work on ethernet mode, which should be easy on FreeBSD, and probably not too terrible to implement on Linux. At the moment that work is delayed so I can get a bunch of other patches in. I may also delay the ethernet work until after I unify the two protocols (1 and 2) so we have a single daemon supporting both protocols.
Peer to peer mode is not more precise, it is present in order to protect against temporary loss of the master, and is intended for cell tower deployments. I have not tested the P2P mode extensively as my application for PTPd is best served by end to end mode.
Tnx for the replies, things are a lot clearer for me right now :)