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

Re: [Linuxptp-users] Polling ptp clock not allowed?

[Keller, J. E <jac...@in...>]

On Thu, 2016-02-25 at 15:26 +0100, frank wrote:
> 
> On 02/25/2016 09:01 AM, frank wrote:
> > On 02/24/2016 06:23 PM, Keller, Jacob E wrote:
> > > > -----Original Message-----
> > > > Finally a collegue used the patch below and the problem
> > > > vanished(above
> > > > test code did run a long time),
> > > >  however it is unclear if the timestamps produced are still
> > > > 'correct' and
> > > > useful for ptp.
> > > > The fix still looks surprising..
> > > > 
> > > > kind regards
> > > >   Frank
> > > > 
> > > This is the work-around I was talking about below. I am surprised
> > > it is not in the 4.4 kernel?
> > > 
> > > This is a known hardware errata on some of the parts (I am not
> > > sure which ones) and it should have had the workaround pushed
> > > upstream. I am guessing your collegue got this from the out-of-
> > > tree driver on SourceForge
> > Hi,
> > 
> > no, we looked at the 4.4 Code and backported it to 3.19, but our
> > testcase still showed the problem.
> > Thought "this workaround cannot work if..." and created the patch
> > below
> > ourselfes.
> > Need to check sourceforge..
> > 
> Hm, the code in e1000e-3.3.3.tar.gz looks like the one in the 4.4
> kernel, so I suspect it will fail
> using the testcase too.
> 
> regards
>   Frank

How fast are you trying to read the clock in your test case? I suspect
that polling too rapidly may be what causes part of the issue?

I'm not certain, though. I don't know that particular hardware very
well.

Thanks,
Jake

Re: [Linuxptp-users] Polling ptp clock not allowed?

[frank <sou...@gm...>]

On 02/25/2016 09:01 AM, frank wrote:
> On 02/24/2016 06:23 PM, Keller, Jacob E wrote:
>>> -----Original Message-----
>>> Finally a collegue used the patch below and the problem vanished(above
>>> test code did run a long time),
>>>  however it is unclear if the timestamps produced are still 'correct' and
>>> useful for ptp.
>>> The fix still looks surprising..
>>>
>>> kind regards
>>>   Frank
>>>
>> This is the work-around I was talking about below. I am surprised it is not in the 4.4 kernel?
>>
>> This is a known hardware errata on some of the parts (I am not sure which ones) and it should have had the workaround pushed upstream. I am guessing your collegue got this from the out-of-tree driver on SourceForge
> Hi,
>
> no, we looked at the 4.4 Code and backported it to 3.19, but our
> testcase still showed the problem.
> Thought "this workaround cannot work if..." and created the patch below
> ourselfes.
> Need to check sourceforge..
>
Hm, the code in e1000e-3.3.3.tar.gz looks like the one in the 4.4
kernel, so I suspect it will fail
using the testcase too.

regards
  Frank

Re: [Linuxptp-users] Polling ptp clock not allowed?

[frank <sou...@gm...>]

On 02/24/2016 06:23 PM, Keller, Jacob E wrote:
>> -----Original Message-----
>> Finally a collegue used the patch below and the problem vanished(above
>> test code did run a long time),
>>  however it is unclear if the timestamps produced are still 'correct' and
>> useful for ptp.
>> The fix still looks surprising..
>>
>> kind regards
>>   Frank
>>
> This is the work-around I was talking about below. I am surprised it is not in the 4.4 kernel?
>
> This is a known hardware errata on some of the parts (I am not sure which ones) and it should have had the workaround pushed upstream. I am guessing your collegue got this from the out-of-tree driver on SourceForge

Hi,

no, we looked at the 4.4 Code and backported it to 3.19, but our
testcase still showed the problem.
Thought "this workaround cannot work if..." and created the patch below
ourselfes.
Need to check sourceforge..

We were surprised that it helped, basically we did not understand what
kind of hardware bug might
cause more than one overflow in such a small amount of time.

It is not clear to me if the "time"  produced by the intel chips using
our patch is "valid" at all,
or if it would be better just to remove the PTP clock from the affected
Intel drivers completely.

Backgrund: What I see in the setup  currently are spikes in the PTP time
distributed by linuxptp.

We investigated the components and found a problem in the intel driver
and a testcase to reproduce it,
developed a patch for the testcase, but  the spikes are still there...
(We have a beagleboard in the system too and suspect problems which
might be related to parallel NFS traffic ,
 but found no simple testcase for this.)

What our testcase confirms is that the results from clock_gettime() 
jumped wildly around before our patch
and did not do this after applying the patch.

A constant counter or somethings with a jitter having an amplitude below
1s would pass our testcase too...

Any opinion very much appreciated.

kind regards
  Frank

Re: [Linuxptp-users] Polling ptp clock not allowed?

[Keller, J. E <jac...@in...>]

Hi,

> -----Original Message-----
> From: frank [mailto:sou...@gm...]
> Sent: Wednesday, February 24, 2016 6:48 AM
> To: lin...@li...
> Subject: Re: [Linuxptp-users] Polling ptp clock not allowed?
> 
> Hi,
> 
> some updates

<snip>

> Finally a collegue used the patch below and the problem vanished(above
> test code did run a long time),
>  however it is unclear if the timestamps produced are still 'correct' and
> useful for ptp.
> The fix still looks surprising..
> 
> kind regards
>   Frank
> 

This is the work-around I was talking about below. I am surprised it is not in the 4.4 kernel?

This is a known hardware errata on some of the parts (I am not sure which ones) and it should have had the workaround pushed upstream. I am guessing your collegue got this from the out-of-tree driver on SourceForge?

Regards,
Jake

Re: [Linuxptp-users] Polling ptp clock not allowed?

[frank <sou...@gm...>]

Hi,

some updates

> Here it would help to see the values of oldts and newts when the >
assertion fails.
The counter values when the assert happens are: 

newts.tv_sec = 56c923a3
  oldts.tv_sec= 56c810c2
  delta=000112e1

The delta at error time is either 
000112e1 or 000112e0


The check code looks now:

#include <time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[])
{
    static const int CLOCKFD = 3;
    int fd = open("/dev/ptp0", O_RDONLY);
    if(fd == -1)
    {
        printf("open failed\n");
        exit(1);
    }
    clockid_t clkid = ((~(clockid_t)(fd) << 3) | CLOCKFD);

    struct timespec oldts;
    struct timespec newts;
    int r = clock_gettime(clkid, &oldts);
    if(r == -1)
    {
        printf("clock_gettime failed\n");
        exit(1);
    }


    for (;;)
    {
        int r = clock_gettime(clkid, &newts);
        if(r == -1)
        {
            printf("clock_gettime failed\n");
            exit(1);
        }
        time_t delta = newts.tv_sec - oldts.tv_sec;
        if(delta < 0)
        {
            printf("newts.tv_sec = %08x\n oldts.tv_sec= %08x\n delta=%08x\n", newts.tv_sec , oldts.tv_sec, delta);
            exit(1);
        }
        if(delta > 1)
        {
            printf("newts.tv_sec = %08x\n oldts.tv_sec= %08x\n delta=%08x\n", newts.tv_sec , oldts.tv_sec, delta);
            exit(1);
        }
        oldts = newts;
    }
}

wrt:

> drivers/net/ethernet/intel/e1000e/netdev.c:e1000e_cyclecounter_read():


The workaround implemented there does not seem to work correctly.
Using a card where the workaround jumps in, the problem appears too.


There are various versions of the workaround in linux and we backported the linux 4.4 workaround
to 3.19, but still the same error happens.

Finally a collegue used the patch below and the problem vanished(above test code did run a long time),
 however it is unclear if the timestamps produced are still 'correct' and useful for ptp. 
The fix still looks surprising..

kind regards
  Frank

patch against 3.19 kernel.

--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4150,11 +4150,29 @@ static cycle_t e1000e_cyclecounter_read(
 	struct e1000_adapter *adapter = container_of(cc, struct e1000_adapter,
 						     cc);
 	struct e1000_hw *hw = &adapter->hw;
+	u32 systimel_1, systimel_2, systimeh;
 	cycle_t systim, systim_next;
-
-	/* latch SYSTIMH on read of SYSTIML */
-	systim = (cycle_t)er32(SYSTIML);
-	systim |= (cycle_t)er32(SYSTIMH) << 32;
+	/* SYSTIMH latching upon SYSTIML read does not work well.
+	 * This means that if SYSTIML overflows after we read it but before
+	 * we read SYSTIMH, the value of SYSTIMH has been incremented and we
+	 * will experience a huge non linear increment in the systime value
+	 * to fix that we test for overflow and if true, we re-read systime.
+	 */
+	systimel_1 = er32(SYSTIML);
+	systimeh = er32(SYSTIMH);
+	systimel_2 = er32(SYSTIML);
+	/* Check for overflow. If there was no overflow, use the values */
+	if (systimel_1 < systimel_2) {
+		systim = (cycle_t)systimel_1;
+		systim |= (cycle_t)systimeh << 32;
+	} else {
+		/* There was an overflow, read again SYSTIMH, and use
+		 * systimel_2
+		 */
+		systimeh = er32(SYSTIMH);
+		systim = (cycle_t)systimel_2;
+		systim |= (cycle_t)systimeh << 32;
+	}
 
 	if ((hw->mac.type == e1000_82574) || (hw->mac.type == e1000_82583)) {
 		u64 incvalue, time_delta, rem, temp;
@@ -4167,8 +4185,21 @@ static cycle_t e1000e_cyclecounter_read(
 		incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
 		for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
 			/* latch SYSTIMH on read of SYSTIML */
-			systim_next = (cycle_t)er32(SYSTIML);
-			systim_next |= (cycle_t)er32(SYSTIMH) << 32;
+			systimel_1 = er32(SYSTIML);
+			systimeh = er32(SYSTIMH);
+			systimel_2 = er32(SYSTIML);
+			/* Check for overflow. If there was no overflow, use the values */
+			if (systimel_1 < systimel_2) {
+				systim_next = (cycle_t)systimel_1;
+				systim_next |= (cycle_t)systimeh << 32;
+			} else {
+			/* There was an overflow, read again SYSTIMH, and use
+			 * systimel_2
+			 */
+				systimeh = er32(SYSTIMH);
+				systim_next = (cycle_t)systimel_2;
+				systim_next |= (cycle_t)systimeh << 32;
+			}
 
 			time_delta = systim_next - systim;
 			temp = time_delta;

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Thank you for the support Richard & all.

On Thu, Feb 18, 2016 at 6:44 PM, Richard Cochran <ric...@gm...>
wrote:

> On Thu, Feb 18, 2016 at 04:03:09PM +0530, Sujatha Guguloth wrote:
> >         /* set the current offset values */
> >         *offset = then;*
>
> This is still wrong.  The delta value is, well, a delta.  You must add
> it to the current offset.
>
> I hate to say it, but this list about the linuxptp software, not about
> proprietary driver development.  We pointed you in the right
> direction, saying that the problem lies in the driver and/or fpga.
> You will have to fix it yourself.
>
> Sorry,
> Richard
>

Re: [Linuxptp-users] Maximum of slaves that ptp4l grandmaster can support?

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

On Thu, Feb 18, 2016 at 04:36:38PM +0000, Daniel Le wrote:
> Just curious, is there a defined upper limit for the number of slaves that ptp4l in grandmaster mode can handle? Per port? I couldn't find the answer in the email archives, ptp4l configuration options and code.

No, there is no artificial limit.

Thanks,
Richard

[Linuxptp-users] Maximum of slaves that ptp4l grandmaster can support?

[Daniel Le <dan...@ex...>]

Hello,

Just curious, is there a defined upper limit for the number of slaves that ptp4l in grandmaster mode can handle? Per port? I couldn't find the answer in the email archives, ptp4l configuration options and code.

Thanks,
Daniel

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

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

On Thu, Feb 18, 2016 at 04:03:09PM +0530, Sujatha Guguloth wrote:
>         /* set the current offset values */
>         *offset = then;*

This is still wrong.  The delta value is, well, a delta.  You must add
it to the current offset.

I hate to say it, but this list about the linuxptp software, not about
proprietary driver development.  We pointed you in the right
direction, saying that the problem lies in the driver and/or fpga.
You will have to fix it yourself.

Sorry,
Richard

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi Richard,

to avoid the confusion, I am putting both the functions below here
completely.

Please have a look.

static int xlnx_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
{
        struct xlnx_ptp_timer *timer = container_of(ptp, struct
xlnx_ptp_timer,
                                              ptp_clock_info);

        int neg_adj = 0;
        u64 freq = 0;
        u32 diff = 0;
        u32 incval = 0;

        /* External clock source Frequency is 200MHz
   */
        /* adjust the RTC Increment Control register by (1/200MHZ = 5ns)
   */
        /* resolution of the increment register is 1/1048576
   */
        /* hence 5 * 1048576 = 0x500000 - value to be written to the
register */
        incval = 0x500000;

        if (ppb < 0) {
          neg_adj = 1;
          ppb = -ppb;
        }

        freq = incval;
        freq *= ppb;
        diff = div_u64(freq, 1000000000ULL);

        incval = neg_adj ? (incval - diff) : (incval + diff);

        /* Write the adjusted value to the RTC Increment Value Control
Register */
        /* Writing the adjustment value to this register intern adjusts the
nanoseconds register value by the hw */
*out_be32((timer->baseaddr + XTIMER1588_RTC_INCREMENT), incval);*

        return 0;
}


static int xlnx_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
{
        unsigned long flags = 0;
        struct xlnx_ptp_timer *timer = container_of(ptp, struct
xlnx_ptp_timer,
                                              ptp_clock_info);
        struct timespec offset, *then = ns_to_timespec(delta);*

        spin_lock_irqsave(&timer->reg_lock, flags);

        /* Read the seconds and nano seconds from the RTC Seconds and RTC
Nano Seconds Registers */
        xlnx_rtc_offset_read(timer, &offset);

        /* set the current offset values */
        *offset = then;*

        /* Write the seconds and nano seconds to the RTC Seconds and RTC
Nano Seconds Registers */
        xlnx_rtc_offset_write(timer, (const struct timespec *)*&offset*);

        spin_unlock_irqrestore(&timer->reg_lock, flags);
        return 0;
}

Best Regards,
Sujatha

On Thu, Feb 18, 2016 at 3:33 PM, Sujatha Guguloth <suj...@gm...>
wrote:

> Hi Richard,
>
> I am writing the incval to the register in adjfreq after the calculation.I
> had written that in the comments and actual code is below.
> out_be32((timer->baseaddr + XTIMER1588_RTC_INCREMENT), incval);
>
>
> In adjtime: delta is passed to  ns_to_timespec
> then = ns_to_timespec(delta)
> offset = then; /* then is copied to offset */
>  xlnx_rtc_offset_write(timer, (const struct timespec *)&offset); /* This
> offset is written to the register */
>
>
> Best Regards,
> Sujatha
>
>
> On Thu, Feb 18, 2016 at 2:59 PM, Richard Cochran <ric...@gm...
> > wrote:
>
>> Wow, your code is totally broken...
>>
>> On Thu, Feb 18, 2016 at 12:04:22PM +0530, Sujatha Guguloth wrote:
>> > static int xlnx_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
>> > {
>> >         struct xlnx_ptp_timer *timer = container_of(ptp, struct
>> > xlnx_ptp_timer,
>> >                                               ptp_clock_info);
>> >
>> >         int neg_adj = 0;
>> >         u64 freq = 0;
>> >         u32 diff = 0;
>> >         u32 incval = 0;
>> >
>> >         /* External clock source Frequency is 200MHz    which is driving
>> > the timer  */
>> >         /* adjust the RTC Increment Control register by (1/200MHZ =
>> 5ns)  */
>> >         /* resolution of the increment register is 1/1048576
>>   */
>> >         /* hence 5 * 1048576 = 0x500000 - value to be written to the
>> > register */
>> >         incval = 0x500000;
>> >
>> >         if (ppb < 0) {
>> >           neg_adj = 1;
>> >           ppb = -ppb;
>> >         }
>> >
>> >         freq = incval;
>> >         freq *= ppb;
>> >         diff = div_u64(freq, 1000000000ULL);
>> >
>> >         incval = neg_adj ? (incval - diff) : (incval + diff);
>> >
>> >         /* Write the adjusted value to the *RTC Increment Value Control
>> > Register* */
>> >         /* Writing the adjustment value to this register intern adjusts
>> the
>> > nanoseconds register value by the hw */
>>
>> You calculate 'incval' and then do nothing with it.
>>
>> >         return 0;
>> > }
>> >
>> >
>> > static int xlnx_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
>> > {
>> >         unsigned long flags = 0;
>> >         struct xlnx_ptp_timer *timer = container_of(ptp, struct
>> > xlnx_ptp_timer,
>> >                                               ptp_clock_info);
>> >         struct timespec offset, then = ns_to_timespec(delta);
>> >
>> >         spin_lock_irqsave(&timer->reg_lock, flags);
>> >
>> >         /* Read the seconds and nano seconds from the RTC Seconds and
>> RTC
>> > Nano Seconds Registers */
>> >         xlnx_rtc_offset_read(timer, &offset);
>> >
>> >         /* set the current offset values */
>> >         offset = then;
>>
>> You are supposed to add the delta.
>>
>> >         /* Write the seconds and nano seconds to the *RTC Seconds* and
>> *RTC
>> > Nano Seconds* Registers */
>> >         xlnx_rtc_offset_write(timer, (const struct timespec *)&offset);
>> >
>> >         spin_unlock_irqrestore(&timer->reg_lock, flags);
>> >         return 0;
>> > }
>>
>> Good luck,
>> Richard
>>
>
>

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi Richard,

I am writing the incval to the register in adjfreq after the calculation.I
had written that in the comments and actual code is below.
out_be32((timer->baseaddr + XTIMER1588_RTC_INCREMENT), incval);


In adjtime: delta is passed to  ns_to_timespec
then = ns_to_timespec(delta)
offset = then; /* then is copied to offset */
 xlnx_rtc_offset_write(timer, (const struct timespec *)&offset); /* This
offset is written to the register */


Best Regards,
Sujatha


On Thu, Feb 18, 2016 at 2:59 PM, Richard Cochran <ric...@gm...>
wrote:

> Wow, your code is totally broken...
>
> On Thu, Feb 18, 2016 at 12:04:22PM +0530, Sujatha Guguloth wrote:
> > static int xlnx_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> > {
> >         struct xlnx_ptp_timer *timer = container_of(ptp, struct
> > xlnx_ptp_timer,
> >                                               ptp_clock_info);
> >
> >         int neg_adj = 0;
> >         u64 freq = 0;
> >         u32 diff = 0;
> >         u32 incval = 0;
> >
> >         /* External clock source Frequency is 200MHz    which is driving
> > the timer  */
> >         /* adjust the RTC Increment Control register by (1/200MHZ =
> 5ns)  */
> >         /* resolution of the increment register is 1/1048576
>   */
> >         /* hence 5 * 1048576 = 0x500000 - value to be written to the
> > register */
> >         incval = 0x500000;
> >
> >         if (ppb < 0) {
> >           neg_adj = 1;
> >           ppb = -ppb;
> >         }
> >
> >         freq = incval;
> >         freq *= ppb;
> >         diff = div_u64(freq, 1000000000ULL);
> >
> >         incval = neg_adj ? (incval - diff) : (incval + diff);
> >
> >         /* Write the adjusted value to the *RTC Increment Value Control
> > Register* */
> >         /* Writing the adjustment value to this register intern adjusts
> the
> > nanoseconds register value by the hw */
>
> You calculate 'incval' and then do nothing with it.
>
> >         return 0;
> > }
> >
> >
> > static int xlnx_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
> > {
> >         unsigned long flags = 0;
> >         struct xlnx_ptp_timer *timer = container_of(ptp, struct
> > xlnx_ptp_timer,
> >                                               ptp_clock_info);
> >         struct timespec offset, then = ns_to_timespec(delta);
> >
> >         spin_lock_irqsave(&timer->reg_lock, flags);
> >
> >         /* Read the seconds and nano seconds from the RTC Seconds and RTC
> > Nano Seconds Registers */
> >         xlnx_rtc_offset_read(timer, &offset);
> >
> >         /* set the current offset values */
> >         offset = then;
>
> You are supposed to add the delta.
>
> >         /* Write the seconds and nano seconds to the *RTC Seconds* and
> *RTC
> > Nano Seconds* Registers */
> >         xlnx_rtc_offset_write(timer, (const struct timespec *)&offset);
> >
> >         spin_unlock_irqrestore(&timer->reg_lock, flags);
> >         return 0;
> > }
>
> Good luck,
> Richard
>

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

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

Wow, your code is totally broken...

On Thu, Feb 18, 2016 at 12:04:22PM +0530, Sujatha Guguloth wrote:
> static int xlnx_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> {
>         struct xlnx_ptp_timer *timer = container_of(ptp, struct
> xlnx_ptp_timer,
>                                               ptp_clock_info);
> 
>         int neg_adj = 0;
>         u64 freq = 0;
>         u32 diff = 0;
>         u32 incval = 0;
> 
>         /* External clock source Frequency is 200MHz    which is driving
> the timer  */
>         /* adjust the RTC Increment Control register by (1/200MHZ = 5ns)  */
>         /* resolution of the increment register is 1/1048576              */
>         /* hence 5 * 1048576 = 0x500000 - value to be written to the
> register */
>         incval = 0x500000;
> 
>         if (ppb < 0) {
>           neg_adj = 1;
>           ppb = -ppb;
>         }
> 
>         freq = incval;
>         freq *= ppb;
>         diff = div_u64(freq, 1000000000ULL);
> 
>         incval = neg_adj ? (incval - diff) : (incval + diff);
> 
>         /* Write the adjusted value to the *RTC Increment Value Control
> Register* */
>         /* Writing the adjustment value to this register intern adjusts the
> nanoseconds register value by the hw */

You calculate 'incval' and then do nothing with it.
 
>         return 0;
> }
> 
> 
> static int xlnx_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
> {
>         unsigned long flags = 0;
>         struct xlnx_ptp_timer *timer = container_of(ptp, struct
> xlnx_ptp_timer,
>                                               ptp_clock_info);
>         struct timespec offset, then = ns_to_timespec(delta);
> 
>         spin_lock_irqsave(&timer->reg_lock, flags);
> 
>         /* Read the seconds and nano seconds from the RTC Seconds and RTC
> Nano Seconds Registers */
>         xlnx_rtc_offset_read(timer, &offset);
> 
>         /* set the current offset values */
>         offset = then;

You are supposed to add the delta.
 
>         /* Write the seconds and nano seconds to the *RTC Seconds* and *RTC
> Nano Seconds* Registers */
>         xlnx_rtc_offset_write(timer, (const struct timespec *)&offset);
> 
>         spin_unlock_irqrestore(&timer->reg_lock, flags);
>         return 0;
> }

Good luck,
Richard

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi Jacob,

I tried to test the driver with testptp and it seems to be working as
expected.

I was able to settime, gettime, adjtime, adjfreq got the expected values.


The setup I am using is explained below.


MASTER [Linux Ubuntu System with Oregano NIC card for Hardware Time
Stamping] < --> SLAVE [Xilinx FPGA Device which supports the HW time
stamping ]
Slave is getting its clock from an external clock source which is running
at 200MHz Frequency.

Xilinx Ethernet Driver which is used for HW timestamping, it is available
on github @
https://github.com/Xilinx/linux-xlnx/blob/master/drivers/net/ethernet/xilinx/xilinx_axienet_main.c

settime, gettime, adjtime, adjfreq functionality is developed in a separate
timer driver which is not available on the github but this driver is pretty
straight forward.


When debugging with PTP4l application, In the normal scenario if
step_threshold is set to 0.0, I have observed that
- during s1 state *adjtime *gets called with ADJ_SETOFFSET | ADJ_NANO modes
to adjust the clock.
- when slave moves to s2 state, upon receiving the sync and followup
packets, *adjfreq *is called for every 1 second to adjust the frequency of
the clock

adjtime and adjfreq are implemented in timer driver as below.


static int xlnx_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
{
        struct xlnx_ptp_timer *timer = container_of(ptp, struct
xlnx_ptp_timer,
                                              ptp_clock_info);

        int neg_adj = 0;
        u64 freq = 0;
        u32 diff = 0;
        u32 incval = 0;

        /* External clock source Frequency is 200MHz    which is driving
the timer  */
        /* adjust the RTC Increment Control register by (1/200MHZ = 5ns)  */
        /* resolution of the increment register is 1/1048576              */
        /* hence 5 * 1048576 = 0x500000 - value to be written to the
register */
        incval = 0x500000;

        if (ppb < 0) {
          neg_adj = 1;
          ppb = -ppb;
        }

        freq = incval;
        freq *= ppb;
        diff = div_u64(freq, 1000000000ULL);

        incval = neg_adj ? (incval - diff) : (incval + diff);

        /* Write the adjusted value to the *RTC Increment Value Control
Register* */
        /* Writing the adjustment value to this register intern adjusts the
nanoseconds register value by the hw */

        return 0;
}


static int xlnx_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
{
        unsigned long flags = 0;
        struct xlnx_ptp_timer *timer = container_of(ptp, struct
xlnx_ptp_timer,
                                              ptp_clock_info);
        struct timespec offset, then = ns_to_timespec(delta);

        spin_lock_irqsave(&timer->reg_lock, flags);

        /* Read the seconds and nano seconds from the RTC Seconds and RTC
Nano Seconds Registers */
        xlnx_rtc_offset_read(timer, &offset);

        /* set the current offset values */
        offset = then;

        /* Write the seconds and nano seconds to the *RTC Seconds* and *RTC
Nano Seconds* Registers */
        xlnx_rtc_offset_write(timer, (const struct timespec *)&offset);

        spin_unlock_irqrestore(&timer->reg_lock, flags);
        return 0;
}


could you please review these functions and let us know if there are any
issues.


Thank you.


Best Regards,
Sujatha




On Wed, Feb 17, 2016 at 9:37 AM, Sujatha Guguloth <suj...@gm...>
wrote:

> Thank you Jocob and Lichavar for your quick replies.
>
> I will try with testptp.
>
> Best Regards,
> Sujatha
>
> On Wed, Feb 17, 2016 at 1:26 AM, Keller, Jacob E <jac...@in...
> > wrote:
>
>> Hi,
>>
>> On Tue, 2016-02-16 at 16:20 +0530, Sujatha Guguloth wrote:
>> > Hi Miroslav Lichvar,
>> >
>> > What aspects of driver/HW needs to be fixed. could you please
>> > elaborate more on this.
>> >
>> >
>> > Best Regards,
>> > Sujatha
>>
>> At this point, we really can't offer more advice unless the source is
>> available. The driver is definitely doing something funky as evidenced
>> above, and unless the driver is available we can't really comment.
>>
>> I suggest using the provided testptp tool provided in the Linux Kernel
>> documentation to do some sanity checks on all your ptp code paths for
>> adjtime, settime, gettime, adjfreq, etc. Verify these are doing what
>> you expect before you continue your debugging with ptp4l.
>>
>> Regards,
>> Jake
>
>
>

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Thank you Jocob and Lichavar for your quick replies.

I will try with testptp.

Best Regards,
Sujatha

On Wed, Feb 17, 2016 at 1:26 AM, Keller, Jacob E <jac...@in...>
wrote:

> Hi,
>
> On Tue, 2016-02-16 at 16:20 +0530, Sujatha Guguloth wrote:
> > Hi Miroslav Lichvar,
> >
> > What aspects of driver/HW needs to be fixed. could you please
> > elaborate more on this.
> >
> >
> > Best Regards,
> > Sujatha
>
> At this point, we really can't offer more advice unless the source is
> available. The driver is definitely doing something funky as evidenced
> above, and unless the driver is available we can't really comment.
>
> I suggest using the provided testptp tool provided in the Linux Kernel
> documentation to do some sanity checks on all your ptp code paths for
> adjtime, settime, gettime, adjfreq, etc. Verify these are doing what
> you expect before you continue your debugging with ptp4l.
>
> Regards,
> Jake

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Keller, J. E <jac...@in...>]

Hi,

On Tue, 2016-02-16 at 16:20 +0530, Sujatha Guguloth wrote:
> Hi Miroslav Lichvar,
> 
> What aspects of driver/HW needs to be fixed. could you please
> elaborate more on this.
> 
> 
> Best Regards,
> Sujatha

At this point, we really can't offer more advice unless the source is
available. The driver is definitely doing something funky as evidenced
above, and unless the driver is available we can't really comment.

I suggest using the provided testptp tool provided in the Linux Kernel
documentation to do some sanity checks on all your ptp code paths for
adjtime, settime, gettime, adjfreq, etc. Verify these are doing what
you expect before you continue your debugging with ptp4l.

Regards,
Jake

Re: [Linuxptp-users] Polling ptp clock not allowed?

[Keller, J. E <jac...@in...>]

On Fri, 2016-02-12 at 15:03 +0100, Richard Cochran wrote:
> On Fri, Feb 12, 2016 at 12:09:25PM +0100, frank wrote:
> > During printf debugging I have seen large jumps in the timespecs
> > returned by clock_gettime().
> > 
> > Using a Intel i5 with a  "Intel Corporation Ethernet Connection
> > I217-V
> > (rev 05)"
> > network card around 100-200 calls to clock_gettime() in a loop are
> > enough.
> 
> This uses the e1000e driver, right?  That driver has a work around
> for
> a HW bug when reading the time, but it is restricted to 82574/82583
> devices:
> 
> drivers/net/ethernet/intel/e1000e/netdev.c:e1000e_cyclecounter_read()
> :
> 		/* errata for 82574/82583 possible bad bits read from
> SYSTIMH/L
> 		 * check to see that the time is incrementing at a
> reasonable
> 		 * rate and is a multiple of incvalue
> 		 */
> 
> Maybe the i217 is also affected?  You could try enabling this work
> around for i217 as well.
> 
> >     struct timespec oldts;
> >     struct timespec newts;
> >     clock_gettime(clkid, &oldts);
> > 
> >     for(;;)
> >     {
> >        clock_gettime(clkid, &newts);
> >        time_t delta = newts.tv_sec - oldts.tv_sec;
> >        oldts = newts;
> >        assert(delta >= 0);
> >        assert(delta <= 1);
> 
> Here it would help to see the values of oldts and newts when the
> assertion fails.
> 
> >     }
> > }
> 
> This sounds like the same old hw bug.  I would ask intel and/or on
> the
> e1000 list.
> 
> Thanks,
> Richard

It is possible this is the same bug. Let me know your results, I can
forward it to the team responsible.

Regards,
Jake

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

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

On Tue, Feb 16, 2016 at 04:20:56PM +0530, Sujatha Guguloth wrote:
> Hi Miroslav Lichvar,
> 
> What aspects of driver/HW needs to be fixed. could you please elaborate
> more on this.

The ADJ_SETOFFSET mode needs to be fixed. When ptp4l tries to step
the clock, it seems the actual step is up to one second off. Maybe
some integer operation with sub-second fields overflows and the second
field is not adjusted accordingly. Just a guess.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi Miroslav Lichvar,

What aspects of driver/HW needs to be fixed. could you please elaborate
more on this.


Best Regards,
Sujatha

On Tue, Feb 16, 2016 at 4:16 PM, Miroslav Lichvar <mli...@re...>
wrote:

> On Tue, Feb 16, 2016 at 10:42:27AM +0530, Sujatha Guguloth wrote:
> > Hi Miroslav Lichvar,
> >
> > I tried your suggestion  by setting the pi_offset_const(set_threshold) to
> > 0.1
> > but, with that the slave clock is not getting stabilized and and entering
> > into s2 state at all, it keeps shuffling between s0 and s1 states
> > It throws the error as "clock jumped backward or running slower than
> > expected!" some times and "clock jumped forward or running faster than
> > expected!" some times
>
> I think that means the clock stepping is completely broken. The
> driver/HW needs to be fixed.
>
> --
> Miroslav Lichvar
>

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

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

On Tue, Feb 16, 2016 at 10:42:27AM +0530, Sujatha Guguloth wrote:
> Hi Miroslav Lichvar,
> 
> I tried your suggestion  by setting the pi_offset_const(set_threshold) to
> 0.1
> but, with that the slave clock is not getting stabilized and and entering
> into s2 state at all, it keeps shuffling between s0 and s1 states
> It throws the error as "clock jumped backward or running slower than
> expected!" some times and "clock jumped forward or running faster than
> expected!" some times

I think that means the clock stepping is completely broken. The
driver/HW needs to be fixed.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi Miroslav Lichvar,

I tried your suggestion  by setting the pi_offset_const(set_threshold) to
0.1
but, with that the slave clock is not getting stabilized and and entering
into s2 state at all, it keeps shuffling between s0 and s1 states
It throws the error as "clock jumped backward or running slower than
expected!" some times and "clock jumped forward or running faster than
expected!" some times

Below are the the logs:
ptp4l[345.444]: selected /dev/ptp0 as PTP clock
ptp4l[345.484]: driver changed our HWTSTAMP options
ptp4l[345.489]: tx_type   1 not 1
ptp4l[345.494]: rx_filter 1 not 12
ptp4l[345.498]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[345.510]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[346.649]: port 1: new foreign master 001ec0.fffe.8614b5-1
ptp4l[350.649]: selected best master clock 001ec0.fffe.8614b5
ptp4l[350.654]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[352.826]: master offset -1553865481389947 s0 freq      +0 path delay
     5128
ptp4l[353.827]: master offset -1553865481406512 s1 freq  -16565 path delay
     5128
ptp4l[354.827]: master offset -1000000463 s0 freq  -16565 path delay
 5128
ptp4l[355.827]: master offset -999998257 s0 freq  -16565 path delay
 2769
ptp4l[356.828]: master offset -999998398 s1 freq  -16706 path delay
 2769
ptp4l[357.822]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[357.832]: master offset -481406489 s0 freq  -16706 path delay
 2769
ptp4l[358.829]: master offset -481404091 s1 freq  -14308 path delay
411
ptp4l[359.827]: master offset -1000000600 s0 freq  -14308 path delay
411
ptp4l[360.822]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[360.832]: master offset -1000003077 s0 freq  -14308 path delay
637
ptp4l[361.829]: master offset -1000005315 s1 freq  -16546 path delay
637
ptp4l[362.822]: clockcheck: clock jumped forward or running faster than
expected!
ptp4l[362.832]: master offset  518595705 s0 freq  -16546 path delay
637
ptp4l[363.829]: master offset  518595591 s1 freq  -16660 path delay
591
ptp4l[364.827]: master offset -1000005266 s0 freq  -16660 path delay
591
ptp4l[365.822]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[365.832]: master offset -1000005230 s0 freq  -16660 path delay
591
ptp4l[366.829]: master offset -1000005072 s1 freq  -16502 path delay
478
ptp4l[367.822]: clockcheck: clock jumped forward or running faster than
expected!
ptp4l[367.832]: master offset  518595452 s0 freq  -16502 path delay
478
ptp4l[368.829]: master offset  518595382 s1 freq  -16572 path delay
401
ptp4l[369.828]: master offset -1000005217 s0 freq  -16572 path delay
401
ptp4l[370.822]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[370.832]: master offset -1000005381 s0 freq  -16572 path delay
401
ptp4l[371.829]: master offset -1000005508 s1 freq  -16699 path delay
380
ptp4l[372.822]: clockcheck: clock jumped forward or running faster than
expected!
ptp4l[372.833]: master offset  518595424 s0 freq  -16699 path delay
380
ptp4l[373.829]: master offset  518595461 s1 freq  -16662 path delay
380
ptp4l[374.828]: master offset -1000005458 s0 freq  -16662 path delay
380
ptp4l[375.822]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[375.834]: master offset -1000005401 s0 freq  -16662 path delay
365
ptp4l[376.829]: master offset -1000005341 s1 freq  -16602 path delay
352



Best Regards,
Sujatha

On Mon, Feb 15, 2016 at 5:34 PM, Sujatha Guguloth <suj...@gm...>
wrote:

> Hi Miroslav Lichvar,
>
> Thank you for quick replay.
>
> We are using Linux 3.19 version and the Hardware is a proprietary FPGA
> Hardware.
>
> I will try your suggestion.
>
> Thank you.
>
> Best Regards,
> Sujatha
>
> On Mon, Feb 15, 2016 at 3:36 PM, Miroslav Lichvar <mli...@re...>
> wrote:
>
>> On Mon, Feb 15, 2016 at 02:16:13PM +0530, Sujatha Guguloth wrote:
>> > In Failire case (Logs provided below)
>> > - slave clock is taking 340 - 278 = 62 seconds for stabilization
>> > -  jitter is maintained below 100ns after stabilization but it is very
>> very
>> > high compared to previous case during the stabilization stage
>>
>> It looks like the initial step is off by one second for some reason.
>> It could be a driver issue. What HW and kernel version do you use?
>>
>> As a workaround you could try setting step_threshold to 0.1 for
>> example and allow ptp4l to correct that one second error by stepping
>> instead of slewing.
>>
>> > *Failure Logs:*
>> > ptp4l[270.981]: selected /dev/ptp0 as PTP clock
>> > ptp4l[271.014]: driver changed our HWTSTAMP options
>> > ptp4l[271.020]: tx_type   1 not 1
>> > ptp4l[271.024]: rx_filter 1 not 12
>> > ptp4l[271.028]: port 1: INITIALIZING to LISTENING on INITIALIZE
>> > ptp4l[271.040]: port 0: INITIALIZING to LISTENING on INITIALIZE
>> > ptp4l[272.323]: port 1: new foreign master 001ec0.fffe.8614b5-1
>> > ptp4l[276.323]: selected best master clock 001ec0.fffe.8614b5
>> > ptp4l[276.328]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
>> > ptp4l[278.496]: master offset -1475113437970290 s0 freq      +0 path
>> delay
>> >      7176
>> > ptp4l[279.496]: master offset -1475113437987402 s1 freq  -17112 path
>> delay
>> >      7176
>> > ptp4l[280.496]: master offset -1000000284 s2 freq -32767999 path delay
>> >  7176
>> > ptp4l[280.501]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
>> > ptp4l[281.501]: master offset -967516976 s2 freq -32767999 path delay
>>
>> --
>> Miroslav Lichvar
>>
>
>

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi Miroslav Lichvar,

Thank you for quick replay.

We are using Linux 3.19 version and the Hardware is a proprietary FPGA
Hardware.

I will try your suggestion.

Thank you.

Best Regards,
Sujatha

On Mon, Feb 15, 2016 at 3:36 PM, Miroslav Lichvar <mli...@re...>
wrote:

> On Mon, Feb 15, 2016 at 02:16:13PM +0530, Sujatha Guguloth wrote:
> > In Failire case (Logs provided below)
> > - slave clock is taking 340 - 278 = 62 seconds for stabilization
> > -  jitter is maintained below 100ns after stabilization but it is very
> very
> > high compared to previous case during the stabilization stage
>
> It looks like the initial step is off by one second for some reason.
> It could be a driver issue. What HW and kernel version do you use?
>
> As a workaround you could try setting step_threshold to 0.1 for
> example and allow ptp4l to correct that one second error by stepping
> instead of slewing.
>
> > *Failure Logs:*
> > ptp4l[270.981]: selected /dev/ptp0 as PTP clock
> > ptp4l[271.014]: driver changed our HWTSTAMP options
> > ptp4l[271.020]: tx_type   1 not 1
> > ptp4l[271.024]: rx_filter 1 not 12
> > ptp4l[271.028]: port 1: INITIALIZING to LISTENING on INITIALIZE
> > ptp4l[271.040]: port 0: INITIALIZING to LISTENING on INITIALIZE
> > ptp4l[272.323]: port 1: new foreign master 001ec0.fffe.8614b5-1
> > ptp4l[276.323]: selected best master clock 001ec0.fffe.8614b5
> > ptp4l[276.328]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> > ptp4l[278.496]: master offset -1475113437970290 s0 freq      +0 path
> delay
> >      7176
> > ptp4l[279.496]: master offset -1475113437987402 s1 freq  -17112 path
> delay
> >      7176
> > ptp4l[280.496]: master offset -1000000284 s2 freq -32767999 path delay
> >  7176
> > ptp4l[280.501]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
> > ptp4l[281.501]: master offset -967516976 s2 freq -32767999 path delay
>
> --
> Miroslav Lichvar
>

Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

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

On Mon, Feb 15, 2016 at 02:16:13PM +0530, Sujatha Guguloth wrote:
> In Failire case (Logs provided below)
> - slave clock is taking 340 - 278 = 62 seconds for stabilization
> -  jitter is maintained below 100ns after stabilization but it is very very
> high compared to previous case during the stabilization stage

It looks like the initial step is off by one second for some reason.
It could be a driver issue. What HW and kernel version do you use?

As a workaround you could try setting step_threshold to 0.1 for
example and allow ptp4l to correct that one second error by stepping
instead of slewing.

> *Failure Logs:*
> ptp4l[270.981]: selected /dev/ptp0 as PTP clock
> ptp4l[271.014]: driver changed our HWTSTAMP options
> ptp4l[271.020]: tx_type   1 not 1
> ptp4l[271.024]: rx_filter 1 not 12
> ptp4l[271.028]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[271.040]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[272.323]: port 1: new foreign master 001ec0.fffe.8614b5-1
> ptp4l[276.323]: selected best master clock 001ec0.fffe.8614b5
> ptp4l[276.328]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[278.496]: master offset -1475113437970290 s0 freq      +0 path delay
>      7176
> ptp4l[279.496]: master offset -1475113437987402 s1 freq  -17112 path delay
>      7176
> ptp4l[280.496]: master offset -1000000284 s2 freq -32767999 path delay
>  7176
> ptp4l[280.501]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
> ptp4l[281.501]: master offset -967516976 s2 freq -32767999 path delay

-- 
Miroslav Lichvar

[Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi All,

I am facing issue with ptp4l application where the SLAVE to MASTER Path
Delay Variation is very high for initial few seconds and it is taking ~62
seconds for the slave clock to get stabilized.

This issue is seen 4 out of 5 times when the system is executed with the
same software.

Our target is to have the slave clock get stabilized with in 5 seconds from
s0 state and the jitter should be less than 100 ns.

In Success case(Logs provided below)
-  slave clock is taking  186 - 173  = 13 seconds for stabilization
-  Jitter is with 100ns after stabilization

In Failire case (Logs provided below)
- slave clock is taking 340 - 278 = 62 seconds for stabilization
-  jitter is maintained below 100ns after stabilization but it is very very
high compared to previous case during the stabilization stage

The issues observed in Failure case logs are ,
-  the Master time stamp and slave time stamp difference is very high
- at s1, adjtime called to adjust the slave time, but after that the  time
difference is more
- adjtime is called only once and after that the time adjustment is
happening only using adjfreq
- the maximum adjfreq can happen is 32767999, hence it is trying to adjust
the frequency using 32767999 for 29 times and then gradually frequency
value is decreased to adjust the slave time and for this it is taking 62
seconds
- This behaviour is observed 4 out of 5 times and suddenly for 1 time the
systems starts behaving correctly where I got the the success logs.
- I have tried to set the pi_offset_const in default.cfg to 1.0 thinking
that if the time difference between MASTER and SLAVE goes beyond 1 second
adjtime might get called. But the value changed in default.cfg does not get
reflected in the software. I have verified it in pi.c file by
printing s->max_offset value , This value is always 0

- Based on the logs below, the time difference between MASTER and SLAVE is
not going beyond 1 second so I experimented the pi_offset_const with 0.5 as
well but could not see any difference.


Can somebody help me to solve this issue. I have been struggling with this
issue for a long time and currently exhausted with all the possible
options.Any pointers on this issue could be a great help to me.


Thank you all in advance.


*Success Logs:*
ptp4l[167.314]: driver changed our HWTSTAMP options
ptp4l[167.320]: tx_type   1 not 1
ptp4l[167.324]: rx_filter 1 not 12
ptp4l[167.329]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[167.340]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[168.503]: port 1: new foreign master 001ec0.fffe.8614b5-1
ptp4l[172.512]: selected best master clock 001ec0.fffe.8614b5
ptp4l[172.527]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[173.676]: master offset -1474359190506508 s0 freq      +0 path delay
     1391
ptp4l[174.677]: master offset -1474359190525503 s1 freq  -18994 path delay
     3347
ptp4l[175.676]: master offset       1686 s2 freq  -17308 path delay
 3347
ptp4l[175.681]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[176.677]: master offset       3777 s2 freq  -14712 path delay
 1391
ptp4l[177.677]: master offset       1412 s2 freq  -15943 path delay
 1425
ptp4l[178.677]: master offset        208 s2 freq  -16724 path delay
 1425
ptp4l[179.677]: master offset       -209 s2 freq  -17078 path delay
 1391
ptp4l[180.677]: master offset        228 s2 freq  -16704 path delay
886
ptp4l[181.678]: master offset       -210 s2 freq  -17074 path delay
886
ptp4l[182.677]: master offset        222 s2 freq  -16705 path delay
381
ptp4l[183.677]: master offset       -293 s2 freq  -17153 path delay
458
ptp4l[184.678]: master offset       -370 s2 freq  -17318 path delay
458
ptp4l[185.678]: master offset       -171 s2 freq  -17230 path delay
381
ptp4l[186.678]: master offset        -38 s2 freq  -17148 path delay
370
ptp4l[187.678]: master offset        -92 s2 freq  -17214 path delay
354
ptp4l[188.678]: master offset         40 s2 freq  -17109 path delay
354
ptp4l[189.678]: master offset        -31 s2 freq  -17168 path delay
349
ptp4l[190.678]: master offset        103 s2 freq  -17044 path delay
346
ptp4l[191.678]: master offset         26 s2 freq  -17090 path delay
346
ptp4l[192.678]: master offset        -35 s2 freq  -17143 path delay
344
ptp4l[193.678]: master offset       -102 s2 freq  -17220 path delay
344
ptp4l[194.678]: master offset         11 s2 freq  -17138 path delay
344
ptp4l[195.682]: master offset        -51 s2 freq  -17197 path delay
340
ptp4l[196.678]: master offset         62 s2 freq  -17099 path delay
340
ptp4l[197.678]: master offset         14 s2 freq  -17128 path delay
337
ptp4l[198.678]: master offset        -66 s2 freq  -17204 path delay
337
ptp4l[199.678]: master offset         72 s2 freq  -17086 path delay
337
ptp4l[200.678]: master offset          5 s2 freq  -17131 path delay
339
ptp4l[201.680]: master offset        -54 s2 freq  -17189 path delay
339



*Failure Logs:*
ptp4l[270.981]: selected /dev/ptp0 as PTP clock
ptp4l[271.014]: driver changed our HWTSTAMP options
ptp4l[271.020]: tx_type   1 not 1
ptp4l[271.024]: rx_filter 1 not 12
ptp4l[271.028]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[271.040]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[272.323]: port 1: new foreign master 001ec0.fffe.8614b5-1
ptp4l[276.323]: selected best master clock 001ec0.fffe.8614b5
ptp4l[276.328]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[278.496]: master offset -1475113437970290 s0 freq      +0 path delay
     7176
ptp4l[279.496]: master offset -1475113437987402 s1 freq  -17112 path delay
     7176
ptp4l[280.496]: master offset -1000000284 s2 freq -32767999 path delay
 7176
ptp4l[280.501]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[281.501]: master offset -967516976 s2 freq -32767999 path delay
 5595
ptp4l[282.497]: master offset -932832166 s2 freq -32767999 path delay
 -1927882
ptp4l[283.497]: master offset -898147308 s2 freq -32767999 path delay
 -3861360
ptp4l[284.497]: master offset -865395833 s2 freq -32767999 path delay
 -3861360
ptp4l[285.497]: master offset -831350054 s2 freq -32767999 path delay
 -5155742
ptp4l[286.497]: master offset -799893170 s2 freq -32767999 path delay
 -3861360
ptp4l[287.497]: master offset -765847415 s2 freq -32767999 path delay
 -5155742
ptp4l[288.497]: master offset -733096073 s2 freq -32767999 path delay
 -5155742
ptp4l[289.497]: master offset -698230049 s2 freq -32767999 path delay
 -7270253
ptp4l[290.498]: master offset -665478434 s2 freq -32767999 path delay
 -7270253
ptp4l[291.498]: master offset -632727061 s2 freq -32767999 path delay
 -7270253
ptp4l[292.498]: master offset -598665729 s2 freq -32767999 path delay
 -8580243
ptp4l[293.498]: master offset -564280251 s2 freq -32767999 path delay
-10214326
ptp4l[294.498]: master offset -531529599 s2 freq -32767999 path delay
-10213455
ptp4l[295.498]: master offset -497634061 s2 freq -32767999 path delay
-11357800
ptp4l[296.498]: master offset -464882705 s2 freq -32767999 path delay
-11357800
ptp4l[297.498]: master offset -432131187 s2 freq -32767999 path delay
-11357800
ptp4l[298.498]: master offset -399380745 s2 freq -32767999 path delay
-11356929
ptp4l[299.498]: master offset -366628279 s2 freq -32767999 path delay
-11357800
ptp4l[300.498]: master offset -333876738 s2 freq -32767999 path delay
-11357800
ptp4l[301.498]: master offset -301125423 s2 freq -32767999 path delay
-11357800
ptp4l[302.498]: master offset -268374981 s2 freq -32767999 path delay
-11356929
ptp4l[303.498]: master offset -235623646 s2 freq -32767999 path delay
-11356929
ptp4l[304.498]: master offset -202794969 s2 freq -32767999 path delay
-11434176
ptp4l[305.498]: master offset -170043447 s2 freq -32767999 path delay
-11434176
ptp4l[306.498]: master offset -137787552 s2 freq -32767999 path delay
-10938890
ptp4l[307.502]: master offset -105035853 s2 freq -32767999 path delay
-10938890
ptp4l[308.498]: master offset  -72284835 s2 freq -32767999 path delay
-10938890
ptp4l[309.498]: master offset  -39533393 s2 freq -32767999 path delay
-10938890
ptp4l[310.498]: master offset   -6782000 s2 freq -6799112 path delay
-10938890
ptp4l[311.498]: master offset     240469 s2 freq -1811243 path delay
-10938890
ptp4l[312.498]: master offset     607326 s2 freq -1372245 path delay
 -9465521
ptp4l[313.502]: master offset     -82486 s2 freq -1879859 path delay
 -7416620
ptp4l[314.499]: master offset    1773547 s2 freq  -48572 path delay
 -7416620
ptp4l[315.499]: master offset    -306599 s2 freq -1596654 path delay
 -5288386
ptp4l[316.498]: master offset     452990 s2 freq -929044 path delay
 -4482990
ptp4l[317.498]: master offset    1379304 s2 freq +133167 path delay
 -4482990
ptp4l[318.499]: master offset   -1209889 s2 freq -2042235 path delay
 -2033615
ptp4l[319.499]: master offset    -570670 s2 freq -1765983 path delay
-667937
ptp4l[320.499]: master offset     942311 s2 freq -424203 path delay
-429615
ptp4l[321.499]: master offset    1361863 s2 freq +278042 path delay
-429615
ptp4l[322.499]: master offset     877075 s2 freq +201813 path delay
-233274
ptp4l[323.499]: master offset     657429 s2 freq +245290 path delay
-233274
ptp4l[324.499]: master offset     256206 s2 freq  +41295 path delay
 -94051
ptp4l[325.499]: master offset     101446 s2 freq  -36603 path delay
482
ptp4l[326.499]: master offset     116561 s2 freq   +8946 path delay
 3951
ptp4l[327.499]: master offset      91065 s2 freq  +18418 path delay
 3951
ptp4l[328.499]: master offset      53869 s2 freq   +8542 path delay
 5785
ptp4l[329.499]: master offset      26391 s2 freq   -2775 path delay
 7659
ptp4l[330.499]: master offset      16293 s2 freq   -4956 path delay
 3184
ptp4l[331.499]: master offset       2694 s2 freq  -13667 path delay
 4398
ptp4l[332.500]: master offset       -982 s2 freq  -16535 path delay
 4398
ptp4l[333.500]: master offset        856 s2 freq  -14992 path delay
 1800
ptp4l[334.500]: master offset       -614 s2 freq  -16205 path delay
 1024
ptp4l[335.500]: master offset      -1311 s2 freq  -17086 path delay
585
ptp4l[336.500]: master offset      -1493 s2 freq  -17661 path delay
585
ptp4l[337.500]: master offset      -1094 s2 freq  -17710 path delay
585
ptp4l[338.500]: master offset       -684 s2 freq  -17628 path delay
585
ptp4l[339.503]: master offset       -178 s2 freq  -17328 path delay
494
ptp4l[340.500]: master offset        -45 s2 freq  -17248 path delay
399
ptp4l[341.500]: master offset        -16 s2 freq  -17233 path delay
399
ptp4l[342.500]: master offset         32 s2 freq  -17189 path delay
362
ptp4l[343.500]: master offset        112 s2 freq  -17100 path delay
328
ptp4l[344.500]: master offset        -42 s2 freq  -17220 path delay
328
ptp4l[345.499]: master offset        -26 s2 freq  -17217 path delay
328
ptp4l[346.500]: master offset         12 s2 freq  -17187 path delay
328
ptp4l[347.500]: master offset         42 s2 freq  -17153 path delay
328
ptp4l[348.500]: master offset       -138 s2 freq  -17320 path delay
333
ptp4l[349.500]: master offset       -102 s2 freq  -17326 path delay
333
ptp4l[350.500]: master offset        -73 s2 freq  -17327 path delay
336
ptp4l[351.500]: master offset        -29 s2 freq  -17305 path delay
337
ptp4l[352.500]: master offset          7 s2 freq  -17278 path delay
336
ptp4l[353.500]: master offset         39 s2 freq  -17244 path delay
334
ptp4l[354.500]: master offset         73 s2 freq  -17198 path delay
332
ptp4l[355.500]: master offset        104 s2 freq  -17145 path delay
330
ptp4l[356.500]: master offset        -41 s2 freq  -17259 path delay
330
ptp4l[357.500]: master offset         -5 s2 freq  -17235 path delay
330


Best Regards,
Sujatha

Re: [Linuxptp-users] Polling ptp clock not allowed?

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

On Fri, Feb 12, 2016 at 12:09:25PM +0100, frank wrote:
> During printf debugging I have seen large jumps in the timespecs
> returned by clock_gettime().
> 
> Using a Intel i5 with a  "Intel Corporation Ethernet Connection I217-V
> (rev 05)"
> network card around 100-200 calls to clock_gettime() in a loop are enough.

This uses the e1000e driver, right?  That driver has a work around for
a HW bug when reading the time, but it is restricted to 82574/82583
devices:

drivers/net/ethernet/intel/e1000e/netdev.c:e1000e_cyclecounter_read():
		/* errata for 82574/82583 possible bad bits read from SYSTIMH/L
		 * check to see that the time is incrementing at a reasonable
		 * rate and is a multiple of incvalue
		 */

Maybe the i217 is also affected?  You could try enabling this work
around for i217 as well.

>     struct timespec oldts;
>     struct timespec newts;
>     clock_gettime(clkid, &oldts);
> 
>     for(;;)
>     {
>        clock_gettime(clkid, &newts);
>        time_t delta = newts.tv_sec - oldts.tv_sec;
>        oldts = newts;
>        assert(delta >= 0);
>        assert(delta <= 1);

Here it would help to see the values of oldts and newts when the
assertion fails.

>     }
> }

This sounds like the same old hw bug.  I would ask intel and/or on the
e1000 list.

Thanks,
Richard

[Linuxptp-users] Polling ptp clock not allowed?

[frank <sou...@gm...>]

Hi,

i have an application which polls ptp clock and tries to execute some
activitites at specific times.

During printf debugging I have seen large jumps in the timespecs
returned by clock_gettime().

Using a Intel i5 with a  "Intel Corporation Ethernet Connection I217-V
(rev 05)"
network card around 100-200 calls to clock_gettime() in a loop are enough.

I have stripped my problem down to the following code, which fails if
between two inner loops the ptp time changes by more than a second:

Is this expected?

kind regards
  Frank

Using linuxptp-1.6 and kernel 3.16

$ phc2sys -v
1.6-00005-g8a79480

$ uname -v
#1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)


#include <time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <assert.h>

int main(int argc, char *argv[])
{
    static const int CLOCKFD = 3;
    int fd = open("/dev/ptp0", O_RDONLY);
    clockid_t clkid = ((~(clockid_t)(fd) << 3) | CLOCKFD);

    struct timespec oldts;
    struct timespec newts;
    clock_gettime(clkid, &oldts);

    for(;;)
    {
       clock_gettime(clkid, &newts);
       time_t delta = newts.tv_sec - oldts.tv_sec;
       oldts = newts;
       assert(delta >= 0);
       assert(delta <= 1);

    }
}