Re: [Xenomai] [PATCH] AT91: SAMA5D3: Adapt Ipipe for AIC5

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/08/2014 02:55 PM, Maxime Ripard wrote:
> On Mon, Jul 07, 2014 at 06:07:32PM +0200, Gilles Chanteperdrix
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 07/07/2014 06:02 PM, Maxime Ripard wrote:
>>> On Sat, Jul 05, 2014 at 10:13:51AM +0200, Gilles Chanteperdrix 
>>> wrote:
>>>>>>> Ok, so, with the changes you mentionned, I can't make
>>>>>>> the system crash anymore (or at least, not as easily as
>>>>>>> it used to be).
>>>>>>> 
>>>>>>> But: - whenever the program mentionned above calls
>>>>>>> exit(), it stalls. However, ctrl+c makes the program
>>>>>>> exit properly, and everything seems fine otherwise -
>>>>>>> whenever we don't link it against xenomai, it just
>>>>>>> hangs. I've not figured out why yet
>>>>>>> 
>>>>>>> With CONFIG_XENOMAI and CONFIG_IPIPE disabled, it
>>>>>>> works fine.
>>>>>> 
>>>>>> My answer was wrong, you probably need to keep the 
>>>>>> set_backup/clear_backup calls in he ->hold and ->release 
>>>>>> callbacks, as the linux interrupt may expect the backup
>>>>>> areas to be in sync. Did you do this, or did you go for
>>>>>> the alternative?
>>>>> 
>>>>> I went for the alternative. I'm sending you a v2 with what
>>>>> I have so far, that shows the behaviour I was describing.
>>>> 
>>>> Could you try the following patch?
>>> 
>>> It actually works much better, thanks!
>>> 
>>> The above mentionned issues are gone, there's only one last
>>> glitch I guess. The max latency under load is around a few
>>> 100's of ms (while idle, it's actually around 200-300us, which
>>> seems more reasonable.
>> 
>> 200us or 300us seems high for a last generation cortex.
>> milliseconds issues indicate an issue, does the msw column in
>> latency increment?
> 
> Ok, so after spending more time running xeno-test and latency
> 
> * xeno-test -l "dohell -s 192.168.0.42 -p 5566 -b
> /usr/bin/hackbench 60" - the average latency measured is 37us, with
> a max at 53
> 
> * If I just use the same load generator program I was using 
> previously (which basically just run hackbench, dohell, do some dd,
> output some data through netcat, etc.), and latency, for 45 
> minutes, I get an average latency at 35us, and a max latency at
> 60.
> 
> So the issue seems to lie in something related to our test
> program.
> 
> It's actually using CLOCK_MONOTONIC. When running just Xenomai's 
> clocktest program, the drift is OK, but the ToD offset is quite
> huge and varies slightly from one run to another. This also happens
> using CLOCK_REALTIME.
> 
> From what I understand of the POSIX clocks, gettimeofday is always 
> using EPOCH as a starting point, while POSIX clocks can pick
> whatever fixed starting point, so an offset might be expected.
> What's weird is that it whenever you use the CLOCK_HOST_REALTIME,
> which is used by xeno-test, and should be in sync with the Linux
> clock, this offset is no longer there.
> 
> That's the only meaningful difference I could spot between the two 
> programs (ours vs clocktest).

The test you are interested in is latency, not clocktest. The main
differences between latency and the test you run are:
- - the "period" (which BTW, in your case would only be a real period if
you removed the call to clock_gettime at the beginning of the loop,
only keeping the one before the loop), which is 1ms in latency case,
100us in your case
- - the fact that your function timespec_diff returns unsigned value, so
in case of early shot, you will get a very large value instead of a
negative ones.

As a general rule, we prefer Xenomai users to use the latency test,
because this is the one we collectively spent time debugging, so it
has more chances to be correct, and if you find a bug, everyone
benefits from the fix.

As for the question of the clocks:
- - for POSIX, CLOCK_REALTIME and gettimeofday use the same time base
- - CLOCK_MONOTONIC may use whatever they want, but usually are the time
from boot or from the clocksource start;
- - CLOCK_HOST_REALTIME should be synchronized with Linux
CLOCK_REALTIME, that is the aim of CLOCK_HOST_REALTIME;
- - CLOCK_REALTIME in the case of Xenomai is not near Linux
CLOCK_REALTIME because the xenomai base time is initialized before
your board sets its base, by whatever mean (hwclock, ntp, ntpdate,
rdate, etc...), you can avoid that by using clock_settime to set
Xenomai clock base, but the clock will drift away from Linux
CLOCK_REALTIME anyway, so you will need to call clock_settime from
time to time to keep them more or less in sync. This early
synchronization is arguably broken, in fact it made sense when xenomai
was compiled as a module, and loaded later on, but probably no longer
makes sense for built-in configurations, which are now the default.

- -- 
                                                                Gilles.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iD8DBQFTvCq1GpcgE6m/fboRAnIoAJoDY1TmGfrFwl8ywOcche/ozOTcZgCcDllh
9ggKL6Ee3xXn1DVPuqGM+08=
=AhHh
-----END PGP SIGNATURE-----