From: "arun4linux" <arun4linux@indiatimes.com>
To: "Roger Larsson" <roger.larsson@norran.net>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Re: Lowering Latency
Date: Mon, 30 Dec 2002 22:54:53 +0530 [thread overview]
Message-ID: <200212301716.WAA30139@WS0005.indiatimes.com> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2854 bytes --]
<<I assume that the only thing the driver does on an interrupt is to wakeup the application?
>>Yes. it wakes up the sleeping threads.
<<Can the interrupts arrive faster than once per 1/50 s = 20 ms?
>>Yes. But at least 3000 interrupts have to get processed by both ISR and application thread.
<<But it is REQUIRED that your application runs with SCHED_FIFO and its memory locked.
>>Did you mean dynamic memory allocation in the application? or something else?
<<But do not use
schp.sched_priority = sched_get_priority_max(SCHED_FIFO);
since there are generally no SCHED_FIFO processes running and the highest levels should be reserved for really important stuff...
>>I use the SCHED_RR (real-time threads) in the application.
<<What is in the PCI registers that the application uses - data?
>>It uses both the device registers as well as data.
Making the driver smarter is also not possible in our case as we are porting it and we try to imitate another OS as much as possible for code maintanece requirement.
Warm Regards
Arun
"Roger Larsson" wrote:
On Wednesday 25 December 2002 23:09, you wrote:
> <> << latency and not much more.
>
> I need to process a minimum of 3000 interrupts per minute generated by a
> PCI based controller.
> And my development environment is RedHat 8.0. I can't change both of these.
> And the application is tightly coupled with the driver. Driver exports the
> PCI base addresses to the application using mmap and application accesses
> the card directly.
>
> Arun
>
Lets see...
3000 interrupts per minute => 50 per second, should not be a problem in driver
code. But...
I assume that the only thing the driver does on an interrupt is to wakeup the
application? Then you have the need for low latency... What is the worst
case? Can the interrupts arrive faster than once per 1/50 s = 20 ms?
Why I ask is because 20 ms is on the average OK for a standard kernel.
But if you like to use the file system on the same time it will be a problem.
But it is REQUIRED that your application runs with SCHED_FIFO and
its memory locked.
see
http://www.gardena.net/benno/linux/audio/
it is old, the standard kernel is better now. But do not use
schp.sched_priority = sched_get_priority_max(SCHED_FIFO);
since there are generally no SCHED_FIFO processes running and
the highest levels should be reserved for really important stuff...
What is in the PCI registers that the application uses - data? Is it data
acuisition application? If not, try to make the driver smarter - it helps.
/RogerL
--
Roger Larsson
Skellefteå
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy the best in Movies at http://www.videos.indiatimes.com
Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now!
next reply other threads:[~2002-12-30 17:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-30 17:24 arun4linux [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-25 22:09 arun4linux
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=200212301716.WAA30139@WS0005.indiatimes.com \
--to=arun4linux@indiatimes.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roger.larsson@norran.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®