Tiny Core Linux
General TC => General TC Talk => Topic started by: Tuftec on June 07, 2011, 12:49:46 AM
-
Does anyone know how to change the timer resolution under Tiny Core?
I am trying to work with a Real Time version of Tiny Core. It appears that the default timer resolution is only 3.3ms on my system (1Ghz X86 CPU).
I would like to change this to something smaller, like 100uS or even 10uS.
Is there some easy way to change this? Maybe a boot option?
-
for high resolution timer you need to use clock_gettime() and clock_nanosleep() like in this example
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#A_Realtime_.22Hello_World.22_Example (https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#A_Realtime_.22Hello_World.22_Example)
-
Hi Tuftec
You might want to be a little more specific about what you are trying to do. Are you referring to the
scheduler, interrupt timing, calling a timer from a program?
I see Arslan S. just posted, you might want to add gettimeofday to his list.
-
I am calling clock_nanosleep() from within a real time program, with the rt patched Tiny Core kernel.
I am finding that the sleep time is limited to a multiple of the jiffie time, which is 3.333ms. I was trying to sleep for only 100us.
-
Hi Tuftec
You probably have to increase the priority of your task, otherwise you will be competing for time with
the other running tasks on an equal or less than equal basis.
-
My task is running at a priority of 99.
It does not appear to be competing with other tasks in the system.
The task runs consistently but will only sleep for 3.3ms. Even when I specify a sleep time of 100000.
I want it to sleep for a shorter time.
-
Hi Tuftec
According to the link Arslan S. posted kernel tasks run at a priority of 50. Maybe you can't run at a
priority higher than that? You could also attach a file with the code you are testing, maybe someone
with some experience in this area will spot something.
-
Here is a copy of the test code that I am running.
It is a modification of another piece of code I found that generates square waves on a parrallel port.
I just modified for my embedded computer hardware.
-
long time ago i have setup real time kernel for tc 2.x tested it on a mobile p4 platform with a similar parallel port square wave program, verified results with an oscilloscope connected at the parallel port pins
i remember successful results for a period of 100us
did you try cylictest program to see if everything is ok ?
it is available in rt-tests.tcz extension
sudo cyclictest -i 1000 -n -t -p 80base interval of thread is 1000us, use clock_nanosleep, start one thread per cpu, highest thread priority is 80
one more thing high resolution timer is also availabe in standart tc kernel
-
I tried running cylictest. I am not really sure what all the numbers that it outputs actually mean.
Things like this
T: 0 ( 3129) P:80 I:1000 C: 22703 Min: 1745 Act:52963515 Avg:26482632 Max:52963515
I thought the clock_nanosleep() call uses the High Resulution Timers. That is where I detected the issue. the HRTs seem to only work down to resolutions of 3333116 nanoseconds.
-
that's the latency between actual and expected sampling time values in us (micro seconds)
what is computer specs you are running ?
-
If I run the cyclictest with no options it reports that the High Resolution Timers not available.
System is embedded system on chip.
1Ghz clock, equiv to 586 style processor. 600Mhz RAM bus speed.
-
i think your system does not have hr timer, it is not the tiny core linux kernel
-
Wait, one of the Xcore86 / DMP / Sis etc cheapos? I really doubt they support better timers, high res ones need hardware support.
-
Hi Tuftec
It does not look promising, but as an act of desperation you can try hpet=force or one of the other
hpet boot codes list here.
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
-
Yep using a DMP SOC system.
So what timers exactly does TC look for.
The DMP chip has 2 x 8254 style timers on board (same as a regular PC I believe).
I will check a bit closer to find how their resolution is set. But I would suspect this is an OS setup thing.
I will look at the force option.
-
Ah yes!!!!
I have just done some reading. The 8254 timer implementation is the problem.
For HPET (and hence HRT) the timers need to be 8253 type.
I guess I could drop the tick (jiffie) time down to 1ms for a marginal improvement but 3 x as many interrupts and probably some sacrifice in performance.
Changing the hardware is not my preference at this point.
Is there an easy way to experiment with different jiffie times? Maybe a boot option or modprobe command or something?
-
No, I don't think they can be set any other way than build time. Many compile-time constants depend on the value.
-
Hi Tuftec
Go to this link
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
and search that page for the word jif
You will find 2 possibilities for changing the kernel's timing. Don't be to aggressive with timing changes.
Linux was not designed to do context changes every few microseconds.
-
Thanks
-
Hi Tuftec
By the way, the link I provided you is chock full of information. You do however need to dig a bit and
get your hands dirty to find some of it. The column on the left includes other subjects such as
scheduler. And as an example of digging, there is some more information about scheduling under
the subject Block.