By Andreja Jarc.
At this time I will grant you a short summer break from all the theory 🙂 and we will do some hands-on refreshment instead! Let’s check if PTP messages between a GM (Grandmaster) and a slave clock both configured with the Default profile are transferred smoothly.
For this purpose attach a laptop with a Wireshark software in a test bed with a GM and a PTP slave as suggested in Figure 1. For those who are not yet familiar: Wireshark is a user-friendly network protocol analyzing tool and free downloadable.
Figure 1: Hands-on setup to prove compatibility of the IEEE 1588 Default Profile configuration of a master and a slave clock.
In Wireshark go to the “Capture menu -> Interfaces” and select the laptop network port attached to the test setup. The network interface listens to all network protocols coming in and out including PTP. In the filter area (see Figure 2) type “ptp” and the data packages displayed will be limited to PTP messages only.
Start a new live capture by clicking “Start” in the Capture menu. After a while stop the running session with a Stop button (the forth icon in the second row). Now you are able to visualize PTP timing packages in a closer detail (Figure 2).
Figure 2: A print screen in Wireshark v1.8.6. showing a successful transfer of PTP messages between a Grandmaster and a slave in the multicast mode.
What we see in the main screen marked yellow is a two-step PTP message sequence between a master and a slave. The first message is called a Sync Message sent from a GM to a multicast IP address (check the Destination column). A Follow_Up Message which carries an accurate time stamp of the Sync Message departure time follows from the GM in a two-step operation. Next a Delay_Req Message is sent by a slave clock to the GM. The GM returns a Delay_Resp Message with an accurate time stamp of the Delay_Req Message arrival back to the slave.
The slave has now all significant t1-t4 time stamps to adjust its own time. One PTP package exchange between a master and slave is by this completed. If you acquired an appetite to learn more about the theory on PTP while trying out this hands-on then check our previous blog posts on IEEE 1588.
I hope you enjoyed today’s session, I will be glad to hear your feedback and discuss questions/comments…
For more information visit our website at www.meinbergglobal.com.
I wish you a nice holiday and am eager to welcome you back to our next on-line tutorials. Cheers!
I have wireshark installed on my laptop. I am capturing packets. I have selected ptp in the filter area. I am not coming up with any packets. Why is that? I am new to Wire Shark and want to capture packets from laptop to the universal server that syncs time for the www.
Hello Dave,
there can be many reasons why Wireshark shows no PTP messages.
What is communication mode you are using: unicast, multicast? Do you use a switch between master and slave? Does the switch permit multicast messages?
It may lay also on older version of the Wireshark.
I recommend step by step troubleshooting. First attach your laptop directly to the master device, configure multicast messaging and check with Wireshark. Then try out unicast. Additionally add a slave to your setup. I hope this helps.
Regards,
Andreja
Hi,
I have currently developed ptp slave hardware, and I want test it for all possible ptp frames. Where can I get sample frames of all protocols.
Hello Ankush,
one way to test a PTP slave is to run Meinberg simulation software which can simulate multiple grandmasters, different PTP profiles, various message rates, delay mechanisms, etc.
You can run a demo version first to see if it suits your requirements. Please check details:
https://www.meinbergglobal.com/english/products/mps_v2.htm
If you have a packet buster for PTP you can test that as well.
In Layer3 mode, does the PTP GrandMaster on Meinberg appliance transmit IP multicast packets with a TTL set to 32?
Hello Brian,
by default Meinberg sets the TTL to 5.
However, the TTL value is configurable via a web interface.
Therefore you can configure a TTL value to 32 if you prefer.
HI,After knowing the time stamps of all 4 packets whether the clock of slave is adjusted on its own or we have to adjust it
As long as the slave clock that you use in your test set up is a finished implementation of PTP, then it should adjust its own time. This tutorial was to show you how to watch the message exchanges using wireshark.
I am Trying ptp between two fpga’s of different clock frequencies
Two PTP instances can have different clock frequencies and still work together as long as they are both able to create timestamps based on the SI second.
Very informative tutorial. Kindly clarify my query. I have a requirement to find out the IP address of the ptp master through software (using C++ in Linux). For that I have the joined the multicast group 224.0.1.129 and listening to messages in port number 319. Using recvfrom socket call, I can obtain the IP Address of the sender to port 319. I am assuming that only master sends multicast to port 319. Is my assumption correct. Whether any of the slaves sends multicast message to port 319.
Port 319 are reserved for PTP event messages. Those are messages that get timestamped. If the PTP network is using End-to-end timing, in other words using delay requests and delay response messages, then PTP ports in the slave state will send delay requests via port 319.
This 4 way verification for PTP using wireshark should be the same for End to End, and Peer to Peer PTP Configuration, Am I understanding correctly?
Thanks for this article, it’s very useful to probe PTP is running properly.
There is on critical difference between End to End and Peer to Peer PTP. Peer delay messages are sent in special type of Ethernet frame that is link local, and so not forwarded by Ethernet switches. You have to be on that link to see them.