linuxptp-devel

[Linuxptp-devel] addition of a "get frequency" op?

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

Hi Richard (and anyone else who might care),

I have thinking it might be worth adding an extra (optional) operation
for ptp devices which allows querying the current adjusted frequency
value. This could be useful for debugging purposes, since there is no
way today to obtain this information from the device.

I was thinking about hacking up a patch for this, but wanted to see if
you thought this was a good idea first. I also wasn't sure exactly where
best to provide the operation, since there is no equivalent "get
frequency" on the clock.

Thanks,
Jake

Re: [Linuxptp-devel] addition of a "get frequency" op?

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

On Fri, Jun 06, 2014 at 06:29:56PM +0000, Keller, Jacob E wrote:
> Hi Richard (and anyone else who might care),
> 
> I have thinking it might be worth adding an extra (optional) operation
> for ptp devices which allows querying the current adjusted frequency
> value. This could be useful for debugging purposes, since there is no
> way today to obtain this information from the device.

But we already have this. Calling clock_adjtime with a cleared struct
timex will return this in the 'freq' field. Linuxptp uses a wrapper
function, clockadj_get_freq.

Or did you mean something else?

Thanks,
Richard

Re: [Linuxptp-devel] addition of a "get frequency" op?

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

On Sat, 2014-06-07 at 17:39 +0200, Richard Cochran wrote:
> On Fri, Jun 06, 2014 at 06:29:56PM +0000, Keller, Jacob E wrote:
> > Hi Richard (and anyone else who might care),
> > 
> > I have thinking it might be worth adding an extra (optional) operation
> > for ptp devices which allows querying the current adjusted frequency
> > value. This could be useful for debugging purposes, since there is no
> > way today to obtain this information from the device.
> 
> But we already have this. Calling clock_adjtime with a cleared struct
> timex will return this in the 'freq' field. Linuxptp uses a wrapper
> function, clockadj_get_freq.
> 
> Or did you mean something else?
> 
> Thanks,
> Richard

Can this be done on the ptp clock device? If so, this would be fine :)

Thanks,
Jake

Re: [Linuxptp-devel] addition of a "get frequency" op?

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

On Mon, Jun 09, 2014 at 10:10:56PM +0000, Keller, Jacob E wrote:
> 
> Can this be done on the ptp clock device? If so, this would be fine :)

Yes, using the FD_TO_CLOCKID macro.
See phc_open() in phc.c.

Thanks,
Richard

Re: [Linuxptp-devel] addition of a "get frequency" op?

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

On Tue, 2014-06-10 at 06:24 +0200, Richard Cochran wrote:
> On Mon, Jun 09, 2014 at 10:10:56PM +0000, Keller, Jacob E wrote:
> > 
> > Can this be done on the ptp clock device? If so, this would be fine :)
> 
> Yes, using the FD_TO_CLOCKID macro.
> See phc_open() in phc.c.
> 
> Thanks,
> Richard

Excellent, thanks!

Regards,
Jake

Re: [Linuxptp-devel] addition of a "get frequency" op?

[Dale S. <ds...@us...>]

Isn't this basically the observedParentClockPhaseChangeRate in the parent
data set? (but with whacky units)

I know linuxptp doesn't implement this, along with
observedParentOffsetScaledLogVariance.  Should it?

-Dale



On Tue, Jun 10, 2014 at 11:36 AM, Keller, Jacob E <jac...@in...>
wrote:

> On Tue, 2014-06-10 at 06:24 +0200, Richard Cochran wrote:
> > On Mon, Jun 09, 2014 at 10:10:56PM +0000, Keller, Jacob E wrote:
> > >
> > > Can this be done on the ptp clock device? If so, this would be fine :)
> >
> > Yes, using the FD_TO_CLOCKID macro.
> > See phc_open() in phc.c.
> >
> > Thanks,
> > Richard
>
> Excellent, thanks!
>
> Regards,
> Jake
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Linuxptp-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>

Re: [Linuxptp-devel] addition of a "get frequency" op?

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

On Tue, Jun 10, 2014 at 12:11:25PM -0400, Dale Smith wrote:
> Isn't this basically the observedParentClockPhaseChangeRate in the parent
> data set? (but with whacky units)

Hm, I thought that was the observed difference *after*
adjustment. If you are right, then it should be easy to provide this
value.

