[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210508191718.GC13867@hoboy.vegasvil.org>
Date: Sat, 8 May 2021 12:17:18 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Yangbo 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 Fri, May 07, 2021 at 04:57:50PM +0800, Yangbo Lu wrote:
> ptp4l -i eno0 -p/dev/ptp1 -m --domainNumber=1 --priority1=128 > domain1-slave.log 2>&1 &
> ptp4l -i eno0 -p/dev/ptp2 -m --domainNumber=2 --priority1=128 > domain2-slave.log 2>&1 &
> ptp4l -i eno0 -p/dev/ptp3 -m --domainNumber=3 --priority1=127 > domain3-master.log 2>&1 &
> - Make changing on physical clock transparent to virtual clocks.
> The virtual clock is based on free running physical clock. If physical
> clock has to be changed, how to make the change transparent to all
> virtual clocks?
Yes, this is a serious defect of this patch series, and there is no
way to fix it. In the above example, suppose that domainNumber 1
needs +11 ppm and domainNumber 2 needs -12 ppm. You can't adjust one
clock in two different ways.
> Actually the frequency adjustmend on physical clock
> may be hidden by updating virtual clocks in opposite direction at same
> time. Considering the ppb values adjusted, the code execution delay
> will be little enough to ignore.
Assuming that the frequency offset is exactly the same on all domains,
which will very often be false.
> But it's hard to hide clock stepping,
> by now I think the workaround may be inhibiting physical clock stepping
> when run user space ptp application.
That won't work either, because a phase offset on one domain will
result in a large slew at the maximum rate, but that rate would spoil
the other domains.
The best way to support multiple PTP domains simultaneously
is in the application. It is really the only way, because the kernel
does not handle any details of the PTP, like domainNumber. The kernel
only provides clock control and packet time stamping.
ptp4l does not handle multiple domains today, but it definitely could
be added with some effort. It would have to synchronize the clock to
one chosen domain, and track the phase and frequency offsets of each
of the other domains with respect to the chosen domain. Having done
this, the software can convert time stamps between the domains
perfectly. Using the tracked phase and frequency offsets, it can also
switch domains seamlessly without hacks or guesswork.
So I have to say NAK to this series because it can't do any of that,
and it cannot be made to work either.
Thanks,
Richard
Powered by blists - more mailing lists