Why is the ibrsp command 100 time slower with 2.3 vs 1.7 driver?

[tambur]

Using the exact same application software and only changing the driver, we see an increase in the time it takes to do an ibrsp command. With 1.7 it takes 0.24 ms and with 2.3 it takes 30 ms.

[ScottieB]

Tambur,

Please use NI-488.2 v2.2 if this issue affects you.  The bug was discovered after the release of NI-488.2 v2.3.  It will be addressed in the next version of NI-488.2.

Scott B.

[tambur]

When will 2.4 or the next version be released? How can I get notified automatically?

[ScottieB]

Unfortunately, we do not have an automatic notification system for driver releases.  The first place that it will be posted is www.ni.com/downloads under the link "Drivers and Updates".  While I cannot give solid release dates, I would expect it to be released well before the end of the year.  There are, obviously, many things that can go wrong and delay software releases, so do not depend on this date.

Is there something that is keeping you from using v2.2 in the mean time?

Scott B.

GPIB Software

National Instruments

[tambur]

As I said before we are evaluating 2.2. We are going to proceed very cautiously and do a lot more testing of any new version of this driver. If something so fundamental as the execution time of the command ibrsp can change so dramatically in a minor release, who knows what else could be wrong. When we first started testing the NI PCI-GPIB card we used the 1.7 version of the driver. We changed to your most recent offering, 2.3, just in the last few months. We changed to aleveate a couple of problems...

1. The SRQ line drops after reading all available data but sometimes the bit in the status byte doesn't. We thought that 2.3 fixed this but not in all cases. We have a workaround in where we issue another ibrd command that fails, but clears the bit.

2. Sometimes the RQS interrupt is not sourced even though the SRQ line does go high. We have a workaround for this also. We normally wait on an event that is set by the interrupt service routine (IRS) established in the ibnotify command. When we timeout waiting for this event, we check the SRQ bit in the status byte, if it is set we manually execute the ISR else we alarm/error out.

Version 2.3 doesn't completely fix these problems. It only makes them occur less often.

FYI

One other problem that you may not be aware of is that the ReadStatusByte command fails in 2.2 and 2.3 where as in 1.7 it succeeds using the same VB program with all versions, 1.7, 2.2, and 2.3. This problem does not concern me in that we do not use ReadStatusByte in our production software, only in a test program that is being obsoleted.

[ScottieB]

Tambur,

I understand your concern over this bug.  We realize that customers depend on the stability of the NI-488.2 driver over the course of many releases, and we do our best to minimize change to the driver while supporting today's newest technologies.  This particular bug was introduced while we added more support for multiprocessor and hyperthreading systems.  We have instituted tests to prevent both command and data byte timing from changing from one release to the next in the future.

With respect to your other issues, I am not ready to label them as "bugs" in the driver.  If you would like to post more information, we can work through them and determine the true root cause.  If they are indeed bugs, I would like to get them fixed so that other users do not have to struggle with them.  If they are issues with your understanding of the API, then we can address that as well. 

RQS, SRQ, Autopolling, IBWAIT, and IBNOTIFY are probably the trickiest parts of our API to understand.  For example, the SRQI bit in the IBSTA word should reflect the status of the SRQ line on a board level descriptor, but the RQS bit in the IBSTA word on a device-level descriptor will not always reflect the status of the RQS bit in the device.  This is because the GPIB standard has certain limitations that we have to work within.  We can get into the specifics if needed.

Let's tackle the issues in whichever order you deem appropriate, handle them one at a time, and get resolution.

Thanks,
Scott B.

GPIB Software

National Instruments

[tambur]

ScottieB,

Thank you for the information and your support. At this time we are not prepared to invest the time to nail down the problems we are having with our software interacting with NI PCI-GPIB card and its driver. When our current workarounds seem to be insufficient, we will start a new post. Jessica Kinnevan, NI, is going to notify us when a new version is ready with the fix of the ibrsp timing problem. Until then, we will be using one of the previous version, 1.7 or 2.2. We are running throughput tests on 2.2 now and should be able to decide on which one soon. In preliminary testing, 2.2 is very close to 1.7 in the timing tests we are doing. In 1.7 ibrsp takes 0.24 ms, in 2.2 0.35 ms. Even though 2.2 is about 1.5 times slower than 1.7, we are only talking about 110 us.

Todd Ambur

Ultratech

[ScottieB]

I wanted to follow this thread up with a notification that NI-488.2 v2.4 has released.  Click here to see all current driver versions.

Thanks
Scott B.
GPIB Software
National Instruments

[tambur]

Thank you for the notification. What type of performance gains are we talking about? We have standardized on 2.2. We probably won't move to 2.4 without some signification throughput increase or major bug in 2.2 because of the cost associated with testing, releasing, upgrading and liability. We were significantly impacted when we changed from 1.7 to 2.3.

[ScottieB]

There aren't performance gains with respect to the ibcmd()/ibrsp() speed, so staying on v2.2 is fine.  Mainly, new hardware is supported along with a couple other minor changes.  I understand the burden associated with testing new releases.  When you do decide to move, I wanted to let you know that 2.4+ should not change the ibcmd()/ibrsp() performance as we have implemented a test to detect these changes and will consider them a release-stopping problem if we discover other performance hits in future releases

Scott B.

GPIB Software

National Instruments