From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Daniele Nicolodi <daniele@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] First loop iteration increased latency
Date: Mon, 08 Mar 2010 18:24:58 +0100 [thread overview]
Message-ID: <4B9532EA.4070300@domain.hid> (raw)
In-Reply-To: <4B9530B5.60809@domain.hid>
Daniele Nicolodi wrote:
> Hello. I'm obtaining quite nice results with Xernomai in my data
> acquisition program. However I observe an unexpected behaviour.
>
> My test application works as follow: one process puts a data frame into
> a shared memory region and increments a semaphore. Another process waits
> on the semaphore, takes the data frame from the shared memory and
> processes it. I also place in the shared memory the time (obtained from
> clock_gettime(CLOCK_REALTIME, &ts)) the time at which I increment the
> semaphore. In the consumer process I look at the time difference between
> the stored time and the time at which I read the frame from the shared
> memory. In this way I hope to obtain a measurement of the inter process
> communication latency.
You should be using clock_gettime(CLOCK_MONOTONIC), it has a lower overhead.
>
> I obtain a quite satisfactory latency, in the 20-30 usec range. However
> the latency for receving the first frame is always much larger: in the
> order of 8-10 msec! What can be the cause of such latency?
Either you have a bug in your protocol, or something else happens, such
as a cache effect. What is the size of the frame, what is the platform
you are using? Could you send us the test program, which would allow us
to reproduce the issue?
>
> I'm monitoring xenomai mode switches with pthread_set_mode_np(0,
> PTHREAD_WARNSW) and I observe none of those. I thought that maybe I'm
> encountering page faults when reading for the first time the shared
> memory segment and I tried to "initialize" the memory reading from it in
> a very stupid loop:
>
> int i;
> char c;
> from (i = 0; i < SIZE; i++)
> c = ((char *)shm)[i];
>
> but it can be that the compiler is smarter than me and is optimizing the
> loop away. What is a better way to issue the page faults in a non
> critical section of my code? It would be nice if xenomai would support
> MAP_POPULATE mmap() flag.
It is not necessary. A conforming xenomai application should use
mlockall, so there is no way a mapping may not be populated.
>
> How can I track the source of this increased latency?
Use the I-pipe tracer.
--
Gilles.
next prev parent reply other threads:[~2010-03-08 17:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-08 17:15 [Xenomai-help] First loop iteration increased latency Daniele Nicolodi
2010-03-08 17:24 ` Gilles Chanteperdrix [this message]
2010-03-08 17:39 ` Daniele Nicolodi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B9532EA.4070300@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=daniele@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.