> I know linuxptp doesn't implement this, along with
> observedParentOffsetScaledLogVariance.  Should it?

Well, this is an optional calculation that seems to me to be just busy
work. What is the point of measuring this anyhow?

Thanks,
Richard

Re: [Linuxptp-devel] addition of a "get frequency" op?

[Dale S. <ds...@us...>]

On Tue, Jun 10, 2014 at 2:57 PM, Richard Cochran <ric...@gm...>
wrote:

> On Tue, Jun 10, 2014 at 12:11:25PM -0400, Dale Smith wrote:
> > Isn't this basically the observedParentClockPhaseChangeRate in the parent
> > data set? (but with whacky units)
>
> Hm, I thought that was the observed difference *after*
> adjustment. If you are right, then it should be easy to provide this
> value.
>

Good question.  I don't know.


> > I know linuxptp doesn't implement this, along with
> > observedParentOffsetScaledLogVariance.  Should it?
>
> Well, this is an optional calculation that seems to me to be just busy
> work. What is the point of measuring this anyhow?
>

I'm no math wizard, but I believe this is basically a metric of how noisy
the clock is.

The reason it is needed is that the specs say you need to report BOTH the
phase
change rate and the variance. (in section 7.6.4.2 parentDS.parentStats).

My question above (Should it?) is really: is it worth the hassle of
implementing and
calculating the variance to get the more useful (IMHO) phase change rate?


-Dale

Re: [Linuxptp-devel] addition of a "get frequency" op?

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

On Tue, Jun 10, 2014 at 03:29:35PM -0400, Dale Smith wrote:
> On Tue, Jun 10, 2014 at 2:57 PM, Richard Cochran <ric...@gm...>
> wrote:
> > On Tue, Jun 10, 2014 at 12:11:25PM -0400, Dale Smith wrote:
> > > Isn't this basically the observedParentClockPhaseChangeRate in the parent
> > > data set? (but with whacky units)
> >
> > Hm, I thought that was the observed difference *after*
> > adjustment. If you are right, then it should be easy to provide this
> > value.
> 
> Good question.  I don't know.

> My question above (Should it?) is really: is it worth the hassle of
> implementing and
> calculating the variance to get the more useful (IMHO) phase change rate?

What exactly is the phase change rate supposed to be useful for? If we
knew that, perhaps we could figure out what value it should have :).

In 7.6.4.4, it's described as a phase change rate (i.e. frequency
offset as per 3.1.25) of the parent's clock as measured by the slave
clock. But compared to what? To another reference clock, the
uncorrected slave clock, or adjusted slave clock (with or without
currently running phase correction)?

-- 
Miroslav Lichvar

Re: [Linuxptp-devel] addition of a "get frequency" op?

[Dale S. <ds...@us...>]

On Wed, Jun 11, 2014 at 7:51 AM, Miroslav Lichvar <mli...@re...>
wrote:

> On Tue, Jun 10, 2014 at 03:29:35PM -0400, Dale Smith wrote:
> > On Tue, Jun 10, 2014 at 2:57 PM, Richard Cochran <
> ric...@gm...>
> > wrote:
> > > On Tue, Jun 10, 2014 at 12:11:25PM -0400, Dale Smith wrote:
> > > > Isn't this basically the observedParentClockPhaseChangeRate in the
> parent
> > > > data set? (but with whacky units)
> > >
> > > Hm, I thought that was the observed difference *after*
> > > adjustment. If you are right, then it should be easy to provide this
> > > value.
> >
> > Good question.  I don't know.
>
> > My question above (Should it?) is really: is it worth the hassle of
> > implementing and
> > calculating the variance to get the more useful (IMHO) phase change rate?
>
> What exactly is the phase change rate supposed to be useful for? If we
> knew that, perhaps we could figure out what value it should have :).
>
> In 7.6.4.4, it's described as a phase change rate (i.e. frequency
> offset as per 3.1.25) of the parent's clock as measured by the slave
> clock. But compared to what? To another reference clock, the
> uncorrected slave clock, or adjusted slave clock (with or without
> currently running phase correction)?
>

Compared to the uncorrected slave clock.  Although it's worded as the phase
change rate
of the master, it's effectively a measure of the slave.  It's basically the
freq adjustment value
scaled to the right units (2^40).

-Dale