ptpd-announce — General announcements about the PTP daemon

[Ptpd-announce] Shutting down Source Forge lists and repository on August 1 2017

[George Neville-N. <gn...@ne...>]

Howdy,

We've been using github for PTPd development for quite a while now.  
It's come time to shut down the SourceForge components of the PTPd 
project.  I'll look at moving any remaining bugs/requests from SF to 
github as part of the transition.  As part of the transition the 
mailings lists will also go away.

Best,
George

[Ptpd-announce] Clock driver API, full Linux PHC support / hardware timestamping, VLAN and bonding support, multiple clock support

[Wojciech O. <woj...@ow...>]

All,

Welcome to the 21st century, it's about time...

* What's happening:

Since the beginning of January I have made significant progress with h/w
timestamping work for ptpd. The code is currently in my branch:
*https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-hwtest
<https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-hwtest>*, and
hopefully will be pulled into the main ptpd git tree in near future.

Code right now is stable and people are more than welcome to test.
Important note: all ptpd2 references have been changed to "ptpd". You can
automatically build RPM packages with the packagebuild/rpm-rh/rpmbuild.sh
script as before.

Man page is not fully up to date yet with new and changed settings, but the
built-in help is, so use "ptpd -H", "ptpd -O" and "ptpd -e [setting]" for
help. Best thing to do for now is to grab the latest stable version, take
"ptpd -O" output from the last official version or git source and diff it
against the new version. Names of settings are descriptive and mostly
self-explanatory. Best way to monitor is to watch the status file,
/var/run/ptpd.status (as in, watch -n 1 "cat /var/run/ptpd.status"). The
status file shows the list of all clocks and their current status.

So far this has been tested on Intel (igb, ixgb), Mellanox ConnectX3
(mlx4_en) and Solarflare (6xxx, 7xxx - sfc) - GE and 10GE with very decent
results. No testing with embedded platforms yet, like i.mx6 or am335x, but
in principle they should work.

A sample config file has been added: test/linuxphc_hw.conf

* What's new:

- First of all, full Linux PHC support with h/w timestamping and hardware
clock control.

- Clock driver API - the PTP engine now only computes an offset and serves
as an external reference to its clock driver. No direct calls to any system
time functions from PTP code. The clock API is quite rich, the clock model
has a state machine that any time nut will recognise: init -> freerun ->
tracking -> locked -> holdover.

- (Linux) support for timestamping over VLAN interfaces and bonded
interfaces (active standby only), with automatic tracking of the active
members changing, being added, removed, etc. This is all done using native
Linux APIs rather than parsing /proc or /sys files.

- Simultaneous, intelligent sync of an arbitrary number of PHC clocks - all
members of a bond, plus any extra clocks you tell it to - and the system
clock of course. When running as PTP master, you can select a designated
clock to be the master clock source. No multiple tools or processes are
required.

- Clock stability tracking is handled by the clock driver and is based on
its frequency offset's Allan deviation. A best clock is selected to which
all other clocks sync - unless they are read-only. The OS clock (and any
clock) is protected from rapid changes of other clocks - if they are
controlled too aggressively, they go out of LOCKED state and other clocks
detach from them, previously LOCKED go into HOLDOVER and one of them takes
over until the PTP-controlled clock is back in good sync. With some
engineering it will become possible to take PTP from multiple sources and
pick the best behaving one.

- Protection from negative clock step - can be selectively enabled for h/w
clocks and OS clock. Once a clock is in NEGSTEP state, manual intervention
is required. Respective alarms are raised and log messages issued.

- Optimal clock frequency is stored in files, one per clock device, stored
and restored when needed (also notably when going into FREERUN state, so we
are not left with a wildly drifting clock).

- Major improvements to filtering, adapted to sync intervals as low as
1/sec with all filters enabled (sync outlier filter, sync stat filter,
delay outlier filter, delay stat filter)

* Caveats:

Caveat #1: this code is currently Linux only - I'm leaving restoring
portability for later
Caveat #2: you need a kernel / OS with Linux PHC support, and some
PTP-enabled NIC. Check "ethtool -T" output of your interface if in doubt.
Caveat #3: leap second support and setting various kernel status flags is
not working yet, it has to be rewritten into the clock API, work in progress
Caveat #4: mixing HW PTP NICs with non-HW NICs in a bond is possible, but
not well tested.
Caveat #5: the old NTP mode 7 integration is not yet compatible with the
new reference clock model and should not be used for now - it is a legacy
method anyway and a successor is in development
Caveat #6: do not try other transports than ipv4 for now, until the
transport is rewritten into an API, which is the very next step after the
clock driver.
Caveat #7: with multiple clocks running, ptpd can get quite chatty - but
all clock-related log messages are prefixed with "clock:"
Caveat #8: currently clock stability estimation is based on Allan deviation
only. If you choose very low servo kP and kI constants, a clock with a high
offset but changing very slowly will seem stable. A fix is underway which
uses clock's offset statistics as one of best clock selection criteria - so
the best clock will really win.

Happy testing!

Regards,
Wojciech

-- 
-

Wojciech Owczarek

[Ptpd-announce] PTPd 2.3.1 ebuild is now officially in Gentoo portage

[Jan B. <jan...@ja...>]

Dear all,

Ebuild for PTPd 2.3.1 is now part of official gentoo portage.

https://packages.gentoo.org/package/net-misc/ptpd

