Message-ID: <AM0PR10MB3073F9694ECAD4F612A86FA7FA050@AM0PR10MB3073.EURPRD10.PROD.OUTLOOK.COM>
Date:   Wed, 14 Oct 2020 09:12:41 +0000
From:   "Meisinger, Andreas" <andreas.meisinger@...mens.com>
To:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "Geva, Erez" <erez.geva.ext@...mens.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "avagin@...il.com" <avagin@...il.com>,
        "0x7f454c46@...il.com" <0x7f454c46@...il.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "john.stultz@...aro.org" <john.stultz@...aro.org>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "oleg@...hat.com" <oleg@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "vdronov@...hat.com" <vdronov@...hat.com>,
        "bigeasy@...utronix.de" <bigeasy@...utronix.de>,
        "frederic@...nel.org" <frederic@...nel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>
CC:     "jesus.sanchez-palencia@...el.com" <jesus.sanchez-palencia@...el.com>,
        "vedang.patel@...el.com" <vedang.patel@...el.com>,
        "Sudler, Simon" <simon.sudler@...mens.com>,
        "Bucher, Andreas" <andreas.bucher@...mens.com>,
        "henning.schild@...mens.com" <henning.schild@...mens.com>,
        "jan.kiszka@...mens.com" <jan.kiszka@...mens.com>,
        "Zirkler, Andreas" <andreas.zirkler@...mens.com>,
        "Sakic, Ermin" <ermin.sakic@...mens.com>,
        "anninh.nguyen@...mens.com" <anninh.nguyen@...mens.com>,
        "Saenger, Michael" <michael.saenger@...mens.com>,
        "Maehringer, Bernd" <bernd.maehringer@...mens.com>,
        "gisela.greinert@...mens.com" <gisela.greinert@...mens.com>,
        "Geva, Erez" <erez.geva.ext@...mens.com>,
        "ErezGeva2@...il.com" <ErezGeva2@...il.com>,
        "guenter.steindl@...mens.com" <guenter.steindl@...mens.com>
Subject: Re: [PATCH 0/7] TC-ETF support PTP clocks series

Hello Thomas,
Sorry about the wrong format/style of my last mail, hope I did get it right this time.

Let me first point at an important thing because we did have discussions here about it too. As of the manpages Linux CLOCK_TAI seems to be defined as an nonsettable clock which does have the same behaviour as of international atomic time TAI. Yet if it's nonsettable it can't be linked or synchronized to the value of International Atomic Time?
On the other hand there seems to be code in place to change the CLOCK_TAI offset thus making it basically sort of "setable"?

> The user space daemon which does the correlation between these PTP domains and TAI is required in any case, so the magic
> clock TAI_PRIVATE is not having any advantage.

I think a userspace daemon handling the translation information between different clocks would be fine. I think it's not really that relevant who exactly does apply the translation. Kernel level might be a little bit more precise but I guess it'd depend on other factors too.
Yet all translation based approaches have in common, setting a clock, renders translations done in past invalid. It would be required to fix old translated values along with setting the clock. I assume we couldn't distinguish between "translated" values and genuine values after translation, so fixing them might not be possible at all.
In our usecase we do have a clock for network operation which can't be set. We can guarantee this because we are able to define the network not being operational when the defined time is not available 😉.
Having this defined the remaining option would  be the target clock to be set. As of your suggestion that would be CLOCK_TAI. So at this point "setable" or "nonsettable" would become important. Here "setable" would introduce a dependency between the clocks. Being independent from clocks outside of our control was exactly the reason to introduce the separate network clock. To me this means if CLOCK_TAI could be changed by anything it couldn't be the base clock for our usecase if it can't it might be a solution.

> Depending on the frequency drift between CLOCK_TAI and clock PTP/$N the timer expiry might be slightly inaccurate, but
> surely not more inaccurate than if that conversion is done purely in user space.
>
> The self rearming posix timers would work too, but the self rearming is based on CLOCK_TAI, so rounding errors and drift
> would be accumulative. So I'd rather stay away from them.

As of the time ranges typically used in tsn networks the drift error for single shot timers most likely isn't a big deal. But as you suggest I'd stay away from long running timers as well rearming ones too, I guess they'd be mostly unusable.

> If such a coordination exists, then the whole problem in the TSN stack is gone. The core can always operate on TAI and the
> network device which runs in a different time universe would use the same conversion data e.g. to queue a packet for HW
> based time triggered transmission. Again subject to slight inaccuracy, but it does not come with all the problems of dynamic
> clocks, locking issues etc. As the frequency drift between PTP domains is neither fast changing nor randomly jumping around
> the inaccuracy might even be a mostly academic problem.

These multiple conversion errors would happen even for applications aware of it's target timescale.
This might usually be an academic issue but for some of our usecases conversion errors aren’t allowed at all.
In any case adding conversion errors sounds strange as our goal is to improve precision.

I don't see a way to avoid conversion errors except of somehow passing the original timestamp down to network card level.
Right now there's only one timestamp in CLOCK_TAI format which is used by ETF as well as by network card thus causing trouble if time is not same there.
If we'd add an (optional) second timestamp to SKB which would have to be set to network card time we could avoid the conversion error. As we do know which network card will be used for sending the SKB we wouldn't need a clock identifier for the second timestamp.
For situations where the application is not aware of the network cards timespace it wouldn't provide the second timestamp. In these situations it'd behave identical to your suggestion. Here the CLOCK_TAI timestamp would be translated to network card time based on the information of the userspace daemon.

What's your opinion about a second timestamp?

Best regards
Andreas Meisinger

Siemens AG
Digital Industries
Process Automation
DI PA DCP
Gleiwitzer Str. 555
90475 Nürnberg, Deutschland
Tel.: +49 911 95822720
mailto:andreas.meisinger@...mens.com

Powered by blists - more mailing lists