PTP_PEROUT_REQUEST and clock stepping

PTP_PEROUT_REQUEST and clock stepping

[Daniel Glöckner]

Hi,
I was wondering how periodic output is supposed to behave if the clock
is stepped from a time after ptp_perout_request.start to a time before
ptp_perout_request.start. Should the periodic output stop until .start
is reached again or should it ignore .start once periodic output has
started?

Best regards,

  Daniel


-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

Re: PTP_PEROUT_REQUEST and clock stepping

[Richard Cochran]

On Wed, Sep 10, 2014 at 06:16:37PM +0200, Daniel Glöckner wrote:
> Hi,
> I was wondering how periodic output is supposed to behave if the clock
> is stepped from a time after ptp_perout_request.start to a time before
> ptp_perout_request.start.

I would say the result is undefined.

User space should first stop the periodic output, then reprogram the
clock, then restart the periodic output. Anything else makes no sense
at all.

Thanks,
Richard

Re: PTP_PEROUT_REQUEST and clock stepping

[Daniel Glöckner]

On Wed, Sep 10, 2014 at 07:26:20PM +0200, Richard Cochran wrote:
> On Wed, Sep 10, 2014 at 06:16:37PM +0200, Daniel Glöckner wrote:
> > I was wondering how periodic output is supposed to behave if the clock
> > is stepped from a time after ptp_perout_request.start to a time before
> > ptp_perout_request.start.
> 
> I would say the result is undefined.
> 
> User space should first stop the periodic output, then reprogram the
> clock, then restart the periodic output. Anything else makes no sense
> at all.

But then the PTP demon has to be responsible for configuring the periodic
outputs as well.

IMHO there is no use for a .start value > .period. It is good for defining
the phase of the periodic output but is just annoying if you want to have
the periodic output running all the time. Only a small fraction of people
using periodic outputs will want to schedule the start of the signal at
a specific time in the future and only a fraction of those will use a
.period value that is so small that they can't use a timer to configure
the periodic output within .period/2 before the desired start time.

Best regards,

  Daniel

-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

Re: PTP_PEROUT_REQUEST and clock stepping

[Christian Riesch]

Hi Daniel,

On Thu, Sep 11, 2014 at 11:52 AM, Daniel Glöckner <dg@emlix.com> wrote:
> On Wed, Sep 10, 2014 at 07:26:20PM +0200, Richard Cochran wrote:
>> On Wed, Sep 10, 2014 at 06:16:37PM +0200, Daniel Glöckner wrote:
>> > I was wondering how periodic output is supposed to behave if the clock
>> > is stepped from a time after ptp_perout_request.start to a time before
>> > ptp_perout_request.start.
>>
>> I would say the result is undefined.
>>
>> User space should first stop the periodic output, then reprogram the
>> clock, then restart the periodic output. Anything else makes no sense
>> at all.
>
> But then the PTP demon has to be responsible for configuring the periodic
> outputs as well.

I guess yes, but is that a problem?

> IMHO there is no use for a .start value > .period. It is good for defining

There is, for the small fraction of people you note below. But you are
talking about PTP_PEROUT_REQUEST here, right?

> the phase of the periodic output but is just annoying if you want to have
> the periodic output running all the time.

How about PTP_ENABLE_PPS? Is this the ptp clock feature you are looking for?

> Only a small fraction of people
> using periodic outputs will want to schedule the start of the signal at
> a specific time in the future and only a fraction of those will use a
> .period value that is so small that they can't use a timer to configure
> the periodic output within .period/2 before the desired start time.

What timer?

Regards,
Christian

Re: PTP_PEROUT_REQUEST and clock stepping

[Christian Riesch]

On Thu, Sep 11, 2014 at 11:52 AM, Daniel Glöckner <dg@emlix.com> wrote:
> Only a small fraction of people
> using periodic outputs will want to schedule the start of the signal at
> a specific time in the future and only a fraction of those will use a
> .period value that is so small that they can't use a timer to configure
> the periodic output within .period/2 before the desired start time.

Ok, I got it now. So you are suggesting to change the behavior of
PTP_PEROUT_REQUEST, aren't you? And break existing applications?
Christian

Re: PTP_PEROUT_REQUEST and clock stepping

[Richard Cochran]

