linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] PTP on Davinci(TI81xx)

[Delio B. <dbr...@au...>]

Hi Suresh,

On Aug 30, 2013, at 2:51 PM, <sur...@wi...> wrote:

> Hi,
> 
>    We are trying to bring up linuxptp on Ti81xx board (Davinci) board

Which SoC is it exactly and which kernel (compiled from which source repository/branch) are you using?

>    In the wiki it is mentioned that it is already been tested and working on Davinci/Sitara...

What are the URLs of the relevant wiki pages?

>    But we are not able to bring it up. 
> 
>    Please let us know the usage of the ptp binaries on this boards.

[...]

> On client side we are getting the error 
> port 1: received SYNC without timestamp
> ptp4l[1473.607]: port 1: bad message
> 
> 
> Server is able to send the Anounce /SYNC / Follow UP message. But client is not responding..?/
> 
> Is the usage of ptp is correct?  

linuxptp's command line options look OK to me (of course that depends on what you are trying to do). There is a problem with packet timestamping though.

Regards
--
Delio

[Linuxptp-users] PTP on Davinci(TI81xx)

[<sur...@wi...>]

Hi,

   We are trying to bring up linuxptp on Ti81xx board (Davinci) board
   In the wiki it is mentioned that it is already been tested and working on Davinci/Sitara...

   But we are not able to bring it up.

   Please let us know the usage of the ptp binaries on this boards.

  On master side we have run ptp4l as below

 ------------------------------------------------------------------------------------------------------------------------------------------
root@dm814x-evm:/home# ./ptp4l -2 -i eth0 -p /dev/ptp0 -m
-sh: ./ptp4l: not found
root@dm814x-evm:/home# cd linuxptp_bin/
root@dm814x-evm:/home/linuxptp_bin# ./ptp4l -2 -i eth0 -p /dev/ptp0 -m
ptp4l[273.895]: selected /dev/ptp0 as PTP clock
ptp4l[273.896]: failed to read out the clock frequency adjustment: Operation not supported
ptp4l[273.897]: port 1: get_ts_info not supported
ptp4l[273.902]: driver changed our HWTSTAMP options
ptp4l[273.902]: tx_type   1 not 1
ptp4l[273.902]: rx_filter 9 not 12
ptp4l[273.902]: driver rejected most general HWTSTAMP filter
ptp4l[273.902]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[273.903]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[279.902]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[279.903]: selected best master clock 080028.fffe.31f6ca
ptp4l[279.903]: assuming the grand master role
---------------------------------------------------------------------------------------------------------------------------