There are available USE flags for almost all optional ptpd features

debug experimental ntp +pcap snmp slave-only +statistics

OpenRC as well as systemd startup scripts are available.

Regards,
Jan Breuer

[Ptpd-announce] PTPd 2.3.1 source and binary RPMs available for RHEL and CentOS and similar

[Wojciech O. <woj...@ow...>]

Dear all,

RPM packages of ptpd 2.3.1 have just been uploaded to:

https://sourceforge.net/projects/ptpd/files/ptpd/2.3.1/rpms/

They are available for RHEL/CentOS 5,6 and 7, with two versions for 6.x:
pre 6.5 and 6.5+, and two builds are provided - ptpd (regular, fully
functional build) and ptpd-slaveonly - limited to slave-only operation, for
use cases that require this. 7.x packages support systemd, and build
scripts will build with systemd where possible.

Some RPM-based distributions already provide PTPd as standard - RHEL does
not. The packages provided here are an easy option for some users on RHEL
or CentOS.

If you wish to build your own RPMs, you can use the released tarball, but
please use the build scripts and spec files from subversion:
trunk/packagebuild/rpm-rh - some updates to spec files (mainly bringing it
in line with 7.x / systemd) did not make it into the 2.3.1 tarball.
Building is as easy as running ./rpmbuild.sh - it builds in a temporary
directory outside of your buildroot - you don't need to prepare anything -
the script will build and clean up and you're only left with the rpm files.

If you're building the slave-only build manually, it is triggered by a
macro called "build_slaveonly" - set to 1 invokes a slave-only build, as
in: rpmbuild  --define "build_slaveonly 1" -ba ptpd.spec


Regards,
Wojciech

-- 
-

Wojciech Owczarek

[Ptpd-announce] Version 2.3.1 of PTPd released

[Wojciech O. <woj...@ow...>]

All,

After over 18 months of development at various intensity and final weeks of
really intensive development and testing, the time has come for PTPd 2.3.1
to see the light of day. Although disappointingly late (leap second
announcement has just started), it is definitely worth the upgrade.

The changelog is quite a long list, perhaps too long to paste it as is.
Apart from continued code reorganisation and bug fixes, many parts were
rewritten (event timers, NTP failover) and cleaned up (network and
isolation of PTP code from OS API specific code).

PTPd 2.3.1 introduces a host of changes and new features - the highlights
are:

- Improved sync and delay filtering with statistical filters and an
advanced outlier filter
- Extensive support for unicast transmission including unicast negotiation
- a feature-complete Telecom profile support, tested to over 1000 slaves
handled by a single ptpd Telecom master instance. Telecom profile support
builds on groundwork sponsored by Perseus Telecom in 2014.
- Improvements to leap second handling: support for leap second
announcement in master state, leap seconds file support, support for leap
second smearing
- Simple interface failover support
- Improved robustness to network failures
- Support for slave-only builds
- Clearer, improved logging and richer status file information making it
easy to identify and troubleshoot issues with PTP
- Improved multi-platform support: Linux and FreeBSD are joined by NetBSD,
OpenBSD and (Open)Solaris.

This release should be the last without hardware timestamping support and
is likely one minor release away from major architectural changes.

Announcements:

- PTPd can be downloaded from:
https://sourceforge.net/projects/ptpd/files/ptpd/2.3.1/

- RPM packages for CentOS / RHEL will follow in due course.

- PTPd will also be moving to GitHub after this release - announcements
will follow.

Hopefully documentation and FAQ will follow.  In the meantime, we invite
all users to downloading and testing 2.3.1. Bugs can be reported via
SourceForge until futther notice and the ptpd2(8) and ptpd2.conf(5) man
pages are still the most complete source of information.

Best regards,
PTPd team

-- 
-

Wojciech Owczarek

[Ptpd-announce] 2.3.1-rc5 released

[Wojciech O. <woj...@ow...>]

All,

After another week of intensive bug scrub and development, rc5 has just
landed.

Some last remaining Telecom master issues have been resolved and optional
compatibility with AVB / 802.1AS was restored - note that we are not fully
802.1AS compliant due to lack of support for the PathTrace TLV - well, and
other features.

PTPd 2.3.1 has been successfully tested running 1000 unicast Telecom slaves
at 32 sync per second over a period of multiple days on a far less than
modern Xeon server and was stable, still providing precision better than
sub-10us. This is a good result given that PTPd is not really optimised for
such throughput - yet it performs. It will run those 1000 slaves at 64 sync
per second, but CPU usage starts going quite high. This is all on systems
which have to loop the packets and do not support transmit timestamps. On
those that do (modern NICs on Linux), most of CPU load related to unicast
master mode should be gone.

Unfortunately this comes very late, but it's definitely worth upgrading
before the leap second - which is now fully supported in master and slave
mode, along with support for the leap seconds file, which is now bundled
with ptpd. On slave side, we can choose how we want to deal with the leap
second, including support for the leap second smear - seamlessly
introducing the extra second over a given period of time. Check the
ptpd2.conf(5) man page for details - look for 'leap'.

Hopefully some FAQ / HOWTO style documentation will follow shortly,
starting with leap second support and what's required to deal with it
correctly.

Very shortly - to ensure PTPd running as master correctly sends out the
leap second information, you need to set:

