Slow PCI-GPIB

[CoryC]

I am trying to move my tester PC from a Win NT 4.0 600MHz machine to a Win XP 2.8GHz machine, but the data transfers are running very slowly on the new machine. I am using Agilent IC-CAP software to run the tests. Does anyone know why this is happening?

Thanks,
Cory

[ScottieB]

What version of the driver are you using on each machine? What exactly about the data transfers is slow? Are you timing the runtime of an ibwrt, for example? Or are you timing the entire program and it seems slower? Has anything else changed besides the machine & OS? (Other instruments on the cable, the program itself, etc)?

Thanks,
Scott B.
GPIB Software
National Instruments

[CoryC]

Scott,

The new XP machine is running driver version 2.3.0.3500, but I have not had a chance to get the version off of the old NT4 machine (it is going to be a few years old). I wrote a simple benchmark program in Visual Basic, and found that the new computer is actually running a little faster in GPIB transfers than the old one (which makes sense). However, when I use the HPIB_read function in the Agilent device modeling program (ICCAP), the time to read approximately 1600 characters (1 character/read) has gone up from about 20 seconds to several minutes. It seems that there is a lot of overhead for each read, as when I try to read all of the characters at once it only takes a second or so (but there are other issues which prevent me from using this approach). Do you have any idea why a third party application might slow down like this?

Thanks,
Cory

[ScottieB]

Cory,

This is a bit of a shot in the dark, but I would be interested to know if v2.2 of the driver is more on par with the performance of the NT machine. Because of the way you're reading (small chunks of data) and the fact that I'm not sure how HPIB_read() calls into our driver, there's a possibility that you're hitting a known issue with 2.3. You'll need to completely uninstall v2.3 of NI-488.2 and then perform a fresh install of 2.2.

Also, an NI-Spy capture would be useful of the nonworking case. See this KB on how to do that, and post your results. Be sure to let me know which driver version your NI-Spy capture is from.

Thanks,
Scott B.
GPIB Software
National Instruments

[CoryC]

Scott,

I installed the v2.2 driver, and my 3rd party application is now doing the 1.6K single character reads in a few seconds as compared to minutes with the v2.3 driver. This seems to be a good solution for me. However, one thing I noticed is that my VB benchmark program now has transfer speeds similar to what I got on the old NT4 machine (this is not an issue for me though).

Thanks,
Cory

[ScottieB]

Cory,

Glad to know that you're good for now. The issue in 2.3 will definitely be addressed in the next version of the driver. I'm still curious about your VB test. So on v2.2, you're seeing similar performance in your VB test to the NT machine...Was 2.3 faster? What does your VB test do? (Large chunks of data or small?) How significant is the difference in speed between 2.2, 2.3, and NT (which I'm pretty sure is 1.2)?

Thanks,
Scott

[CoryC]

Scott,

My VB benchmark sets up an Agilent 4156 to measure enough data to put 14K characters into it's buffer. Then I either do a single read into a 50K character string variable, or 14K reads into a single character string variable. The benchmark runs the large read test 5 times and then the small read test 5 times and gives the average characters/second for each. The results for each configuration are as follows:

Machine Driver Large Reads Small Reads
NT4 ~600MHz ? 8405 Ch/sec 5267 Ch/sec
XP 2.8GHz v2.2 8358 Ch/sec 5871 Ch/sec
XP 2.8GHz v2.3 11946 Ch/sec 7284 Ch/sec

Cory

[ScottieB]

Cory,

Odd. The numbers you show above are what I would expect to see (as you said), but this third-party app is having difficulty acheiving this sort of throughput from what you describe. I think what would be interesting is an NI-Spy capture of this "IC-CAP" software running its 1600 1 byte reads. The HPIB_Read() function must call some function that is slow on the XP 2.8 w/2.3 loaded, but fast on the NT 600mhz with 1.2 loaded. I can examine the spy log to see if there's anything odd in there that might explain this behavior.

Of course, these steps aren't necessary if you're up and running and don't want to mess with it, but for my curiosity, I'd like to work with you further.

See the link above for a KB with special instructions on taking NI-Spy captures.

Thanks,
Scott B.
GPIB Software
National Instruments

[CoryC]

Scott,

I have attached a zip file with the IC-CAP macro that does the transfer, and the saved NI Spy capture. The capture is fairly long, as there are 1350 data points with about 12 chars/point, but except for the beginning and the end it is just the single character reads.

Cory

[ScottieB]

Cory,

That spy capture is interesting because it does reveal an inefficiency in the way that it reads data. The instrument might require this behavior, but it shouldn't if it fully complies to the 488.2 spec. For each single byte that is read, the program is setting the talker and listener on the bus, which takes 3 bytes to do. That's what all the "ibcmd" calls are that are interspersed with the ibrd() calls. The code really only has to do this once, not every single time it wants to do an ibrd(). . .This is definitely going to make it inefficient, but it doesn't quite explain why it was fast on the NT machine. Perhaps the code calling into the NI-488.2 driver is more efficient in the NT incarnation, and it doesn't make all those redundant ibcmd calls...

If you have further questions, feel free to post again! Thanks for the spy cap.

Scott B.
GPIB Software
National Instruments

Message Edited by ScottieB on 06-13-2005 12:48 PM