Many thanks Richard. Follow up:
>Well, there is a driver bug. There is a fix upstream, but your old
>4.2 kernel lacks the fix. You can either upgrade your kernel or
>back port the fix.
Imagine that. An actual error log that describes the problem!
Upgrading completely could compromise a very stable platform for other
tasks this stack executes.
Which version has the fix??
>You can set it to 'true'
>using the GRANDMASTER_SETTINGS_NP management message.
Does this have to be done each time with pmc or can it be in the ptp4l conf
file??
If you are curious, follow the link, you'll see one of our two sister
vehicles.
https://images.marinetechnologynews.com/images/maritime/deployment-board-alliance-73812.jpg
Marco
On Thu, Aug 30, 2018 at 12:50 PM Richard Cochran <richardcoch...@gmail.com>
wrote:
> On Thu, Aug 30, 2018 at 12:59:12AM +0200, TheMazzim M wrote:
> > 2) The igb driver is loaded for the NIC on this PC104. As a result, the
> ptp
> > module is loaded as well.
>
> You can believe the ethtool output.
>
> > As I understand, this is further evidence that
> > hardware time stamping is supported?? Yet, the kernel (question 1)
> appears
> > not to be compliant?? What am I missing?
>
> No, your kernel configuration is okay.
>
> > After some time, I see the following "error". What is this trying to tell
> > me??
> ...
> > *ptp4l[7816.367]: increasing tx_timestamp_timeout may correct this issue,
> > but it is likely caused by a driver bug*
>
> Well, there is a driver bug. There is a fix upstream, but your old
> 4.2 kernel lacks the fix. You can either upgrade your kernel or
> back port the fix.
>
> > 4) NOTE: As instructed by the Deployment Guide, since I would ultimately
> > like hardware timestamping, I also issue the phc2sys as
> >
> > *phc2sys -m -c eth3 -s CLOCK_REALTIME -w*
> >
> > Which outputs:
> > *phc2sys[20583.688]: p4p1 sys offset -32 s2 freq -84541 delay
> 8096*
> > *phc2sys[20584.688]: p4p1 sys offset -45 s2 freq -84564 delay
> 8096*
> > *phc2sys[20585.688]: p4p1 sys offset -32 s2 freq -84565 delay
> 8016*
>
> ...
>
> > What are the units of sys offset??
>
> nanoseconds.
>
> > Does this seem like a "healthy"
> > situation between ptp4l and phc2sys??
>
> Looks okay.
>
> > 5) The PTP time code is needed by custom A/D devices that time tag each
> > sample with the PTP time. I've discovered that they do not remove the
> UTC
> > offset (37 seconds) as reported by the PTP sync packets when I use
> hardware
> > timestamping. This problem disappears if I use software timestamping.
> The
> > manufacturer of the A/D's would look into this "bug". If I wanted to
> > continue to use hardware timestamps, could I force a UTC_OFFSET of 0
> > seconds in the ptp4l config file.???
>
> You can set the TAI-UTC offset to zero if that suits your needs.
> After all, you have a closed environment.
>
> The A/D slaves might be paying attention to the currentUtcOffsetValid
> field in the Announce message from your GM. By default, when ptp4l is
> a GM, that flag will be cleared to false. You can set it to 'true'
> using the GRANDMASTER_SETTINGS_NP management message.
>
> Thanks,
> Richard
>
------------------------------------------------------------------------------
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
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
