Re: Reducing interruption latency for feedback-loop
Re: Reducing interruption latency for feedback-loop
- Subject: Re: Reducing interruption latency for feedback-loop
- From: Michael Smith <email@hidden>
- Date: Wed, 7 Feb 2007 13:12:05 -0800
Date: Wed, 7 Feb 2007 09:58:18 -0800
From: "CJ Bell" <email@hidden>
Subject: Reducing interruption latency for feedback-loop
To: email@hidden
Message-ID:
<email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm trying to get a feedback-loop for a digital-analog converter
running at 40 kHz (or faster). Ideally, I would like to respond to
each sample as it comes and not let any back up.
I'm a little unclear as to what you're describing here, and
particularly what you mean by "not let any back up".
This is essentially what I have so far:
thread_priority_set(...)
start
while(running)
{
if(sample is ready)
{
read/write
usleep(0);
}
}
stop
This implies that you are running in userspace, and since there are
no hard realtime guarantees available to you, you must be prepared to
tolerate delays of tens or hundreds of milliseconds.
I have been able get it to run for 24 sec with only 100 to 200
interruptions that, each time, cause roughly 4 samples to back up --
on a 1.17 GHz dual-core G4, using a 3rd-party driver which
communicates via PCI. Since the device-manufacturer doesn't yet
provide PCI Express cards, I am unable to upgrade computers at this
time.
Any suggestions on how to reduce the interruption latency?
Do your work at primary interrupt time, in the device driver's
interrupt filter method.
Using a multi-core computer, can I tell the scheduler to ensure that
the thread runs uninterrupted (well, with interruptions limited to 30
or 40 usec in latency) on a CPU at all times?
No.
Is it necessary to work in the kernel to achieve what I'm looking for?
Yes.
Can I increase the granularity of usleep()?
I'm not sure what you mean by "increase the granularity". As has
been pointed out, usleep() is typically as precise and reliable as it
can be on a given system. I don't think that's really relevant here
though.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden