[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <768227b1f347cb1573efb1b5f6c642e2654666ba.camel@oss.nxp.com>
Date: Fri, 08 Oct 2021 09:13:58 +0200
From: Sebastien Laveze <sebastien.laveze@....nxp.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
yangbo.lu@....com, yannick.vignon@....nxp.com,
rui.sousa@....nxp.com
Subject: Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL
On Thu, 2021-10-07 at 13:19 -0700, Richard Cochran wrote:
> On Thu, Oct 07, 2021 at 03:31:43PM +0200, Sebastien Laveze wrote:
> > For example:
> > Let's take a worst case, the PHC is adjusted every 10 ms, vclock every
> > 1 sec with 1 ppm error.
>
> You can't justify adjusting the HW clock and the vclocks
> asynchronously with a single, isolated example.
This was a single worst case example, many asynchronous PHC adjustments
impacting vclocks.
> If two independent processes are both adjusting a clock concurrently,
> asynchronously, and at different control rates, the result will be
> chaos.
This is especially what we want to prove feasible and we think it's
posssible with the following conditions:
-limited frequency adjustments
-offset adjustment in software
> It does not matter that it *might* work for some random setup of
> yours.
>
> The kernel has to function correctly in general, not just in some
> special circumstances.
Of course, so what tests and measurements can we bring on the table to
convince you that it doesn't lead to chaos ?
Thanks,
Sebastien
Powered by blists - more mailing lists