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

[Riconquistiamola]

Hello everyone,

Our investigation is ongoing, but I have a couple of points to update everyone.

• On FieldPoint controllers, installing LVRT 8.5 may incorrectly turn on CPU load measurement. This has shown a 2 - 4% decrease in performance in certain applications. This can be corrected by inserting EnableCPULoadDisplay = FALSE in the [lvrt] section of FieldPoint lvrt.ini file and resetting the controller.
  
• We have seen performance decreases related to caching in RT 8.5 compared to RT 8.2.1. We have not determined a cause at the present time.
  
• As mentioned in many posts above, we have reproduced an increase of 10 - 15% CPU usage but not the 30% increase mentioned by others.
• We are currently working with a customer system shown to have the 30% increase.
• We will continue to update this forum, but if you would like more help please contact your local AE Department.

Cheers.

[Ching_F.]

Hello everyone,

We've continued our testing, and as mentioned in Michael's post earlier, we have been able to reproduce CPU loading similar to that seen by Geir when using his example code.  After including the ini tokens that Michael provided in the previous post the increase in CPU usage was approximately 15% (24% CPU load in LabVIEW Real-Time 8.2.1 and 39% in LabVIEW Real-Time 8.5).

In addition, we have found that some of the performance issues may be specifically linked to reading from and writing to digital inputs and outputs via the FieldPoint API.  If you are experiencing this issue, please contact your local AE department.  They will be able to provide a workaround for you. 

We will continue updating this forum as we continue testing.  If you have any additional questions or concerns, please contact your local AE department or reply to this forum.

[Roy_F]

For tracking purposes, here are some CARs that have been reported to R&D so far as part of troubleshooting this problem:

CAR 4EUGC7X6 - FieldPoint VIs Run Slower and Increase CPU Usage (8.5 vs 8.2.1)

CAR 4F4IN39A - Default value of INI token causing 2 - 4% slowdown.
CAR 4FEFCU00 - Embedded Digital Read/Write is slower in FP 6.0 than in FP 5.0.1.
CAR 4FD7TN1R - Performance Degradation In LabVIEW 8.5.

Roy

P.S.

Info and work compliments of Ching and Michael (and others). I just want credit for posting the CAR numbers. 🙂

[geirove]

Hello,

CARe to explain where and how these CAR numbers may be used?

Thanks

Geir Ove

---

Roy F wrote:

For tracking purposes, here are some CARs that have been reported to R&D so far as part of troubleshooting this problem:

CAR 4EUGC7X6 - FieldPoint VIs Run Slower and Increase CPU Usage (8.5 vs 8.2.1)

CAR 4F4IN39A - Default value of INI token causing 2 - 4% slowdown.
CAR 4FEFCU00 - Embedded Digital Read/Write is slower in FP 6.0 than in FP 5.0.1.
CAR 4FD7TN1R - Performance Degradation In LabVIEW 8.5.

Roy

P.S.

Info and work compliments of Ching and Michael (and others). I just want credit for posting the CAR numbers. 🙂

---

[Jimmie_A.]

Hello Geir!

Whenever a bug is reported we write a Corrective Action Report (CAR) or a bug report if you like. In LabVIEW 8.0 for an example we didn’t publish the bugs that have been corrected or known issues and how to get around these. If you on the other hand look in LabVIEW 8.5 Readme file you will find a subset of issues fixed between LabVIEW 8.2.1 and LabVIEW 8.5. Note that this is not an exhaustive list of issues fixed in the current version of LabVIEW. You will also find a list of known issues still present and possible workarounds. Now when you have access to the CAR ID, you can use it in order to track when the issue will be fixed.

[geirove]

---

Jimmie A. wrote:

Hello Geir!

 Now when you have access to the CAR ID, you can use it in order to track when the issue will be fixed.

---

That was the second part of my question: Where on NI's site do I track this CAR Ids ? I have searched for them in vain.

Geir Ove

[Ben]

Hi Geir,

Jimmie's reply should have read;

"Now when you have access to the CAR ID, you can use it in order to track if the issue has been fixed in the most recent release."

The AE's have access to a report that tells them about what is planned to be fixed in which version.

See here for a list of the bugs fixed in LV 8.5.

Ben

Message Edited by Ben on 11-29-2007 11:04 AM

[Roy_F]

---

geirove wrote:

...Where on NI's site do I track this CAR Ids ? I have searched for them in vain.

---

As Ben indicated, you can not "track" the CAR's current status on our web site, but there are a few places where the CAR ID might show up:

• LabVIEW 8.5 Known Issues - http://zone.ni.com/devzone/cda/tut/p/id/6449
  This is a live document; i.e. we regularly update this as new issues are discovered. Not all issues make it on this list.
  There are numerous things we consider when deciding which CARs are included here and which are not, but in general,
  if it is helpful to tell people about an issue, we will. When is that not the case? Trivial and/or cosmetic problems, extreme
  edge case problems, there's just nothing helpful to say (e.g. labels are not aligned with fields in dialog xxx), etc.
  When given a new CAR ID, it might show up here in the near future.
   
• LabVIEW X.Y Bug Fixes - http://zone.ni.com/devzone/cda/tut/p/id/6448
  We now document the CARs we fixed in a release for all releases (we used to only do that for maintenance releases). Not
  all CARs get documented, but the bar for inclusion in this list is lower than that used for Known Issues. For example, an extreme
  edge case problem would be included here as it is helpful for those who reported the problem to know if it was fixed or not.
  When given a new CAR ID, it might show up here in a future release.
   
• Discussion Forum threads.
  If you know the CAR ID of a particular problem, you can search for that ID in our forums and perhaps find a thread with some useful
  discussion on the problem, perhaps some alternate workarounds.

Roy

Message Edited by Roy F on 11-30-2007 06:02 PM

Message Edited by Roy F on 11-30-2007 06:03 PM

[Riconquistiamola]

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.

Please note one more CAR for this issue.
LogosXT causes a significant increase in CPU on compactFieldPoint controllers This was reported to R&D (4HNCF7CY CAR ID) for further investigation.

Please contact your local Applications Engineering Department if you are experiencing performance problems when upgrading to LabVIEW Real-Time 8.5.

Cheers.

[Ben]

Thank you for the update and exceptional support you have provided on this issue!

You wrote;

"

......internal investigation closed.

....(4HNCF7CY CAR ID) for further investigation.

"

Please clarify this apparent contradiction.

Ben

Message Edited by Ben on 01-25-2008 07:30 AM