This fixes a clock drift issue that is measurable with clocktest. The
change was suggested by Jan a while ago [0], I tested it again on 4.19.89.
[0] https://www.xenomai.org/pipermail/xenomai/2019-May/040929.html
Signed-off-by: Bart Vissers
---
arch/x86/include/asm/ipipe_base.h | 4 ++--
1 file
a regression regarding the
> TSC-to-nanoseconds
> > calculations. Maybe check the parameters Xenomai is using
> internally, if they
> > are differing.
> >
> > Jan
> >
> > >
> > > Thanks again,
> > > Bart
Jan
>
> >
> > Thanks again,
> > Bart
> >
> > On Tue, 14 May 2019 at 09:14, Jan Kiszka > <mailto:jan.kis...@web.de>> wrote:
> >
> > On 13.05.19 18:41, Bart Vissers via Xenomai wrote:
> > > Hi all,
> > >
> >
ork due to too much drift wrt to
slave clocks.
We don't really care about the system time, but I added ntp logs because I
thought it might help finding the cause.
Thanks again,
Bart
On Tue, 14 May 2019 at 09:14, Jan Kiszka wrote:
> On 13.05.19 18:41, Bart Vissers via Xenomai wrote:
> &
Hi all,
When running clocktest I get the following output:
$ /usr/xenomai/bin/clocktest
== Testing built-in CLOCK_REALTIME (0)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -- --
01553975.5 4
I've done some testing with the X-window suggestions at:
https://gitlab.denx.de/Xenomai/xenomai/wikis/Troubleshooting#the_latency_test_shows_high_latencies
My results on an Intel PC with Xenomai 3.0.7, Linux 4.9, Debian 9.7 with
xfce4, worst-case latencies:
- Using Intel driver: 39.8 us
- Using fb