The PTP daemon (PTPd) implements the Precision Time protocol (PTP) as defined by the IEEE 1588 standard. PTP was developed to provide very precise time coordination of LAN connected computers.
The Precision Time Protocol is a method by which a computer, communicating over a
Local Area Network can keep its local clock synchronized to a better time source,
commonly referred to as a Master Clock.
All commercially available computers do come with a built in clock. The built in clock
in an off the shelf desktop, server or laptop is only accurate to within a few seconds
per day. Depending on local conditions, such as high heat or vibration the clock built
into your computer can wander by minutes in a day. If you don't need your computer's
clock to be in line with the rest of the world's clocks by more than a few seconds
then you don't need PTP. Stop here, rest easy.
Most operating systems (FreeBSD, MacOS X, Linux, Windows, etc.) have a built in network time
client based on the Network Time Protocol (NTP). NTP is meant to synchronize a clock over the Internet.
Many organizations, including companies and governments, set up very accurate clocks,
which are synchronized to a globally set standard, for use within their organization
or to the public. Because NTP works across the Internet it is not generally capable of
keeping a client computer's clock accurate to better than a second, though this is a rough
guess depending on how the computer is connected to the Internet.
If your application requires time to be accurate to within milliseconds or microseconds
then you'll want to use PTP and you'll want to synchronize your clocks to a nearby
master.
That depends on your application. The reason that your computer's clock is so inaccurate is
that the clock chip used is quite cheap, about $0.10, and possibly cheaper. You get what you
pay for, and most people aren't willing to pay for something better. The people who are
willing to pay for something better are willing to pay quite a bit more, and master clocks
can start at about $5000 and go up from there. The better materials are both rare
and hard to work with, which is part of what drives up the price. Oven baked crystals are
the next most expensive, followed by rubidium, and all the way up to cesium clocks, which are
also referred to as atomic clocks because they're using atomic decay to derive their time signal.
If you already have one of these you probably don't need this FAQ.
PTP does not require an expensive master clock but the protocol does depend on there being
a master and one or more slaves. If your application requires only that a group of machines
on a LAN be synchronized to each other, for instance in a factory automation or local audio
application, then an expensive master could be avoided by designating a normal server as
the master, and having it run both NTP and PTP. NTP would be used to get decent time from
the Internet, and PTP would be used to keep all of the slaves close to the time set by
the master. All the clients will only be as accurate as the system designated as the master
but this can work for systems that don't need to be synchronized within microseconds.
The project does not endorse or verify any particular vendor's Grand Master Clock.
Several different models are available from a number of vendors including:
EndRun
Meinberg
Spectracom
Symmetricom
That Symmetricom link should be "http://www.symmetricom.com/". Are there any sort of API/tutorial resources for this project?
Last edit: rega 2013-04-03
On Apr 2, 2013, at 21:40 , rega regar@users.sf.net wrote:
Thanks, fixed.
Nothing more than the FAQ, and as it's a stand alone daemon an API tutorial doesn't really make
sense.
Best,
George
re API: in my application I would need access to the clock (I assume clock_gettime(..REALTIME) then) as well as an indication of the maximum time drift relative to the current master, with the intent to cause an emergency stop of the application if the clocks drift apart more than a certain threshold
how would I go about detecting this limit?
PTPd populates the esterror field of the timex structure with the current offset from master. Any application can read it with ntp_gettime() or adjtimex(). You can also periodically read ptpd's status file and get the offset from there. As to the value of the threshold, well, there is no recipe for that.
Wojciech - thanks - that was it!
suggestion on the debian package - it works fine, but it lacks a .conf file to start from: https://packages.debian.org/sid/i386/ptpd/filelist
the ptp2.conf files from https://sourceforge.net/p/ptpd/code/HEAD/tree/trunk/src/ would make it simpler to get going
I lifted my ptpd.conf from there, had to disable some options because they were not supported in the deb version
The Debian package is maintained independently. The latest version of ptpd is always the recommended version - currently 2.3.1. Anything older should be upgraded.
From this reading, it looks like the LinuxPTP project implements the PTP client. Does it also implement PTP master code? If not, what are the goods source for PTP master code? Thanks!
No idea about LinuxPTP but the ptpd project (now on github:
https://github.com/orgs/ptpd/dashboard) does implement a master.
Best,
George
On 26 Jan 2017, at 17:05, Siheng Huang wrote: