How to reduce high CPU usage caused by receiver thread of CAN messages?

Hello,

I am struck with a serious issue and not able to get through it.I am writing a program which handles the CAN messages Received from BUS.My code is taking almost 60% of CPU usage.

Similar issue discussed here: http://forums.codeguru.com/showthrea...1)-doesnt-work

gg

Adding ::Sleep() to code doesn't "solve" anything.

At best it can give you a false perception that something is running "better" under the specific circumstances you're testing it on. On another computer, with another resource load, other cpu, memory... You may very well have made things even worse by adding that Sleep().

So is there any other way to solve this issue.i am thinking that the buffer size for the receiving CAN messages is not large enough.So by creating larger buffer will solve this issue?

What "issue"?
CPU usage isn't necessarily an issue, as long as real work is getting done. If you are in a hard-spin waiting for data, then a blocking API would be better (as discussed in the other thread).

What CAN library are you using - and how are you using it?

gg

Quote:

---

Originally Posted by Codeplug

What "issue"?
CPU usage isn't necessarily an issue, as long as real work is getting done. If you are in a hard-spin waiting for data, then a blocking API would be better (as discussed in the other thread).

What CAN library are you using - and how are you using it?

gg

---

But for my case its an issue,because of High CPU usage the performance of HMI is degrading.After 3 hours of continuous HMI Pc getting slower.

I am using XL Driver library.

>> My code is taking almost 60% of CPU usage due to the Receiver thread used for receiving CAN messages.
Not sure how to help without seeing some real code - other than "don't call Sleep" and follow the advice in the other thread.

gg

Just google'ing the documentation for xlReceive(), I can see that it isn't being used correctly (msgsrx is uninitialized). It also appears that xlReceive() is always non-blocking, so you're code will be in a hard spin doing a whole lot of nothing while XL_ERR_QUEUE_IS_EMPTY is returned.

Look into the xlSetNotification() API. This will give you a Win32 waitable handle that can be used to wait efficiently for messages to come in. Also consider calling xlReceive() to read more than just 1 event at a time.

Read this for how to post code on this forum: http://forums.codeguru.com/misc.php?do=bbcode#code

gg

Quote:

---

Originally Posted by Codeplug

Just google'ing the documentation for xlReceive(), I can see that it isn't being used correctly (msgsrx is uninitialized). It also appears that xlReceive() is always non-blocking, so you're code will be in a hard spin doing a whole lot of nothing while XL_ERR_QUEUE_IS_EMPTY is returned.

Look into the xlSetNotification() API. This will give you a Win32 waitable handle that can be used to wait efficiently for messages to come in. Also consider calling xlReceive() to read more than just 1 event at a time.

Read this for how to post code on this forum: http://forums.codeguru.com/misc.php?do=bbcode#code

gg

---

Can you please tell me how to avoid the non-blocking of xlreceive().I tried adding xlSetNotification() API in my code.And how can I call xlreceive() to read more than 1 event at a time?
Please help me with this.I am nearing the deadline.

Have you also included the WaitForSingleObject(..). This is the how you write non-blocking code. It's described in the manual together with examples of how its used. RTM!

Code:

---

_declspec(dllexport)
int receive_data(unsigned char *data_output, int *MsgId, XLportHandle g_xlPortHandle)
{
    XLstatus        xlStatus;
    XLevent        xlEvent;
    unsigned int    msgsrx = 1;
    Xlhandle        h = 0;
   
    if (!g_RXThreadRun)
    {
        // TODO - log that we are shutting down?
        return XL_ERROR;
    }
   
    xlStatus = xlSetNotification(g_xlPortHandle, &h, 1);
    if (xlStatus)
    {
        h = 0;
        // TODO - log error, and that xlReceive() will be non-blocking
    }

    if (h)
    {
        // TODO - allow caller to pass in the timeout
        const DWORD timeout = 3000; // arbitrary
        DWORD status = WaitForSingleObject(h, timeout);
        if (status == WAIT_TIMEOUT)
        {
            return XL_ERR_CMD_TIMEOUT;
        }
    }

    xlStatus = xlReceive(g_xlPortHandle, &msgsrx, &xlEvent); 
    if (!xlStatus)
    {
        // TODO - allow the caller to pass in their own XLevent object (and count)
        memcpy(data_output, xlEvent.tagData.msg.data, 8);
        *MsgId = xlEvent.tagData.msg.id;
    }

    return xlStatus;
}

---

See if that helps your CPU usage any.

gg

You will have to profile your code to see if the CPU usage is due to real work being done, or if the code is still "spinning" needlessly in places.

>> After 3 hours of continuous HMI Pc getting slower.
Use something like ProcessExplorer to see if your app has a resource leak (memory or handles) that may explain the degradation over time.
http://channel9.msdn.com/Shows/Defra...ocess-Explorer

gg

Quote:

---

Originally Posted by Codeplug

You will have to profile your code to see if the CPU usage is due to real work being done, or if the code is still "spinning" needlessly in places.

>> After 3 hours of continuous HMI Pc getting slower.
Use something like ProcessExplorer to see if your app has a resource leak (memory or handles) that may explain the degradation over time.
http://channel9.msdn.com/Shows/Defra...ocess-Explorer

gg

---

I have used this tool and I have seen that there is no memory leak.The CPU usage is mainly because of receiver thread which is continuously running,that is used for receiving messages from CAN Bus.The messages come at a rate of 40 milliseconds but this thread is running at a rate in microseconds so increasing CPU usage.So i wanted to know if anything else can be done in the code,which I attached earlier to reduce this fast loop?

If the new code is calling WaitForSingleObject(), then xlReceive() should efficiently return a message on every call - which is followed by the real CPU work of processing that message.

So assuming the CPU usage reflects real work, why do you want to reduce it?
Are you looking to "sample" less than 25 messages a second?
Or do you want to process all 25 messages per second, but use less CPU than you are using now to do so?

If it's the later, then you will have to profile your code to see where the "hot spots" are and optimize.

gg

Quote:

---

Originally Posted by Codeplug

If the new code is calling WaitForSingleObject(), then xlReceive() should efficiently return a message on every call - which is followed by the real CPU work of processing that message.

So assuming the CPU usage reflects real work, why do you want to reduce it?
Are you looking to "sample" less than 25 messages a second?
Or do you want to process all 25 messages per second, but use less CPU than you are using now to do so?

If it's the later, then you will have to profile your code to see where the "hot spots" are and optimize.

gg

---

I think new messages are coming before the previously received messages are parsed.As a result the buffer is overwritten.So can you tell me am I thinking in the correct way?If so by creating a buffer of larger size can solve this issue.The incoming messages are of 8 bytes and a total of 11 messages I am getting,so I need to store all 11 messages in the buffer and then parse the data accordingly.