Using DSP/BIOS IDL_busyObj for CPU load in 5.41.02.14

Jim -

It looks like you've seen this article, that's good.

I don't have knowledge of how the minimum idle loop is calculated, so unfortunately I can't give a great answer here. 

However, I did have a thought. You said the 'max' value is correct if you run in CCS? If you run your application repeatedly in CCS, is the 'max' value consistent?

Because the 'max' field is used to calculate the overhead of the idle loop, which I imagine is a fixed value for your device, I wonder if you could simply hardcode the value into your application. That is, don't bother looking at the 'max' field at runtime, just use a fixed value for 'minIdleLoop'.

Maybe give that a try and see if the load values you calculate seem reasonable?

Thanks,

Chris

Hi Chris-

Thank you for your response.

Yes, the "max" value is always basically the same in debug build, and it basically matches the value I get in release build after "enabling" it by starting CPU load trace in CCS. Hard-coding to this is the fallback plan. However, we want this code to work on multiple platforms (DM642 and DM648), and be robust to upgrading the DSP/BIOS, etc. Hence, I really want to do it the *right* way.

In release build, it does not work even if I take off all optimizations, and tell it to generate debug info. At that point, there is no difference I can find between release and debug builds, other than we have an _DEBUG prepoc def in debug build (for our use). They are linking with same version of BIOS and libraries. Also, I know there is a way to make it work, if I can just figure out how to kick the OS like is done when CCS starts the CPU trace.

I noticed a function in the map file (IDL_F_calibrate) but I cannot figure out how to explicitly call it to see if that is magic trick. Also, can't figure out why it would be called in debug and not release, though it seems a whole lot of BIOS decisions are made by tools based on .tcf, and they may take into account wether its release or debug?.  

Jim

I'm not familiar with the RTA implementation in CCSv3, but I am in CCSv4, and I know that the CCSv4 solution doesn't do anything special to kick the target.  

I built the BIOS stairstep example with the release profile, and ran it in BIOS 5 RTA in CCSv4. I get a reasonable value (326 on an evmDM6437) on the first read of the STS records.

RTA reads the STS records by sending down a command to call RTA_F_getsts, and this reads and clears the STS object and copies it to a buffer to be sent to the host. This reading and clearing is done in the idle loop.

At what point in the execution of your application are you reading the object? It might be a problem if you're trying to read it before main...

Thanks,

Chris

Btw, I found IDL_F_calibrate and it does look key to the calculation of the idle loop overhead. It has some constraints on when it's called, though, so I don't think it would work to call it yourself. You could try placing a breakpoint on it, though, to ensure that it's being called before you try to read the STS object?

Thanks,

Chris

Hi Cheng-

You don't have to rebuild the bios. The .tcf configures which components of the bios will be included in your project. I'm not 100% certain which (if any) is required to include the IDL_busyObj, but the "special" configurations I have in my .tcf that may be related tot his are:

bios.enableRealTimeAnalysis(prog);
bios.enableRtdx(prog);
bios.enableTskManager(prog);

You can figure out which (if any) are required to have IDL_busyObj supported, but with all three you should be fine, assuming the version of bios you have supports it.

Cheers,

Jim

hi:

    i am very happy to see your reply. i have a problem to ask you ,it is about DSP load,  in the above ,the first step is must ?why? it is right to cal m_minIdleLoop like this.

                       thanks

         best regards

Hi Fengwei-

It is only necessary to calibrate the minIdleLoop as I did if your application can, as mine does, sometimes do chunks of processing in a task that has higher priority than the Bios Idle task. When this happens, the counter for the Bios minIdleLoop value wraps, and the Bios comes up with a negative value for the minIdleLoop, which is interpreted as a large positive number (both bugs in Bios, imho). The net result is you end up with a HUGE, erroneous, value for minIdleLoop, which ruins the CPU load calculation.

minIdleLoop is *supposed* to be the minimum execution time of one idle loop, and is measured by the Bios by keeping track of the minimum delta counter between two executions of the idle loop. Thus, the minimum is reached when the idle loop is run consectutively (nothing else going on in the system). I create a way to explicitly do this (all tasks are sleeping), and just save the value.

Hope this clears it up,

Jim

Hi James Gort:

         I copy your program in CCS,but when compile and run it ,the value of m_load is so so large,this is the program in my project,please help me to check the error.

       Thank you very much.

