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

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Sunday, February 26, 2017 2:53 AM
> To: Norbert Lange <nol...@gm...>
> Cc: Keller, Jacob E <jac...@in...>; linuxptp-
> us...@li...
> Subject: Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L
> 
> On Thu, Feb 23, 2017 at 11:20:26AM +0100, Norbert Lange wrote:
> > Yeah, I seen that matrix, and both NICs are on that list. Still have
> > some rather serious issues, one is completely useless (82579LM, e1000e
> > driver) and the other (i354, igb driver) apparently wraps the timer
> > very 18 minutes, losing their master role.
> 
> Looks like you aren't the only one with this issue:
> 
>   https://www.spinics.net/lists/kernel/msg2446767.html
> 
> So it does look like a bug where driver the driver selects the wrong
> clock values.
> 
> Cheers,
> Richard

Yep that's what it sounded like. Glad that appears resolved now.

Regards,
Jake

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

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

On Thu, Feb 23, 2017 at 11:20:26AM +0100, Norbert Lange wrote:
> Yeah, I seen that matrix, and both NICs are on that list. Still have
> some rather serious issues, one is completely useless (82579LM, e1000e
> driver) and the other (i354, igb driver) apparently wraps the timer
> very 18 minutes, losing their master role.

Looks like you aren't the only one with this issue:

  https://www.spinics.net/lists/kernel/msg2446767.html

So it does look like a bug where driver the driver selects the wrong
clock values.

Cheers,
Richard

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

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

> -----Original Message-----
> From: Norbert Lange [mailto:nol...@gm...]
> Sent: Thursday, February 23, 2017 2:20 AM
> To: Richard Cochran <ric...@gm...>
> Cc: Keller, Jacob E <jac...@in...>; linuxptp-
> us...@li...
> Subject: Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L
> 
> Yeah, I seen that matrix, and both NICs are on that list. Still have
> some rather serious issues, one is completely useless (82579LM, e1000e
> driver) and the other (i354, igb driver) apparently wraps the timer
> very 18 minutes, losing their master role.
> 
> Kind regards,
> Norbert
> 

The igb driver is likely bugged, it should be maintaining a separate "real counter" and the internal hardware counter wrapping should be hidden from the user.

Most likely in all these cases you have hardware the driver recognizes, and assumes a certain hardware frequency, but the software was not updated for the new frequency rate, so it is assuming a different internal rate which results in these problems.

Hopefully one of the e1000e maintainers will be able to give more insight on the intel-wired-lan list.

Thanks,
Jake

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

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

On Thu, Feb 23, 2017 at 11:20:26AM +0100, Norbert Lange wrote:
> Yeah, I seen that matrix, and both NICs are on that list. Still have
> some rather serious issues, one is completely useless (82579LM, e1000e
> driver) and the other (i354, igb driver) apparently wraps the timer
> very 18 minutes, losing their master role.

Please take a closer look.  Neither the 82579 nor the i354 are
mentioned on that page.

Thanks,
Richard

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

[Norbert L. <nol...@gm...>]

Yeah, I seen that matrix, and both NICs are on that list. Still have
some rather serious issues, one is completely useless (82579LM, e1000e
driver) and the other (i354, igb driver) apparently wraps the timer
very 18 minutes, losing their master role.

Kind regards,
Norbert

2017-02-23 11:13 GMT+01:00 Richard Cochran <ric...@gm...>:
> On Thu, Feb 23, 2017 at 10:18:40AM +0100, Norbert Lange wrote:
>> ptp doesnt work on any intel hardware, this scientific proof was based
>> on samplesize 2. Sent another mail to that list.
>> Just out of curiosity, what hardware is this tested on, and verified
>> to work as master?
>
> See:
>
> http://linuxptp.sourceforge.net/
>
> 5.3 Driver Support Matrix
>
>
> Thanks,
> Richard

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

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

On Thu, Feb 23, 2017 at 10:18:40AM +0100, Norbert Lange wrote:
> ptp doesnt work on any intel hardware, this scientific proof was based
> on samplesize 2. Sent another mail to that list.
> Just out of curiosity, what hardware is this tested on, and verified
> to work as master?

See:

http://linuxptp.sourceforge.net/

5.3 Driver Support Matrix


Thanks,
Richard

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

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

> ptp doesnt work on any intel hardware

Probably with the e1000 driver. I have an Intel i350 with the igbx driver. I'm using it since 4 years as both master and slave and I have never had any issue. 


-----Original Message-----
From: Norbert Lange [mailto:nol...@gm...] 
Sent: 23 February 2017 10:19
To: Keller, Jacob E
Cc: lin...@li...
Subject: Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

ptp doesnt work on any intel hardware, this scientific proof was based on samplesize 2. Sent another mail to that list.
Just out of curiosity, what hardware is this tested on, and verified to work as master?