- PTP timescale -> PTP
- ClockClass: NOT 13 or 14 as those set the timescale to ARB. You can go
with 6 or 52.
- UTC valid: yes - will be set to yes it UTC offset is set in the kernel or
if leap seconds file is successfully parsed.

With those settings, a PTP master will correctly announce the leap second
information - either from the leap seconds fille if pointed to it, or from
the kernel, if another PTPd instance or NTP has set the STA_INS / STA_DEL
flag.

During the leap second event, PTPd both in master and in slave state will
cease processing event messages - which carry timestamps and from which
timestamps are derived, and it will only resume their processing on first
Announce message received after the event. This guarantees uninterrupted
operation, provided that the leap second information is provided by the
master, be it PTPd or another software or hardware.

Regards,
Wojciech / PTPd project

-- 
-

Wojciech Owczarek

[Ptpd-announce] ptpd 2.3.1-rc4 released

[Wojciech O. <woj...@ow...>]

All,

After a very long and seemingly quiet period of time in development and
testing, 2.3.1-rc4 has landed, with hope for immediate release of 2.3.1.
Shame it's a bit late with regards to the upcoming leap second event, but
all users are strongly encouraged to test the leap second with 2.3.1 as it
brings several improvements in this area - both for master (which can now
announce the leap second) and slave (which can deal with it in multiple
ways). 2.3.1 also introduces official support for OpenSolaris-like
operating systems - thanks to original patch from Dan McDonald of OmniTI.
Support for QNX is on its way, but will not be merged in time for 2.3.1.

2.3.1 is quite a major update. I will be sending out further information
outlining key changes and feature additions, but apart from the leap
second, one could say that this release is all about unicast.

Back in early 2014 a simple and very minimal unicast grandmaster
implementation was delivered for Perseus Telecom, who kindly allowed us to
open source it after a certain amount of time. This was quite a long time
ago, but this work laid the foundations for what 2.3.1 expands upon -
essentially packing and unpacking signaling TLVs - also stacked ones. What
was committed today goes far beyond that original code: we now have feature
complete Telecom Profile support. If I'm not mistaken this makes it the
industry's first non-restrictive, BSD-licenced ITU-T G.8265.1
implementation. Some nuances may not be fully up to scratch, but this code
has been tested with major vendors' hardware (and with itself) and it seems
to interoperate OK. A lot of work has been put into making the unicast
negotiation support robust and standards-compliant. Many thanks to Perseus
- this would have been much more difficult without you.

This is what's supported for unicast operation:

- unicast witout negotiation: support for masters talking to multiple
pre-configured unicast slaves at fixed message rates
- unicast negotiation, both in slave and master states (signaling messages)
- option to disable BMCA for grandmasters - the GM goes straight into
MASTER state and ignores Announce messages
- unicast Telecom slave requesting transmission from multiple GMs
simultaneously - with traditional BMCA
- a simplified model of a Telecom slave: requests unicast transmission from
multiple masters in multiple domains, and best master election can be
influenced with local preference. You can still run multiple instances if
you so wish.
- unicast master operation when using unicast negotiation supports
different slaves running different message rates independently.

A new implementation of event timers using the POSIX timer API allows for
much higher message rates than previously. Message scheduling is still
somewhat naive (we need a pipeline / thread for that in future), we can
comfortably support multiple unicast slaves. Performance testing results
will follow.

Standalone documentation is still nearly non-existent, however the
ptpd2.conf man page is up to date and is the best source of information
about all settings available. The man page alone is enough to allow a
person familiar with IEEE 1588 to work with ptpd.

Hardware timestamping support is still missing, but that is the next
immediate roadmap item: a) generic hardware-enabled  transport API with
implementations at least for Linux and b) clock driver API. The transport
part is mostly complete in the 2.4 test branch, so the clock driver work is
the missing piece. There are no more feature excuses to pre-empt this work.

More information to follow - namely on leap second support and running
various unicast configuration.

Source can be downloaded from
https://sourceforge.net/projects/ptpd/files/ptpd/2.3.1/rc4/ - testing is
welcome, and needed. RPM builds for RHEL-like systems will be released
along with the final 2.3.1 version.

Regards,
Wojciech / PTPd team

-- 
-

Wojciech Owczarek

[Ptpd-announce] PTPd 2.3.1 RC2 is now available

[Wojciech O. <woj...@ow...>]

Dear All,

PTPd 2.3.1-rc2 has just been made available for download from the "files"
section of the project website:

https://sourceforge.net/projects/ptpd/files/ptpd/2.3.1/rc2/

Builds have been tested and were successful on all supported platforms,
testing is undergoing. Binary packages for RHEL will follow.

As usual, we encourage everyone to download and test, test, test.

2.3.1 brings bug fixes, many improvements, mostly to platform support and
to the outlier filters, allowing ptpd to run in more demanding environments
(high network and CPU loads), but also features like (simple) backup
interface support.

Full change log:

        * New features since 2.3.0:

        - simple failover mechanism - ptpengine:backup_interface
        - ptpengine:max_delay_max_rejected setting to unblock ptpd
          rejecting all messages when max_delay set
        - ptpengine:max_delay_stable to only use max_dely when clock
          is stable
        - configurable log timestamp format (unix or datetime)
        - ptpd now compiles and runs out of he box on NetBSD, OpenBSD,
FreeBSD,
          OSX and Solaris and its derivatives (OpenIndiana, OmniOS etc.)
        - major rework of the ACL code
        - outlier filter auto-tune to improve operation in noisy