On the slave side
----------------------------------------------------------------------------------------------------------------------------
./ptp4l -s -2 -i eth0 -p /dev/ptp0  -m
ptp4l[1452.755]: selected /dev/ptp0 as PTP clock
ptp4l[1452.757]: failed to read out the clock frequency adjustment: Operation not supported
ptp4l[1452.757]: port 1: get_ts_info not supported
ptp4l[1452.763]: driver changed our HWTSTAMP options
ptp4l[1452.763]: tx_type   1 not 1
ptp4l[1452.763]: rx_filter 9 not 12
ptp4l[1452.763]: driver rejected most general HWTSTAMP filter
ptp4l[1452.764]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1452.764]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1458.773]: driver changed our HWTSTAMP options
ptp4l[1458.773]: tx_type   1 not 1
ptp4l[1458.773]: rx_filter 9 not 12
ptp4l[1458.773]: driver rejected most general HWTSTAMP filter
ptp4l[1458.774]: selected best master clock 847e40.fffe.2aabdc
ptp4l[1464.773]: driver changed our HWTSTAMP options
ptp4l[1464.773]: tx_type   1 not 1
ptp4l[1464.773]: rx_filter 9 not 12
ptp4l[1464.773]: driver rejected most general HWTSTAMP filter
ptp4l[1464.774]: selected best master clock 847e40.fffe.2aabdc
ptp4l[1470.773]: driver changed our HWTSTAMP options
ptp4l[1470.773]: tx_type   1 not 1
ptp4l[1470.773]: rx_filter 9 not 12
ptp4l[1470.773]: driver rejected most general HWTSTAMP filter
ptp4l[1470.774]: selected best master clock 847e40.fffe.2aabdc
ptp4l[1473.606]: port 1: received SYNC without timestamp
ptp4l[1473.607]: port 1: bad message
ptp4l[1474.606]: port 1: received SYNC without timestamp
ptp4l[1474.607]: port 1: new foreign master 080028.fffe.31f6ca-1
ptp4l[1474.607]: port 1: bad message
ptp4l[1475.606]: port 1: received SYNC without timestamp
ptp4l[1475.607]: port 1: bad message
ptp4l[1476.606]: port 1: received SYNC without timestamp
ptp4l[1476.607]: port 1: bad message
ptp4l[1476.773]: driver changed our HWTSTAMP options
ptp4l[1476.773]: tx_type   1 not 1
ptp4l[1476.773]: rx_filter 9 not 12
ptp4l[1476.774]: driver rejected most general HWTSTAMP filter
ptp4l[1476.774]: selected best master clock 847e40.fffe.2aabdc
ptp4l[1477.606]: port 1: received SYNC without timestamp
ptp4l[1477.607]: port 1: bad message
ptp4l[1478.607]: port 1: received SYNC without timestamp
ptp4l[1478.609]: selected best master clock 080028.fffe.31f6ca
ptp4l[1478.609]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1478.609]: port 1: bad message
ptp4l[1478.665]: port 1: received DELAY_REQ without timestamp
ptp4l[1479.607]: port 1: received SYNC without timestamp
ptp4l[1479.607]: port 1: bad message
ptp4l[1479.882]: missing timestamp on transmitted delay request
ptp4l[1479.883]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1495.893]: driver changed our HWTSTAMP options
ptp4l[1495.893]: tx_type   1 not 1
ptp4l[1495.893]: rx_filter 9 not 12
ptp4l[1495.893]: driver rejected most general HWTSTAMP filter
ptp4l[1495.894]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[1496.609]: port 1: new foreign master 080028.fffe.31f6ca-1
ptp4l[1496.610]: port 1: received SYNC without timestamp
ptp4l[1496.610]: port 1: bad message
---------------------------------------------------------------------------------------------------------------------------




On client side we are getting the error
port 1: received SYNC without timestamp
ptp4l[1473.607]: port 1: bad message


Server is able to send the Anounce /SYNC / Follow UP message. But client is not responding..?/

Is the usage of ptp is correct?

Thanks and regards
Suresh

Re: [Linuxptp-users] Measure the accuracy of system time respect to the PHC time

[Ledda W. E. <Wil...@it...>]

Thanks Richard. Now I have a better understanding of the problem and I can support the use of this approach.

Regards

-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: 22 August 2013 14:39
To: Ledda William EXT
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Measure the accuracy of system time respect to the PHC time

On Thu, Aug 22, 2013 at 12:16:32PM +0000, Ledda William EXT wrote:
> Hi all,
> I need to measure the accuracy of the system time respect to the time 
> from the PHC. With the two clock synchronize with phc2sys I've tried 
> the following
> 
> clock_gettime(CLOCK_REALTIME, &ts)

(here is a delay of a few microseconds, reading the PCIe bus)

> clock_gettime(phc, &tphc)
> accuracy = ts - tphc
> 
> In this way the accuracy is always about 3 us.
> 
> I'm a bit confused about the difference between this value and the offset reported from phc2sys (always under 1us). I have seen the code in order to find the reason of this difference and I understand that the offset is calculated reading the PHC between two system time and assuming that the PHC is exacltly in the half between them.
> 
> My question is: which is the best way to measure the accuracy between the system time and the PTP time?

The best way would be to feed signals from both clocks into a oscilloscope or frequency counter. However, the Linux system time is a software clock, so you cannot do that.

The next best way that I know of is to do what phc2sys does. There is an ioctl called PTP_SYS_OFFSET to read the two clocks in kernel space (which phc2sys uses if available).

Your suggestion is poor because you are comparing the two clocks at different points in time.

HTH,
Richard

Re: [Linuxptp-users] Measure the accuracy of system time respect to the PHC time

