I need to know NIOS2 CPU utilization

Hi jan,

You might want to try vmstat ... it has a simple text-based

output that may be helpful ... I'm not sure if it's included with

the released apps, but you can probably find it at uClinux.org.

Otherwise, you can cook up shell script to read the info directly

from the /proc filesystems ... as I recall, that's all that vmstat

does anyway.

Regards,

--Scott

hello Scott,

thank you for answer, I investigated more your idea and found following:

- /proc/vmstat does not contain info about cpu utilization, I think it highly depends on target system (NIOS, PC,..), even more there exist no application "vmstat" as in normal linux (I tried it in cygwin, and there it works)

- but I went through all /proc system report files and found, that /proc/stat produces required info abt CPU utilization on the first line identified by "cpu" keyword

- ok I told to me - try to make app, which will extract this line and compute CPU usage

- this was succesfully done, but the results are not so good, because:

- I think the time consumed by idle and user(system) apps. which is indicated in /proc/stat increases (and also decreases) very very slowly, when another strong process starts (or stops) to have heavy load on CPU. In my example I had CPU usage at about 2 or 3 % in idle state, when I ran heavy IP communication, then NIOS2 CPU usage raised to 95 % but after abt. 5 minutes!! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif which is of course impossible delay time for any testing.. maybe there is some settings for kernel to force him to measure more precisely, but I do not believe this.. ??

- I also tried my small application under cygwin in normal PC and it also seems to have a great lag (the current CPU usage value looks like to be averaged in long time - for ex. in one minute)

- ok, now I have decided to follow my first idea with my own special application for measuring CPU usage, I will see, but I believe in succes http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif or another ideas?

Hi jan,

> - /proc/vmstat does not contain info about cpu utilization,

I was referring to the &#39;vmstat&#39; application which reads /proc/stat,

/proc/meminfo, etc. -- it&#39;s normally part of the procps package.

> even more there exist no application "vmstat" as in normal linux

Don&#39;t be silly :-)

http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/...procps/vmstat.c (http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uclinux-dist/user/procps/vmstat.c)

> but the results are not so good, because:

I&#39;ve never observed a 5 minute delay. You might want to check your code ;-)

... and take a look at the vmstat code. You may also want to look at

/proc/loadavg ... which is often more meaningful.

Regards,

--Scott

hi Scott,

thanks, now it works well - I have forgotten to include line which saves old CPU times, from /proc/stat, so it produced averaged values from the time when the application started http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

maybe, if you are not disgusted with my small problems, you can give me advice how to get exact 20ms timing in uClinux running in NIOS2. I tried classic timer using interrupt with SIGVTALRM signal, but the time, which I measured did not correspond to the time period, which was set before timer started and even more the timer delay is not equivalent, I found this unpleasant feature, when tried to make my own CPU usage monitoring application - It looks like the timer has very low interrupt priority... So it was the "lucky" reason to get back to your advices and search for error in my code.. But the unlucky issue is, that there is no chance to get precise continuous timing or yes?

with regards jan

Hi jan,

> can give me advice how to get exact 20ms timing in uClinux

> running in NIOS2

Linux user-space timer mechanisms don&#39;t always behave in a manner that

most embedded developers would expect. For example, on some systems

usleep(1000) will sleep for 20 msec ... not 1 msec! 8-P

A (potential) work-around is to use select() system call ... which may give

you better resolution on some systems ... and is relatively portable.

I&#39;ve used it successfully on several PowerPC & ARM systems with timeouts

as low as 1 msec ... although I haven&#39;t tested it with Nios-II/uClinux.

You might want to give it a try (and let us all know what you learn).

Ultimately, this all depends on your hardware timer though :-)

    struct timeval to;
  to.tv_sec = 0;
  to.tv_usec = SOME_USEC_VALUE;
  select( 0, NULL, NULL, NULL, &to );

Regards,

--Scott

hi Scott,

Thank you, I tried your advice and it it pretty nice..

But I need timer with interrupt service, which will work as an interval timer and will call interrupt service routine each 20ms. I followed "KURT-Linux User Manual" especially UTIME library. In fact the programming from the user view is the same as for standard linux timer. UTIME library just increases the timer resolution on reasonable value - under 1ms. I suppose that in uClinux must be something similar implemented.

I tried interval timer with this code:

#include <signal.h># include <sys/time.h># include <stdio.h>
static int i=0;
void timer_handler(int signal)
{
    printf("%d\n",i++);
}
void setitimer_test(int delay, int interval, int tries) 
{
    struct itimerval timer;
    sigset_t mask;
    struct sigaction action;
    int i;
    timer.it_interval.tv_sec = 0;
    timer.it_interval.tv_usec = interval;
    timer.it_value.tv_sec = 0;
    timer.it_value.tv_usec = delay;
    sigemptyset(&mask);
    action.sa_handler = timer_handler;
    action.sa_flags = 0;
    sigaction(SIGALRM, &action, 0);
    setitimer(ITIMER_REAL, &timer, 0);
    for (i = 0; i < tries; i++)
    {
  sigsuspend(&mask);
    }
    timer.it_interval.tv_sec = 0;
    timer.it_interval.tv_usec = 0;
    timer.it_value.tv_sec = 0;
    timer.it_value.tv_usec = 0;
    setitimer(ITIMER_REAL, &timer, 0);
}
int main()
{
    setitimer_test(500000,500000,1000);
}

it generates interrupt after each 0.5 sec, but when I used my stopwatch and averaged through long time, I found, that the real time interval is about 0.96*0.5 sec, where 0.96 is some magic constant.. And even more it seems, that sometimes time intervals are not the same, sometimes shorter period, sometimes longer.. So, this did not impressed me so much, now I am trying to make timer kernel driver, also described in KURT manual, but it is a hard task for me, so wait a bit.. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

I wish to have direct access to NIOS2 high_res_timer defined in linux_1c20.ptf file. Is it possible?..

with regards jan.

Hi Jan,

Within your itimer code, the delivery of the signal SIGALRM to your application is a source of offset in term of accuracy. The signal is generated within one clock tick (10 ms for Nios II) of the timer expiring, but your application needs to be scheduled first in order to handle that signal. If the system is busy enough, you could lose some signals.

Currently the kernel does not utilize the other nios timer built in the core. I don&#39;t know of any reason why you can not use that timer and do some work in the timer interrupt service routine. In fact, I think this is the best solution if you have a high requirement for accuracy.

regards,

wentao

Hi all,

hello wentao, thansk for answer, but.. the accuracy of the timer using SIGALRM signal is not enough, since when the period is small (I need 20ms periodic timing) then there is problem with high jiffy (jiffies), which is the basic time step for linux process management. It means, when any process is not handled by process mangement service now, then it is handled after one jiffy period when the next system timer interrupt occured. jiffy time is 10ms for stadard linux and it seems also for NIOS2 uClinux. I think so, because I tried small example, which initializes periodic timer with interrupt and just counted some value in interrupt routine and compared with realy real time on my watches and here are the results:

period (watches time)/(NIOS2 "real" time)

------------------------------------------------------

200ms 1.06

100ms 1.11

50ms 1.21

20ms 1.52

10ms 2.00

5ms 2.02

2ms 5.05

1ms 10.08

So as you can see, it looks very strange. My explanation comes from www.tldp.org, where they say, that after the kernel timer is served by appropriate process, it is always removed from timers queue by process manager.. and now it depends on, whether the periodic timer is restarted automatically - independantly on this machinery - which is the only case to produce exact periodic timing or the timer is renewed by process manager and due to this there is some additional processing delay (maybe even more complicated by the jiffy value, I suppose 10ms) which is added to the timer period.. So the SIGALRM use is definitelly not the right way for NIOS2 uClinux...

From the kernel description I made my issue, that there is no chance to get exact timing only in kernel user space. There is also problem with modifying kernel, because I can not just write my own timer driver, due to the fact, that my process must be always handled by kernel process manager which works with default (big) jiffy step. The only way I see is the jiffy redesign to be much more smaller (< 1ms), but I am not experienced to do this..

I will be happy for any ideas http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/blink.gif

with regards Jan

Hi Jan,

SIGALRM is not the right solution when you have strict timing requirements. This is true not just on Nios II.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

From the kernel description I made my issue, that there is no chance to get exact timing only in kernel user space. There is also problem with modifying kernel, because I can not just write my own timer driver, due to the fact, that my process must be always handled by kernel process manager which works with default (big) jiffy step.[/b]

--- Quote End ---

I still don&#39;t understand why you cannot take advantage of the second Nios timer in the core. In fact, I think this is the best solution for you.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

The only way I see is the jiffy redesign to be much more smaller (< 1ms), but I am not experienced to do this..[/b]

--- Quote End ---

you can just change the HZ value in head file include/nios2-nommu/param.h. One jiffy will be 1ms if HZ is 1000. This might make the generation of the signal more accurate, but this will not make the delivery of it faster. Besides, your system will have an interrupt overhead...