* POSIX clock_gettime value is incorrect
@ 2021-02-05 6:23 Sam Daniel
2021-02-05 14:35 ` Jan Kiszka
0 siblings, 1 reply; 3+ messages in thread
From: Sam Daniel @ 2021-02-05 6:23 UTC (permalink / raw)
To: xenomai
This is my test program, compiled/linked against the POSIX skin.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(int argc, char* argv[]) {
timespec time;
clock_gettime(CLOCK_REALTIME, &time);
fprintf(stdout, "%lu\n", time.tv_sec);
return 0;
}
When I run it on my Xenomai system, this is its output:
$ ./clock
413
This appears to be roughly the number of seconds since boot:
$ uptime
04:40:44 up 7 min, 1 user, load average: 0.36, 0.31, 0.16
Compiling without POSIX skin and running it has expected results:
$ ./clock
1612500006
Running date from my bash shell has expected results:
$ date
Fri Feb 5 04:38:10 UTC 2021
I ran the clocktest tool:
$ clocktest
== Testing built-in CLOCK_REALTIME (0)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 -1612499588990078.2 -0.046 0 0.0
1 -1612499588990077.8 0.061 0 0.0
2 -1612499588990077.8 0.004 0 0.0
3 -1612499588990077.8 0.022 0 0.0
I do not understand its output, but to my eye it does not appear to be
"correct"...
After searching through the mailing list, I tried this:
$ clocktest -C CLOCK_HOST_REALTIME
clock_gettime failed for clock id 32
clock_gettime failed for clock id 32
XNVDSO_FEAT_HOST_REALTIME not available
clock_gettime failed for clock id 32
XNVDSO_FEAT_HOST_REALTIME not available
Which led me to this thread:
https://www.mail-archive.com/xenomai@xenomai.org/msg15904.html. I, too,
could not set CONFIG_XENO_OPT_HOSTRT or CONFIG_IPIPE_HAVE_HOSTRT
So I made this patch:
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 124398ef7336..28afa4b4b091 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -149,6 +149,7 @@ config ARM64
select HAVE_KRETPROBES
select HAVE_IPIPE_SUPPORT
select HAVE_IPIPE_TRACER_SUPPORT
+ select IPIPE_HAVE_HOSTRT if IPIPE
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
CONFIG_XENO_OPT_HOSTRT and CONFIG_IPIPE_HAVE_HOSTRT were now both set
to y. Recompiled
and re-ran with this patch:
$ clocktest -C CLOCK_HOST_REALTIME
clock_gettime failed for clock id 32
clock_gettime failed for clock id 32
clock_gettime failed for clock id 32
hostrt data area is not live
hostrt data area is not live
I tried the extension flag as well:
$ clocktest -E -C CLOCK_HOST_REALTIME
clocktest: bad extension clock name 'CLOCK_HOST_REALTIME': Invalid argument
I am using Cobalt v3.1 with ipipe-core-4.19.55-arm64-4.patch. Is my kernel
building configured incorrectly? Am I missing some config parameter?
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: POSIX clock_gettime value is incorrect
2021-02-05 6:23 POSIX clock_gettime value is incorrect Sam Daniel
@ 2021-02-05 14:35 ` Jan Kiszka
2021-02-05 22:58 ` Sam Daniel
0 siblings, 1 reply; 3+ messages in thread
From: Jan Kiszka @ 2021-02-05 14:35 UTC (permalink / raw)
To: Sam Daniel, xenomai, Greg Gallagher
On 05.02.21 07:23, Sam Daniel via Xenomai wrote:
> This is my test program, compiled/linked against the POSIX skin.
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
> int main(int argc, char* argv[]) {
> timespec time;
> clock_gettime(CLOCK_REALTIME, &time);
> fprintf(stdout, "%lu\n", time.tv_sec);
> return 0;
> }
>
> When I run it on my Xenomai system, this is its output:
> $ ./clock
> 413
>
> This appears to be roughly the number of seconds since boot:
> $ uptime
> 04:40:44 up 7 min, 1 user, load average: 0.36, 0.31, 0.16
>
Yes, the Xenomai CLOCK_REALTIME is decoupled from the Linux realtime
clock, at least so far. Will change in future Xenomai versions.
> Compiling without POSIX skin and running it has expected results:
> $ ./clock
> 1612500006
>
> Running date from my bash shell has expected results:
> $ date
> Fri Feb 5 04:38:10 UTC 2021
>
> I ran the clocktest tool:
> $ clocktest
> == Testing built-in CLOCK_REALTIME (0)
> CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
> --- -------------------- ---------------- ---------- --------------
> 0 -1612499588990078.2 -0.046 0 0.0
> 1 -1612499588990077.8 0.061 0 0.0
> 2 -1612499588990077.8 0.004 0 0.0
> 3 -1612499588990077.8 0.022 0 0.0
>
> I do not understand its output, but to my eye it does not appear to be
> "correct"...
>
> After searching through the mailing list, I tried this:
> $ clocktest -C CLOCK_HOST_REALTIME
> clock_gettime failed for clock id 32
> clock_gettime failed for clock id 32
> XNVDSO_FEAT_HOST_REALTIME not available
> clock_gettime failed for clock id 32
> XNVDSO_FEAT_HOST_REALTIME not available
>
> Which led me to this thread:
> https://www.mail-archive.com/xenomai@xenomai.org/msg15904.html. I, too,
> could not set CONFIG_XENO_OPT_HOSTRT or CONFIG_IPIPE_HAVE_HOSTRT
>
>
> So I made this patch:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 124398ef7336..28afa4b4b091 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -149,6 +149,7 @@ config ARM64
> select HAVE_KRETPROBES
> select HAVE_IPIPE_SUPPORT
> select HAVE_IPIPE_TRACER_SUPPORT
> + select IPIPE_HAVE_HOSTRT if IPIPE
> select IOMMU_DMA if IOMMU_SUPPORT
> select IRQ_DOMAIN
> select IRQ_FORCED_THREADING
>
> CONFIG_XENO_OPT_HOSTRT and CONFIG_IPIPE_HAVE_HOSTRT were now both set
> to y. Recompiled
> and re-ran with this patch:
> $ clocktest -C CLOCK_HOST_REALTIME
> clock_gettime failed for clock id 32
> clock_gettime failed for clock id 32
> clock_gettime failed for clock id 32
> hostrt data area is not live
> hostrt data area is not live
>
> I tried the extension flag as well:
> $ clocktest -E -C CLOCK_HOST_REALTIME
> clocktest: bad extension clock name 'CLOCK_HOST_REALTIME': Invalid argument
>
> I am using Cobalt v3.1 with ipipe-core-4.19.55-arm64-4.patch. Is my kernel
> building configured incorrectly? Am I missing some config parameter?
>
That patch isn't sufficient. ARM64 lacks the architectural support for
that. I do not recall the reasons, though, maybe Greg can explain.
Also note that CLOCK_HOST_REALTIME will serve for reading time only, not
for scheduling events on it. That is only possible for CLOCK_REALTIME
and CLOCK_MONOTONIC. The purpose of that clock is to permit timestamping
of events in the RT domain.
Again, a limitation to be lifted in future versions.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: POSIX clock_gettime value is incorrect
2021-02-05 14:35 ` Jan Kiszka
@ 2021-02-05 22:58 ` Sam Daniel
0 siblings, 0 replies; 3+ messages in thread
From: Sam Daniel @ 2021-02-05 22:58 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai, Greg Gallagher
On Fri, Feb 5, 2021 at 6:35 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 05.02.21 07:23, Sam Daniel via Xenomai wrote:
> > This is my test program, compiled/linked against the POSIX skin.
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <time.h>
> > int main(int argc, char* argv[]) {
> > timespec time;
> > clock_gettime(CLOCK_REALTIME, &time);
> > fprintf(stdout, "%lu\n", time.tv_sec);
> > return 0;
> > }
> >
> > When I run it on my Xenomai system, this is its output:
> > $ ./clock
> > 413
> >
> > This appears to be roughly the number of seconds since boot:
> > $ uptime
> > 04:40:44 up 7 min, 1 user, load average: 0.36, 0.31, 0.16
> >
>
> Yes, the Xenomai CLOCK_REALTIME is decoupled from the Linux realtime
> clock, at least so far. Will change in future Xenomai versions.
>
> > Compiling without POSIX skin and running it has expected results:
> > $ ./clock
> > 1612500006
> >
> > Running date from my bash shell has expected results:
> > $ date
> > Fri Feb 5 04:38:10 UTC 2021
> >
> > I ran the clocktest tool:
> > $ clocktest
> > == Testing built-in CLOCK_REALTIME (0)
> > CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
> > --- -------------------- ---------------- ---------- --------------
> > 0 -1612499588990078.2 -0.046 0 0.0
> > 1 -1612499588990077.8 0.061 0 0.0
> > 2 -1612499588990077.8 0.004 0 0.0
> > 3 -1612499588990077.8 0.022 0 0.0
> >
> > I do not understand its output, but to my eye it does not appear to be
> > "correct"...
> >
> > After searching through the mailing list, I tried this:
> > $ clocktest -C CLOCK_HOST_REALTIME
> > clock_gettime failed for clock id 32
> > clock_gettime failed for clock id 32
> > XNVDSO_FEAT_HOST_REALTIME not available
> > clock_gettime failed for clock id 32
> > XNVDSO_FEAT_HOST_REALTIME not available
> >
> > Which led me to this thread:
> > https://www.mail-archive.com/xenomai@xenomai.org/msg15904.html. I, too,
> > could not set CONFIG_XENO_OPT_HOSTRT or CONFIG_IPIPE_HAVE_HOSTRT
> >
> >
> > So I made this patch:
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 124398ef7336..28afa4b4b091 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -149,6 +149,7 @@ config ARM64
> > select HAVE_KRETPROBES
> > select HAVE_IPIPE_SUPPORT
> > select HAVE_IPIPE_TRACER_SUPPORT
> > + select IPIPE_HAVE_HOSTRT if IPIPE
> > select IOMMU_DMA if IOMMU_SUPPORT
> > select IRQ_DOMAIN
> > select IRQ_FORCED_THREADING
> >
> > CONFIG_XENO_OPT_HOSTRT and CONFIG_IPIPE_HAVE_HOSTRT were now both set
> > to y. Recompiled
> > and re-ran with this patch:
> > $ clocktest -C CLOCK_HOST_REALTIME
> > clock_gettime failed for clock id 32
> > clock_gettime failed for clock id 32
> > clock_gettime failed for clock id 32
> > hostrt data area is not live
> > hostrt data area is not live
> >
> > I tried the extension flag as well:
> > $ clocktest -E -C CLOCK_HOST_REALTIME
> > clocktest: bad extension clock name 'CLOCK_HOST_REALTIME': Invalid
> argument
> >
> > I am using Cobalt v3.1 with ipipe-core-4.19.55-arm64-4.patch. Is my
> kernel
> > building configured incorrectly? Am I missing some config parameter?
> >
>
> That patch isn't sufficient. ARM64 lacks the architectural support for
> that. I do not recall the reasons, though, maybe Greg can explain.
>
> Also note that CLOCK_HOST_REALTIME will serve for reading time only, not
> for scheduling events on it. That is only possible for CLOCK_REALTIME
> and CLOCK_MONOTONIC. The purpose of that clock is to permit timestamping
> of events in the RT domain.
>
> Again, a limitation to be lifted in future versions.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
How would you recommend I get the current system time (preferably in
seconds since epoch)? Is there a POSIX-friendly way of getting an accurate
system time in primary mode without mode switches? Or do I need to
wrap/link my executable with both Alchemy and POSIX in order to call the
Alchemy API's rt_timer_read function?
Thanks in advance
~ Sam
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-02-05 22:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-05 6:23 POSIX clock_gettime value is incorrect Sam Daniel
2021-02-05 14:35 ` Jan Kiszka
2021-02-05 22:58 ` Sam Daniel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.