multitasking question
Joel Sherrill
joel.sherrill at OARcorp.com
Mon Feb 11 23:31:42 UTC 2002
" (Michael P. Collins on korat)" wrote:
>
> Stan wrote:
> >
> > Hi,
> >
> > How to determine the CONFIGURE_MICROSECONDS_PER_TICK and
> > CONFIGURE_TICKS_PER_TIMESLICE value for optimal performance.?
> >
> > At the present time, I use
> >
> > #define CONFIGURE_MICROSECONDS_PER_TICK 833
> > #define CONFIGURE_TICKS_PER_TIMESLICE 3
> >
> > with 68000 (16 MHz).
> >
> > What do you think about it?
>
> Eric Norum replied:
>
> > Offhand I'd say that 833 usec/tick is pretty fast for a 16 MHz 68000.
> > Your system will be spending a significant portion of its time
> > entering/exitting/executing the clock interrupt handler.
>
> To provide some real-world info, I have been using the following
> parameters on a 25MHz MC68331 board over the past few days:
>
> #define CONFIGURE_MICROSECONDS_PER_TICK 122
>
> /*
> * Timeslice interval is approx. 20ms.
> */
> #define CONFIGURE_TICKS_PER_TIMESLICE 164
>
> I've had as many as four tasks running simultaneously, three of which
> can be pretty busy for short intervals, and have not apparently run out
> of bandwidth. Now I can't say that my configuration is optimal; the
> numbers chosen were simply first guesses, however I would expect Stan's
> configuration should work at 16MHz.
>
> On a related note, what is the best way to determine how a CPU's
> bandwidth is being used within an application? I've thought of adding
> some diagnostic code to each task which drives an output signal high
> while the task is running (this works for tasks which do something
> then execute rtems_task_wake_after()) but I suspect there are probably
> better methods.
See cpuuse in libmisc. Alternatively, I have some gdb macros to
do something similar.
> -- MC --
> --
> mcollins at wdc.sps.mot.com
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list