Message-ID: <DB7PR04MB5017D35C76AAEDEE0319DA12F8509@DB7PR04MB5017.eurprd04.prod.outlook.com>
Date:   Fri, 14 May 2021 06:41:28 +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日 23:50
> 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 Tue, May 11, 2021 at 10:40:15AM +0000, Y.b. Lu wrote:
> > 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.)
> 
> You understand correctly.
> 
> > 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?
> 
> No, it won't work.  You can't adjust both the physical clock and the
> timecounters at the same time.  The code would be an awful hack, and it
> would not work in all real world circumstances.  If the kernel offers a new
> time service, then it has to work always.
> 
> So, getting back to my user space idea, it _would_ work to let the application
> stack control the HW clock as before, but to track the other domains
> numerically.  Then, the other applications could use the TIME_STATUS_NP
> management message (designed for use with gPTP and
> free_running) to get the current time in the other domains.
> 
> So take your pick.  You can't have it both ways, I'm afraid.
> 

I give up supporting physical clock and the timecounters adjusting at the same time, but I may continue to support virtual clock per your suggestion.
 
Getting back to your user space idea, I'd like to understand further to see if I can make some contribution.
Actually I can't think out how to track (there is not timecouner like in kernel) in a easy way, and I have some concerns too.

I assume we have a way for physical clock domain to track phase and frequency offset for each of other domains.
Are the phase and frequency offset enough to convert timestamp?

Still the key problem is hiding physical clock changes for the virtual.
There is another reason that I initially gave workaround of no stepping on physical clock.
Because timestamping is asynchronous with physical clock phase changing.
When a timestamp is captured and physical clock time has a small change, we have no idea if timestamping happened before or after clock changing during conversion.

Finally gPTP standard does use management messages. I think it doesn’t matter only if it implements the function we need.
Maybe I haven't got your point...

Thanks a lot.

Powered by blists - more mailing lists