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