Hi Richard,

-----Original Message-----
From: Richard Cochran <richardcochran@gmail.com>
Sent: 2021年5月11日 7:19
To: Y.b. Lu <yangbo.lu@nxp.com>
Cc: netdev@vger.kernel.org; David S . Miller <davem@davemloft.net>; Claudiu
Manoil [off-list ref]; Jakub Kicinski [off-list ref]
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:

quoted

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.

quoted

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.

quoted

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!

quoted

If the physical clock has change on frequency, there is also way to make the

change not affect virtual clocks.

quoted

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