Speeding up VxWorks' clock....

[Christian Williamson]

I'd like to make the clock on VxWorks run faster than one sixtieth of a
second. Anybody done this before? What effects does it have on VxWorks'
own tasks?

[Jeffrey Creem]

Post by Christian Williamson
I'd like to make the clock on VxWorks run faster than one sixtieth of a
second. Anybody done this before? What effects does it have on VxWorks'
own tasks?

I've run "production" systems as fast as 200 Hz. I certainly have seen
some source code drivers and other things that do things like
taskDelay(N) that sure seem to assume that it is 60 Hz.

I've seen third party add in libraries that only do the sysClkRateGet at
initialization time.

So, to be safe, I'd set it in the BSP during initialization rather than
changing it later. There is probably a small chance you will run into an
issue with some specific piece of code but in general, it works.

There are good reasons to increase it but there are also cases where
there are better solutions.

What is the effect you are trying to achieve?

[Christian Williamson]

Post by Jeffrey Creem

Post by Christian Williamson
I'd like to make the clock on VxWorks run faster than one sixtieth of
a second. Anybody done this before? What effects does it have on
VxWorks' own tasks?

I've run "production" systems as fast as 200 Hz. I certainly have seen
some source code drivers and other things that do things like
taskDelay(N) that sure seem to assume that it is 60 Hz.
I've seen third party add in libraries that only do the sysClkRateGet at
initialization time.
So, to be safe, I'd set it in the BSP during initialization rather than
changing it later. There is probably a small chance you will run into an
issue with some specific piece of code but in general, it works.
There are good reasons to increase it but there are also cases where
there are better solutions.
What is the effect you are trying to achieve?

I've got some polling in a task going on; I want to use nanosleep() to
have the taskDelay spend less time in the delay.

[Jeffrey Creem]

Post by Christian Williamson

Post by Jeffrey Creem

Post by Christian Williamson
I'd like to make the clock on VxWorks run faster than one sixtieth of
a second. Anybody done this before? What effects does it have on
VxWorks' own tasks?

I've run "production" systems as fast as 200 Hz. I certainly have seen
some source code drivers and other things that do things like
taskDelay(N) that sure seem to assume that it is 60 Hz.
I've seen third party add in libraries that only do the sysClkRateGet
at initialization time.
So, to be safe, I'd set it in the BSP during initialization rather
than changing it later. There is probably a small chance you will run
into an issue with some specific piece of code but in general, it works.
There are good reasons to increase it but there are also cases where
there are better solutions.
What is the effect you are trying to achieve?

I've got some polling in a task going on; I want to use nanosleep() to
have the taskDelay spend less time in the delay.

And that is one of those good reasons! :)

[Michael R. Kesti]

Post by Christian Williamson
I'd like to make the clock on VxWorks run faster than one sixtieth of a
second. Anybody done this before?

Yes, certainly. The system clock rate is set using sysClkRateSet(). The
allowable range of system clock rate is specified by the macros
SYS_CLOCK_RATE_MIN and SYS_CLK_RATE_MAX in the BSP's config.h file.

Post by Christian Williamson
What effects does it have on VxWorks'
own tasks?

None, when using priority premptive scheduling which is the default
scheduling algorithm. When using round-robin scheduling (sometimes
called time slicing) a faster system clock rate increases scheduling
resolution just as the resolution of all timed processes is increased.

The cost of an increased system clock rate is increased timer ISR
overhead. Whether this is a problem depends on system performance and
loading. I've run 40 MHz MPC860 systems' system clocks at 1000 Hz in
order to get millisecond resolution without difficulty.

[Ben]

Just a "me too" vote here. I've implemented a system at 500Hz without
difficulty. In fact, we chose 500Hz because that was the same rate that
our legacy pSOS-based system was running at - at the default of 60Hz,
we simply weren't getting enough resolution to do everything as
precisely as was required.