Google 網路論壇不再支援新的 Usenet 貼文或訂閱項目,但過往內容仍可供查看。

Re: [ace-users] ACE Reactor scheduling precision

瀏覽次數:3 次
跳到第一則未讀訊息

Douglas C. Schmidt

未讀,
2007年4月12日 上午8:15:592007/4/12
收件者:Mario Bouchard、ace-...@cse.wustl.edu

Hi Mario,

> Note: If you cannot aswer the following question, please supply me the appropriate person`s email address.

Thanks very much for your email. Please make sure to send all
questions related to TAO or ACE to the ACE mailing list or ACE+TAO
newsgroup, rather than to me directly since I travel frequently and
often don't have ready access to email. See

http://www.cs.wustl.edu/~schmidt/ACE-mail.html

for more info on how to access these resources.

In addition, to ensure that we have proper version/platform/compiler
information, please make sure you fill out the appropriate problem
report form (PRF), which is in

$ACE_ROOT/PROBLEM-REPORT-FORM
$TAO_ROOT/PROBLEM-REPORT-FORM

or in

$ACE_ROOT/BUG-REPORT-FORM
$TAO_ROOT/BUG-REPORT-FORM

in older versions of ACE+TAO. Make sure to include this information
when asking any questions about ACE+TAO since otherwise we have to
"guess" what version/platform/compiler/options you've using, which is
very error-prone and slows down our responsiveness. If you don't use
the PRF, therefore, it is less likely that someone from the core
ACE+TAO developer team will be able to answer your question.
Naturally, we encourage and appreciate other members of the ACE+TAO
user community who can respond to questions that they have the answers
to.

> Context:
> I wish to use the Reactor to schedule, in a timer based manner, different tasks.
> I see that I can specify the schedule interval using the parameter 4 ``interval`` of methode ``ace_reactor.schedule_timer
> ``.
>
> This parameter is of type ``ACE_Time_Value`` which gives me the capability to set second and microsecond values.
> Questions:
> a) What is the real granularity (millisecond, microsecond) of the timer and the minimum interval value?
> - On Linux.
> - On Windows

Please see the documentation on Windows and Linux for the answers to
timer granularity.

> b) Can I expect being able to schedule with precision a task at 60 hz which means an interval value of 16.666 millisecond?

Yes, that should work fine.

> c) If cannot, what is the closest (ex: 16 or 16.6 etc) I can get to achieve the 16.666 millisecond?
> d) Is there a way to get the real interval value after having start a timer (it may not accept or able to support the
> requested ``interval`` value)? Is there an interval getter methode?

I don't think there's a way to get this info currently, but if you'd
like to add this to the ACE_Timer_Queue and contribute it back to us
that would be great.

Thanks,

Doug

Matthew Gillen

未讀,
2007年4月12日 上午9:02:592007/4/12
收件者:Mario Bouchard、ace-...@cse.wustl.edu
> Mario wrote:
>> b) Can I expect being able to schedule with precision a task at 60 hz which means an interval value of 16.666 millisecond?

ACE is certainly capable of setting up the timers that /should/ schedule your
process at that rate. It's up to your operating system to actually schedule
your process though, so depending on the real-time features of your OS, you
may or may not actually get your process to run exactly every 16.6 ms.

For instance, there are several operations that the linux kernel performs that
can take longer than 20ms. If you happen to trigger one of those operations,
your process will not get scheduled during that period.

>> c) If cannot, what is the closest (ex: 16 or 16.6 etc) I can get to achieve the 16.666 millisecond?

No one can answer that for you. It totally depends on your OS and what
real-time mechanisms you're able to take advantage of. It's also highly
dependent on the exact hardware and versions of Operating Systems you use.

Your best bet is to write a test application that monitors when it actually
gets scheduled and compares it with what it expected. Then, if you want to
see why you want a real-time OS, load the machine up with a bunch of work and
re-run that test app. Your results will probably vary quite a bit if you're
on a non-RTOS.

Matt

0 則新訊息