gpib performance C#

[Michael The Developer]

Hello,

My question is about understanding and optimizing the performance of GPIB communications. I am curious about the reasons why I observe a very inconsistent performance measurements:

sequence of synchronous write commands (Device.Write):
- write 1, 167 bytes, 0.6 ms
- write 2, 957 bytes, 1.6 ms
- write 3, 558 bytes, 42.6 ms
- write 4, 12 bytes, 113 ms

read on events from GPIB (OnNotify -> Device.Read):
- read 1, 29 bytes, 0.74 ms
- read 2, 55 bytes, 2 ms
- read 3, 46 bytes, 0.5 ms
- read 4, 11 bytes, 0.9 ms

I am using C# interface in NationalInstruments.NI4882 namespace of the NI drivers ver. 2.46 (Windows XP). On one side of GPIB it is my software application, on the other - a custom hardware device.

Could you explain me in more details what is actually happening in the SW/FW/HW during the read/write commands and what can be the bottleneck for the data transmission?

Is there any way to optimize this performance? For example I saw "bus timing" in the GPIB configuration options, with settings 2us, 350 ns, 500 ns.

Thank you.

Michael

[Nick_D]

Hey Michael,

You may try to test out timing of the bus, Sometimes for wire lengths, changing the timing of the bus can improve the situation.

Something I'm curious about, is if you're to constantly do the same size output, for example 167,167,167,& 167. Does it give you the same timing? also, do you have any other processes going on in the background? It may just be a cause of the non-determinism of windows that is causing this.

Regards,

Nick D

[Michael The Developer]

Hi Nick,

I connected the GPIB packet sniffer to analyze the performance in more detail on the lower level. What I found that it seems that write delays are caused by the FW, which tries to processes the packets as it receives them. Thus, when I combine all my messages into one, and write all this at once it takes several milliseconds to do so, and it is very consistent. In fact I see that all the data is transmitted over the wire during this time, so it is not buffered somewhere in the driver. So, I am not concerned with the writing performance any more.

Inconsistent reading still bothers me, but it seems that I found a really big problem - which is the delay between when FW sends the data, and when I receive Notify callback from NI driver. I see the data being transferred over the wire almost instantaneously, but I get the NI Notify call in my C# assembly 60-100 ms later!

To answer your question - there is no heavy processing on the SW side. So, it seems that either NI driver itself, or its interface to C# is very inefficient. Of course there is a third option that I am doing something wrong 🙂

Best regards,
Michael

[Nick_D]

Hey Michael,

Something that may be causing this in reads is your word size that you specify. If you make you're word size too large, your program will have to wait for a termination character, and I think that you may be able to see faster results if you specify the word size to be exact.

A troubleshooting strategy, I'm not sure if you're already using this, but you can try to use NI-Spy to see what is being sent and at what time.

Another strategy that may work, is if you were to read 1 character at a time, and try to concatenate strings. This may add lots of delay, but there's a chance if the wait on the return character is too slow, that it may improve you situation.

Regards,

Nick D.