Message-ID: <DB7PR04MB501793F21441B465A45E0699F8539@DB7PR04MB5017.eurprd04.prod.outlook.com>
Date:   Tue, 11 May 2021 10:40:15 +0000
From:   "Y.b. Lu" <yangbo.lu@....com>
To:     Richard Cochran <richardcochran@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: RE: [net-next 0/6] ptp: support virtual clocks for multiple domains

Hi Richard,

> -----Original Message-----
> From: Richard Cochran <richardcochran@...il.com>
> Sent: 2021年5月11日 7:19
> To: Y.b. Lu <yangbo.lu@....com>
> Cc: netdev@...r.kernel.org; David S . Miller <davem@...emloft.net>; Claudiu
> Manoil <claudiu.manoil@....com>; Jakub Kicinski <kuba@...nel.org>
> Subject: Re: [net-next 0/6] ptp: support virtual clocks for multiple domains
> 
> On Mon, May 10, 2021 at 03:04:39AM +0000, Y.b. Lu wrote:
> 
> > There may be some misunderstanding. In the example, domain 1, 2, 3 are
> based on PTP virtual clocks ptp1, ptp2 and ptp3 which are utilizing their own
> timecounter.
> > The clock adjustment on them won't affect each other. The example worked
> fine in my verification.
> 
> Okay, now I think I understand what you are suggesting.  Still, there are issues
> you haven't considered.
> 
> > I mean if the physical clock keeps free running, all virtual clocks utilizing their
> own timercounter can work fine independently without affecting on each
> other.
> 
> Right.  This is critical!
> 
> > If the physical clock has change on frequency, there is also way to make the
> change not affect virtual clocks.
> > For example, when there is +12 ppm change on physical clock, just give -12
> ppm change on virtual clocks.
> 
> That will cause issues in very many cases.
> 
> For example, what happens when the "real" clock sees a large offset, and it
> doesn't step, but rather applies the maximum frequency offset to slew the
> clock?  That maximum might be larger that the max possible in the virtual
> clocks.  Even with smaller frequency offsets, the un-synchronized, quasi
> random changes in the "real" clock will spoil the virtual clocks.  I won't
> support such an approach.
> 

What I thought was in code writing registers to adjust physical clock frequency, and immediately adjusting virtual clocks in opposite direction.
Make the operations atomic by locking. Assume the code execution has a DELAY, and the frequency adjusted is PPM.
Then the time error affecting on virtual clock will be DELAY * PPM. I'm not sure what the DELAY value will be on other platforms.
Just for example, for 1us delay, 1000ppm adjustment will have 1ns time error.

But indeed, this approach may be not feasible as you said. Especially it is adjusting clock in max frequency, and there are many virtual clocks.
The time error may be large enough to cause issues. (I'm not sure whether I understand you correctly, sorry.)

So, a question is, for hardware which supports only one PTP clock, can multiple domains be supported where physical clock also participates in synchronization of a domain?
(Because sometime the physical clock is required to be synchronized for TSN using, or other usages.)
Do you think it's possible?

> However, if the "real" clock is guaranteed to stay free running, and the virtual
> clocks give up any hope of producing periodic outputs, then your idea might
> work.
> 
> Thinking out loud: You could make a sysfs knob that converts a "real"
> clock into two or more virtual clocks.  For example:
> 
>     cat /sys/class/ptp/ptp0/number_vclocks
>     0 # ptp0 is a "real" clock
> 
>     echo 3 > /sys/class/ptp/ptp0/number_vclocks
>     # This resets the frequency offset to zero and creates three
>     # new clocks using timecounter numeric adjustment, ptp0, 1, and 2.
>     # ptp0 loses its periodic output abilities.
>     # ptp0 is now a virtual clock, just like ptp1 and 2.
> 
>     echo 0 > /sys/class/ptp/ptp0/number_vclocks
>     # back to normal again.
> 
> In addition to that, you will need a way to make the relationships between the
> clocks and the network interfaces discoverable.

Agree. This should be done carefully and everything should be considered.
Will converting physical clock ptp0 to virtual clock ptp0 introduce more effort to implement,
comparing to keep physical clock ptp0 but limit to use it?

> 
> It needs more thought and careful design, but I think having
> clock_gettime() available for the different clocks would be nice to have for the
> applications.

Thank you. Then regarding the domain timestamp, do you think it's proper to do the conversion in kernel as I implemented.

> 
> Thanks,
> Richard

Powered by blists - more mailing lists