why does taskDelay(1) take so long?
Bob Johnson
ticks per second (shown by sysClkRateGet). If I call tickGet() at
random times, I get numbers with no specific pattern.
However, if I call taskDelay(1), and then tickGet, I ALWAYS get a
value which a is a multiple of 20. It seems that the taskDelay is
taking much longer than 1 tick.
I tried running my test at priority 3 and priority 100 and neither
priority made a difference.
Any ideas?
Thanks!
Ilya Krasavin
May be the timeslice that your scheduler uses is multiple of the 20
ms. Every time you call to the taskDelay() - you actually calls your
scheduler and signal it that another task may be run now, so scheduler
allocates the timeslice to it. After the timeout of original task is
expired it will get control immidiately only if it runs on highest
priority among other tasks.
Try to rise priority of your task.
Ilya
Martin Raabe
taskDelay(0) is giving up the time slice, taskDelay(1) is waiting one or two
ticks!
After that the task gets to the state ready again and it is up to the
priority scheme, when the task next gets the CPU!
Ciao
Martin Raabe
"Bob Johnson" <eagl...@yahoo.com> schrieb im Newsbeitrag
news:67868445.02010...@posting.google.com...
Bob Johnson
Thanks for the suggestions. Unfortunately..
To test how often the scheduler runs, I used the function
taskSwitchHookAdd. This will call a function during every task
switch. In that function, I incremented a counter. During every
taskDelay(1), the counter increments 20-30 times. That means that
task switching is occurring as expected.
As far as the priority is concerned, I am already running at priority
3, and that doesn't help. I increased the priority to 1, just to see
what would happen. That didn't make a difference either.
Any more suggestions?
Johan Borkhuis
> To test how often the scheduler runs, I used the function
> taskSwitchHookAdd. This will call a function during every task
> switch. In that function, I incremented a counter. During every
> taskDelay(1), the counter increments 20-30 times. That means that
> task switching is occurring as expected.
Can you also add a counter to sysClkInt, and see if this routine is called?
Groeten,
Johan
--
o o o o o o o . . . _____________________________
o _____ || Johan Borkhuis |
.][__n_n_|DD[ ====_____ | bork...@agere.com |
>(________|__|_[_________]_|__________________________|
_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
=== VxWorks FAQ: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ===
Donald McLachlan
Does your system have a slow peice of code inside a taskLock/unlock()
or intLock/unlock() block?
--
Donald McLachlan E-mail Donald.M...@crc.ca
Communications Research Centre / RNS Tel (613) 998-2845
3701 Carling Ave., Fax (613) 998-9648
Ottawa, Ontario
K2H 8S2
Canada
Jiandong Wang
sysClkRateSet(nTicks) is a BSP-specific routine. Did you check the BSP
document if you can use 2000 as parameter?(Alough sysClkRateGet shows it has
been set correctly.)
In our system, I normally use 1000 to set the highest time-resolution. I
suggest you set 1000 ticks per second firstly to see if this works
correctly. Then, try 2000.
----------------------
"Bob Johnson" <eagl...@yahoo.com> wrote in message
news:67868445.02010...@posting.google.com...
Ephraim Gadsby
There is nothing intrinsically wrong about 20-30 context switches
during one taskDelay(1) (or even during one tick) but it might be
useful to see what those tasks are. The task-switch handler gets the
TID of the old and new tasks as arguments. I'd dump them into an array
during the delay period.
In VxWork the sequence taskx -> Idle state -> taskx does not
involve any context switches, so presumably there must be two or more
highly active tasks with a real or inherited priority 0.
Also in msg <9tbnst$8l8$1...@uranium.btinternet.com>
David Laight refered to some bugs showing-up above 2k ticks/s.
Bob Johnson
certain that a low priority task is locking interrupts. It only
unlocks the interrupts on 20 tick boundaries.
Bob
eagl...@yahoo.com (Bob Johnson) wrote in message news:<67868445.02010...@posting.google.com>...
Ephraim Gadsby
>Thanks to Donald and everybody else for their help! I am fairly
>certain that a low priority task is locking interrupts. It only
>unlocks the interrupts on 20 tick boundaries.
I'd be interested to know what is going on there.
If this low-priority task locks-out the clock interrupts, how does it
know when the 20 ticks boundary is reached?
It could spin on a counter that is synchronized to the system
clock, but in that case wouldn't most of the clock interrupts be lost
completely, so that the tick-count would not increment by twenty.
Even if the clock can queue-up 20 interrupts, then the fact that
taskDelay(1) always returns on 20 tick boundaries suggests that the
task is spinning with interrupts locked-out for almost all the time.
Frank
I got another question:
If I set sysClkRate=2000, Does that take lots of overhead to OS kernel ?
As I know from document, normally the sysClkRate should be set "<600",while
default is "60".
Is it good to set "2000" so high in real product?
Frank
--
"Ephraim Gadsby" <a@b.c> wrote in message
news:a92p3uc8e8os3ean6...@4ax.com...
Donald McLachlan
> Hi, VxWorkser
> I got another question:
> If I set sysClkRate=2000, Does that take lots of overhead to OS kernel ?
> As I know from document, normally the sysClkRate should be set "<600",while
> default is "60".
> Is it good to set "2000" so high in real product?
>
> Frank
Depends on processor speed and interupt efficiency. Seat of the pants answer:
- run spy to find out % time spent in kernel.
- call sysClkRateSet()
- call clock_setres()
- run spy to find out % time spent in kernel.
adjust as you see fit.