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?
Solved! Go to 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.
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.
- 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…
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.
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.