Kind regards,
Norbert

2017-02-23 0:16 GMT+01:00 Keller, Jacob E <jac...@in...>:
>
>
>> -----Original Message-----
>> From: Norbert Lange [mailto:nol...@gm...]
>> Sent: Wednesday, February 22, 2017 1:20 PM
>> To: Keller, Jacob E <jac...@in...>
>> Cc: Richard Cochran <ric...@gm...>; linuxptp- 
>> us...@li...
>> Subject: Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 
>> 82579L
>>
>> I sent a mail to int...@li..., since the other is 
>> for out-of-tree drivers. Still waiting approval.
>> I am not so sure about a driver bug, all those intel chips are rather 
>> similiar. Will try to read out the hardware PTP clock directly.
>>
>
> Ok that should still hit the right person. Driver bug, because each hardware runs at different clock rates and the likely problem is that the software is using the wrong values to take that into account.
>
> Thanks,
> Jake
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

[Norbert L. <nol...@gm...>]

ptp doesnt work on any intel hardware, this scientific proof was based
on samplesize 2. Sent another mail to that list.
Just out of curiosity, what hardware is this tested on, and verified
to work as master?

Kind regards,
Norbert

2017-02-23 0:16 GMT+01:00 Keller, Jacob E <jac...@in...>:
>
>
>> -----Original Message-----
>> From: Norbert Lange [mailto:nol...@gm...]
>> Sent: Wednesday, February 22, 2017 1:20 PM
>> To: Keller, Jacob E <jac...@in...>
>> Cc: Richard Cochran <ric...@gm...>; linuxptp-
>> us...@li...
>> Subject: Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 82579L
>>
>> I sent a mail to int...@li..., since the other is
>> for out-of-tree drivers. Still waiting approval.
>> I am not so sure about a driver bug, all those intel chips are rather
>> similiar. Will try to read out the hardware PTP clock directly.
>>
>
> Ok that should still hit the right person. Driver bug, because each hardware runs at different clock rates and the likely problem is that the software is using the wrong values to take that into account.
>
> Thanks,
> Jake
>

Re: [Linuxptp-users] PTP Clock completely wrong on an Intel 82579L

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

> -----Original Message-----
> From: Norbert Lange [mailto:nol...@gm...]
> Sent: Wednesday, February 22, 2017 1:20 PM
> To: Keller, Jacob E <jac...@in...>
> Cc: Richard Cochran <ric...@gm...>; linuxptp-
> us...@li...
> Subject: Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 82579L
> 
> I sent a mail to int...@li..., since the other is
> for out-of-tree drivers. Still waiting approval.
> I am not so sure about a driver bug, all those intel chips are rather
> similiar. Will try to read out the hardware PTP clock directly.
> 

Ok that should still hit the right person. Driver bug, because each hardware runs at different clock rates and the likely problem is that the software is using the wrong values to take that into account.

Thanks,
Jake

Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 82579L

[Norbert L. <nol...@gm...>]

I sent a mail to int...@li..., since the other is
for out-of-tree drivers. Still waiting approval.
I am not so sure about a driver bug, all those intel chips are rather
similiar. Will try to read out the hardware PTP clock directly.

2017-02-22 20:09 GMT+01:00 Keller, Jacob E <jac...@in...>:
>> -----Original Message-----
>> From: Richard Cochran [mailto:ric...@gm...]
>> Sent: Wednesday, February 22, 2017 5:49 AM
>> To: Norbert Lange <nol...@gm...>
>> Cc: lin...@li...
>> Subject: Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 82579L
>>
>> On Wed, Feb 22, 2017 at 01:22:33PM +0100, Norbert Lange wrote:
>> > The Hardware is an Intel 82579L, soldered on the motherboard. Any idea
>> > if this is a software issue, a systematic hardware bug or something
>> > like a wrong reference clock?
>>
>> Could be a driver issue.  I took a brief look at the e1000e driver,
>> and it doesn't seem to specifically handle the 82579 WRT ptp.  I would
>> take this up with Intel, or try the e1000-devel list.
>>
>> Thanks,
>> Richard
>
> Yes, please forward as specific details as you can to the e1000-devel list, and the correct person should notice there. It sounds like a driver bug, though I dont really know the e1000e driver very well.
>
> Thanks,
> Jake
>
>

Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 82579L

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

> -----Original Message-----
> From: Richard Cochran [mailto:ric...@gm...]
> Sent: Wednesday, February 22, 2017 5:49 AM
> To: Norbert Lange <nol...@gm...>
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 82579L
> 
> On Wed, Feb 22, 2017 at 01:22:33PM +0100, Norbert Lange wrote:
> > The Hardware is an Intel 82579L, soldered on the motherboard. Any idea
> > if this is a software issue, a systematic hardware bug or something
> > like a wrong reference clock?
> 
> Could be a driver issue.  I took a brief look at the e1000e driver,
> and it doesn't seem to specifically handle the 82579 WRT ptp.  I would
> take this up with Intel, or try the e1000-devel list.
> 
> Thanks,
> Richard

