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.meisin...@siemens.com

Reply via email to