System clock rate ???
Martin Roth
following tools:
- Tornado 2.2 and Vxworks 5.5 for 82xx family
-SBC8260 reference board - 8250 and 8270 targets (similar to 8260)
- Our designed CPU board runs under 66 Mhz bus, ~165 Mhz CPM and ~198 Mhz
core
Our system is driven by a periodic task which wakes up periodically every 10
msec (there is no drift).
To get resolution of 10 msec I have changed the system clock to 100 ticks
per second.
Now I am getting an additional requirement to allow Vxworks style watchdog
in 1 msec resolution.
For example, we have warmed up the radio for 20-30 msec before starting the
transmit. To speed up the communication, we have a requirement for maximum
3-4 msec of warmup time. There are additional cases that we need short
timers.
I can think about two possibilities to solve the general problem:
1) To define the system clock as 1000 ticks per second and use the Vxworks
watchdog timers.
2) The system clock rate is not changed, but an additional hardware timer is
used to synchronize a high priority (server) task which is notified
according the variable needs of the system. The task keeps a linked list of
event records sorted by difference of time. When an event expires, the timer
activates the task that activates the registered function corresponding to,
which runs the first function one in the queue.
No doubt, that it is easy to implement the first solution , however have
performance concerns.
Questions:
What is better from performance and CPU load time point of view 1 or 2?
Did anybody define the system clock as 500 or 1000 ticks per second ?
Martin Roth
Motorola
Patrick and Susanne
Martin,
The second method sounds better. Increasing the system ticks can
generates kernel overhead (kernel will take more CPU than the
application itself).
But this depends on your application architecture (amount on interrupts
connected and periodicity, time constraint, how the tasks are used..).
Many CPU are faster enough to support a system clock rate with 1000
ticks per seconds (I got systems working with system clocks set to 1000
ticks).
HTH,
Patrick
Martin Roth
What was the architecture (CPU, CPU clock , etc.) with 1000 ticks per second
?
Martin
"Patrick and Susanne" <patrick...@arcor.de> wrote in message
news:3f92c...@news.arcor-ip.de...
Emmanuel Herbreteau
Imho, you should use a auxiliairy clock for the
fastest task. This is what we've done on our
MPC 555 design. But our CPU runs much slower
than your 8260...
Regards
Emmanuel.
Martin Roth wrote:
> - Tornado 2.2 and Vxworks 5.5 for 82xx family
Ganesh Okade
The second option is the right one. Infact VxWorks gives you a
"Auxiliary Clock" exactly for this purpose! Check your BSP and see if
it supports an Auxiliary clock on the second timer.
Ganesh Okade
Sunlux Technologies
www.sunlux-india.com
Mario Semo
what problem can there be with 1000 ticks per second? i drive my CPUs
(Pentium 350) with 4000 ticks.
the 1st stmt in my startup file is:
sysClkRateSet(4000)
--
mit freundlichen Grüßen/best regards
mario semo
"Martin Roth" <bmr...@email.mot.com> wrote in message
news:bn0acm$la3$1...@newshost.mot.com...
Martin Roth
system clock interrupt.
I have changed the system clock to 100, 500, 1000, 2000 Hz by
sysClkRateSet() call.
I addition , I performed some heavy ping and I have defined a low priority
task that counts a counter.
The time given to the low priority task should somehow be reflected by the
value reached by the counter.
After 30 second (per each clock rate) I print out the value of the counter.
The difference is very low for the above clock rates.
The difference in the counter when the clock rate is 60 Hz and 2000 Hz is
only 1% !!!!
I did not create Vxworks watchdogs, which also may have some influence on
the system clock time interrupt overhead.
Can I conclude that the additional overhead of the clock interrupt is only
1 % of the CPU power?
If so why not define the system clock rate as 1000 Hz ?
I do understand that the performance of the system depends on many
additional factors and the most important one
is the total overhead in % you sacrifice for system calls.
Martin Roth
"Martin Roth" <bmr...@email.mot.com> wrote in message
news:bmu7ld$hu9$1...@newshost.mot.com...
Andrew Johnson
>
> Can I conclude that the additional overhead of the clock interrupt is only
> 1 % of the CPU power?
> If so why not define the system clock rate as 1000 Hz ?
When vxWorks was first written, a system clock rate of that order would
have used up a significant proportion of the CPU time, maybe all of it on
some machines. Thus the default of 60Hz is there for historic reasons,
and because customers who are upgrading probably expect it to stay the
same - there are probably many calls to taskDelay(1) in vxWorks
application code that shouldn't have been written like that and which will
break if the rate is raised.
- Andrew
--
There are 10 types of people in the world:
Those who understand binary, and those who don't.
Chris Hann
to process the system clock tick.
Wind River will still tell you dire tales of high system clock rates but
they are just that, tales. By modern standards the system tick doesn't
do much processing. I know of one Highly Priced company that was running
the system clock at 800Hz on a ppc860 in around 1998, would that be a 40
or 50MHz part? Their Windview plot showed that the tick was processed in
a couple of microseconds!
The system clocks have been run up to 10s of kHz during stress testing
and the system still didn't fail. The RAD6000 (the processor that ran
the lander on the Mars Pathfinder) was run much faster than that during
testing.
The 60Hz rate is an anachronism, Jerry Fiddler or Dave Wilner probably
decided mains frequency was good enough for the system to reschedule and
there after we were landed with a 16.67ms tick. Of course most of the
world is on 50Hz and the military is on 400Hz, but what the heck, the
idiosyncratic US mains frequency is as good a number to start with as any.
As Andrew pointed out you need to remember that any delays you have
should be evaluated relative to the the system clock rate obtained from
sysClkRateGet(), so a 10th of a second delay is:-
taskDelay(sysClkRateGet()/10);
Chris
Andrew Johnson wrote:
> Martin Roth wrote:
>
>>
>> Can I conclude that the additional overhead of the clock interrupt is
>> only
>> 1 % of the CPU power?
>> If so why not define the system clock rate as 1000 Hz ?
>
>
David Laight
> hello,
>
> what problem can there be with 1000 ticks per second? i drive my CPUs
> (Pentium 350) with 4000 ticks.
> the 1st stmt in my startup file is:
> sysClkRateSet(4000)
Don't go above 2147Hz, if you do select() will fail if tv_usec is large.
You also need to tell the RTC - or gettimeofday() etc don't work.
Also if your system stays up for 2^32 ticks the RTC gets stuffed.
David
almo...@hotmail.com
Since software is cheaper than hardware, I would try not to add hardware. I've
seen i960/33MHZ do a lot of work with a 1000 tps clock.
Make the change, and see how it affects your CPU load. The ability to hold such
a clock is very application-dependant.
If an aux clock is available, than things get even better.
AR
Vikas
But what if the Aux Clk is not supported by a particular BSP. e.g in
MVME5100 BSP by VxWorks , sysAuxClkRateSet( ) is not supported.
(the auxiliary clock always runs at the same rate as the system
clock).
Can anyone suggest some other software solution , apart from using
sysClkRateSet() to get a periodic interrupt say every .5 milli sec
...something hopefully more efficient ?
Thanks,
Vik
Martin Roth
I have compared the idle when the system clock is 1000 tps (ticks per
second) and 100 tps.
The test was performed on PPC 8260 processor, 66 Mhz bus, 198 Mhz core.
The idle time at 1000 tps was by 1 % less than at 100 tps.
So there is no overhead (1%) when you increase the system clock from 100 tps
to 1000 tps.
The only question that you have to ask your self is what is the impact of
your application on the performance ? In other words, you should understand
how frequent does your application cause to context switching ?
For example:
The context switching takes 30 usec.
You are running 50 tasks, each of the tasks periodically runs the CPU for 30
usec and then delays or waits for a very short (1 msec) event.
In this case the overhead of context switching is at least 50% (30 usec
running and 30 usec context switch), so the system is not efficient.
If you can prove yourself that the nature of your system does not cause to
too expensive context switching overhead , you can define the system clock
rate to 100-1000 tps. Of course, you should also take into account
additional overhead factors within the system clock interrupt like watchdog,
etc.
In my system I need a ~2-3 ms resolution timer and it is activated maximum
once per second.
If I set the system clock to 1000 tps, I am loosing 1% of CPU.
In addition, once per second there is an additional context switch and this
is not expensive.
Vik, I do not have the sources of Vxworks, but I will apply to Windriver and
ask them what additional overheads (like watchdogs) des the system clock
interrupt perform ? If there are no additional overhead, I tend to define
my system clock rate as 1000 tps.
Of course, there is an additional factor like CPU power, speed, etc. - for
you to check.
Martin Roth
Motorola Israel
"Vikas" <vik_g...@yahoo.com> wrote in message
news:f62c1578.0311...@posting.google.com...