double m_load, m_percentIdle;
int  long m_minIdleLoop;
unsigned int m_loopCount, m_loopCountOld;
unsigned int m_totalTime, m_totalTimeOld;

void LoadInit(void)
{ 
 TSK_sleep(10);
 IDL_busyObj.max = 0x80000000;
 IDL_busyObj.acc = 0;
 IDL_busyObj.num = 0;
 
 TSK_sleep(100);
 
 m_minIdleLoop = IDL_busyObj.max;
 m_minIdleLoop *= -1;
 
 m_loopCountOld = IDL_busyObj.num;
 m_totalTimeOld = IDL_busyObj.acc;
}
void LoadMain(void)
{ 
 m_loopCount = IDL_busyObj.num - m_loopCountOld;   
 m_totalTime = IDL_busyObj.acc - m_totalTimeOld;
 
 m_loopCountOld = m_loopCountOld + m_loopCount;
 m_totalTimeOld = m_totalTimeOld + m_totalTime;
 
 m_totalTime *= -1; 
 
 m_percentIdle = ((double) m_loopCount * (double) m_minIdleLoop) / double) m_totalTime;
 m_load = (1 - m_percentIdle) * 100;
}

Hi Fengwei-

I'm a little confused--the code snippet that came through in email I got from your post is not the same as the one above. In the email, your code has DSP_OPERATING_RATE as divisor in computation of m_percentIdle. That should not be there--the m_percentIdle is just a ratio values that are all in units of "processor tics", and hence no constants should be used in calculating the % (that is, the snippet above is correct).

Other than that, make sure that your "LoadMain" function above is called at least once every 500 millisecs or so. If there is too much time between calls, the IDL_busyObj.acc will wrap, giving wrong value for m_totalTime, usually smaller than it *should* be, hence giving a percentIdle of more than 100% (the more times it wraps, the larger your erroneous % idle will be).

Also, you should have check m_loopCount is not zero--this can happen if you call LoadMain too quickly back-to-back, and the Bios has not entered the idle loop at all between calls. In this case, just don't compute the m_percentIdle.

Finally, you should add a low-pass filter on the m_load, as it jitters due to fact that Idle loop may only be called a couple times (or zero) between calls to LoadMain.

If you still have problems, please post the values of all of the variables in a call to LoadMain (break on it after you are in steady-state for a while), including the IDL_busyObj values, along with the delta time (as measured by Bios timer) between the call you broke on and the previous call, and then I can help you find problem.

Jim

Hi James Gort

Hi,

I'm just wondering if this method works together well with DSP/BIOS LINK? My task is blocked at calling MPCS_enter() but I'm not sure if the IDL_busyObj is updated during this time, because its fields don't seem to be changed at all. Any clues?

Thanks,

-Tamas

Hi Tamas-

I'm not familiar with DSP LINK, but maybe I can help. The DSP/BIOS Idle task is the lowest priority task, so if any higher priority task is active, the Idle task will not be called. This becomes a problem if a task is doing long, atomic (meaning no task switching--no Sleep, no wait on semaphore, etc.) operation. The Idle task weill not be called until it is done. And, the IDL_busyObj is only updated when the Idle task is called.

So, if the number of times the Idle task is called is zero, it simply means you are at 100% CPU load! Also, note the above thread for dealing with counter wrap issues in cases where you starve the Idle task for long periods of time.

Jim

Hi Jim,

Thanks for your reply. I think, it's clear from your earlier posts how this is supposed to work. Actually, my question was if the MPCS_enter() function call yields the CPU to the idle thread or not.

Nevertheless, you gave me an idea: I inserted a TSK_sleep(10) just before calling MPCS_enter() so that my worker task surely gives the CPU to the idle task for some time. And now, IDL_busyObj is updated! I think, this is a rather disappointing result, because it means that MPCS_enter() does some busy-loop kind of thing rather than a sleep kind of thing. I wish, I was wrong. :-(

Is there anybody out there knowing more about DSP/BIOS LINK to explain if it's compatible with IDL_busyObj? Any help is greatly appreciated.

Thanks,

-Tamás

Hi Tamas-

In the little bit of research I did about MPCS_enter() before I replied earlier, I think you came to correct conclusion--it waits in a stupid polling loop with no sleep! Bad Programmer!

:)

JIm

very hard to understand！