Benchmarking GPIB

[dragon5]

I wonder if there is a GPIB benchmarking methodology similar to RFC2544 for network interconnect devices that can be used to characterize the performance of a GPIB device.

How do I compare the linux-gpib bitbang driver performance to the proprietary solutions?

I get up to 80 KBytes/s download speed when I download waveforms from Yokogawa DL1540L with the linux-gpib bitbang driver over wireless network ( https://www.hackster.io/lightside-instruments/wireless-lan-gpib-gateway-with-open-source-hardware-6e0af8 ). How do I know if the bottleneck is the oscilloscope or the adapter?

[colorado.rob]

Networking is easier because it typically uses fairly symmetric protocols. GPIB is asymmetrical. You would need to have some sort of test device that could sink and source GPIB data at the theoretical max rate, and report on the throughput of the host.

[dragon5]

Yes. But how difficult is to connect any FPGA to the 16 bit GPIB connector and make this reference devices that only source and sink traffic at optimal speed?

[coromonadalix]

for 1  device it could be possible   but many instruments on the gpib  may give you different values / timings,   if you mix  oldies vs new stuff

some of them require specific commands who can slow your gpib system(s)  different brands are not equal

better use network when possible,  but once again having an 100mb 1Gb   line  doesn't mean the instrument will spit values faster ...

[pqass]

As others have said, the source of the bus data is usually the limiting factor (eg. ADC speed). 

As for the bus itself, GPIB is basically a TTL-level bus (48mA line drivers) at most 15m long without terminators and with open collector handshaking lines (DAV, NRFD, NDAC). You can drive it as fast as the peer can stand (it's asynchronous) until bad data creeps in (due to capacitance, reflection, etc. affecting line quality).  To mitigate errors, intentionally limiting the data rate is all there is unless each peer implements a CRC as part of their data exchange.

Higher powers have decided that given the topology, the maximum data rate should be 1MB/s in standard mode or 8MB/s in high-speed mode (according to this).  FYI: see page 13 for the handshaking protocol explained.

[alm]

For a purely synthetic test, the easiest is probably to connect a second GPIB interface, known to be faster than the one you're testing, to the same computer. Set this adapter to device mode (supported by most of the brand name adapters) and connect them together with a cable without anything else on the bus. You can now send data back and forth as fast as the GPIB interface will go.

[ballsystemlord]

OP, maybe this isn't obvious, but (based on all the various TE docs I've read), most test equipment will display data on their screens faster than they'll upload it to a PC, with or without GPIB. I don't understand why, that's just they way most test equipment is.

[rcjoy]

Probe the DAV, NRFD, and NDAC lines with an oscilloscope or logic analyzer to determine whether it is the host PC (and its GPIB adapter and software driver) or the instrument that is the limiting the speed.
Have only one instrument on the GPIB bus when making these measurements.

When sending data from the PC to the instrument:
  The time between the PC driving DAV low to the instrument driving NDAC high:  this is the instrument limiting the speed.
  The time between the instrument driving NRFD high to the PC driving DAV low:  this is the PC limiting the speed.

When sending data from the instrument to the PC:
  The time between the instrument driving DAV low to the PC driving NDAC high:  this is the PC limiting the speed.
  The time between the PC driving NRFD high to the instrument driving DAV low:  this is the instrument limiting the speed.

[alm]

OP, maybe this isn't obvious, but (based on all the various TE docs I've read), most test equipment will display data on their screens faster than they'll upload it to a PC, with or without GPIB. I don't understand why, that's just they way most test equipment is.

It depends on what kind of test equipment. Systems multimeters like a HP 34401A may be able to do thousands of measurements per second, but there's no way they can display them that fast. Never mind that you'd be able to read them. So they achieve their fastest speeds via GPIB: possibly by reading batches into internal memory and then read a batch from memory via GPIB. Scopes have a very different architecture where they sample into sample memory and then display as fast as possible, and reading quickly via GPIB is generally not a priority.

[DavidKo]

HP 66332A have for example buffer of 4096 points for dynamic measurements with smallest sampling rate of 15.6us for such a purpose. Than you can read the values from buffer with slower interface (RS232 supports 9600baud on that device, command processing time 4ms). Clearly the measurement cannot be read out in real time .

[dietert1]

I remember testing a DIY GPIB adapter with two of them connected to two PCs and looking at the transfer rate depending on transfer size. The CPLDs in those devices use digital filters for debouncing input signals at a sampling rate of 18 MHz. The implied data rate limit is about 3 MHz. The PC interface is a FT245RL USB chip (at most 1 MByte/second). The maximum transfer rate was as expected. Really the test was more about error rate.
In general when using GPIB for T&M automation such a PC adapter won't be the limiting factor. You need a very fast instrument to demonstrate the difference between two different adapters. Of course somebody can make a really bad adapter that slows things down, e.g. using bit-banging drivers.
As far as i understood nowadays good USB adapters are available from China for about US$ 85. Does this justify benchmarking? Is this about identifying fakes?

Regards, Dieter