[Richard C. <ric...@gm...>]

On Thu, Aug 22, 2013 at 12:16:32PM +0000, Ledda William EXT wrote:
> Hi all,
> I need to measure the accuracy of the system time respect to the time from the PHC. With the two clock synchronize with phc2sys I've tried the following
> 
> clock_gettime(CLOCK_REALTIME, &ts)

(here is a delay of a few microseconds, reading the PCIe bus)

> clock_gettime(phc, &tphc)
> accuracy = ts - tphc
> 
> In this way the accuracy is always about 3 us.
> 
> I'm a bit confused about the difference between this value and the offset reported from phc2sys (always under 1us). I have seen the code in order to find the reason of this difference and I understand that the offset is calculated reading the PHC between two system time and assuming that the PHC is exacltly in the half between them.
> 
> My question is: which is the best way to measure the accuracy between the system time and the PTP time?

The best way would be to feed signals from both clocks into a
oscilloscope or frequency counter. However, the Linux system time is a
software clock, so you cannot do that.

The next best way that I know of is to do what phc2sys does. There is
an ioctl called PTP_SYS_OFFSET to read the two clocks in kernel space
(which phc2sys uses if available).

Your suggestion is poor because you are comparing the two clocks at
different points in time.

HTH,
Richard

[Linuxptp-users] Measure the accuracy of system time respect to the PHC time

[Ledda W. E. <Wil...@it...>]

Hi all,
I need to measure the accuracy of the system time respect to the time from the PHC. With the two clock synchronize with phc2sys I've tried the following

clock_gettime(CLOCK_REALTIME, &ts)
clock_gettime(phc, &tphc)
accuracy = ts - tphc

In this way the accuracy is always about 3 us.

I'm a bit confused about the difference between this value and the offset reported from phc2sys (always under 1us). I have seen the code in order to find the reason of this difference and I understand that the offset is calculated reading the PHC between two system time and assuming that the PHC is exacltly in the half between them.

My question is: which is the best way to measure the accuracy between the system time and the PTP time?

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[David G. <dav...@po...>]

On 08/22/2013 01:08 AM, Miroslav Lichvar wrote:

> The PPS time stamps are always relative to the system clock, so it can
> be used only with CLOCK_REALTIME as the slave clock. (phc2sys should
> print an error message if not)


Yup, looks like I'm writing a radio driver myself then.  The Z3805A has
two ports anyways.  One for the SCPI commands and the other spits
format2 time continually, which beats the poll and grab it a second
later thing the NTPd driver does.

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[Miroslav L. <mli...@re...>]

On Thu, Aug 22, 2013 at 12:48:51AM -0700, David Gravereaux wrote:
> So instead of phc2sys, I'm wanting a gps2phc+rtc ;)
> 
> If my head is screwed on right, this almost gets me there given system
> clock is the reference for start offset, but takes over from PPS, though
> not a physical signal to the NIC.
> 
>   phc2sys -wmql 7 -d /dev/pps0 -s CLOCK_REALTIME -c /dev/ptp0
> 
> If this is true, I'd be happy with this for the moment.

The PPS time stamps are always relative to the system clock, so it can
be used only with CLOCK_REALTIME as the slave clock. (phc2sys should
print an error message if not)

You can split it in to two phc2sys commands, one synchronizing the
system clock from the PPS (ntpd must be disabled or configured to not
touch the system clock) and the other synchronizing the PHC from the
system clock.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[David G. <dav...@po...>]

On 08/21/2013 10:33 PM, Richard Cochran wrote:
> On Wed, Aug 21, 2013 at 03:38:26PM -0700, David Gravereaux wrote:

>> Now if I'm using ptp as a grandmaster, who trains the /dev/ptp0 and how?
> 
> (That would be the program that you are going to write ;)
> 
>>  Or if I'm driving a PPS input at the comport's DCD line that NTPd is
>> using through its atom driver to /dev/pps0, is this managed by ptp4l for
>> slewing the card's clock?
> 
> No, it is not managed by ptp4l. You have to make sure that, if run
> them at the same time, ntpd and ptp4l/phc2sys do not step on each
> other's toes.


