There are a lot of videos on RUclips about how the synchronization is done, but none of them actually explain exactly how its done. Yours does. Thank you for making such a nice video !!
It is easy to understand how propagation delay is compensated, I wasn't able to understand how delay inside the switch is compensated previously, but you explained very well. Thanks for making this video!
PTP cannot detect asymmetries. However, if the asymmetries are known, then PTP as defined in IEEE 1588 v2 can be statically configured so that clocks take them into account. This is called "asymmetry correction" in the standard.
Great video! The explanation was very easy to understand and the animations are very well done. The last step, delay_request and delay_response, assumes a symmetrical network topology. How can a PTP system detect or measure asymmetry, e.g. where master to slave takes 2 seconds but slave to master takes 3 seconds?
Same question asked by George in previous comment: "I understand why there needs to be compensation for the processing/encapsulating delay in the master's first message, but why isn't there a similar one for the slave's delay request time stamp? Wouldn't there be a delay between reading its own clock and transmitting as well?"
The Delay Request message does *not* contain a timestamp in the message. The slave reads the timestamp from hardware after the Delay Request message is sent.
because only the slave needs this timestamp, and master doesn't need it. Slave can read it's hardware timestamp after it sends out the Delay Request message.
Great Video for sure ! Question: why the Master could not embed the directly its transmission timestamps inside the first Sync message ? the Slave being capable to embed the transmission timestamp directly inside the delay_request message , I'm wondering why the Master would not be able to act similarly ? ( I would suspect here that add the timestamps inside the message would be done right before being sent on the wire, by the Network Interface itself) , thanks for your response !
Hi, thanks a lot for the explanation, will transmitting a follow up message late will introduce an offset? or it does not matter since the slave will sync his clock with the timestamp from the follow up message or it does matter? and we need to send follow up very fast
How does it work if propagation is not the same in both directions? So when delay in one direction is not round-trip/2 ? That is not unrealistic - even in direct P2P links (though would be smaller than in NTP sync of a workstation over some dial up link or a antique broad band where downstream was via cable tv signal but upstream via dial up phone. This did happen in the early years where older cable networks where not return capable
Hey David, do you know the significance of announce messages? What happens when you have 2 clocks connected and have different announce intervals (one set to 2(4 seconds) and one set to 4(16 seconds)? Great tutorials by the way! :-)
What is the rate of the messages (the bandwidth) between the Master and Slave ? and how does the message looks like, how long is each message ? is it possible to obtain the precision using RF link instead of fiber ? I would like to ask more questions if it is possible to contact you in someway it would be great. Thank you very much for the great videos
I understand why there needs to be compensation for the processing/encapsulating delay in the master's first message, but why isn't there a similar one for the slave's delay request time stamp? Wouldn't there be a delay between reading its own clock and transmitting as well?
Hi George, the difference between the first master message (SYNC) and the first slave message (DELAY_REQ) is that the timestamp inside the message of DELAY_REQ isn't that important. The important value in this case is the time the packet left the port, which can be determined with high precision right away. I hope this helps.
Thanks. it was very clear and nice step by step explanation. just one doubt: in last step why the calculated delay for propagation is divide by 2. it should be done in NTP because the time values that used to calculate the propagation delay include one way go and one way back. But here the time values to calculate delay just include one way propagation! Thanks in advance if you reply on this.
The slave time already contains the propagation delay from the follow up message (Master->Slave). Therefore, the Master->Slave propagation time is not required anymore.
That is why the timestamp of the Sync (1st) message is sent in the Follow Up (2nd) message. This gives the master time to fetch the recorded timestamp from hardware without any delay being incurred by the Sync message.
In the final delay request sent by the slave clock, you have chosen 208s, an even number. What if you had chosen 209s, yielding a difference of 3 seconds instead of 4? This would give us 1.5 second transmission delay - what happens then?
If the slave had sent its delay request at 209 seconds then the master would have received it at (according to its clock) a timestamp of 213. When the slave receives 213 in the delay response, it would subtract 209 from 213 = 4. So the propagation delay is still 4/2 = 2 seconds. However, if the network had a propagation of only 1.5 seconds instead of 2, the calculations are still exactly the same - you would simply add 1.5 seconds to the slave's clock.
Hi David, i work for CLARO ARGENTINA, having some doubts about implementing G8275.2 Telecom Profile; we found 10000 nano seconds in a TIME ERROR testing and ITU says the Maximun is 1500 ns; we have investigated on our packet network (QoS, link capacity) and no found any evidence of the problem. COuld you help me troubleshooting it? Regards
The goodness is not only about the virtue of knowledge you possess, but also about your amazing presentation skill, well done, keep it up!
There are a lot of videos on RUclips about how the synchronization is done, but none of them actually explain exactly how its done. Yours does. Thank you for making such a nice video !!
exactly!!!
Yes exactly
The best explanation to PTP I ever found. I was struggling months to understand this and thanks for making this wonderful video.
Thank you. I finally understand master - slave sync procedure. Great respect to your teaching skills
By far one of the best PTP explanation!
It is easy to understand how propagation delay is compensated, I wasn't able to understand how delay inside the switch is compensated previously, but you explained very well. Thanks for making this video!
Very good explaination about how PTP synchronization works I ever seen. Thank you so much!
Thank you for such a comprehensive explanation.... Amazing video if anyone wants to learn the basic of Time Sync 🙏
PTP cannot detect asymmetries. However, if the asymmetries are known, then PTP as defined in IEEE 1588 v2 can be statically configured so that clocks take them into account. This is called "asymmetry correction" in the standard.
Great clear explanation of a complex topic. Well done!
very good and crystal-clear explanation with diagram thank you
BLESS YOU MAN !
Thanks for great visual explanation!!!
Good presentation for PTP I've ever seen.
Thank you for this great presentation! It helped me get a better grasp of this subject.
Thank you so much for the superb explanation.
Very well explained. Great presentation skills.. I couldn't any other better explanation for PTP other than this. Thanks you
Nicely explained. Helps a lot. Thank you.
Excellent explanation! Cutos to you
Great video! The explanation was very easy to understand and the animations are very well done.
The last step, delay_request and delay_response, assumes a symmetrical network topology. How can a PTP system detect or measure asymmetry, e.g. where master to slave takes 2 seconds but slave to master takes 3 seconds?
Same question asked by George in previous comment:
"I understand why there needs to be compensation for the processing/encapsulating delay in the master's first message, but why isn't there a similar one for the slave's delay request time stamp? Wouldn't there be a delay between reading its own clock and transmitting as well?"
It is not used. It does not use absolute time He just mentioned the scenario.
The Delay Request message does *not* contain a timestamp in the message. The slave reads the timestamp from hardware after the Delay Request message is sent.
because only the slave needs this timestamp, and master doesn't need it. Slave can read it's hardware timestamp after it sends out the Delay Request message.
In a utopic society - the 3 people that disliked this video will be either in jail or digging a tunnel somewhere in Siberia...
Very briefly explanation just into the point nice work.
I love the explaination thanks
Very well explained
Excellent video!!
Great Video for sure ! Question: why the Master could not embed the directly its transmission timestamps inside the first Sync message ? the Slave being capable to embed the transmission timestamp directly inside the delay_request message , I'm wondering why the Master would not be able to act similarly ? ( I would suspect here that add the timestamps inside the message would be done right before being sent on the wire, by the Network Interface itself) , thanks for your response !
extremely good explained
Very Nice explanation
Hi, thanks a lot for the explanation, will transmitting a follow up message late will introduce an offset? or it does not matter since the slave will sync his clock with the timestamp from the follow up message or it does matter? and we need to send follow up very fast
How does it work if propagation is not the same in both directions? So when delay in one direction is not round-trip/2 ? That is not unrealistic - even in direct P2P links (though would be smaller than in NTP sync of a workstation over some dial up link or a antique broad band where downstream was via cable tv signal but upstream via dial up phone. This did happen in the early years where older cable networks where not return capable
amazing video, please, DO GO INTO THOSE DETAILS NOW, I want the rest of the info !!!
Concise and useful 👌
excellent explanation!!!
Excelente video/explicación, superdidáctico. Amazing presentation skills, thanks.
Hey David, do you know the significance of announce messages? What happens when you have 2 clocks connected and have different announce intervals (one set to 2(4 seconds) and one set to 4(16 seconds)? Great tutorials by the way! :-)
What is the rate of the messages (the bandwidth) between the Master and Slave ?
and how does the message looks like, how long is each message ?
is it possible to obtain the precision using RF link instead of fiber ?
I would like to ask more questions if it is possible to contact you in someway it would be great.
Thank you very much for the great videos
I understand why there needs to be compensation for the processing/encapsulating delay in the master's first message, but why isn't there a similar one for the slave's delay request time stamp? Wouldn't there be a delay between reading its own clock and transmitting as well?
Hi George,
the difference between the first master message (SYNC) and the first slave message (DELAY_REQ) is that the timestamp inside the message of DELAY_REQ isn't that important.
The important value in this case is the time the packet left the port, which can be determined with high precision right away.
I hope this helps.
Thanks. it was very clear and nice step by step explanation.
just one doubt: in last step why the calculated delay for propagation is divide by 2. it should be done in NTP because the time values that used to calculate the propagation delay include one way go and one way back. But here the time values to calculate delay just include one way propagation!
Thanks in advance if you reply on this.
The slave time already contains the propagation delay from the follow up message (Master->Slave). Therefore, the Master->Slave propagation time is not required anymore.
very easy explanation...........thanks....
* I need help configuring PTP. My relays are showing slave, slave, Master even though set Tekron server as “Master”. Any suggestions?
This is a great video however I don't see how the time lost by the master transmitting the message (1s in your video) is accounted for by the slave ?
That is why the timestamp of the Sync (1st) message is sent in the Follow Up (2nd) message. This gives the master time to fetch the recorded timestamp from hardware without any delay being incurred by the Sync message.
what is the difference between peer to peer vs end to end delay, can i assume the description in this video is for "peer-to-peer"
Nice Video..informative
In the final delay request sent by the slave clock, you have chosen 208s, an even number. What if you had chosen 209s, yielding a difference of 3 seconds instead of 4? This would give us 1.5 second transmission delay - what happens then?
If the slave had sent its delay request at 209 seconds then the master would have received it at (according to its clock) a timestamp of 213. When the slave receives 213 in the delay response, it would subtract 209 from 213 = 4. So the propagation delay is still 4/2 = 2 seconds. However, if the network had a propagation of only 1.5 seconds instead of 2, the calculations are still exactly the same - you would simply add 1.5 seconds to the slave's clock.
Hi David, i work for CLARO ARGENTINA, having some doubts about implementing G8275.2 Telecom Profile; we found 10000 nano seconds in a TIME ERROR testing and ITU says the Maximun is 1500 ns; we have investigated on our packet network (QoS, link capacity) and no found any evidence of the problem. COuld you help me troubleshooting it? Regards
Sehr schön erklärt, hat mir echt geholfen =)
thank you
great
good job boy!
thank you :)
Thank you