environments(high PDV)
        - added ptpengine:clock_update_timeout setting to reset slave
          if no clock updates for a period of time
        - when running slave-only in unicast mode, unicast address
          does not have to be specified

        * Bug fixes / improvements since 2.3.0:

        - ptpd now usable on systems with no adjtimex() call like OSX,
          OpenBSD and LynxOS ()
        - moving standard deviation algorithm fix improving the outlier
          filters
        - network code cleanup
        - fixed bug #66 - Ethernet interfaces no longer need IP addresses
          to run PTP Ethernet transport
        - fixed bug / feature request #21: timestamping initialisation on
          PHC kernels (like RHEL6.5 - likely fixed 100% CPU usage issue)
        - fixed bug / feature request #22: prevent FMR from overwriting
           best master
        - improved servo stability detection: servo no longer reporting
          stable when discarding most samples or heavily slewing
        - ptpd will now join and leave multicast groups only when running
          multicast or hybrid: allows running unicast and multicast
          independently
        - ptpd will now ignore unicast packets in multicast-only mode
          and vice versa. In hybrid mode, only unicast Delay Request /
          response is accepted; multicast management messages are always
          accepted
        - other minor bugs fixed - see SVN log

Regards,
PTPd team

[Ptpd-announce] ptpd configuration/tutorial

[Luís C. G. <dua...@ho...>]

Hello,

I have been working in a testbed with several nodes that are not connected to the Internet (just two) neither to GPS, the nodes are not synchronized but i need them synchronized in order to get measures of some transfers I do between the nodes. 

I am trying to used ptpd to make the synchronization of the nodes, I have already installed it on the nodes but now I don't know how to configure it. I searched it on the Internet but I could not find any tutorial or information about how to use this protocol.

If you can help me I would appreciate.

Thank you in advance,
Luís Guedes
 		 	   		  

[Ptpd-announce] PTPd 2.3.1 RC1 is now available...

[George Neville-N. <gn...@ne...>]

Howdy,

PTPd 2.3.1 Release Candidate 1 is now available either from subversion 
(tags/ptpd-2.3.1-rc1)
or as a tarball on the PTPd project site: 
https://sourceforge.net/projects/ptpd/files/ptpd/2.3.1/

Please test this candidate and report any issues.  The Changelog is not 
yet updated but
this is the capsule summary:

New features:

- simple failover mechanism - ptpengine:backup_interface
- ptpengine:max_delay_max_rejected setting to unblock ptpd
   rejecting all messages when max_delay set
- ptpengine:max_delay_stable to only use max_dely when clock
   is stable
- selectable log timestamp format (unix or datetime)
- ptpd now compiles and runs out of he box on NetBSD, OpenBSD, FreeBSD, 
OSX
- major rework of the ACL code

Bug fixes:

- ptpd now usable on systems with no adjtimex() call like OSX,
   OpenBSD and LynxOS ()
- moving standard deviation algorithm fix improving the outlier
   filters
- network code cleanup
- fixed bug #66 - Ethernet interfaces no longer need IP addresses
   to run PTP Ethernet transport
- other minor bugs fixed

Best,
George

[Ptpd-announce] PTPd release 2.3.1 planning

[George Neville-N. <gn...@ne...>]

Hi,

It’s time to start planning for a maintenance release of PTPd 2.3.1.  I’m going to branch the tree for testing
in early April.  What does this mean for you?

If you’re a consumer of PTPd please report any bugs or problems you’re seeing asap on our bug tracker:

http://sourceforge.net/p/ptpd/bugs/?source=navbar

If you’re a committer please start adding any bug fixes to trunk so that everyone can begin testing changes.

Best,
George

Re: [Ptpd-announce] [Ptpd-devel] Supported platform improvements (BSD*)

[Harlan S. <st...@nt...>]

I won't be near my test lab until tonight, and I don't recall trying to
plug my MacBook into a PTP network.  But I won't be near my test lab
until at least this weekend.

I can try compiling there, though.

H

Re: [Ptpd-announce] Supported platform improvements (BSD*)

[George Neville-N. <gn...@ne...>]

On Feb 11, 2014, at 19:13 , Wojciech Owczarek <woj...@ow...> wrote:

