Re: [Linuxptp-users] Synchronization fault with stmmac

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

On Thu, 2014-03-20 at 16:27 +0100, Mohamed Belaouad wrote:
> 
> > On Wed, 2014-03-19 at 10:46 +0100, Richard Cochran wrote:
> > > On Wed, Mar 19, 2014 at 09:54:00AM +0100, Mohamed Belaouad wrote:
> > > 
> > > > From the first test I did (running ptp4l to get the PC time then
> > > > stopping it), the board ptp time seems to run slower than the PC
> > > > time. While 5 minutes elapsed on the PC, 2/3min only do on the
> > > > board.
> > > 
> > > You can easily test the clock speed like this.
> > > 
> > >     testptp -g
> > >     sleep 60
> > >     testptp -g
> > > 
> > > Then, see if 60 seconds elapsed.
> > > 
> 
> This is now working correctly after setting the correct frequencies in the driver. There is no more synchronization fault :).
> 
> > 
> > Also test with various adjustment frequencies applied, I don't know
> > exact commands here, but you can do something like:
> > 
> > adjust frequency by 50% (500 million ppb)
> > set clock to system time or 0
> > get time
> > sleep some amount of time
> > get time
> > 
> > then check to see if the expected time adjusted by the frequency change
> > has actually passed.
> > 
> > In this way, you can see whether frequency adjustment is working right,
> > since if you modify the clock frequency by say.. 1.5x, then you should
> > see roughly an equivalent decrease in the time different on clock, of
> > "time difference / 1.5".
> > 
> > Please do these experiments using testptp first and see if things make
> > sense. This will help limit the scope of the tests so you can see what
> > parts might be failing.
> > 
> > I would suggest attempting to set the ppb to the maximum value your
> > driver allows as well, to check to see if the adjustment is overflowing
> > somehow.
> 
> The driver implementation is not checking the max frequency adjustment...
> I still did some tests and strange enough there is a value change to -32,768,000 when passing ppb greater than 32,768,000. Also, the value saturates to -32,768,000 with ppb lesser than -32,768,000.
> So I am forced to use values between [-32,768,000 | 32,768,000]. I guess your test suggestion will pass once I get through this.
> 
> Could you please shed some light on that? Is it something related with the kernel ptp clock driver? I did not find 
> 

Your driver does have to fill in the maximum value to register to the
ptp core, and ptp core handles checking, but maybe there is a bug
regarding that in your kernel... It should be keeping the sign the same
when it clips the maximum value, however.

It should be changing it to the max adjust, non negative.

Look at your driver, where you set the max_adj field of ptp_caps.

Thanks,
Jake


> 
> The value received by the driver is the one after ppb:
> TEST PTP ADJ FREQ:
> # ./testptp -d /dev/ptp0 -f 32767999
> [ADJ_FREQ 0] ppb:32767999
> frequency adjustment okay
> # ./testptp -d /dev/ptp0 -f 32768000
> [ADJ_FREQ 0] ppb:-32768000
> frequency adjustment okay
> # ./testptp -d /dev/ptp0 -f -32768000
> [ADJ_FREQ 0] ppb:-32768000
> frequency adjustment okay
> # ./testptp -d /dev/ptp0 -f -32768001
> [ADJ_FREQ 0] ppb:-32768000
> frequency adjustment okay
> 
> Thanks,
> Mohamed