So instead of phc2sys, I'm wanting a gps2phc+rtc ;)

If my head is screwed on right, this almost gets me there given system
clock is the reference for start offset, but takes over from PPS, though
not a physical signal to the NIC.

  phc2sys -wmql 7 -d /dev/pps0 -s CLOCK_REALTIME -c /dev/ptp0

If this is true, I'd be happy with this for the moment.

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[David G. <dav...@po...>]

On 08/21/2013 10:33 PM, Richard Cochran wrote:

> I think you are on the right track. (At least you are asking the right
> questions :)

EPIC!  Thanks.  So many toes on this foot.

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[Richard C. <ric...@gm...>]

On Wed, Aug 21, 2013 at 03:38:26PM -0700, David Gravereaux wrote:
> 
> Conceptually, yes, I want to train the high-res clock of the i210 from
> the radio.  And from that, or maybe in parallel with, train the system
> clock.

Okay.
 
> First, I don't understand what phc2sys is used for.  If I'm running the
> ptp4l daemon as a slave with free-running off, the daemon is setting and
> training system clock, yes?

No, just /dev/ptp0.

The phc2sys program is for syncing CLOCK_REALTIME to /dev/ptp0.

[ But if you select SW time stamping, then ptp4l will discipline
  CLOCK_REALTIME instead of /dev/ptp0. In that case, you don't need to
  run phc2sys at all. ]

> Or is it just the clock of the controller?

Yes.

> Now if I'm using ptp as a grandmaster, who trains the /dev/ptp0 and how?

(That would be the program that you are going to write ;)

>  Or if I'm driving a PPS input at the comport's DCD line that NTPd is
> using through its atom driver to /dev/pps0, is this managed by ptp4l for
> slewing the card's clock?

No, it is not managed by ptp4l. You have to make sure that, if run
them at the same time, ntpd and ptp4l/phc2sys do not step on each
other's toes.

> Yeah, I'm lost.

I think you are on the right track. (At least you are asking the right
questions :)

Thanks,
Richard

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[David G. <dav...@po...>]

On 08/20/2013 11:09 PM, Richard Cochran wrote:
> The PPS will give you the phase offset from the full second, and you
> can read the time and date from the serial port.


Richard,

I love this idea.  But being a newb, I don't understand how all the
parts work.  Could you walk me though this?

Conceptually, yes, I want to train the high-res clock of the i210 from
the radio.  And from that, or maybe in parallel with, train the system
clock.

First, I don't understand what phc2sys is used for.  If I'm running the
ptp4l daemon as a slave with free-running off, the daemon is setting and
training system clock, yes?  Or is it just the clock of the controller?

Now if I'm using ptp as a grandmaster, who trains the /dev/ptp0 and how?
 Or if I'm driving a PPS input at the comport's DCD line that NTPd is
using through its atom driver to /dev/pps0, is this managed by ptp4l for
slewing the card's clock?

Yeah, I'm lost.

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] PTP master slewing to other network time

[Dave C. <dav...@un...>]

On Wed, Aug 21, 2013 at 1:03 PM, Miroslav Lichvar <mli...@re...>wrote:

> On Wed, Aug 21, 2013 at 12:46:01PM +0100, Dave Craig wrote:
> > On Wed, Aug 21, 2013 at 12:29 PM, Miroslav Lichvar <mli...@re...
> >wrote:
> > > You can check if the local PTP port is in the master state with
> > > pmc -u -b 0 'GET PORT_DATA_SET'.
> >
> > Although I can get the master state and then choose to set the system
> clock
> > based on that, it means that I'd be writing very similar code to the
> servo
> > code of PTP inside my NTP process. It currently just calls settimeofday,
> > but I'd rather it slewed to the new time more gracefully. I wondered if
> > having that work done inside ptp4l would be tidier? In the master state
> the
> > clock servo would be accepting changes over pmc and in the slave state
> > ignoring it.
>
> You could use the adjtime system call instead of settimeofday to
> adjust the clock slowly and not in one step.
>
That's probably the approach I'll take. I was concerned about a race
between calling pmc to find out if the local device was the master and
actually setting the time, but it's by far the simplest solution and the
chances of a race are small and it's effects fairly minor.


