lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