On Fri, Sep 12, 2014 at 08:24:49AM +0200, Christian Riesch wrote:
> On Thu, Sep 11, 2014 at 11:52 AM, Daniel Glöckner <dg@emlix.com> wrote:
> > Only a small fraction of people
> > using periodic outputs will want to schedule the start of the signal at
> > a specific time in the future and only a fraction of those will use a
> > .period value that is so small that they can't use a timer to configure
> > the periodic output within .period/2 before the desired start time.
> 
> Ok, I got it now. So you are suggesting to change the behavior of
> PTP_PEROUT_REQUEST, aren't you? And break existing applications?
> Christian

I think he wants the periodic output to continue at the same phase and
frequency, even when you reset the clock time.

However, this is impossible to acheive because the hardware does not
support it.

Thanks,
Richard

Re: PTP_PEROUT_REQUEST and clock stepping

[Daniel Glöckner]

On 09/12/14 08:33, Richard Cochran wrote:
> On Fri, Sep 12, 2014 at 08:24:49AM +0200, Christian Riesch wrote:
>> Ok, I got it now. So you are suggesting to change the behavior of
>> PTP_PEROUT_REQUEST, aren't you? And break existing applications?
>> Christian

I don't want to change the API. I would just have preferred a slightly
different one.

> I think he wants the periodic output to continue at the same phase and
> frequency, even when you reset the clock time.
> 
> However, this is impossible to acheive because the hardware does not
> support it.

You mean the hardware that you know of that currently exists.

I just think it is wrong to place the burden of stopping and starting
the periodic output on the PTP demon. The kernel knows when clock_adjtime
and clock_settime are called and it also knows which periodic outputs
are enabled and how they are configured. We just have to decide on the
correct behavior (respect .start vs. ignore .start once running) to be
implemented.

Taking the Intel i210 as an example, the third option (doing nothing)
would lead to the following behavior:

 - If the clock is stepped back, the periodic output stops until the
   clock reaches the point when it was adjusted.

 - If the clock is stepped forward, the periodic output oscillates at
   62,5 MHz to catch up.

Best regards,

  Daniel

-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

Re: PTP_PEROUT_REQUEST and clock stepping

[Richard Cochran]

On Fri, Sep 12, 2014 at 01:40:32PM +0200, Daniel Glöckner wrote:
> You mean the hardware that you know of that currently exists.

Yes, that is the hardware we support. I am sorry that I don't know how
to support mythical hardware.
 
> I just think it is wrong to place the burden of stopping and starting
> the periodic output on the PTP demon.

I think it is the right place.

> The kernel knows when clock_adjtime
> and clock_settime are called and it also knows which periodic outputs
> are enabled and how they are configured. We just have to decide on the
> correct behavior (respect .start vs. ignore .start once running) to be
> implemented.

The only reasonable actions for kernel would be to either stop all
periodic outputs, or to just do nothing.
 
> Taking the Intel i210 as an example, the third option (doing nothing)
> would lead to the following behavior:
> 
>  - If the clock is stepped back, the periodic output stops until the
>    clock reaches the point when it was adjusted.
> 
>  - If the clock is stepped forward, the periodic output oscillates at
>    62,5 MHz to catch up.

That is a good example of "the results are undefined".

So, how would you reprogram the i210 to keep the period output
continuous?

Thanks,
Richard

Re: PTP_PEROUT_REQUEST and clock stepping

[Daniel Glöckner]

On 09/12/14 16:40, Richard Cochran wrote:
>> Taking the Intel i210 as an example, the third option (doing nothing)
>> would lead to the following behavior:
>>
>>  - If the clock is stepped back, the periodic output stops until the
>>    clock reaches the point when it was adjusted.
>>
>>  - If the clock is stepped forward, the periodic output oscillates at
>>    62,5 MHz to catch up.
> 
> That is a good example of "the results are undefined".
> 
> So, how would you reprogram the i210 to keep the period output
> continuous?

0. I'm assuming here that new_time >= start
1. stop the periodic output via TSAUXC
2. set the clock via SYSTIM* to new_time
3a. if (new_time - start) % period < period / 2
	set the TRGTTIM* regs to new_time - (new_time - start) % period
3b. else
	set the TRGTTIM* regs to new_time - (new_time - start) % period
	                                  + period
4. start the periodic output via TSAUXC

Best Regards,

  Daniel

-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

Re: PTP_PEROUT_REQUEST and clock stepping

[Richard Cochran]

On Fri, Sep 12, 2014 at 05:19:29PM +0200, Daniel Glöckner wrote:
> 0. I'm assuming here that new_time >= start

Feel free to submit a patch, but please be sure to handle the case
where (new_time < start) as well. In addition, it can happen that
abs(new_time-start) < X, where X is the time it takes to reprogramm
the signal.

Thanks,
Richard