> I guess there could be a private pmc command to feed the servo
> manually, but it would have to be called periodically in the sync
> interval as the servo can't slew the clock by a specified offset with
> just one point. It's a feedback loop.
>
The NTP process gets the time fairly regularly so this wouldn't be a
problem.


> Why not use ntpdate or a regular NTP daemon instead?
>
Unfortunate legacy reasons :-(

Thanks again for your advice,

Dave

Re: [Linuxptp-users] PTP master slewing to other network time

[Miroslav L. <mli...@re...>]

On Wed, Aug 21, 2013 at 12:46:01PM +0100, Dave Craig wrote:
> On Wed, Aug 21, 2013 at 12:29 PM, Miroslav Lichvar <mli...@re...>wrote:
> > You can check if the local PTP port is in the master state with
> > pmc -u -b 0 'GET PORT_DATA_SET'.
> 
> Although I can get the master state and then choose to set the system clock
> based on that, it means that I'd be writing very similar code to the servo
> code of PTP inside my NTP process. It currently just calls settimeofday,
> but I'd rather it slewed to the new time more gracefully. I wondered if
> having that work done inside ptp4l would be tidier? In the master state the
> clock servo would be accepting changes over pmc and in the slave state
> ignoring it.

You could use the adjtime system call instead of settimeofday to
adjust the clock slowly and not in one step.

I guess there could be a private pmc command to feed the servo
manually, but it would have to be called periodically in the sync
interval as the servo can't slew the clock by a specified offset with
just one point. It's a feedback loop.

Why not use ntpdate or a regular NTP daemon instead?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] PTP master slewing to other network time

[Dave C. <dav...@un...>]

Hi Miroslav,

Thanks for the quick response.

On Wed, Aug 21, 2013 at 12:29 PM, Miroslav Lichvar <mli...@re...>wrote:

> On Wed, Aug 21, 2013 at 11:23:41AM +0100, Dave Craig wrote:
> > There's already a process on each device that gets the current time via
> NTP
> > or HTTP and so I'd like to make it so that the PTP master accepts times
> > from this process and slews/steps it's clock appropriately. Devices which
> > are currently slaves would simply ignore/discard the attempts to set
> their
> > time and stay locked to the master.
> > Is there already a mechanism I can use to do this that I've missed, or
> > should I try adding one to ptp4l or possibly phc2sys?
>
> Is that with hw or sw time stamping?
>
I'm using sw timestamping.


> You can check if the local PTP port is in the master state with
> pmc -u -b 0 'GET PORT_DATA_SET'.

Although I can get the master state and then choose to set the system clock
based on that, it means that I'd be writing very similar code to the servo
code of PTP inside my NTP process. It currently just calls settimeofday,
but I'd rather it slewed to the new time more gracefully. I wondered if
having that work done inside ptp4l would be tidier? In the master state the
clock servo would be accepting changes over pmc and in the slave state
ignoring it.

Thanks

Dave

Re: [Linuxptp-users] PTP master slewing to other network time

[Miroslav L. <mli...@re...>]

On Wed, Aug 21, 2013 at 11:23:41AM +0100, Dave Craig wrote:
> There's already a process on each device that gets the current time via NTP
> or HTTP and so I'd like to make it so that the PTP master accepts times
> from this process and slews/steps it's clock appropriately. Devices which
> are currently slaves would simply ignore/discard the attempts to set their
> time and stay locked to the master.
> Is there already a mechanism I can use to do this that I've missed, or
> should I try adding one to ptp4l or possibly phc2sys?

Is that with hw or sw time stamping?

You can check if the local PTP port is in the master state with
pmc -u -b 0 'GET PORT_DATA_SET'. If the hw time stamping is used, you
will need to also synchronize the PTP hardware clock from the system
clock with the phc2sys program.

-- 
Miroslav Lichvar

[Linuxptp-users] PTP master slewing to other network time

[Dave C. <dav...@un...>]

Hi,