> All,
> 
> In the last commits, I have restored NetBSD compatibility (after build broken reported by Anton Samsonov via SF) and in the very last commit (472), initial support for OpenBSD was added (only the simple adjtime() so far, no support for OpenBSD's adjfreq() yet). IPv4, IPv4 + libpcap and Ethernet transports have been successfully tested on the two "new" platforms, NetBSD and OpenBSD. On OpenBSD, ptpd builds and runs, but timing performance is yet to be tested (likely poor at the moment). On NetBSD, from the initial tests it seems that it will run as good as on Linux and FreeBSD.
> 
> Hopefully this hasn't broken Apple compatibility, but if any of you are using ptpd on a Mac or can build it on a Mac, we would appreciate a quick test to confirm this (Harlan?)
> 

My plan is to test the Apple stuff this weekend when I am again near my test lab with my Mac.

Best,
George

[Ptpd-announce] Supported platform improvements (BSD*)

[Wojciech O. <woj...@ow...>]

All,

In the last commits, I have restored NetBSD compatibility (after build
broken reported by Anton Samsonov via SF) and in the very last commit
(472), initial support for OpenBSD was added (only the simple adjtime() so
far, no support for OpenBSD's adjfreq() yet). IPv4, IPv4 + libpcap and
Ethernet transports have been successfully tested on the two "new"
platforms, NetBSD and OpenBSD. On OpenBSD, ptpd builds and runs, but timing
performance is yet to be tested (likely poor at the moment). On NetBSD,
from the initial tests it seems that it will run as good as on Linux and
FreeBSD.

Hopefully this hasn't broken Apple compatibility, but if any of you are
using ptpd on a Mac or can build it on a Mac, we would appreciate a quick
test to confirm this (Harlan?)

Regards
Wojciech

-- 
-

Wojciech Owczarek

Re: [Ptpd-announce] Version 2.3.0 of PTPd Released

[Jan B. <jan...@ja...>]

2013/11/25 Jaap de Jong <jaa...@ne...>

> Congratulations!
> Impressive list.
>
> I do have a question...
> What about compatibility with earlier versions within a network?
>
>
It implements same standard IEEE1588-2008 so it should be compatible with
older version of PTPd 2.x.x and all other non PTPd devices implementing
same protocol. If you want to upgrade from older version of PTPd I added
command line migration guide to doc folder in the source tree
doc/ptpd-2.3.0-migration-guide.html

Regards,
Jan

Re: [Ptpd-announce] Version 2.3.0 of PTPd Released

[Jaap de J. <jaa...@ne...>]

Congratulations!
Impressive list.

I do have a question...
What about compatibility with earlier versions within a network?

On 22-11-13 17:46, George Neville-Neil wrote:
> Hi,
>
> It is with great pleasure that the PTPd team announces the official release of PTPd v 2.3.
>
> There are several advances in this release including:
>
> 	- IEEE 802.3 Support
> 	- Support for reading from the Berkeley Packet Filter, resulting in lower jitter
> 	- Configuration file support, multiple previously unsupported options
> 	- Full help (-H) for all configuration options,
> 	- Configuration reload support with SIGHUP,
> 	- Rewritten logging subsystem,
> 	- Support for tick adjustment as well as frequency
> 		maximum frequency offset is now configurable and can be above 512 ppm - tick is used above 512 ppm,
> 	- Added a compatibility option to always honour the UTC offset announced by a GM when in slave state
> 	- Support for RTC clock control on Linux
> 	- Extensive support for realtime statistics
> 	  	online long term statistics and moving statistics
> 	  	mean and std dev.
> 	  		Some new features included depend on statistics support, enabled with the --enable-statistics
> 	  		configure switch. Statistics rely on double precision so may be disabled for simple embedded systems
> 	- Outlier filters based on Peirce's criterion
> 	  blocks / filters spikes from delayMS and delaySM
> 	- Generic PI controler model
> 	- P and I components changed from attenuations to gains
> 	- Double precision servo allows for tighter clock control
> 	- Clock stabilisation detection based on the standard dev of observed drift
> 	- Clock "calibration delay"
> 		allows a configurable delay between seeing a GM for the first time and enabling clock control
> 	- Support for "panic mode"
> 		if ptpd sees offset from master above 1 second, it will pause clock updates for a given amount of time
> 	- NTPd integration and failover
> 		ptpd can now connect to local ntpd using mode 7 packets (code derived from ntpdc)
> 	  	and using authenticated requests can enable/disable ntpd clock control.
> 	  		Enable with configure --enable-ntpdc
> 	- Dump counters + clear counters using a SIGUSR2 handler to dump all counters to the log file
> 	  	configure --enable-sigusr2=counters
> 	- Support for ACLs for management and timing messages
> 	- Basic support for SO_TIMESTAMPING (RX, TX) on Linux
> 	- Support for non-Ethernet interfaces on Linux (Infiniband, GRE etc.)
> 	- Support for offset / delay asymmetry correction
> 	- Ptpd can now prefer or require GMs with valid UTC time
> 	- Support for setting IP DSCP values
> 	- Periodic IGMP joins also in master mode - improved robustness against network port failures
> 	- Support for binding PTPd to a CPU core
> 	- Control over tick rate on Linux, allowing faster clock slewing if needed
>     
> The full list of new features and bugs fixed are in the ChangeLog.
>
> Best,
> The PTPd Team
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Ptpd-announce mailing list
> Ptp...@li...
> https://lists.sourceforge.net/lists/listinfo/ptpd-announce
>

Re: [Ptpd-announce] Version 2.3.0 of PTPd Released

[Wojciech O. <woj...@ow...>]

RHEL5 and RHEL6 RPMs (and the source tarball of course) are also available
for download on the project page:

https://sourceforge.net/projects/ptpd/files/ptpd/2.3.0/

Enjoy.

Regards
Wojciech

-- 
-

Wojciech Owczarek

[Ptpd-announce] Version 2.3.0 of PTPd Released

[George Neville-N. <gn...@ne...>]

Hi,

It is with great pleasure that the PTPd team announces the official release of PTPd v 2.3.

There are several advances in this release including:

	- IEEE 802.3 Support
	- Support for reading from the Berkeley Packet Filter, resulting in lower jitter
	- Configuration file support, multiple previously unsupported options
	- Full help (-H) for all configuration options,
	- Configuration reload support with SIGHUP,
	- Rewritten logging subsystem, 
	- Support for tick adjustment as well as frequency
		maximum frequency offset is now configurable and can be above 512 ppm - tick is used above 512 ppm,
	- Added a compatibility option to always honour the UTC offset announced by a GM when in slave state
	- Support for RTC clock control on Linux
	- Extensive support for realtime statistics
	  	online long term statistics and moving statistics 
	  	mean and std dev. 
	  		Some new features included depend on statistics support, enabled with the --enable-statistics
	  		configure switch. Statistics rely on double precision so may be disabled for simple embedded systems
	- Outlier filters based on Peirce's criterion 
	  blocks / filters spikes from delayMS and delaySM 
	- Generic PI controler model
	- P and I components changed from attenuations to gains
	- Double precision servo allows for tighter clock control
	- Clock stabilisation detection based on the standard dev of observed drift
	- Clock "calibration delay" 
		allows a configurable delay between seeing a GM for the first time and enabling clock control
	- Support for "panic mode"
		if ptpd sees offset from master above 1 second, it will pause clock updates for a given amount of time
	- NTPd integration and failover
		ptpd can now connect to local ntpd using mode 7 packets (code derived from ntpdc)
	  	and using authenticated requests can enable/disable ntpd clock control.
	  		Enable with configure --enable-ntpdc
	- Dump counters + clear counters using a SIGUSR2 handler to dump all counters to the log file
	  	configure --enable-sigusr2=counters
	- Support for ACLs for management and timing messages
	- Basic support for SO_TIMESTAMPING (RX, TX) on Linux
	- Support for non-Ethernet interfaces on Linux (Infiniband, GRE etc.)
	- Support for offset / delay asymmetry correction
	- Ptpd can now prefer or require GMs with valid UTC time
	- Support for setting IP DSCP values
	- Periodic IGMP joins also in master mode - improved robustness against network port failures
	- Support for binding PTPd to a CPU core
	- Control over tick rate on Linux, allowing faster clock slewing if needed
   
The full list of new features and bugs fixed are in the ChangeLog.

Best,
The PTPd Team

[Ptpd-announce] PTPd 2.3.0 RC2 RHEL5 and RHEL6 RPMs available

[Wojciech O. <woj...@ow...>]

All,

2.3.0-RC2 binaries for 64-bit x86 RHEL5 and RHEL6 systems have been added
to the files section on the project website along with the respective
source RPMs.

The service name and package name is ptpd and configuration file is
/etc/ptpd2.conf, which is populated with some healthy defaults for
slave-only operation. The /etc/sysconfig/ptpd file contains all the
parameters passed to ptpd's command line (which thus override the same
config file options) - everything else should sit in the configuration file.

For an easy start if you already have a GM, all that's needed is to
configure the interface name and PTP domain number. Log file is
/var/log/ptpd2.log and the status file (ntpq equivalent if you will) is
/var/run/ptpd2.status and is refreshed every second.

RPM spec files, init script and an RPM build script have also been added to
the ptpd source code tree so those who want / need to build RPMs from the
subversion code, can do from now on.

I am aware that ptpd packages exist for Fedora for example, but ptpd 2.3 is
configured and operated in a completely different way to previous versions
so with those RPMs you can run ptpd the way we would recommend. So while
this may not be 100% ready for inclusion with major distributions, because
of RPM spec standards and / or other factors, this is at least a very
decent base for that.

Packages have been tested on RHEL5.5 and RHEL6.2.

Any improvement suggestions, fixes, anything that helps with building
packages for more Linux distributions are welcome and needed (I think
George and Steve have got the FreeBSD case under control).

Happy testing!

Regards
Wojciech

-- 
-

Wojciech Owczarek

[Ptpd-announce] 2.3.0 RC2 now on line...

[George Neville-N. <gn...@ne...>]

Howdy,

We now have a branch tag and tarball for ptpd 2.3.0 release candidate 2.

Please begin testing with this version.

Thanks,
George

https://sourceforge.net/projects/ptpd/files/ptpd/2.3.0/?

[Ptpd-announce] 2.3.0 RC-1 tagged

[George Neville-N. <gn...@ne...>]

Howdy,

I have created a tag from the trunk of the tree for 2.3.0 release candidate 1.
Everyone who is testing the latest code should check out:

svn+ssh://svn.code.sf.net/p/ptpd/code/tags/ptpd-2.3.0-rc1

and begin testing.

For developers with commit bits, please be VERY careful of committing anything to this branch.
There are few enough that I don't think I need to lock the tag, but please, only critical bug
fixes should go into the tagged branch.

Best,
George

[Ptpd-announce] Version 2.3 call for testers...

[George Neville-N. <gn...@ne...>]

For those of you who can build their own ptpd from source.  The PTPd development team is preparing
the 2.3 release of PTPd.  Right now we need as many people as possible to test the release.
Please grab the latest bits from our source repository and build and test the both the client and server.

http://sourceforge.net/p/ptpd/code/HEAD/tree/trunk/

svn checkout svn://svn.code.sf.net/p/ptpd/code/trunk ptpd-code

Please report bugs in our bug tracker.

http://sourceforge.net/p/ptpd/bugs/

Best,
George

[Ptpd-announce] Upcoming 2.3 release...

[George Neville-N. <gn...@ne...>]

Howdy,

I'm now preparing to release vesion 2.3 of PTPd.  There are a lot of new features.  I've included the ChangeLog entry below.

Best,
George

2013-07-25  George Neville-Neil  <gn...@ne...>

	* 2.3.0 release

	* New Features
	
	- IEEE 802.3 Support
	- Support for reading from the Berkeley Packet Filter, resulting in lower jitter
	- Configuration file support, multiple previously unsupported options
	- Rewritten command line parameter handling, new parameters
	- Command line options to print default configuration, print lock file,	check configuration and more,
	- Full help (-H) for all configuration options,
	- Configuration reload support with SIGHUP,
	- Rewritten logging subsystem, 
	- Separate log file and statistics file, SIGHUP reprints the headers
  	- Support for mode and interface specific lock files
	- Network interface checks before startup and during config reload
	- Added ./configure --sigusr2=counters - will dump PTP engine countersto current log target when SIGUSR2 received
	- Support for presets - groups of PTP protocol options defining	ptpd behaviour
		presets available: slaveonly, masteronly, masterslave
	- Support for tick adjustment as well as frequency
		maximum frequency offset is now configurable and can be above 512 ppm - tick is used above 512 ppm,
	- Added a compatibility option to always honour the UTC offset announced by a GM when in slave state
	- Added an announce receipt timeout "grace period" for slave state
	  	slave can wait n times timeout without fully resetting
	  	allows a seamless failover without resetting delay values etc.,
	- Added support for DELAY_DISABLED delay mode - syntonisation only
	- Initial support for informing the clock subsystem about the sync status
		STA_UNSYNC is unset when adjusting the clock (allows syncing hardware RTC clocks with the system clock)
		also maxerror and esterror are set,
	- Support for legacy command line switches from previous versions
	- Configurable log level for normal logs, not only debug logs.
	- Generic log file handler mechanism with a simple built-in logrotate implementation
		for each log file container you can specify max size and max number of files
	- Extensive support for realtime statistics
	  	online long term statistics and moving statistics 
	  	mean and std dev. 
	  		Some new features included depend on statistics support, enabled with the --enable-statistics
	  		configure switch. Statistics rely on double precision so may be disabled for simple embedded systems
	- Outlier filters based on Peirce's criterion 
	  blocks / filters spikes from delayMS and delaySM 
	- Generic PI controler model
	- P and I components changed from attenuations to gains (scaled to 1/1000)
	- Optional double precision servo allows for tighter clock control
			configure --enable-double-servo
	- Clock stabilisation detection based on the standard dev of observed drift
	- Clock "calibration delay" 
		allows a configurable delay between seeing a GM for the first time and enabling clock control
	- Realtime statistics - mean and std dev of one-way delay, ofm and observed drift
	- Status file: one-screen dump of information about the current state of ptpd, updated in configurable intervals.
	- Support for "panic mode"
		if ptpd sees offset from master above 1 second, it will pause clock updates for a given amount of time
	- NTPd integration and failover
		ptpd can now connect to local ntpd using mode 7 packets (code derived from ntpdc)
	  	and using authenticated requests can enable/disable ntpd clock control.
	  		Enable with configure --enable-ntpdc
	- Dump counters using a SIGUSR2 handler to dump all counters to the log file
	  	configure --enable-sigusr2=counters

Re: [Ptpd-announce] [Ptpd-devel] 802.3 (Ethernet) mode for clients and PCAP support added to the trunk...

[Wojciech O. <woj...@ow...>]

Hi Jan,

1) Fair point, it's an easy fix the current way, we can merge the functions later

