RT FIFO results in 100% cpu load?

[GerdW]

Hi,

I'm trying to replace some queues with RT FIFOs on a cRIO9074 target (using LV2011), which should be rather easy as the API is very similar for both:

This example VI works for sure: the lower loop puts an I32 into the FIFO each 100ms, the upper loop should wait for "timeout" (set to 50ms) before attempting to read a new element from the FIFO. For this example the upper loop should run (about) 2-3 times for each iteration of the lower loop due to 50ms timeout.

The problem I have is: it reports 100% cpu load and I don't get why it says so:

Where does this example VI burn 100% cpu load? Does the RTFIFORead just poll the current FIFO state?

[Norbert_B · Accepted solution]

Have you checked if a timeout of >100ms also creates 100% CPU load?

Please note that the Create FIFO provides configuration of reading and writing for polling vs. blocking. Refer to the help for detailed information.

Norbert

[GerdW]

Hi Norbert,

thanks for your comment on the blocking/polling behaviour. That's what I missed when replacing queue by RT-FIFO…

Default behaviour is to poll for both read and write access.

Results:

- setting timeout to >100ms still results for 100% cpu load for default polling modes

- setting blocking mode for atleast read access gives <15% cpu load for this example VI…

[skusie]

Hi GerdW, Hi Norbert,

thanks a lot for sharing this problem and its solution. I searched two days for the reason of the high cpu load. And it really was "just" changing the r/w modes to blocking. I wonder, if it wouldn't be better to change the default value to blocking.

Kind regards,

skusie

[Norbert_B]

skusie,

the default setting is polling (with maximum speed, hence the 100% CPU load) is the fasted method to react on a new elelemt. For most RT applications, this is by far more important than 100% CPU load.

I am not sure, so please take care with the following:

The polling should have the priority of the caller, so if the FIFO Read is contained in a low(er) prioritized VI, it should create 100% CPU load, but other threads may preempt the polling.

Norbert