I have a group of devices successfully keeping their system clocks
synchronized on a local network using ptp4l. The master is left up to the
bmc arbitration and as all the devices are basically the same, the chosen
master comes down to the device MAC address. I'd like the master time to be
'roughly' UTC, so want to slew/step whoever the current master is to make
this happen.
There's already a process on each device that gets the current time via NTP
or HTTP and so I'd like to make it so that the PTP master accepts times
from this process and slews/steps it's clock appropriately. Devices which
are currently slaves would simply ignore/discard the attempts to set their
time and stay locked to the master.
Is there already a mechanism I can use to do this that I've missed, or
should I try adding one to ptp4l or possibly phc2sys?

Thanks

Dave Craig.

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[David G. <dav...@po...>]

On 08/20/2013 11:09 PM, Richard Cochran wrote:
> On Wed, Aug 21, 2013 at 07:47:54AM +0200, Richard Cochran wrote:
>> On Tue, Aug 20, 2013 at 02:00:05PM -0700, David Gravereaux wrote:
>>> I was wondering if I use NTPd for controlling the GPS radio with its
>>> built-in driver for it along with the PPS signal on the comport as the
>>> DCD line
>>> <http://support.ntp.org/bin/view/Support/Z3801AReceiverModifications>,
>>> would this share the same counter for PTP?
>>
>> This setup will synchronize the Linux system time to the external
>> Z3801A box using a PPS signal. You could use ptp4l with software time
>> stamping and the 'free_running' option to serve this time to your
>> network.
> 
> But you have an Intel i210, right?
> 
> So it would be even better to feed the PPS from the Z3801A into one of
> the i210's SDP pins. (Be careful with the signal conditioning, SDP is
> CMOS directly to the chip.)
> 
> I posted a igb patch on netdev to enable the SDP functions. This was
> not accepted into mainline (I'll have to make minor changes first),
> but it does work. You can patch your kernel with it.
> 
> Then you can use the i210's external time stamps of the PPS to
> discipline the i210's clock. You will have to write some code, but
> you can re-use phc2sys and the testptp program, as they have most of
> what you need.
> 
> The PPS will give you the phase offset from the full second, and you
> can read the time and date from the serial port.
> 
> Good luck,
> Richard
> 


Awesome!  I thought there might have been hardware support in the card,
but wasn't sure.  Let me meditate on this for a bit.  Writing C is what
I live for.  I won't get the radio for a couple weeks yet.

I want to get a leg-up on this "stock" workstation if possible before
moving to PC/104e

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[Miroslav L. <mli...@re...>]

On Wed, Aug 21, 2013 at 08:09:08AM +0200, Richard Cochran wrote:
> On Wed, Aug 21, 2013 at 07:47:54AM +0200, Richard Cochran wrote:
> > On Tue, Aug 20, 2013 at 02:00:05PM -0700, David Gravereaux wrote:
> > > I was wondering if I use NTPd for controlling the GPS radio with its
> > > built-in driver for it along with the PPS signal on the comport as the
> > > DCD line
> > > <http://support.ntp.org/bin/view/Support/Z3801AReceiverModifications>,
> > > would this share the same counter for PTP?
> > 
> > This setup will synchronize the Linux system time to the external
> > Z3801A box using a PPS signal. You could use ptp4l with software time
> > stamping and the 'free_running' option to serve this time to your
> > network.
> 
> But you have an Intel i210, right?
> 
> So it would be even better to feed the PPS from the Z3801A into one of
> the i210's SDP pins. (Be careful with the signal conditioning, SDP is
> CMOS directly to the chip.)

Just to list all options, if the requirement is to have the PTP slaves
well synced together, but the absolute accuracy of the PTP time
doesn't matter match, the PHC can be synchronized from the system
clock by phc2sys with a very slow PI servo and used by ptp4l without
losing hw time stamping.

e.g. phc2sys -w -c eth0 -s CLOCK_REALTIME -P 0.03 -I 0.0001

-- 
Miroslav Lichvar

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[Richard C. <ric...@gm...>]