2) I'm working on config file implementation, we won't need to worry about switches soon, more info coming.

3) I thought so, just haven't looked into it

4) Fair point and easy fix again.


Regards,
Wojciech

-
Wojciech Owczarek


On 27 May 2013, at 08:09, Jan Breuer <jan...@ja...> wrote:

> Hi All,
> 
> this is great! 
> 
> I didn't test it, but I look into the code and I have some proposals.
> 
> 1) P2P mode will not work, because it uses multicast address 224.0.0.107. P2P for Ethernet mode is just not implementet. We should unify netSend and netRecv functions. We should use defines in constant_dep.h for port numbers and addresses.
> 
> 2) We can save the -e switch for the future by adding modifier defining the Network Protocol - for now UDP_IPV4, IEEE_802_3 and in the future for example UDP_IPV6. This can avoid wasting of switches like for "Delay Mechanism".
> Example: ptpd -g -e IEEE_802_3
> 
> 3) If I remember it correctly, solving ICMP problem is easy. I played with PCAP years ago for windows port. If using PCAP you should call recv on the eventSock or generalSock and just discard the packet.
> 
> 4) Ethernet mode should not join to UDP/IPv4 multicast groups.
> 
> If you don't work on these problems, I can prepare some patches - at least for 2 and 4.
> 
> Best,
> Jan
> 
> 
> 2013/5/27 Wojciech Owczarek <woj...@ow...>
> George,
> 
> It's similar on Linux - PCAP gets the data even before they hit IPFilter / IPTables - straight off the driver. The latest pcap versions allow you to set the timestamp resolution (using arbitrary keywords like HIGH/LOW) but I still need to establish if you can get ns resolution in the newer kernels.
> 
> So basically very similar to FreeBSD, however I'm not sure how the performance actually compares. The SyncLab / RADClock guys did some benchmarks with BPF included, but Linux unfortunately was not tested.
> 
> Regards
> Wojciech
> 
> 
> On 27 May 2013 02:36, George Neville-Neil <gn...@ne...> wrote:
> 
> On May 26, 2013, at 18:33 , Wojciech Owczarek <woj...@ow...> wrote:
> 
> > George, All,
> >
> > I just submitted some minor fixes to the PCAP code - tested on Linux: RHEL6 and Ubuntu. Hybrid and unicast modes should be working OK with PCAP now [ only slave mode tested! ]
> >
> 
> Great, I'll check them on FreeBSD in the next day or so.
> 
> > Naturally PCAP works fine on Linux. I don't think there is a more portable solution in userspace.
> >
> > Observations so far:
> >
> > - accuracy improved by approx 5us straight away, precision improved as well due to lower jitter
> > - unfortunately servo output will be a little jittery (short-term jitter in smaller scale - "thicker" plots basically), reason being that pcap we're back to microsecond timestamp resolution - not much can be done about it it seems, even with the latest libpcap
> > - need to double check socket initialisation and handling when using pcap: ptpd is currently bounding back ICMP unreachables in reaction to unicast delay responses. Doesn't break anything on the slave side but shouldn't be happening.
> 
> So one thing that will happen on FreeBSD, but I"m not sure on Linux is that with BPF
> we take the timestamp right above the network driver, before any other part of the system
> sees the packet.  That was one of my main motivations for doing that.  The other thing
> that will eventually go into the code is that BPF/PCAP on FreeBSD can now have
> nanosecond timestamps, as of FreeBSD 10 (CURRENT).  Once I test that I'll add those
> switches to the code.
> 
> Best,
> George
> 
> 
> 
> 
> -- 
> -
> 
> Wojciech Owczarek
> 
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Ptpd-announce mailing list
> Ptp...@li...
> https://lists.sourceforge.net/lists/listinfo/ptpd-announce
> 
> 

