Serious Performance hit on RT (cFP 2120) using LV 8.5 compared to LV 8.2

[geirove]

---

Riconquistiamola wrote:
While we are giving several customers one-on-one support with this LabVIEW Real-Time 8.5 performance issue, we consider our internal investigation closed.


Cheers.

---

I find it surprising that the internal investigation has been closed. The LV 8.5 RT Performance issue has a much wider scope than just the Shared Variables.

On December 12. 1007 I sent an example to Ching Phuong that demonstrates that 3 Simple Loops reading / writing local variables also has 6% points higher CPU Load on LV 8.5 RT (cFP 2120) than it has on LV 8.2 RT (cFP 2120).

Ching has verified this problem. How can NI then simply state that the problem is <<resolved>> ? I find this strange and unsatisfactory. The simple test I provided to Ching is not specific in any way.

If NI simply resigns, then the CFP is for all future use less usefull than it used to be. If this trend is allowed to continue, this does not indicate a bright future for NI's RT technology.

Conclusion is: The performance problem is not resolved, so please do not state that it is.

[Ching_F.]

During our investigation, National Instruments has found that there are a few things that may increase the CPU usage of your application when upgrading to LabVIEW Real-Time 8.5 on FieldPoint controllers.  If you are experiencing increased CPU usage as described in this thread, please implement the corrective actions listed below.

1.  Disable LogosXT.  Refer to this KnowledgeBase article for more information on how to do this.

On FieldPoint controllers, the new shared variable protocol may result in a decrease in the performance of your application.

2.  Upgrade to NI-FieldPoint 6.0.1.  

NI-FieldPoint 6.0.1 increased performance of "All Channel" reads and writes on digital input and digital output modules.

3.  Add EnableCPULoadDisplay = FALSE to the [lvrt] section of your ni-rt.ini file. Reboot your controller.  

On FieldPoint controllers, installing LabVIEW Real-Time 8.5 may incorrectly turn on CPU load measurement. This has shown a 2 - 4% increase in CPU usage in certain applications.

4.  Minimize thread switching in your application.

Our investigation of pure LabVIEW code causing a 6% increase in CPU usage found the CPU increase is exacerbated by the application containing multiple thread switches.

As a result, we can expect customers to see more or less CPU usage depending on the amount of thread switching in the application. National Instruments can help minimize the amount of thread switching if you are experiencing this performance decrease in your application.

While this performance decrease occurs across all controllers running LabVIEW Real-Time 8.5, performance decrease is graded and much less likely to affect applications on controllers with faster processors.

Root cause investigation has narrowed the performance decrease to code changes in the RT Scheduler required to support new features in LabVIEW Real-Time 8.5. As a result, the RT Scheduler requires additional overhead to execute thread scheduling.

We consider the CPU increase a trade-off needed to support features introduced in 8.5. We will continue work to minimize the performance impact of these changes while still retaining the features. This investigation is documented for R&D in CAR 4HSBEPCY."

If the above corrective actions do not resolve your performance issues, please contact your applications engineering department for further assistance.  National Instruments is committed to making your RT applications on FieldPoint successful.

[Wayne.C]

Ching,

Thank you for summarizing this in one post.

[Neil.Pate]

I have been following this thread for some time now, purely out of curiosity.

It is interesting that someone seems to be awarding Geir Ove 1 star for a lot of his comments when they are perfectly valid.

We all know what a 1 star rating can do to a members overall rating.

Interesting...

[Ben]

I have to admit that I am indebted to Geirove for bringing this issue to the front.

Without his tenacity, I would have been a "lone voice crying in the wilderness" and wondering if there was a fundamental falw in my applications.

I also would like to that Micahel Ching and the others at NI who have worked behind the scenes to address this issue.

As I often tell my rookies "The first step in fixing a problem is defining the problem." It appears that the NI and LV user partnership haas not only ID'd the problems but has also provided a path to a solution.

Ben

PS: NO NI did not pay to write this posting. It's Friday and I am in a good mood.

[Jimmie_A.]

Hi,

I am glad to see that we have been able to summarize and explain what caused the problems and that we are working on minimizing the impact of the thread switching.

Geir and Ben have both been pushing us - and we appreciate your feedback and concerns how to make LabVIEW a better product.

Have a good weekend,

[Wayne.C]

nrp,

You are right about the 1 star ratings.  Considering all the time and effort involved , Geir Ove deserves much better. 

But as usual I see that the forums have already begun to correct the problem.