Thanks for the clarification.
What I'm trying to achieve:
I'd like to be able to use both domains as if they were Linux clocks
like CLOCK_REALTIME. That is, I want the functionality of
clock_gettime, but also other system calls like timer, timerfd,
nanosleep, hrtimer etc.
I want both domains to have similar performance in terms of
latency/noise when using these.
Since I won't be able to use the standard system calls, the only
alternative I can think of is to write my own library that provides the
same functionality.
Under the hood, this library would use the PHC vclock directly.
Alternatively, the library could maintain its own virtual clock
(offset/rate ratio relative to CLOCK_REALTIME, obtained from a "free
running" ptp4l), and convert to/from this virtual clock under the hood.
Is this the right way to go, or are there better ways?
I understand that performance is much better when using CLOCK_REALTIME
(as opposed to working with a PHC directly) because a PHC generally
exists behind a bus on external hardware. Am I correct in assuming this
wouldn't be an issue with a PHC vclock?
Thanks for all the help
JP
On 2021/08/11 15:42, Richard Cochran wrote:
On Tue, Aug 10, 2021 at 05:47:44PM +0200, JP wrote:
I guess I will only be able to make use of one domain "the standard way"
(i.e. use phc2sys to synchronize CLOCK_REALTIME, and then use standard Linux
clock system calls with CLOCK_REALTIME).
right.
Is there a best practice when it comes to using a second domain?
It depends on what you are trying to accomplish. The stack is
flexible enough to cover many use cases.
Can one use
a PHC clock id with any system call that uses clock ids (e.g. the timerfd
family)?
No.
Or are these only expected to work with clock_gettime & co?
Yes.
And is
this different for virtual PHCs?
A PHC vclock is simply a PHC that shares the MAC HW with other PHCs,
but it is otherwise a PHC like any other.
Would a "free running" instance of ptp4l for the 2nd domain be more useful
in user space, rather than going the virtual PHC route?
Again, it depends on the use case.
HTH,
Richard
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