Yes, please forward as specific details as you can to the e1000-devel list, and the correct person should notice there. It sounds like a driver bug, though I dont really know the e1000e driver very well.

Thanks,
Jake
 

Re: [Linuxptp-users] PTP Clock completely wrong on a Intel 82579L

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

On Wed, Feb 22, 2017 at 01:22:33PM +0100, Norbert Lange wrote:
> The Hardware is an Intel 82579L, soldered on the motherboard. Any idea
> if this is a software issue, a systematic hardware bug or something
> like a wrong reference clock?

Could be a driver issue.  I took a brief look at the e1000e driver,
and it doesn't seem to specifically handle the 82579 WRT ptp.  I would
take this up with Intel, or try the e1000-devel list.

Thanks,
Richard

[Linuxptp-users] PTP Clock completely wrong on a Intel 82579L

[Norbert L. <nol...@gm...>]

Hello,

I tried enabling PTP in a local Network, there where just nonsensical
value all the time.
Looking with Wireshark at the communication, the master sends out a
"Followup" Packet every second (very precisely), which contains the
internal time.

This time increases almost by 4 seconds every time.

The Hardware is an Intel 82579L, soldered on the motherboard. Any idea
if this is a software issue, a systematic hardware bug or something
like a wrong reference clock?

OS is an actual Linux Debian 9 AMD64 with Linux 4.9

Kind Regards,
Norbert

Re: [Linuxptp-users] Hardware recommendation

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

On Sun, Feb 12, 2017 at 10:19:38PM +0100, Jan Deinhard wrote:
> I am looking for a low-budget (< 150 EUR) network interface card
> (preferable PCIe) with reasonable hardware support for PTP.
> 
> Can someone recommend a card?

Take a look at the Intel I210-T1.  I can recommend it, and I saw on
alternate.de for 82 EUR.

Cheers,
Richard

[Linuxptp-users] Hardware recommendation

[Jan D. <jan...@gm...>]

Hi,

I am looking for a low-budget (< 150 EUR) network interface card
(preferable PCIe) with reasonable hardware support for PTP.

Can someone recommend a card?

Best regards
Jan

Re: [Linuxptp-users] timemaster and phc2sys

[FUSTE E. <emm...@th...>]

Le 10/02/2017 à 09:50, Miroslav Lichvar a écrit :
> On Thu, Feb 09, 2017 at 06:26:25PM +0100, FUSTE Emmanuel wrote:
>> Hello,
>>
>> Why timemaster launch phc2sys with the "-r" option ?
>>
>> It could be a complete misunderstanding of the doc/code on my side.
>> But as the goal is to pass the measurement to ntpd via the ntpshm pseudo
>> servo to let ntpd do the system clock adjustments and updates, "-r" is
>> irrelevant and will step on/conflict with ntpd time adjustments/updates.
> I can see why this could be confusing.
>
> The -r option enables synchronization of the system clock to the PTP
> clock, but phc2sys doesn't care which servo is selected. With the
> ntpshm servo, it's another process controlling the clock instead of
> phc2sys. If timemaster started phc2sys without -r, it wouldn't try to
> synchronize the system clock and the ntpshm servo wouldn't write any
> samples for ntpd.
>
Ok, I dig deeper into the code and the magic is in the SERVO_UNLOCKED 
and zero return from ntpshm_sample().
And CLOCK_REALTIME is still registered as it is the clock against we are 
producing samples to be passed to ntpd/chrony.

Thank you !

Perhaps something like "With the ntpshm servo, system clock is not 
directly updated but samples against it are produced to  allow another 
process to do it." Could be added after the second phrase of the "-r" 
description in the doc/man page.

Emmanuel.

Re: [Linuxptp-users] timemaster and phc2sys

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

On Thu, Feb 09, 2017 at 06:26:25PM +0100, FUSTE Emmanuel wrote:
> Hello,
> 
> Why timemaster launch phc2sys with the "-r" option ?
> 
> It could be a complete misunderstanding of the doc/code on my side.
> But as the goal is to pass the measurement to ntpd via the ntpshm pseudo 
> servo to let ntpd do the system clock adjustments and updates, "-r" is 
> irrelevant and will step on/conflict with ntpd time adjustments/updates.

I can see why this could be confusing. 

The -r option enables synchronization of the system clock to the PTP
clock, but phc2sys doesn't care which servo is selected. With the
ntpshm servo, it's another process controlling the clock instead of
phc2sys. If timemaster started phc2sys without -r, it wouldn't try to
synchronize the system clock and the ntpshm servo wouldn't write any
samples for ntpd.

