Yes! I did, and I saw.. the time amount measured increases crazyly!!! But,
this instance reported.. seems to be caused by sthing particular.. always
happens near by the same instance.. could it be what?? Anything?
Could be an application bug? A nanosleep bug? No clue for that at all??
.. it is just curiosity!
Thank you so much for your reply.
Cassia Yuri Tatibana
<[EMAIL PROTECTED]>
"Life is hard,
after all it kills you."
Katherine Hepburn
On Sat, 2 Feb 2002 [EMAIL PROTECTED] wrote:
> Linux offers no assurances whatsoever about timing. Try running
> some loads at the same time and see what happens.
>
>
> On Sat, Feb 02, 2002 at 09:53:22PM -0200, Cassia Yuri Tatibana wrote:
> >
> >
> > Hello
> >
> > I've been running real time threads under Linux (kernel 2.4.0-test10),
> > using SCHED_FIFO policy in order to try to describe temporal behavior of
> > these tasks under Linux (not real time linux). The threads use the highest
> > priority allowed for the scheduller (5 threads, 5 different priorities)
> > and each of the five threads implemented use the same code but different
> > periods.
> >
> > Periods are determined by nanosleep call, which is called using a
> > different time amount parameter according to each thread's chosen period.
> >
> > My idea was to see how these tasks were treated by Linux, through the
> > analysis of the time interval caught in each instances of the tasks
> > executed (response time: instant of task's execution conclusion -
> > instant of task arrival).
> >
> > Well after adjusting the nanosleep time amount paramenter (in order to
> > get a more precise sleep period), the response times got were closer to
> > the expected.
> >
> > But sometimes, like coming from nowhere, one instance of the
> > experiment returns a time value much higher than the rest.
> > (ex: when most of the values are 67us, this particular instance returns
> > 20ms). And I just can't imagine what it could be!! All I know is that it
> > is caused by the nanosleep call, which, despite being called with a time
> > parameter very close to the rest of the instances, takes much more time in
> > sleep..
> > It has happens once in each experiment (first task with 3000 instances /
> > period = 50ms), and sometimes it just don't happen...
> > Would anyone have a clue of what could it be?
> >
> > The code of my little program can be downloaded in
> > http:\\www.lcmi.ufsc.br\~cytatiba
> > the file is tr5.c
> >
> > Thank you so much!
> > Cassia Yuri Tatibana
> > <[EMAIL PROTECTED]>
> >
> > "Life is hard,
> > after all it kills you."
> > Katherine Hepburn
> >
> >
> >
> >
> >
> > -- [rtl] ---
> > To unsubscribe:
> > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> > echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> > --
> > For more information on Real-Time Linux see:
> > http://www.rtlinux.org/
>
> --
> ---------------------------------------------------------
> Victor Yodaiken
> Finite State Machine Labs: The RTLinux Company.
> www.fsmlabs.com www.rtlinux.com
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
