Messages in this thread | | | Subject | Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL | From | Sebastien Laveze <> | Date | Thu, 07 Oct 2021 15:31:43 +0200 |
| |
On Thu, 2021-09-30 at 07:35 -0700, Richard Cochran wrote: > > What we miss currently in the kernel for a better multi-domain usage > > and would like to find a solution: > > -allow PHC adjustment with virtual clocks. Otherwise scheduled traffic > > cannot be used... (I've read your comments on this topic, we are > > experimenting things on MCUs and we need to assess on measurements) > > Yeah, so you cannot have it both ways, I'm afraid. Either you adjust > the HW clock or not. If you don't, it becomes impractical to program > the event registers for output signals. (Time stamps on input signals > are not an issue, though)
Yes, this is especially true for periodic events completely handled in hardware like scheduled traffic.
However, not being able to support multiple domains + scheduled traffic is a true limitation for TSN use cases.
I'm aware of your opinon on this topic: https://lore.kernel.org/netdev/20210510231832.GA28585@hoboy.vegasvil.org/
However, a few points that _might_ change your mind: * regular and random small adjustments don't cost that much since the error you create for the children clocks is only the time for the PHC to adjust. Since this time is quite small (~10 us ? ), a few ppm on this short time is negligible.
For example: Let's take a worst case, the PHC is adjusted every 10 ms, vclock every 1 sec with 1 ppm error. vclock error is 1 us, now if you add the 100 PHC adjustments each of them with an error of 1 ppm over 10 us. That gives 0.01 ns * 100 = 1 ns. This is negligible vs the 1 us error. Of course, in general, the vclock would be updated more frequently but in this case even less impacted by PHC adjustments.
* large frequency adjustments are more problematic. I've checked that some drivers allow up to 10^6 ppm... This could lead to non-negligible error. However, since it's already accepted that using vclock is at the cost of loosing adjustments on the PHC, it could be accepted that it's still adjustable but with some restrictions. (1000 ppm max ?)
* offset adjustments do not introduce any error if performed in software. On other systems we support, handling the offset in software helped to improve stability as the hardware time becomes monotonic. There is no added value in setting the offset in the PHC.
> I think the best option for user space wanting timers in multiple > domains is to periodically do > > gettime(monotonic); gettime(vclock); gettime(monotonic); > > figure the conversion, and schedule using clock_monotonic.
Yes, having a good ratio/offset measurement should lead to decent performance.
Thanks, Sebastien
| |