Re: [Ptpd-announce] [Ptpd-devel] 802.3 (Ethernet) mode for clients and PCAP support added to the trunk...

[Jan B. <jan...@ja...>]

Hi All,

this is great!

I didn't test it, but I look into the code and I have some proposals.

1) P2P mode will not work, because it uses multicast address 224.0.0.107.
P2P for Ethernet mode is just not implementet. We should unify netSend and
netRecv functions. We should use defines in constant_dep.h for port numbers
and addresses.

2) We can save the -e switch for the future by adding modifier defining the
Network Protocol - for now UDP_IPV4, IEEE_802_3 and in the future for
example UDP_IPV6. This can avoid wasting of switches like for "Delay
Mechanism".
Example: ptpd -g -e IEEE_802_3

3) If I remember it correctly, solving ICMP problem is easy. I played with
PCAP years ago for windows port. If using PCAP you should call recv on the
eventSock or generalSock and just discard the packet.

4) Ethernet mode should not join to UDP/IPv4 multicast groups.

If you don't work on these problems, I can prepare some patches - at least
for 2 and 4.

Best,
Jan


2013/5/27 Wojciech Owczarek <woj...@ow...>

> George,
>
> It's similar on Linux - PCAP gets the data even before they hit IPFilter /
> IPTables - straight off the driver. The latest pcap versions allow you to
> set the timestamp resolution (using arbitrary keywords like HIGH/LOW) but I
> still need to establish if you can get ns resolution in the newer kernels.
>
> So basically very similar to FreeBSD, however I'm not sure how the
> performance actually compares. The SyncLab / RADClock guys did some
> benchmarks with BPF included, but Linux unfortunately was not tested.
>
> Regards
> Wojciech
>
>
> On 27 May 2013 02:36, George Neville-Neil <gn...@ne...> wrote:
>
>>
>> On May 26, 2013, at 18:33 , Wojciech Owczarek <woj...@ow...>
>> wrote:
>>
>> > George, All,
>> >
>> > I just submitted some minor fixes to the PCAP code - tested on Linux:
>> RHEL6 and Ubuntu. Hybrid and unicast modes should be working OK with PCAP
>> now [ only slave mode tested! ]
>> >
>>
>> Great, I'll check them on FreeBSD in the next day or so.
>>
>> > Naturally PCAP works fine on Linux. I don't think there is a more
>> portable solution in userspace.
>> >
>> > Observations so far:
>> >
>> > - accuracy improved by approx 5us straight away, precision improved as
>> well due to lower jitter
>> > - unfortunately servo output will be a little jittery (short-term
>> jitter in smaller scale - "thicker" plots basically), reason being that
>> pcap we're back to microsecond timestamp resolution - not much can be done
>> about it it seems, even with the latest libpcap
>> > - need to double check socket initialisation and handling when using
>> pcap: ptpd is currently bounding back ICMP unreachables in reaction to
>> unicast delay responses. Doesn't break anything on the slave side but
>> shouldn't be happening.
>>
>> So one thing that will happen on FreeBSD, but I"m not sure on Linux is
>> that with BPF
>> we take the timestamp right above the network driver, before any other
>> part of the system
>> sees the packet.  That was one of my main motivations for doing that.
>>  The other thing
>> that will eventually go into the code is that BPF/PCAP on FreeBSD can now
>> have
>> nanosecond timestamps, as of FreeBSD 10 (CURRENT).  Once I test that I'll
>> add those
>> switches to the code.
>>
>> Best,
>> George
>>
>>
>
>
> --
> -
>
> Wojciech Owczarek
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Ptpd-announce mailing list
> Ptp...@li...
> https://lists.sourceforge.net/lists/listinfo/ptpd-announce
>
>