On Wed, Aug 21, 2013 at 07:47:54AM +0200, Richard Cochran wrote:
> On Tue, Aug 20, 2013 at 02:00:05PM -0700, David Gravereaux wrote:
> > I was wondering if I use NTPd for controlling the GPS radio with its
> > built-in driver for it along with the PPS signal on the comport as the
> > DCD line
> > <http://support.ntp.org/bin/view/Support/Z3801AReceiverModifications>,
> > would this share the same counter for PTP?
> 
> This setup will synchronize the Linux system time to the external
> Z3801A box using a PPS signal. You could use ptp4l with software time
> stamping and the 'free_running' option to serve this time to your
> network.

But you have an Intel i210, right?

So it would be even better to feed the PPS from the Z3801A into one of
the i210's SDP pins. (Be careful with the signal conditioning, SDP is
CMOS directly to the chip.)

I posted a igb patch on netdev to enable the SDP functions. This was
not accepted into mainline (I'll have to make minor changes first),
but it does work. You can patch your kernel with it.

Then you can use the i210's external time stamps of the PPS to
discipline the i210's clock. You will have to write some code, but
you can re-use phc2sys and the testptp program, as they have most of
what you need.

The PPS will give you the phase offset from the full second, and you
can read the time and date from the serial port.

Good luck,
Richard

Re: [Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[Richard C. <ric...@gm...>]

On Tue, Aug 20, 2013 at 02:00:05PM -0700, David Gravereaux wrote:
> I was wondering if I use NTPd for controlling the GPS radio with its
> built-in driver for it along with the PPS signal on the comport as the
> DCD line
> <http://support.ntp.org/bin/view/Support/Z3801AReceiverModifications>,
> would this share the same counter for PTP?

This setup will synchronize the Linux system time to the external
Z3801A box using a PPS signal. You could use ptp4l with software time
stamping and the 'free_running' option to serve this time to your
network.

HTH,
Richard

[Linuxptp-users] grandmaster with an H/P 3805A GPS disciplined osc

[David G. <dav...@po...>]

I was wondering if I use NTPd for controlling the GPS radio with its
built-in driver for it along with the PPS signal on the comport as the
DCD line
<http://support.ntp.org/bin/view/Support/Z3801AReceiverModifications>,
would this share the same counter for PTP?

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] poll tx timestamp timeout

[David G. <dav...@po...>]

On 08/14/2013 01:25 AM, Richard Cochran wrote:
...
> So 10 ms might not be enough for this system. Try 100 ms.
> 
> Thanks,
> Richard
> 

Not one blip since last night, thanks.

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] offset explosion and irregular phc offsets

[Miroslav L. <mli...@re...>]

On Tue, Aug 13, 2013 at 08:29:32PM +0000, Keller, Jacob E wrote:
> On Tue, 2013-08-13 at 08:05 +0200, Richard Cochran wrote:
> > On Tue, Aug 13, 2013 at 01:29:52AM -0400, Dale Smith wrote:
> > > Well, with PCIe, there are a *lot* more busses, but 37 sure does seem like
> > > a lot.
> > 
> > Googling around, I see that I am not the only person annoyed by this
> > brilliant naming. Apparently the automatic slot numbering is fragile
> > and breaks more often than not. That would explain the "37".
> > 
> > Thanks,
> > Richard
> 
> Interesting... Yea I have machines that get something like p261p1, so..
> it definitely isn't exactly slot number..

BTW, recent systemd/udev versions use their own interface naming
instead of biosdevname, so don't be surprised when you see names like
enp2s0 or wlp3s0 :).

http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20

-- 
Miroslav Lichvar

Re: [Linuxptp-users] poll tx timestamp timeout

[Richard C. <ric...@gm...>]

On Wed, Aug 14, 2013 at 12:56:02AM -0700, David Gravereaux wrote:
> On 08/14/2013 12:01 AM, Richard Cochran wrote:
> 
> > Which messages are affected, sync, peer delay request, or both?
> 
> Not sure. It causes the master to change to the switch, then it grabs it
> back after it recovers.  I would assume a sync

You can see this in the log on the line after the failure ...

> ptp4l[88356.177]: assuming the grand master role
> ptp4l[95586.834]: poll tx timestamp timeout
> ptp4l[95586.834]: port 1: send sync failed
                                 ^^^^