-- 
Miroslav Lichvar

[Linuxptp-users] timemaster and phc2sys

[FUSTE E. <emm...@th...>]

Hello,

Why timemaster launch phc2sys with the "-r" option ?

It could be a complete misunderstanding of the doc/code on my side.
But as the goal is to pass the measurement to ntpd via the ntpshm pseudo 
servo to let ntpd do the system clock adjustments and updates, "-r" is 
irrelevant and will step on/conflict with ntpd time adjustments/updates.

Sorry for the noise if my reasoning is faulty/incomplete.

Emmanuel.

Re: [Linuxptp-users] [Linuxptp-devel] Windows and Linux mixed network

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

On Wed, Feb 08, 2017 at 02:35:45PM -0500, Vanderpool, Clyde wrote:
> I do not know how familiar anyone is with Greyware but I used the
> connection troubleshooter and while it can ping the Linux machine it then
> shows 'Error 53: The network path was not found'.
> 
> It just doesn't seem like either machines PTP software can see that the
> other machine exists.

What PTP profile is Greyware using?  Is it possibly using unicast?

This sounds like a firewall issue.  You can use tools like wireshark
or tcpdump on both ends to see whether the packets are getting through.

Thanks,
Richard

[Linuxptp-users] Unable to obtain time stamp

[<ds...@gm...>]

Hi,

i have two systems with phytec am335x boards running.
One with kernel 3.12.30-rt45 and one with kernel 4.4.19-rt27.
I use both ethernet devices eth0 and eth1.

The synchronizing of the timestamp works.

When i start my own application which reads the ptp timestamp and runs at rt priority
i get sometimes these error messages:

[  546.816142] cpts: event pool is empty
[  546.820002] cpts: unable to obtain a time stamp
[  546.825038] cpts: event pool is empty
[  546.828895] cpts: unable to obtain a time stamp
[  546.834031] cpts: event pool is empty
[  546.837885] cpts: unable to obtain a time stamp
[  546.842884] cpts: event pool is empty


Sometimes it stops after a while and sometimes i have to reset the system.

What can i do to avoid this problem?

Thanks

DSP

Re: [Linuxptp-users] E2E Protocol

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

On Wed, Jan 25, 2017 at 03:49:48PM +0800, Hardik Gohil wrote:
> yes using dual emac mode.

That explains it.  I don't think dual emac and cpts will work together.
At least I never tested it.
 
> sorry for late response.

No problem.

Thanks,
Richard

Re: [Linuxptp-users] E2E Protocol

[Hardik G. <har...@gm...>]

On Mon, Jan 23, 2017 at 1:33 PM, Richard Cochran <ric...@gm...>
wrote:

> On Mon, Jan 23, 2017 at 09:58:22AM +0800, Hardik Gohil wrote:
> > currently I am using eth0 as peer device.
>
> And are you using dual_emac mode?
>

yes using dual emac mode.

sorry for late response.

Re: [Linuxptp-users] E2E Protocol

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

On Mon, Jan 23, 2017 at 09:58:22AM +0800, Hardik Gohil wrote:
> currently I am using eth0 as peer device.

And are you using dual_emac mode?

Thanks,
Richard

Re: [Linuxptp-users] E2E Protocol

[Hardik G. <har...@gm...>]

On Sun, Jan 22, 2017 at 11:42 PM, Richard Cochran <ric...@gm...>
wrote:

> On Thu, Jan 19, 2017 at 04:51:23PM +0800, Hardik Gohil wrote:
> >  both MAC means eth0 and eth1 you mean ? yes they are active.
>
> >                         active_slave = <0>;
>
> So is there a PTP peer device connected on slave 1 (probably =eth1) as
> well?  That would explain the messages, as the HW+driver only support
> one active PTP port.
>

currently I am using eth0 as peer device.

>
> > I am using kernel version 3.12.30-AM335x-PD15.2.1 build using YOCTO by
> > PHYTEC.
> > I think vendor kernel.
>
> If the above hint doesn't explain your issue, then your next step is
> to try a mainline linux kernel.
>
>
>

Re: [Linuxptp-users] E2E Protocol

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

On Thu, Jan 19, 2017 at 04:51:23PM +0800, Hardik Gohil wrote:
>  both MAC means eth0 and eth1 you mean ? yes they are active.
 
>                         active_slave = <0>;

So is there a PTP peer device connected on slave 1 (probably =eth1) as
well?  That would explain the messages, as the HW+driver only support
one active PTP port.

> I am using kernel version 3.12.30-AM335x-PD15.2.1 build using YOCTO by
> PHYTEC.
> I think vendor kernel.

If the above hint doesn't explain your issue, then your next step is
to try a mainline linux kernel.

Thanks,
Richard