From: "Viktor Stark" <abraar@domain.hid>
To: xenomai@xenomai.org
Subject: [Xenomai-help] [RT_PIPE] - User space read() not waking up
Date: Thu, 22 Mar 2007 22:57:07 +0100 [thread overview]
Message-ID: <20070322215707.232970@domain.hid> (raw)
Hello,
I'm having a little issue with RT pipes and I was wondering if anyone could give me some pointers.
I wrote a RT kernel module for a DAQ card. The DAQ card gets interrupts every 200 us (5 kHz) and I've got a RT interrupt handler which wakes up a RT function (by sending an event to it). Inside that function I use rt_pripe_write to send some data (about 300 bytes) down to user space.
On the user space side, I've got a real small executable which basically opens the pipe via the Xenomai registry and then reads data from it in a tight loop. Inside that loop I read the TSC after each write and I compute a minimum / maximum for a 10 seconds cycle. The problem is that I get a maximum of about 395 us (which is 2 times 200 us approximately). On the kernel side I also do timings and I am 100% sure that my function using rt_pipe_write() is woken up every 200 us (+- 10 us jitter), that is no interrupts are missed.
After further reasearch I realised that I get a maximum value every 10000 cycles, that is every two seconds. I don't have anything in my system (to my knowledge) that has such a period so I'm really confused about what could be causing this.
I tried to have a look at pipe.c in src/nucleus and saw that the user space side is supposed to get woken up on each xnpipe_send() but I admit that I didn't quite catch all the details.
So basically, my question is:
If I have rt_pipe_write() writing to a pipe from a kernel module with a 200 us period and I have a read() in a tight loop reading from that same pipe is user space, what could be the origin of the fact that sometimes my read() doesn't get woken up?
It's worth to mention too, that I'm not losing any data. That is, after the read which eats up 2 cycles, the next read finishes nearly instantaneously (within 5 us) as if only the second rt_pipe_write() woke up the user space read().
Timing illustration (time between read()'s in us): 195 | 200 | 205 | 395 | 5 | 195 | 200 | 200
My setup:
Xenomai 2.2-rc3
Kernel 2.6.17 (with Xenomai compiled in - ie. not compiled as modules)
P4 3GHz - 1Gb RAM
No APM/ACPI/CpuFreq - SMI workaround enabled.
Tried with 2.6.19 / Xenomai 2.3 - same results.
Thanks in advance for any pointers.
Keep up the good work! Xenomai just *rocks*.
Viktor STARK
--
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
next reply other threads:[~2007-03-22 21:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 21:57 Viktor Stark [this message]
2007-03-23 8:38 ` [Xenomai-help] [RT_PIPE] - User space read() not waking up Jan Kiszka
2007-03-23 8:42 ` Dmitry Adamushko
2007-03-23 8:49 ` Jan Kiszka
2007-03-24 1:48 ` Viktor STARK
[not found] ` <460481F2.5010408@domain.hid>
2007-03-24 10:20 ` Dmitry Adamushko
2007-03-24 11:55 ` Philippe Gerum
2007-03-24 12:07 ` Viktor STARK
2007-03-24 22:49 ` Philippe Gerum
2007-03-25 0:23 ` Viktor STARK
2007-03-24 22:36 ` [off-list] " Dmitry Adamushko
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=20070322215707.232970@domain.hid \
--to=abraar@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.