here.

> >> I've increased 'tx_timestamp_timeout' to 10ms, but has happened a few
> >> more times even when run with an increased priority such as:

...

> $ grep ^CONFIG_HZ /boot/config-3.8.0-27-generic
> CONFIG_HZ_250=y
> CONFIG_HZ=250
> 
> period of 250Hz is 4ms    (interesting)

So 10 ms might not be enough for this system. Try 100 ms.

Thanks,
Richard

Re: [Linuxptp-users] poll tx timestamp timeout

[David G. <dav...@po...>]

On 08/14/2013 12:01 AM, Richard Cochran wrote:
> On Tue, Aug 13, 2013 at 05:15:05PM -0700, David Gravereaux wrote:
>> I've been running ptp4l as a master, and this cropped-up a few times in
>> the log last night.
> 
> You are running your i210 as master with P2P, right?

Yes

> What are you using for logSyncInterval and logMinPdelayReqInterval?

logSyncInterval         -3
logMinPdelayReqInterval 0

> How often does this occur? Twice in twelve hours?

16 times since 7:30 this morning.  Happened just a couple times last night.

> Which messages are affected, sync, peer delay request, or both?

Not sure. It causes the master to change to the switch, then it grabs it
back after it recovers.  I would assume a sync

$ sudo nice -n -19 ptp4l -i eth2 -f gPTP.cfg
ptp4l[88348.672]: driver changed our HWTSTAMP options
ptp4l[88348.672]: tx_type   1 not 1
ptp4l[88348.672]: rx_filter 1 not 12
ptp4l[88348.672]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[88348.672]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[88352.175]: port 1: new foreign master 0026f2.fffe.f25aa0-1
ptp4l[88354.672]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[88354.672]: selected best master clock a0369f.fffe.1cdd3b <-me
ptp4l[88354.672]: assuming the grand master role
ptp4l[88356.177]: selected best master clock 0026f2.fffe.f25aa0 <-switch
ptp4l[88356.177]: assuming the grand master role
ptp4l[95586.834]: poll tx timestamp timeout
ptp4l[95586.834]: port 1: send sync failed
ptp4l[95586.834]: port 1: MASTER to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[95588.864]: driver changed our HWTSTAMP options
ptp4l[95588.864]: tx_type   1 not 1
ptp4l[95588.864]: rx_filter 1 not 12
ptp4l[95588.864]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[95593.793]: port 1: new foreign master 0026f2.fffe.f25aa0-1
ptp4l[95594.864]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[95594.864]: selected best master clock a0369f.fffe.1cdd3b
ptp4l[95594.864]: assuming the grand master role
ptp4l[97678.318]: poll tx timestamp timeout
...


>> I've increased 'tx_timestamp_timeout' to 10ms, but has happened a few
>> more times even when run with an increased priority such as:
>>
>>   sudo nice -n -19 ptp4l -i eth2 -f gPTP.cfg
> 
> Changing the priority of ptp4l will have no effect (see below).

Good to know, thanks.

>> Could this be igb.ko slow on the up-take?
> 
> When the i210 time stamps a transmitted event packet, it generates an
> interrupt. The ISR then schedules a work callback which runs after the
> next system tick.* The callback then delivers the time stamp to the
> error queue of the process's socket.
> 
> * [Make sure tx_timestamp_timeout is long enough to account for this.]

$ grep ^CONFIG_HZ /boot/config-3.8.0-27-generic
CONFIG_HZ_250=y
CONFIG_HZ=250

period of 250Hz is 4ms    (interesting)

> Although the i210 can only handle one outstanding Tx time stamp, still
> I don't see how any can go missing, since the ptp4l program always
> waits for Tx time stamp before sending another event message.
> 
> I can think of two explanations.
> 
> 1. The i210 simply fails to time stamp some event packets.
> 2. You are running a second program that generates event packets.


I'm running locally on this workstation as a test before pondering how
to put this on a PC/104 embedded system connected to an HP Z3801A or
other GPS-disciplined oscillator for its real duty.

Thanks Richard.  I'm coming up to speed

-- 
David Gravereaux <dav...@po...>