netdev - Re: [PATCH net-next 1/3] ptp: add ability to configure duty cycle for periodic output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3f8f4f4b-b5f3-11b6-2dfe-3bce5e1b79f3@intel.com>
Date:   Thu, 16 Jul 2020 16:56:35 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        richardcochran@...il.com, yangbo.lu@....com,
        xiaoliang.yang_1@....com, po.liu@....com,
        UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next 1/3] ptp: add ability to configure duty cycle for
 periodic output



On 7/16/2020 3:09 PM, Vladimir Oltean wrote:
> On Fri, Jul 17, 2020 at 12:49:27AM +0300, Vladimir Oltean wrote:
>> On Thu, Jul 16, 2020 at 02:36:45PM -0700, Jacob Keller wrote:
>>>
>>>
>>> On 7/16/2020 2:20 PM, Vladimir Oltean wrote:
>>>> There are external event timestampers (PHCs with support for
>>>> PTP_EXTTS_REQUEST) that timestamp both event edges.
>>>>
>>>> When those edges are very close (such as in the case of a short pulse),
>>>> there is a chance that the collected timestamp might be of the rising,
>>>> or of the falling edge, we never know.
>>>>
>>>> There are also PHCs capable of generating periodic output with a
>>>> configurable duty cycle. This is good news, because we can space the
>>>> rising and falling edge out enough in time, that the risks to overrun
>>>> the 1-entry timestamp FIFO of the extts PHC are lower (example: the
>>>> perout PHC can be configured for a period of 1 second, and an "on" time
>>>> of 0.5 seconds, resulting in a duty cycle of 50%).
>>>>
>>>> A flag is introduced for signaling that an on time is present in the
>>>> perout request structure, for preserving compatibility. Logically
>>>> speaking, the duty cycle cannot exceed 100% and the PTP core checks for
>>>> this.
>>>
>>> I was thinking whether it made sense to support over 50% since in theory
>>> you could change start time and the duty cycle to specify the shifted
>>> wave over? but I guess it doesn't really make much of a difference to
>>> support all the way up to 100%.
>>>
>>
>> Only if you also support polarity, and we don't support polarity. It's
>> always high first, then low.
>>
> 
> Sorry for the imprecise statement.
> If you look at things from the perspective of the signal itself, the
> statement is correct.
> If you look at them from the perspective of the imaginary grid drawn by
> the integer multiples of the period, in the PHC's time (a digital
> counter), the correct statement would be that "it's always rising edge
> first, then falling edge".  And then the phase is just the delta between
> these 2 points of reference.
> 
> Let me annotate this:
> 
>      t_on
>      <------>
>      t_period
>      <--------->
> phase
>    <->
>>    +------+  +------+  +------+  +------+  +------+  +------+  +------+
>>    |      |  |      |  |      |  |      |  |      |  |      |  |      |
>>  --+      +--+      +--+      +--+      +--+      +--+      +--+      +
>>
>>  +---------+---------+---------+---------+---------+---------+--------->
>    t=1000    t=1010    t=1020    t=1030    t=1040    t=1050    t=1060
>>  period=10                                                          time
>>  phase=2
>>  on = 7
>>
>> There's no other way to obtain this signal which has a duty cycle > 50%
>> by specifying a duty cycle < 50%.
>>
> 
> Thanks,
> -Vladimir
> 

Right this makes sense now, thanks for the detailed explanation!

Regards,
Jake