an analysis of hp-ib performance · hp-ib,performance, measurement systems, test systems,...

FliiiW HEWLETTa:~ PACKARD

An Analysis of HP-IB Performancein Real Test Systems

Keith Moore, Stan WoodsInstrument and Photonics LaboratoryHPL-93-20August, 1992

HP-IB, performance,measurementsystems, testsystems, debugging,monitoring

The LAN Based Instrument and Control project in theMeasurement Systems Department at Hewlett-PackardLaboratories is investigating the control and communicationsrequirements of Test and Measurement instruments and systems.This project is concerned with the functional partitioning of testsystems and the distribution of this functionality into appropriatehardware and software modules.

We investigated the role of Hp·JB in test systems today whileconsidering Hp·JB's replacement with a different communicationmedia such as Ethernet. To facilitate this investigation wedeveloped a prototype Hp·JB analyzer which shows solid productpotential. This analyzer combines three key pieces: 1) a fasthardware front end which time stamps captured data, 2) long termdata storage on disk, and 3) graphical analysis software. Thisanalyzer can capture and analyze bus activity for entire testslimited only by available disk space.

The analyzer can be used in four areas of system development tocharacterize and measure key parameters which can lead toperformance improvement. The four areas are: 1) applicationdevelopment, 2) development of instrument Hp·JB commands, 3)software driver development for controllers, and 4) software driverdevelopment for instruments.

This paper describes the analyzer and the experiment we performed,which consisted of acquiring data from real manufacturing testsystems and analyzing the bus activity. An example is given for theuse of the analyzer in each of the four areas previously mentioned.

Internal Use Only© Copyright Hewlett-Packard Company 1992

Internal Accession Date Only

Internal Use Only

Executive summary 3

1: Introduction 51.1: Brief history of HP-IB 51.2: Our research perspective 5

2: Experiment 72.1: HP-IB analyzer development 72.2: Our biases and expected results 82.3: Research questions 82.4: Description of test systems 10

3: Experimental results and conclusions 113.1: Comments on biases 113.2: Types of tests 123.3: Types of instrument HP-IB drivers/parsers 123.4: Sources of variability 133.5: Timing variability in plot of throughput versus packet size 133.6: Impact of faster controllers, faster instruments, faster HP-IB cards 153.7: Throughput 163.8: Packet size 163.9: Separation of mnemonic execution time 163.10: Error checking 163.11: Addressing time 203.12: Redundant addressing 203.13: Redundant mnemonics 203.14: Replacement of HP-IB by Ethernet 23

4: Potential uses of HP-ffi analyzer 244.1: Application deve1opment. 244.2: Instrument development 244.3: Controller HP-IB driver development 284.4: Instrument HP-IB driver/parser development 285: Future directions 346: Final conclusions and recommendations 35

Acknowledgments 36References 36Appendix A: HP-IB analyzer description 37Appendix B: Data analysis model 40Appendix C Test case summary 48Appendix D: Examples of different HP-ffi instrument parser/drivers 56

1

Internal Use Only

2

Internal Use Only

Executive summaryThe LAN Based Instrument and Control (LINC) project in the Measurement SystemsDepartment at Hewlett-Packard Laboratories is investigating the control andcommunications requirements of Test and Measurement instruments and systems.This project is concerned with the functional partitioning of test systems and thedistribution of this functionality into appropriate hardware and software modules.We investigated the role of HP-IB in test systems today while considering HP-IB'sreplacement with a different communication media such as Ethernet. To facilitatethis investigation we developed a prototype HP-IB analyzer which shows solidproduct potential. This analyzer combines three key pieces: 1) a fast hardware frontend which time stamps captured data, 2) long term data storage on disk, and 3)graphical analysis software. This analyzer can capture and analyze bus activity forentire tests limited only by available disk space.

The analyzer can be used in four areas of system development to characterize andmeasure key parameters which can lead to performance improvement. The four areasare 1) application development, 2) development of instrument HP-IB commands, 3)software driver development for controllers, and 4) software driver development forinstruments.

This paper describes the analyzer and the experiment we performed which consistedof acquiring data from real manufacturing test systems and analyzing the busactivity. An example is given for the use of the analyzer in each of the four areaspreviously mentioned.The analyzer can measure not only key bus timing parameters, but can also displaythe variation of these parameters for an entire test. In addition it can provideinformation regarding the commands used most often for each instrument,throughput bottlenecks in the system, instrument driver efficiency and the effect onthe system of redundant addressing. The analyzer is an excellent HP-IB systemanalysis tool unlike any on the market today.Most of the test cases were partial or complete final test procedures at HewlettPackard manufacturing sites. We do not imply that the results of this experiment arecharacteristic of HP-IB usage in general and caution against using the resultspresented here as such. However the results are based on real test systems and thuspresent examples of HP-IB usage.

The following statements are supported by the test data:

• Most of the system bottlenecks are found in either the controller or theinstruments and not the HP-lB.

• Over fifty percent of the test time can be taken up by addressing bytes. Up totwenty-five percent of the test time is taken up by redundant addressing bytes(the same source and destination for an HP-IB command are used for the currentcommand as for the previous command).

3

Internal Use Only

• The use of instrument drivers may waste test time by sending redundantmnemonics.

• Error checking is not widely used to monitor the instruments comprising the testsystem.

• Instruments can be long lived in test systems. For this reason alone a LAN suchas Ethernet will not completely replace HP-IB for instrument control and willneed to co-exist in the near term.

The design approach we took could be used to create a set of analyzers to look at multibus systems such as dual HP-IB, VXI/HP-IB, SCSI/HP-IB, EthernetlHP-IB. Inaddition the usefulness of the analyzer could be enhanced by creating a tool whichcorrelated the bus activity with a view of the code in the controller responsible for thebus activity.

Tools, like these, are needed to add credibility to Hewlett-Packard's commitment toselling and supporting Test and Measurement systems.

4

Internal Use Only

1 Introduction

1.1 Brief history of HP-IBIn the 1960's and 1970's computers were introduced into test systems to controlelectronic instruments. Computers were used to obtain faster throughput and morereliable and consistent operation than had been previously achieved with manuallycontrolled test systems. Many different approaches were used to interface thecomputers to instruments. Early approaches included dedicated digital lines for eachinstrument function and unidirectional input and output lines for each instrument.Each instrument had a custom I/O card that connected the computer to theinstrument. This approach was increasingly cumbersome as the number ofinstruments in the system increased. [LOUGHRY72]Little progress was made towards a cost and performance effective general purposeinterface until Hewlett-Packard developed a byte-serial interface called the HewlettPackard Interface Bus (HP-IB) in the early 1970's. At the same time there was aninterest in an international interface standard for controlling programmableinstruments. The HP-IB interface was evolved into a standard (IEEE 488.1) whichallowed the integration of computers, instruments and peripherals into powerfulautomated test systems. This interface is now known as HP-IB, the General PurposeInterface Bus (GP-IB), the IEEE bus, the ASCII bus and the PLUS bus.This IEEE 488.1 standard was not enough to ensure a consistent way of interfacingwith instruments. IEEE 488.1 did not specify standard data formats and standardmnemonics for controlling instruments. A following extension, IEEE 488.2 coveredmuch of this, however instruments with similar functions from different companieswere still programmed with different mnemonics. The Standard Commands forProgrammable Instruments (SCPI) has attempted to address this. There are now setsof standard mnemonics for a wide variety of instruments. However, when new typesof instruments are created new mnemonics may have to be added to the SCPIlanguage.Many companies now offer instruments which can be controlled over HP-IB. Inaddition there are graphical user interfaces used to minimize HP-IB programming,libraries of routines to control specific HP-IB instruments and varioustroubleshooting tools to help diagnose HP-IB systems.

1.2 Our research perspectiveThe LAN Based Instrument and Control (LINC) project in the Measurement SystemsDepartment at Hewlett-Packard Laboratories is investigating the control andcommunications requirements of Test and Measurement instruments and systems.This project is concerned with the functional partitioning of test systems and thedistribution of this functionality into appropriate hardware and software modules. Aspart of the project we needed to investigate the role of HP-IB in test systems todaywhile considerin~ the replacement of HP-IB with a different communication mediasuch as Ethernet .

5

Internal Use Only

HP- IB is twenty years old. We were surprised to find no articles which analyzed theHP-IB activity of an entire system in depth. The troubleshooting tools provided by HPand other vendors such as IOTech Inc. and National Instruments do not provide theright combination of deep memory, selective triggering and time stamping of data toallow the bus activity of an entire system to be analyzed.

It is becoming obvious that the computer industry is not going to support HP-IB as ithas in the past. Workstations and peripherals currently offer serial, SCSI, orEthernet I/O options but not HP- lB.

There are conjectures on what is wrong and what is right about HP-IB and how it isused to control instruments but little data to back up or disprove the conjectures. Wewanted to obtain this data and set out to build a prototype analyzer with off the shelftools. Since we were unable to purchase all the pieces we needed, we built a prototypeconsisting of both custom and off the shelf hardware and software which allowed usto capture the bus activity for an entire test. We feel this tool would be useful for avariety of users including:

• Application developers

• Instrument developers• Instrument HP-IB driver/parser developers

• Controller HP-IB driver developers

This paper contains the conclusions from measurements of HP-IB activity on realmanufacturing test systems at HP, a description of the tools used to analyze the testsystems and examples of different views of the data which could prove useful to thefour types of users mentioned above.

1. Ethernet is a registered trademark of Xerox Corporation.

6

Internal Use Only

2 ExperimentThe experiment consisted of attaching the HP-IB analyzer to various test systems,capturing the data and post-processing it in our laboratory. Test sites were more orless selected ad hoc. Factors which affected their selection were geographical location(primarily San Francisco Bay Area), interest expressed by hosting division, contactsmade previously at manufacturing divisions, and availability of test systems due tomanufacturing schedules. At the beginning some of the test sites were used to verifycorrect operation of the custom data acquisition hardware and the custom HP-IBprotocol decoding software.

2.1 HP-IB analyzer developmentThe following sections briefly describe the HP-IB analyzer we developed. Moredetailed information is found in Appendix A.

2.1.1 Description of hardwareThe hardware consists of a non-invasive custom front end which is connected to theHP-lB. This front end detects events of interest, time stamps them and stores themin local memory. At the same time a personal computer with off the shelf hardwareand software is reading the time stamped events from the front end memory andstoring the events to disk. The distinguishing features of this data logger are that thedata storage capability is only limited by the size of the disk drive in the system andthe samples are time stamped for post-processing timing analysis.

2.1.2 Description of information collectedThe information collected consists of the state of the eight HP-IB control lines and theeight HP-IB data lines at the time an event of interest occurred. The time stamp iscollected for the purposes of exploring the timing relationships between states. Thereare also logger status bits which indicate the occurrence of lost events. Lost eventsoccur if the front end memory is not read fast enough by the PC.

2.1.3 Description of analysis softwareThe analysis software consists of custom C language programs which break thelogged data into what we call packets. A packet roughly corresponds to the commandsand data sent in a single Rocky Mountain BASIC 'OUTPUT' statement. Moreprecisely a packet consists of all the bytes sent between sequences of addressingcommands (UNT, UNL, MLA and MTA). The software performs statistics on thetiming of different portions of the packet and outputs this information as variousASCII files which can serve as input data files for a third party graphical analysispackage.

2.1.4 Definition of analysis termsThe following terms were defined to discuss different timing characteristics of thelogged HP-IB data. Appendix B discusses these terms in reference to examples oflogged data if more clarification is needed.

7

Internal Use Only

• Byte delivery time (BDT): The time between DAV true and DAV false.• Interbyte quiet time (IBQT): The time between DAV false and DAV true.• Interbyte time (lBT): The time between two successive DAV true states.

Interbyte time is also equal to the sum of the byte delivery time and the interbytequiet time.

• Interpacket quiet time (lPQT): The time between the last DAV false state of apacket and the first DAV true state of the next packet.

• Packet size: The sum of the number of addressing, control and data bytes in apacket.

• Packet start time: The time the first addressing byte is detected with DAVactive, after one or more control or data bytes.

• Packet stop time: The time the last byte of a sequence of data or control bytes isdetected with DAV inactive.

• Packet duration: The time equal to packet stop time minus packet start time.

• Packet throughput: The number of bytes in a packet divided by the packetduration.

2.2 Our biases and expected resultsWe started the data acquisition phase with biases regarding what we expected to see:

• There would be a noticeable bifurcation on packet sizes and packet throughputs.

• Faster throughputs would correspond to large responses from instruments.

• The maximum throughput would be 200 Kbytes/sec. If this is exceeded themaximum packet size would not be larger than 64 Kbytes. This was based on theHP-IB card specifications for HP 9000 series 300 computers.

• Overall throughput would be low.• RESET, PRESET, RST, *RST, or SDC would be used often to put instruments

into known states.• Group execute trigger (GET) would not be used in multi-cast mode.

• Serial poll would be used more often to query the state of an instrument than asa response to a service request (SRQ).

• Parallel poll would not be used.• Variability would exist in the execution of mnemonics from run to run.• Single bus test systems would be the norm.• Very little downloaded Instrument BASIC would be used.

2.3 Research questionsThe following questions were selected as a means of analyzing each test case andexploring the usefulness of our analyzer. The means we used to answer each question

8

Internal Use Only

follows each question. Appendix C contains plots and tables showing the answers tothese questions for a specific data set.

1. What is the distribution of packet throughputs for a complete test?All the packet throughputs are passed to the analysis package where ahistogram is created.We expect to see a bifurcation of packet throughputs: alarge number of slower throughputs and a smaller number of fasterthroughputs. See appendix C, figure Cl.

2. What is the distribution of packet sizes for a complete test?

All the packet size fields are passed to the analysis package where a histogramis created.We expect to see a bifurcation of packet sizes: a large number ofsmaller packet sizes and a smaller number oflarger packet sizes. See appendixC, figure Cl.

3. What is the correlation between packet throughput and packet size?The corresponding packet throughputs and packet sizes are plotted on an x-yplot using the analysis package.We expect to see larger packet sizescorresponding to faster throughputs. See appendix C, figure Cl

4. How busy is the HP-IB during a test? What does the loading look like?

A list of cumulative bytes transferred is created and plotted versus the packetstop times.We expect to see a series of staircase steps corresponding to largerpacket size and a relative smooth sloped line where there are a lot of smallerpackets. See appendix C, figure C2.

A pulse is plotted for each packet duration. The pulse rises at the packet starttime and drops to zero at the packet stop time. The amplitude for each pulse isnot constant but varies according to a mod function. The mod factor is selecteddepending on the number of packets in a testcase. The effect is a set of rampswhich give an indication of the number of packets displayed on the plot and howfast they are occurring. Ramps with steeper slopes indicate more packets perunit time. White space with no pulses represents interpacket quiet time. Seeappendix C, figure C2.

5. What percentage of the total test time is spent on address byte delivery, controlbyte delivery, data byte delivery, inter-byte quiet time and inter-packet quiettime?

A custom routine adds up the contributions to these five categories and plots thenumbers using the analysis package. In general we expect to see a largepercentage of time spent in interbyte quiet time and interpacket quiet time. Alarger percentage of time will be spent in interpacket quiet time if the test isrelatively long and the bus is not loaded. A larger percentage of time will bespent in interbyte quiet time if there are mnemonics which take a long time toexecute or if the bus is loaded and the time between packets is short. Seeappendix C, figure C3.

9

Internal Use Only

6. What percentage of the total bytes delivered are addressing, control and databytes?

A custom routine adds up the contributions to each of the three categories andplots the numbers using the analysis package. We expect to see the majority ofthe bytes transferred to be data bytes, however if the majority of the packets aresmall then there will be a larger percentage of addressing bytes. A test whichperforms intensive serial polls may have a higher percentage of addressing andcontrol bytes. See appendix C, figure C3.

7. What are the minimum, average and maximums for address byte delivery times(ABDT), control byte delivery times (CBDT), data byte delivery times (DBDT),interbyte times, packet size, and packet throughputs?

A custom routine calculates these numbers and presents the results in tabularform. This is meant to be a summary of selected parameters in the data set. Seeappendix C, table CI.

8. What is the distribution of bytes sent and received on a per instrument basis?A custom routine calculates these numbers and presents them in a tabular formto show the distribution of activity amongst the instruments. See appendix C,table C2.

9. What are the most common sets of commands executed for a given test and whowere the senders and receivers?

A custom routine is used to extract these mnemonics along with the number oftimes the mnemonic was executed in the test and the source and destination ofthe mnemonic. See appendix C, table C3.

10.How often is redundant addressing done during a test? How much test timecould be saved if redundant addressing were not performed?

A custom routine examines the data for sequential occurrences of the samepacket source and destination. The time spent setting up the redundant sourceand destination is accumulated and reported at the end of the analysis. Theresults obtained with this analysis will be discussed later in section 3.12.

2.4 Description of test systemsThe test sites were all located at Hewlett-Packard divisions. We have data fromtwenty-one different logging sessions from seven different test sites. Six of the testsites are manufacturing divisions. One of these is an analytical instrument division,the rest are test equipment manufacturing divisions. The remaining test site is adeveloper of instrument calibration test systems. Most of the tests measured werefinal verification tests, one was a process control application.

10

Internal Use Only

3 Experimental results and conclusionsMost of this experiment was spent developing the HP-IB analyzer and exploring theanalysis possibilities presented by the capture ofHP-IB activity for an entire test. Weused graphical methods and custom software routines for most of our data analysis inefforts to summarize the large amounts of data we collected. Most of the files werelarger than one megabyte of raw data with two test cases producing over fiftymegabytes of data. Our questions were partly determined by the data on hand.Future work would be more selective in the tests to be logged and aimed at answeringspecific questions.Most of the test cases were partial or complete final test procedures at HewlettPackard manufacturing sites.

Note: We do not imply that the results of this experiment are characteristic of HP-IBusage in general and caution against using the results presented here as such.However the results are based on real test systems and thus present examples ofHPIB usage.

3.1 Comments on biasesMost of our biases were substantiated with the following exceptions:

• Faster throughputs did not always correspond to long response messages. Therewas a lot more variation when plotting packet throughput versus packet sizethan expected. This was mostly due to large variations in the time it takes toparse and execute different control mnemonics which contain the same numberof bytes. To make any sense of this plot we had to separate out specificinstruments and in some cases specific mnemonics going to a single instrumentbefore we could show a clear relationship between packet throughput and packetsize. See section 3.5 for more details.

• RESET, PRESET, RST, *RST and SDC commands were not used as often as weexpected. There were only three test cases where these commands were used infour to five percent of the packets.

• There were six test cases where the serial poll packets represented betweenforty-six and eighty-five percent of all the HP- IB packets in the test. As expectedthe serial polls where used to primarily query the state of an instrument and notas responses to SRQs as expected. We did not expect to see serial pollsrepresenting such high percentages of packets in a test case.

• We were surprised at how many test cases used two buses. In all cases the secondbus was dedicated to the unit under test. To analyze these test cases mostaccurately two HP-IB analyzers should be used with a common time base andthe data later merged according to time stamp.

• We did not gather data on different runs of the same test. We cannot commenton how much variation there is in test execution time from one run to another.

11

Internal Use Only

We can look at the variation of the same mnemonic in the same run of a test.There was more variation than expected. See section 3.5 for more details.

3.2 Types of testsAt a high level we can divide the test cases into two types of tests. One type has a largepercentage of time spent in interbyte quiet time implying the instruments are thebottleneck and the second type has a large percentage of time spent in interpacketquiet time implying the controller is the bottleneck. This observation must betempered in the cases where one controller is talking over more than one HP-IB.Interpacket quiet time on one bus may actually be filled with packet delivery time onanother bus.

3.3 Types of instrument HP-IB drivers/parsersWe were able to observe several different timing characteristics inside the packets.

1. No noticeable difference in BDT or IBQT. The bus is released quickly. Themnemonic appears to be executed in the interpacket quiet time. An example ofthis is an HP Modular Measurement System module.

An example ofsuch a packet is shown in figure D1. The interbyte quiet times areshown in bold type. Note also the very short byte delivery times.

2. A longer time is observed for the IBQT associated with a carriage return (CR)implying the mnemonic is executed after this character is parsed. The bus is heldoff. An example is the HP 3335A.

An example of such a packet is shown in figure D2. The longer interbyte quiettime is shown in bold type.

3. A longer time is observed for the IBQT associated with a line feed (LF) implyingthe mnemonic is executed after this character is parsed. The bus is held off. Anexample is the HP 8340A.


4. A longer time is observed for the BDT on every byte except for CR or LF. Anexample is the HP8902A.

An example of such a packet is shown in figure D4. The longer byte deliverytimes are shown in bold type.

The throughput to instruments of type 1 is consistent and in general longer packetstake a longer time to deliver. This type of instrument frees up the controller toperform other tasks, however the burden of ensuring synchronization is placed on thetest developer. Since the bus is not held off it is very important to use *OPC, *OPC?or *WAI with these instruments to ensure the mnemonic has completed beforecontinuing on with the next part of the test.

These are four instrument driver/parser timing behaviors we observed. Additionalbehaviors most likely exist. It would be interesting to plot the number of different HP-

12

Internal Use Only

IB drivers developed by different HP divisions in the computer, instrument, andmedical groups over the last twenty years. Where would we observe inflection pointsin the plot (e.g. introduction of GP-IB integrated circuits, emphasis on code reuse inHP)?

3.4 Sources of variabilityVariability in the data was found to come from a number of sources. It is importantto understand these sources when an entire test system is being analyzed.

1. Test site practices such as the use of a separate bus for the unit under test, useof software instrument drivers, and the use of serial poll versus SRQ: thesefactors will affect the overall style of the test. Instrument drivers may addredundant commands.

2. Programming environment such as RMB Workstation, RMB-UX, and PCs usingQuick BASIC, Quick Cor C: the use ofRMB-UX may introduce larger delays indifferent packets of the test. An example would be when disks are 'synced' by theoperating system.

3. Type of controller used such as HP 9000 series 200, series 300, HP Vectra: eachcomputer has different internal timing parameters such as the operating systemtime 'tick', interrupt latency and task switching times. These can account forsome of the timing variation observed in occurrences of the same command sentto the same instrument. Different I/O cards are available for each platform andthey have different maximum transfer rates associated with them.

4. Instruments used and the type ofHP-IB driver/parser in the instrument: thetype of driver/parser affects the overall timing which will be observed for aspecific instrument. The number and combination of instruments will affect thetime it takes to process the addressing bytes.

5. Packet type (control, data, mixed control and data).

6. Packet size: buffering issues will come into play depending on the packet sizewhich is being sent. Longer delays may be observed every N number of byteswhere N is the buffer size.

7. Direction of transmission (from controller to instrument, from instrument tocontroller): the controller may use a different transfer method for commandssent to an instrument versus receiving data sent from an instrument. This mayaffect the average transfer rate for packets in each transmission direction.

8. Individual mnemonics used in an instrument: Different mnemonics takedifferent amounts of time to execute. There is also variability in the execution ofthe same mnemonic. The bottom plot of figure 5 shows an example of this.

3.5 Timing variability in plot of throughput versus packet sizeFigure 1 shows plots of throughput versus packet size for all packets in two test cases.The first plot shows the expected result, larger packets having faster throughputs,

13

Internal Use Only

Throughput versus packet size, SID_1, 2/6/92000001\I ....,.

• ••4Ift., ", ..0

"""" I

., ...0 •0 ,........ ••

0 0Q) ill I .~.III ,...

.~ ..t·<, , •III ,.Q)

>. 0 I' .'.0 00 •... 0 I::J 0 ,a. ,...

J:.Cl I::J~ 0

t.0

J:. 0...0ill

• •0 Ie • It •

0 1000 2000 3000 4000

packet size, bytes

Throughput versus packet size, SAD_1, 1/14/92

11" 111 I' I'" 'Id • .' II'::P I' :, .1' '·:nl·I·I!;aI!"I.I:.

1 11 '111 , ,1. 111' 1 ,.,. "'. . .' ., ..

oo 0Q) 0~ <Xl

! 0), 0.0 0... CD::Ja. 0J:. 0Cl 06 '<t...J:.... 0

oo1\I

o

••I I • ','"• • •I' I '1111'1' •i III I I I

•I.'p • "I' ,'.. , .

•• : • '1 ... • ..... I •.liI.. 1I .. I .,.

20

1"'" • ••••••

40

if

.., ...... 1. .. ,....• •

• • •••

60

packet size, bytes

Figure 1. Thruput versus packet size

14

Internal Use Only

with throughput approaching a two hundred Kbytes/sec asymptote due to thehardware and software comprising the system.

The second plot shows the variation present in a second system where all of thepackets are under one hundred bytes long. We asked ourselves the question: ''Why isthere so much variation in throughput for packets of the same size"? We found thatthe wide spreading of throughputs for packets of the same size was due to thedifferent types of instruments as mentioned in section 3.3. That is to say someinstruments had their command execution time included in the packet durationtime.2 When we separated out the same size commands for specific instruments westill saw variation on the plot. We separated out occurrences of the same commandsent to the same instrument and still found several hundred usecs variation in theduration of the packets. Separating the parts of the packet into addressing and databytes we saw that most of the variation came from the addressing portion. Finallyinside the addressing bytes we saw that the MTA byte, that is the controlleraddressing itself to talk was where most of the variation was coming from. Ourconjecture is that since this is the first byte sent in a new packet, the variation comesfrom the task switching characteristics of the controller while preparing to executethe HP-IB driver code.

3.6 Impact of faster controllers, faster instruments, faster HP-m cardsWhen developing or analyzing a system it is important to know how to improvethroughput. Where is the bottleneck? Is it a specific instrument? Is it the controller?Is it the bus? Tables 1 and 2 show the effect of separately adding a two times and tentimes faster bus, set of instruments and controller to each of our test cases. Thesetables are based on the following three assumptions:

1. The byte delivery time is a good measure of the speed of the bus.

2. The interbyte quiet time is a good measure of the speed of the instruments.

3. The interpacket quiet time is a good measure of the speed of the controller.

Note the relative lack of performance improvement obtained by using a faster bus.Using faster instruments'[ and faster controllers offer the best opportunities forimproving overall HP-IB system throughput.t

2. Even an instrument which releases the bus as quickly as possible may still have large variations in packetduration for packets of the same length. This is due to holding off the bus when the instrument is addressedto listen and the instrument has not finished executing a previously received command sequence. This is observed in the logged data as a long interbyte time for the first data byte after the addressing bytes are processed. Thus partial execution times may get shifted forward to the next consecutive packet sent to aninstrument.3. Some instruments will not be able to make measurements faster because of constraints imposed by the lawsofphysics. However other instruments may show improved throughput through improved software and fastercomputation hardware.

15

Internal Use Only

3.7 ThroughputMost of the packet throughputs were between one and ten Kbytes per second. Thismeasure of throughput includes execution time for instruments which hold off thebus. The maximum packet throughput we observed was approximately 200 Kbytesper second. This maximum was observed in three test cases.

3.8 Packet size

Most of the packet sizes were under 100 bytes. The maximum packet size we observedwas 40 K bytes.

3.9 Separation of mnemonic execution timeSome concern was raised during the analysis of the data that it is inappropriate toassume that the low throughput numbers are caused by the HP-IB parsers in theinstruments. It was suggested to separate the amount of time spent parsing versusthe amount of time executing the commands. This can be done easily ifthe instrumentholds off the bus while executing the command. Figure 2 shows the difference inthroughput with and without the execution time for a specific instrument in aparticular test case. We see here that the execution time takes about two to threetimes longer than it takes to get the command bytes to the instrument.This does not change the fact that the bus is held off. Our original throughputnumbers reflect the available bandwidth on the bus with the particular combinationsof instruments. Parsers/drivers are being written to buffer commands and release thebus as soon as possible. As was mentioned previously this gives the applicationprogrammer more flexibility to control multi-tasking in the system, however it placesthe responsibility of synchronization on the application programmer. From strictly athroughput point of view this way of writing the driver/parser may not improveoverall throughput. One must take into account the additional overhead of sendingand processing synchronization commands such as *OPC, *OPC? or *WAI if theinstrument specific commands require synchronization.

3.10 Error checkingWe were surprised at the lack of error checking to ensure overall system integrity. Weexpected to see more usage of either the serial poll status byte to check for errors orthe setup of the IEEE 488.2 standard event registers in each instrument to create anSRQ in case of error conditions.

4. Capital Equipment Corporation has proposed an extension to IEEE 488.1 and 488.2 called 488-SD, HighSpeed Streaming Data Protocol. This protocol can send data at five Mbytes/sec over a one meter long HP-IBcable. This is not simply a faster bus proposal since the instruments and controllers must have software whichadheres to the new protocol. In addition the hardware in both the controller and instrument must be fastenough and use large enough data buffers to maintain these transfer speeds. This protocol is not intended forsending short commands but rather long sequences of data. While this protocol does provide a faster bus italso requires faster instruments and controllers. This extension will not increase throughput for most applications.

16

Internal Use Only

Timesaved(sees)

189.9

8.5

9.4

251

10.2

206.7

453.1

% testtime

saved

1.7%

2.4% 0.5

14.1%

0.1%

2.4%

14.6%

11.0%

12.8%

Timesaved(sees)

3811.2

43.0

13.8

144.2

865.5

79.2

51.5

1111

1.0

1.3

% testtime

saved

11.5%

15.0%

7.5%

11.9%

10.3%

0.6%

5.5%

15.5%

2X faster instruments 2X faster controller

0.4%

0.3%

......................................:.:.:.:.:...:..

::.::.::.i..:..2..:..:..·..·:..6...:::..1.~.::.::.:;.•·.P.· i../::/// 5.7.· ::::::}~f::

::::4$~~l.j:·::::::::::://i 10.0:.:.:.:.:.: ::::::::::.:

2X faster bus

TestRaw test

time % test Timecase

(sees) time savedsaved (sees)

lidl 5509.0 4.8% 264.9

lid2 69.7 0.2% 0.2

lid3 3002.6 0.4% 13.3

lid4 344.4 0.9% 3.0

lidS 337.0 0.1% 0.3

nmdl 1614.1 3.2% 51.4

nmd2 1058.9 4.0% 42.5

nmd3 4128.1 3.9% 159.8

sadl 5576.3 0.8% 43.9

sedla 1083.5 2.1% 23.0

sed2 665.2 1.2% 7.9

sed3 684.7 0.6% 3.8

sed4 2500.1 0.1% 1.6

sedS 2617.9 1.5% 38.7

sed6 286.4 2.7% 7.7

sidl 15278.9 0.1% 12.5

spdl 211 0.0% 0.0

spd3 21.9 1.8% 0.4

spdS 543.1 2.0% 10.9

ssdl 1349.3 6.0% 81.6

sedlb 33282.9 0.3% 98.0

Table 1: Impact of 2X faster bus, instruments and controller

17

Internal Use Only

Test caseRaw

test time(secs)

lOX faster bus

% test Timetime saved

saved (sees)

lOX fasterinstruments


saved (sees)

lOX faster controller


saved (sees)

3002.6 0.8%

1 8

0.7% 2.3

0.5%

92.6

0.6

5.4

0.3

23.9

0.2%

1614.1 5.7%

337.0

344.4 16%

5509.0

69.7 0.4%

nmdl

lidS

lid4

lid2

lid3

lidl

nmd2 1058.9 7.2% 76.4 :::::iit,liiiiii::ijiiii:ii:::iii 831.4:::~:~:~:~:~:~:~:::::::::::::::::::::::::.:::::::::::::.:.

4.3% 45.2

1083.5 38%

41281 7.0% iil·lllii!IIIIIIIIIIJlillilllllll: 2612.2

14.2

79.0

41.4

287.6

2.1%665.2

5576.3 1.4%

nmd3

sed2

sad I

sedla

sed3 684.7 1.0% 6.8 13.5% 92.7 :i:i:tts;§I::::::::::j:::;":i::. 516.7:::::::::::::;:::::;:::;:;:;:: .

2617.9 2.7%

15278.9 0.1% 15.30.1%

24.8

259.6

1.0%

9.9%

138

22.4

2.8

696

4.8%286.4

2500.1 0.1%

scd6

sidl

sed4

sed5

spdl

spd3

211

21.9

0.1%

33%

0.0

0.7

:::·:41;~I:j:::j....i:i:i:i:i:i:i 10.2........:.:::::::::::::::.:.:.:: '::

iiliill~lljljlj.jljll:jijlliillll 18.0 4.3% 0.9

0.5% 176.4

:.:::..::.t.~x:·.O.:.:.:·...:.l.:.9%.:.:.:.:.:.·.:...: ...: ...:.:.:.) (itt 146.8~}t~{:

17.031%

:::::~~).::::::::::::::::::::::: 22918 1:::::: ::::.:::::::::::::::::::::::::::::::::

19.636%

1349.3

33282.9

5431

scdlb

spdS

ssdl

Table 2: Impact of lOX faster bus, instruments and controller

18

ool/l

...:JC. 0~ l/l:J

eJ:~<,

'2o:;;:JoQ)xQ)...:J

~ 0... ,...~

...:JC.J:Ol:Jo l/lIJ:~

Internal Use Only

Comparison of throughput with and without command execution, HP8340A, SAD_1, 1_1(92, (C·> I)

o 500 1000

packet number

1500 2000 2500

Figure 2. Comparison of throughput with and without CRILF

19

Internal Use Only

3.11 Addressing timeAn analysis of the data was performed to calculate the relative amount of packet timeand total test time taken up by the addressing bytes each time a command istransmitted over the bus. Table 3 shows these two numbers for each of the test cases.Note the very large percentage of packet time taken up by the addressing bytes.Depending on the size of the packets and the number of packets sent in the test thisalso translates into a large percentage of total test time.

3.12 Redundant addressingAn analysis was performed to measure the number of times commands were sent tothe same instrument in separate consecutive packets. The amount of time spent insending the addressing bytes was added up to see how much test time could be saved.Two ways to save this time are: 1) send all the consecutive commands to aninstrument in a single packet'' or 2) use a smarter HP-IB driver in the controllerwhich keeps track of the current talker and listeners. The results are summarized intable 4. This experiment shows that up to twenty-six'' percent of the test time wasspent sending redundant addressing information.

3.13 Redundant mnemonicsThere were numerous cases of redundant mnemonics sent to instruments presumablydue to the use of instrument drivers. Instrument drivers can provide improvement inapplication software development time. They can also waste bus bandwidth bysending redundant commands. An example of a redundant mnemonic sequence isshown below:

Each line in the following example represents a separate packet. This groupingof packets was sent many times in the test case without any other commandsbeing sent to the instrument in between. One set of these instructions wouldhave been all that was needed for the entire test.

1. *RST;:PULS1:EDGE:LEAD lNS;TRAIL lNS;:PULS2:EDGE:LEAD lNS;TRAILlNS;:PULS1:LEV:LOW -3.0V;OFFS -1.5V;:PULS1:TIM:WIDT lOUS;DELOPS;:PULS2:TIM:WIDT lNS;DEL OPS;:PULS2:LEV:LOWO.OV;OFFS 2.50V

2. :OUTPUT1:PULSE:STATE ON;:OUTPUT1:PULSE:CSTATE ON

3. :PULSE1:TIMING:WIDTH 65NS

4. :OUTPUT1:PULSE:STATE ON;:OUTPUT1:PULSE:CSTATE ON

5. :PULSE:TIMING:PER 490NS

5. This may be inconvenient if the application software uses instrument drivers.6. There is one test case which shows 81.7% of the test time spent in redundant addressing. This testcase hada large number of serial polls. The removal of the redundant addressing would allow the serial polls to be sentcloser together. In this application the serial polls are used to detect anevent in an instrument. Removing redundant addressing would allow faster detection of the event. This might be important in some control applications.

20

Test case

lidl

lid2

lid3

lid4

lid5

nmdl

nmd2

nmd3

sadl

sedla

sed2

sed3

sed4

sed5

sed6

Internal Use Only

% of packet timeconsisting of addressing

time

22.2 %

22.5 %

36.8 %

16.9 %

44.3 %

43.1 %

36.4 %

74.9%

15.5 %

77.2 %

% of test time consistingof addressing time

12.7 %

16.0%

19.8 %

0.4 %

0.3 %

29.7 %

10.7 %

9.5 %

15.1 %

0.9%

2.2%

27.3 %

sidl

spdl

spd3

spd5

ssdl

sedlb

53.6 %

Table 3: Addressing time

21

28.8 %

68.6%

60.1 %

21.6 %

21.4 %

Internal Use Only

Test caseNumber of

packets

%ofpackets

withredundantaddressing

Total testtime(sees)

% of totaltest time

consistingof

redundantaddressing

0.2%

0.6%

1.0 %

4.3%

0.7 %

1.7 %

0.4 %

2.5 %

0.9%

0.1 %

0.7 %

0.0%

:i:·:gl~I:::~.:.:.·.:·....:.·:.:·.:.:·.::.:.:.I.:.!.·.I.!.I.:.I.:.I.:.I.:I.:.I.:.I.:I.·I.·I!...:.:.:.:.:.:.:.:.:.:.:.:.:.:.:

... :::::::::::':':':':':': .. :::::::::::::::::::::::::

:.i.•::.t.·..:.;J..·.•.·.•.:.~.:.:.O'...·.:.·.;.:.:.:.~.;.:.:...~.•...:.:.:.:.:. :::::::::::::::::::}:::.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:/:~:~:~tttt:

........:.:...:.:.:.:::::::::::::::::::::::::::::::::::::.:.:.:.-.

.................................................. :::::::::::::::::::::::g;p}mi::::::::

15278.9

1349.3

286.4

1614.1

5576.3

4128 1

344.4

337.0

3002.6

45.7 %

46.0%

33282.9 3.6 %

4.5%

41.5 %

51.6 %

20.2 %

39.4 %

19.5 %

25.6 %

lillllll~II!::I·I·:·:·!·:·!·::!::·!·::··:·::·:·: 2500.1

xc-xox-x .

::::~1:*i:::7<t!::,.::::::::::::::: 1083.5.::: ..: :.:.:.:.:.:.;.:.:.;.: :.:.:.:.:.: :.:.:.:.:.:.:.:.:

........................

·i·i]~~~::.I:.:::::::·:::::::::::::::::::::: 5509.0lid1 163486

lid2 368

1id3 5559

lid4 1325

1id5 1194

nmd1 4371

nmd2 2581

nmd3 21600

sad1 12424

sed1a 9860

sed2 3651

sed3 2425

sed4 17552

sed5 6346

sed6 5911

sid1 98184

spdl 95

spd3 88

spd5 1784

ssd1 2401

sedlb 495554

Table 4: Redundant addressing time

a.This testcase contains a large number of serial polls.

22

Internal Use Only

3.14 Replacement of HP-IB by EthernetIt is not reasonable to expect a single interface system to solve all requirements fordata rates, path widths, data transmission lengths, the number of interconnecteddevices and message traffic volume [LOUGHRY72]. We do not believe HP-IB will bereplaced by Ethernet in the immediate future. HP-IB, however, will have to coexist intest systems which may be controlled from Ethernet. Until a cost and performanceeffective replacement arrives instruments will continue to be controlled by HP-lB. IfEthernet is used to control test systems Ethernet to HP-IB converters will be neededto interface with the large number of HP-IB instruments in existing test systems.Indeed Ethernet to HP-IB converters are being sold today by National Instrumentsand IOtech Inc.

The main reasons for moving to Ethernet include:

• Higher data throughput for instruments which either consume or produce largequantities of data.

• The gain of longer path lengths and greater number of interconnected deviceswithout a large sacrifice in bandwidth.

• The support and continued enhancement of Ethernet interfaces by mainstreamcomputing.

The main reason not to move to a LAN, like Ethernet, is the variability that may beintroduced due to retransmission. In HP-IB there is an assumption of reliable datadelivery, and thus an assumption of deterministic behavior. If the timing constraintsare such that the variability introduced by retransmission is unacceptable and themessage can not be queued or sent early or synchronized with a real-time clock, thena deterministic bus like HP-IB will offer better real-time performance.IThe desired approach is a system architecture which will support the use of variousI/O interfaces and the partitioning of applications into real-time and non real-timemodules.The style of communication may need to be changed to one which uses downloadedcode or stored states instead of sending and executing many low level commands toset up a required state in an instrument.

7. Moving to Ethernet to communicate with instruments is perceived to be a potential problem in applicationsrequiring deterministic behavior. Moving to Rocky Mountain Basic-UX has not been perceived to be a bigissue. Why? Is the potential non-determinism really not a problem or are people not aware of the potentialnon-determinism being introduced?

23

Internal Use Only

4 Potential uses of HP-IB analyzerThe following sections describe four different areas were the HP-IB analyzer could beused to improve and troubleshoot designs. An example is given for each case toillustrate the type of information which can be obtained by analyzing the system HPIB activity. The four areas are application development, instrument development,controller HP-IB driver development, and instrument HP-ill driver/parserdevelopment. Figure 3 shows these four areas in a block diagram of a test system. Allof the information items of interest mentioned in each of the four areas is availablethrough the analysis of bus data captured for entire tests.

4.1 Application developmentApplication developers are concerned with optimal use of resources and overallperformance of the test system. Examples of specific information of interest to theapplication developer include:

• Throughput of a test.• Effect of a faster bus, instruments, controller on the overall test time.

• Reduction of test time through the optimal selection of instruments.

• Most commonly used mnemonics.

• Occurrence of redundant addressing.

• History of bus activity if the bus hangs.

ExampleFigure 4 shows a sequence of five plots describing the distribution of bus activityamongst the four instruments in the test system. In all five plots the actual test timeis shown along the horizontal axis. In the first plot we show the cumulative bytestransferred during the test. The next four plots show packets being sent to theinstruments (labeled as commands on the plot) and packets being returned by theinstruments to the controller (labeled as queries on the plot). The amplitude of thelines vary to give an indication of the rate at which packets are being sent.Table 5 shows the distribution of test time amongst the instruments.

4.2 Instrument developmentInstrument developers are concerned with the time it takes to request and execute afunction in the instrument and the optimization of these functions. Examples ofspecific information of interest to instrument developers include:

• Commands used most often.

• Relative comparison of the product being developed with instruments producedby competitors.

• Distribution of execution time for the same mnemonic.

24

Internal Use Only

Application development

Controller

Application

HP- IB driver

HP-IB

Controller driver development

Instrument #1

Instrument #2

Instrument #3

Instrument development

Instrument driver development

Figure 3. Areas where HP-IB analyzer can be used

25

Internal Use Only

Byteslransferred, NMD_2, 1/14/92

..J-'-'-'-'.'.'.'.'.'.'.'.'.'.'.'.'.'.'.'.'.'.'.'.'-'.'-.-......•...•.....•...•1

1-'---'-,...-.-.-.-_.......-...........--•.

200 400 600 800 1100

t6SllilTl&,secs

1hin~ellJinlel, NMD_2, 1/14/92, 100 packels'ramp

C«rrn d

I I IQui

Que

200 400 600 800 1100

IdtirM,secs

HP54120B Dijlal scope, NMD), 1/14/92, 100 packetslramp

C«rrn d

Qui

200 400 600 800 1100

t6Sltim8,secs

HP8112A Pulse generator, NMD_2, 1/14192, 100 pockelshamp

C«rrn d

Qui J UQue

200 400 600 800 llOO

te.;:lime,secs

HP83620A (DUl), NMD), 1/14192, 100 pockelsJramp

QuelL-~~~~~~~~~~~~~~_~~~~~~~~~...;,..,;....:....:....:......~ __------_-----'

200 400

leilime,secs

800 1100

Figure4. Distribution of packets in a test system

26

Internal Use Only

A PacketS C D E D/ATotal

time as % PacketsTotal

Max AvgAddress packet bytestime

of total sentsent

thruput thruputtest time

TALKER PACKETS:

Address 6 879.5 sees 83.1 % 350 5660 12091.0 6.4HP54120B packets bytes bytes/sec bytes/sec

Address 19 13.1 sees 1.2 % 128 42853 34066.7 3275.6HPMMS aekets bytes bytes/sec bytes/sec

Address 21 116.2 sees 11.0 % 2103 106720 23673.5 918.8Controller packets bytes bytes/sec bytes/sec

LISTENER PACKETS:

Address 1 83.3 sees 7.9% 1265 88736 3102.4 1065.2Printer packets bytes bytes/sec bytes/sec

Address 6 28.4 sees 2.7% 520 12674 10789.1 446.9HP54120B packets bytes bytes/sec bytes/sec

Address 12 1.7 sees 0.2% 63 686 6711.4 415.2HP8112A packets bytes bytes/sec bytes/sec

Address 19 2.8 sees 0.3 % 255 paek- 4624 23673.5 1627.8HPMMS ets bytes bytes/sec bytes/sec

Address 21 892.6 sees 84.3 % 478 48513 34066.7 54.4Controller packets bytes bytes/sec bytes/sec

QUIET TIME

Interpaeket 50.2 sees 4.7% N/A N/A N/A N/Aquiet time

Table 5: Talker/listener summary

27

Internal Use Only

ExampleTable 6 shows all the mnemonics used in a selected test case to control oneinstrument. This instrument has over one hundred and fifty commands. Here we seethe use of only about twenty different commands or only less than fifteen percent ofthe total number of commands which were shipped with the instrument.

Figure 5 shows a histogram of the packet durations for the mnemonics in table 6. Thesecond histogram shows the variation in packet duration for all executions of aselected mnemonic in this test case.

The HP-IB analyzer could be used in conjunction with an HP-IB test program tocompare the execution times of all the commands in the instrument and check forabnormal occurrences.

4.3 Controller HP-IB driver developmentController driver developers are concerned with maximizing the throughput of dataout of and into the controller. Information of interest to these developers include the:

• Effect of redundant addressing.• Distribution of mnemonic throughputs.

• Distribution of interpacket quiet times.

ExampleThe first plot of figure 6 compares the distribution of packet sizes for packets sent bythe controller with the distribution of packet sizes for packets sent by the instrumentsfor a particular test case8. Most of the packets were under one hundred bytes longwith a few packets eight thousand bytes long. There were more packets sent by thecontroller as shown by the wider box plot width.

The second plot of figure 6 compares the distribution of packet throughputs forpackets sent by the controller with the distribution of packet throughputs for packetssent by the instruments for a particular test case. Most of the throughputs measuredwere between one and ten Kbytes/sec.The third plot of figure 6 shows the distribution of interpacket quiet time for aparticular test case. Here we can see that there are between one and twenty msecsbetween commands. These numbers could be used to optimize the execution of thedriver code and application code. They can also provide an estimate for the executionof tasks performed by the controller in between HP-IB commands.

4.4 Instrument HP-IB driver/parser developmentInstrument driver developers are concerned with maximizing the throughput of datainto and out of an instrument. Information of interest to these developers include the:

8. The boxplots in this figure should be interpreted as follows. The box shows the bounds of the middle halfof the data. The line inside the box shows the location of the median. The whiskers extending from the boxshow the extreme bounds of the data.

28

Internal Use Only

Usage Command sequence

116 :MEASURE:VSTOP?

116 :MEASURE:VSTART?

116 :MEASURE:SOURCE CHANNEL2;VPP?

116 :ERASE PMEMO

9 :CHANNEL2:0FFSET O;RANGE .08

6 :TIMEBASE:RANGE 1.8E-7;REFERENCE LEFT;DELAY 5.E-8




3 :ACQUIRE:TYPE AVERAGE;COUNT 128

3 *RST

2 :VIEW CHANNEL2

2 :TRIG:HFREJECT ON;PROBE 20;LEVEL 1.2;SLOPE POSITNE

2 :ERASE PMEMO;:MEASURE:SOURCE CHANNEL2;VPP?



1 :TIMEBASE:RANGE 2.E-8

1 :TIMEBASE:MODE TRIG;RANGE 1.8E-7;REFERENCE LEFT;DELAY 5.E-8

1 :TIMEBASE:MODE FRE;RANGE 5.E-9

1 :TIMEBASE:MODE FRE

1 :DISP:GRAT GRID;FORM 1

1 :CHANNEL2:PROBE I;OFFSET O;RANGE .16



1 :BLANK CHANNEL1;:BLANK CHANNEL2;:BLANK CHANNEL3;:BLANK CHANNEL4

1 :ACQUIRE:TYPE NORMAL;:DISP:PERS .5

1 :ACQUIRE:TYPE AVERAGE;POINTS 500


1 SDC

Table 6: Commands usedto control selected instrument, HP54120B, NMD_2

29

oo(')

I/JQ)ocQ)..::l 0o 0g (IJ

....o..Q).0E 0::l 0c: ,..

o

Internal Use Only

Hp·IB packet duration, NMD_2, all packets to HP54120B scope, 1/14/92

II

0.0 0.1 0.2 0.3

packet duration, sec

0.4 0.5 0.6

Hp·IB packet duration, NMD_2, :MEASURE:SOURCE CHANNEL2;VPP? to HP54120B scope, 1/14/92

o(')

I/JQ)ocQ)

~ 08 (IJo....o..II).0

E 0~ ,..

o I II I

0.110 0.112 0.114

packet duration, sec

0.116 0.118

Figure 5. Packet duration for specific instrument and specific command

30

Internal Use Only

HP·IB pi¥:ket size, NM[t2, U4J2

TIIIII

I....L.

cnttlrtoinslr.

""I

II1

1

_I

crmvtoillSlr.

Hp·1B tlvuoo!tllut, NMD), U(92

k1IefJli¥:ket quiettimes, NMD_2, U(92

Mr,locnilr

I

II

..1"r.tocnl~

I

1

1

1

-1-Figure 6. Comparision of packets sent from/to controller

31

Internal Use Only

• Effects of releasing the bus immediately versus holding it off until the commandis finished.

• Relative parsing time of common 488.2 mnemonics versus instrument specificmnemonics.

• Distribution of mnemonic string lengths.

• Distribution of mnemonic throughputs.

• Distribution of consecutive mnemonics sent to same instrument.

• Effect of input buffer sizes on throughput.

ExampleFigure 7 compares command processing for two instruments in the same test system.One of the instruments (HP8340A) holds off the bus until the mnemonic is finishedexecuting. This instrument also executes the mnemonic when it sees the carriagereturn byte at the end ofthe message. The second instrument releases the bus as soonas the bytes are put into a buffer and execution occurs during the interpacket quiettime. Let us imagine we are the developer of the first instrument and we arepreparing to design an updated version of the instrument. We might ask if there is anadvantage to releasing the bus as quickly as possible for this particular instrument?

The first plot of figure 7 shows the variation of what is labeled as ratio 'A'. This ratiois the relative length of time it takes to receive a byte in the message terminatorversus the amount of time it takes to receive a byte in the packet header or packetbody. If an instrument is simply placing the bytes into a buffer we expect this ratio tobe approximately one. If the commands are executed inside the packet we expect theratio to be somewhat larger. This first plot shows this comparison. We see that theinstrument which holds off the bus has a ratio 'A' considerably larger than theinstrument which does not hold off the bus during execution of the mnemonic.

The second plot shows whether it would be worth while to change this instrument tobuffer up the commands instead of holding off the bus. Ifwe release the bus as quicklyas possible and the mnemonic does not need to be synchronized with the rest of thesystem with a *OPC or *WAI command we can take advantage of the time betweenpackets and the time it takes to transmit the addressing bytes in the next packet toexecute the mnemonic. This plot shows that in fifty percent of the cases there isenough time to execute the previous mnemonic sent to the HP 8340A.

32

Internal Use Only

CR/LF command termination processing, SAD_1, t 1(92

oooT'"

ooT'"

«o'+l

~ 0T'"

TIIIII

-:-I

-Lbus held off while executing command (HP 8340A)

A= BIC where:B= IBOT for CRILF divided by 2C= (total lOOT -B) I (packet size-2)

±bus not held off while executing command (HP MMS)

Types of instruments

CR/LFtime· next IPOT· next header time, SADJ, 1J(92

, , . .•• -' rrn

NOTE:This plot is for the instrument which held off the buswhile executing commands. (HP 8340A)

Execution time is less than (next IPOT +next header time)50% of the time in this test case.

illE III.. 0...ill'0lUill '<t~ 0...xII)CI C'l

r- oa0.....

~xill 0C

illE T'".. 0

l.L....J qIi'PUIl(( 0 • d0 0

0 500 1000

packet number

1500 2000 2500

Figure 7. Comparison of instrument drivers/parsers

33

Internal Use Only

5 Future directionsWe have raised more questions than we have had time to answer on this portion ofthe LINC project. The following are proposals for future research using the HP-IBanalyzer we have developed:

1. Obtain more measurements of different test systems including outside customertest sites.9

2. Team up with a manufacturing line and use the analyzer to characterize andoptimize the system. What are the bottlenecks? How can throughput beimproved?

3. Use the analyzer to characterize the use of mnemonics in a single instrument ortype of instrument. This data could be used to help determine the optimal set ofmnemonics for future instruments.

4. Use the analyzer to characterize a new product while it is still underdevelopment. The data could be used to help optimize the most commonly usedmnemonics and to characterize the execution times of all the mnemonics.

5. Use the analyzer to further study the variability in the way parsers aredesigned? How does parser design affect bus performance? How many differentparsers were developed at Hewlett-Packard in the last twenty years? How doesthe HP Leveraged Design System (LDS) parser compare with other parserswritten at HP?

6. How do competitors parsers and drivers compare with HP's parsers and drivers?

7. Can HP's ITG drivers be improved? Can we get a competitive advantage? Howmany redundant commands are sent over the bus? How often does redundantaddressing occur?

8. Use the analyzer to investigate context switching in a instrument. What wouldbe the effect of using stored states or named states instead of sending manyindividual HP-IB commands to set up the required instrument states?

9. Construct a second analyzer and use it to look at systems with two HP-IB s. Ascheme must be devised to synchronize clocks in the two data acquisition frontends. We have a method in mind and do not anticipate any major problems inthe implementation.

IO.Why does the addressing sequence take such a large percentage of the packettime? What parameters affect the timing of these commands?

11.What does a plot of byte delivery time and interbyte quiet time versus date ofinstrument manufacture look like? Are there noticeable trends?

9. We purposefully did not select test sites outside of Hewlett-Packard. We did not want to show this analysiscapability until we knew whether HP was interested in turning the analyzer into a product.

34

Internal Use Only

12.What is the usage of IEEE 488.2 common commands (*XXX) in test systems.What is their parsing and execution time compared to other instrumentmnemonics?

13.Study how errors are handled in different HP-IB test systems. Which methodsare most effective in determining correct test system operation?

14.The analyzer front end can be used to capture the long term state ofup to sixteendigital lines. If separate analysis software is written different analyzers can becreated similar to the different post processing which is used in logic analyzersto show specific microprocessor mnemonics or specific bus commands such asVME or SCSI. One possibility is to monitor a register inside the instrumentwhich would have status bits corresponding to the start of an HP-IB command,and the end ofparsing and execution and possibly other events of interest to theinstrument designer. This would allow the time spent on parsing and executionof the command to be separated in order to understand the distribution of timeinside the instrument.

6 Final conclusions and recommendationsThe proto-type for an HP-IB analyzer has been built and tested by gathering data onreal manufacturing systems. This analyzer allows the user to obtain unique overallviews of the system from a bus perspective. This analyzer can be used to characterizeand verify performance of instruments and entire systems.

Most of the test cases were partial or complete final test procedures at HewlettPackard manufacturing sites. We do not imply that the results of this experiment arecharacteristic of HP-IB usage in general and caution against using the resultspresented here as such. However the results are based on real test systems and thuspresent examples ofHP-IB usage.

The following statements are supported by the test data:

• Most of the system bottlenecks are found in either the controller or theinstruments and not the HP-lB.

• Over fifty percent of the test time can be taken up by addressing bytes. Up totwenty-five percent of the test time is taken up by redundant addressing bytes(the same source and destination for an HP-IB command are used for the currentcommand as for the previous command).

• The use of instrument drivers may waste test time by sending redundantmnemonics.

• Error checking is not widely used to monitor the instruments comprising the testsystem.

• Instruments can be long lived in test systems. For this reason alone a LAN suchas Ethernet will not completely replace HP-IB for instrument control and willneed to co-exist in the near term.

35

Internal Use Only

The design approach we took could be used to create a set of analyzers to look at multibus systems such as dual HP-IB, VXI/HP-IB, SCSIIHP-IB, EthernetlHP-IB. Inaddition the usefulness of the analyzer could be enhanced by creating a tool whichcorrelated the bus activity with a view of the code in the controller responsible for thebus activity.

Tools, like these, are needed to add credibility to Hewlett-Packard's commitment toselling and supporting Test and Measurement systems.

AcknowledgmentsThe authors would like to thank all the divisions who graciously permitted us togather information on their test systems:

• Loveland Instrument Division:Harry Dietrich, Greg Beam, Bill Jones

• Network Measurement Division:Jim Terhorst, Doug Lash

• Signal Analysis Division:Ed Dempsey

• Santa Clara Division:Joyce Fong, Bob Shearer, John Johnson, Leo Steindorf

• Scientific Instruments Division:Peter Low

• Stanford Park Division:Les Brubaker, Chris Bostak

• System Support Division:David Land

Special thanks goes to Craig Hamilton at HP Labs for reviewing this paper andoffering many helpful comments.

References[LOUGHRY72] Donald C. Loughry. "A Common Digital Interface for Programmable

Instruments: The Evolution of a System". Hewlett-Packard Journal, HewlettPackard Company, October 1972.

[MOORE92] Keith Moore. "HP-IB Data Logger Hardware Overview". HewlettPackard Laboratories, Hewlett-Packard, February, 1992.

[WOODS92] Stan Woods. "HP-IB Data Logger Software Overview". Hewlett-PackardLaboratories, Hewlett-Packard, March, 1992

36

Internal Use Only

Appendix A: HP-IB analyzer descriptionLogger requirementsWe started the data logger project with several key design goals:

• Non-invasiveness: The logger must sample the bus lines and not handshake withthe controller. This is important to ensure that the logger does not interfere withthe test system.

• Logger memory: The logger must store the bus activity for an entire test. Sometests run for hours. We wanted the storage capability for logged data to belimited only by the size of the logger's hard disk.

• Time stamping of data: The logger must time stamp events with at least onemicrosecond resolution.

• Event specification: The logger must allow specification of events in terms ofcombinations of rising and falling edges of any of the sixteen data and controllines comprising the HP-IB.

• Data rates: The logger must capture all specified events at HP-IB throughputrates of at least 300 Kbytes/second.

• Lost event detection: The logger must keep a count oflost events and alsoindicate if this count is overrun.

The project was also started with the assumption that it would only take a few weeksto assemble the data logger from existing off-the-shelf hardware and software. Theshort story is that we could not purchase all the pieces which would allow us to meetour design goals. The final prototype implementation was a combination of customhardware/software and purchased hardware/software. Development spanned aperiod of several months. Two separate papers [MOORE92] and [WOODS92] explainthe different approaches explored and more details about the implementation of thehardware and software.

Data logger descriptionThe data logger prototype consists of the following modules:

• A custom hardware front end which is connected to the HP-IB. We used anexisting HP 59401 HP-IB Analyzer to hold the custom circuitry and leveragedthe power supply and the front panel user interface. The custom circuitry detectsevents and time stamps the captured data.

• A laptop computer with an off-the-shelf hardware board (Keithley's PDMA-32board) and off-the-shelf software (Keithley's Streamer) which places the timestamped raw data on the hard disk of the laptop computer.

• Custom post-processing tools written in C residing on a workstation.

• Analysis routines written for an off-the-shelfdata analysis and plotting package(S-PLUS).

37

Internal Use Only

Figure Al shows a block diagram of the prototype and the functions performed byeach module.

Logging session processThe logger takes only a few minutes to set up. An HP-IB cable is used to connect thefront end event detector to the bus. A second cable is used to connect the modifiedHP5940I to the laptop computer. The front end hardware is reset and the software isthen started on the laptop. The equipment is left in place until a particular test iscompleted.

The Streamer product requires previously allocated contiguous files. Therefore alarge file must be allocated to ensure the capture of all the bus traffic produced duringa particular test. The custom hardware front end has a button which is used to log aknown pattern into memory at the end of a logging session. This allows the user toeasily trim the file so it only contains valid data.

The logged data is off loaded to a workstation for analysis.

38

Custom and PurchasedSoftware

Internal Use Only

Workstation

IData presentation IData analysis I•

Disk Storage I

Functions:

• Post-processingof raw data

• Data analysis

• Plotting

Purchased Hardwareand Software Laptop

ComputerDisk Storage I•

DMA TransferIj

• Storage to disk

• Management ofdata files

• Low level dataanalysis

Modified HP59401

f FIFO Memory

Custom Hardware

HP-IB

EventDetector I Time

Stamp

II

• Data capture

• Time stamping• Detection of lost

events

Figure A1. Data logger block diagram

39

Internal Use Only

Appendix B: Data analysis modelPost-processing frame of referenceThe transmitted bytes are grouped into three categories defined as:

• Addressing bytes: Addressing bytes are the UNL, UNT, MLA, and MTAcommands.

• Control bytes: Control bytes are commands such as DCL,LLO, SPE, SPD, PPU,GET, SDC, GRL, PPC, TCT, PPE, and PPD.

• Data bytes: All other bytes are defined as data bytes and comprise the HP-IBmnemonics, mnemonic parameters and query responses from instruments

Using the definitions above, the following pattern is observed in the logged data:<addressing bytes>, < control and/or data bytes>, <addressing bytes>, <controland/or data bytes>, ...

If we define a packet as a grouping of addressing, control and data bytes, the patternobserved is a succession of packets with each packet consisting of a packet headerindicating the source and destinationts) and a packet body containing the data sentfrom the source to the destinationis).

In addition we have defined various terms as shown in figures Bl, B4 and B5. Theseinclude byte delivery time, interbyte quiet time, interbyte time, interpacket quiettime, packet throughput and packet size:

• Byte delivery time (BDT): The time between DAV true and DAV false.

• Interbyte quiet time (IBQT): The time between DAV false and DAV true.

• Interbyte time (lBT): The time between two successive DAV true states.Interbyte time is also equal to the sum of the byte delivery time and the interbytequiet time.

• Interpacket quiet time (IPQT): The time between the last DAV false state of apacket and the first DAV true state of the next packet.

• Packet size: The sum of the number of addressing, control and data bytes in apacket.

• Packet start time: The time the first addressing byte is detected with DAVactive, after one or more control or data bytes.

• Packet stop time: The time the last byte of a sequence of data or control bytes isdetected with DAV inactive.

• Packet duration: The time equal to packet stop time minus packet start time.• Packet throughput: The number of bytes in a packet divided by the packet

duration.The logged data was captured using events specified by one of the rising and fallingedges of DAV, IFC, SRQ, and Ear. We did not generate events based on rising orfalling edges of the other control lines for the following reasons:

40

Internal Use Only

• NRFD, NDAC: While the monitoring of these lines would have allowed us tomeasure parameters such as byte delivery time more accurately, there wouldhave been a significantly larger amount of data to log and process. Figure B1shows BDTerror and IBQTerror. These errors are typically a small percentage ofBDT and IBQT.

• ATN: The state of this line is needed to determine whether a byte is an IEEE488.1 command. This is automatically available by the events generated byDAV.

• REN: Monitoring this line might have allowed us to tell which long interpacketquiet times were due to local operations. We ignored transitions of this line tominimize the number oflogged events.

Available views of logger dataWe created various views of the logger data. The simplest is a tabular form showingthe control and data bytes in hexadecimal format along with the time stamp of eachstate and difference in time between the current state's timestamp and the previousstate's time stamp. An example is shown in figure B2.

Another view is similar to one obtained on a logic analyzer equipped with an HP-IBpost-processor where the state of each HP-IB control line and a decoded version of thedata lines. Time is shown as accumulated time with a delta time equal to the onedescribed above. An example is shown in figure B3.

The third view of the data is the packetized data format which consists of variousstatistical parameters regarding IBT, IBQT, BDT and overall packet parameters suchas throughput and number of each category of byte. This is a computer and humanreadable format which is used to make plots and perform further data reduction. Thelabels are inserted to allow easy reading by humans. An example is shown in figureB6.

Graphical analysisAny of the timing parameters may be extracted and saved into an ASCII file for usewith a graphical analysis package. The data may be explored by plotting histograms,and xy plots to look for correlations of interest.

41

Internal Use Only

DIOl·8

~--DAV I.. Byte delivery time _I.. Interbyte Quiet Time _I

NRFD

BDTerror 1 ~Terror

all ready

NDAC

all accepted

Figure 81. Data byte transfer timing

42

Internal Use Only

Sample # 1 Status 1 Timestamp Delta Control I Data---------1---------1----------- ----------- ---------1---------

1 1 e3 1 4e733e 0 bl 1 552 1 e3 1 4e7701 3e3 51 1 553 1 e3 I 4e7801 100 bl 1 3f4 1 e3 1 4e7ge3 le2 51 1 3f5 1 e3 I 4e7fe8 625 bl I 2e6 I e3 I 4e82e3 2db 41 2e7 1 e3 1 4e88be 5f9 al 528 1 e3 1 4e8a4a 18e 41 529 1 e3 I 4e8b58 10e al 45

10 I e3 1 4e8bdd 85 41 4511 e3 1 4e8eea 10d a1 5612 e3 1 4e8d6f 85 41 5613 e3 1 4e8e7e 10d al 3f14 e3 1 4e8fOl 85 41 3f15 e3 1 4e900e 10d al d16 e3 I 4e9093 85 41 d17 e3 1 4e9aOe 97b al a18 e3 1 4e9a92 84 41 a19 e3 1 4eb325 1893 bl 4e20 e3 1 4eb5a4 27f 51 4e21 e3 1 4ebbe9 625 bl 3f22 e3 1 4ebd8b le2 51 3f23 e3 1 4ebe8e 101 bl 3524 e3 1 4ee04d lel 61 025 e3 I 4ee582 535 al 3326 e3 1 4ee5f4 72 41 027 e3 1 4ee73b 147 a1 3028 e3 1 4ee7ad 72 41 029 e3 1 4ee8f4 147 al 3230 e3 I 4ee966 72 41 031 e3 1 4eeabf 159 al 3332 e3 1 4eeb31 72 41 033 e3 1 4eeebb 18a al d34 e3 1 4eed2e 71 41 035 e3 1 4eee82 156 al a36 e3 I 4eeef3 71 41 0

/ I \ \Data lines (base 16)

Indicates data integrityand data format(base 16) Raw time stamp Delta time Control lines (base 16)

(base 16) (base 16)

Figure 82. View of raw data

43

Internal Use Only

# I Control lines I Data IElpsd time 1 Delta \ END--1-------------------------------1-------1------------1------------1----

11DAV RFD ATN RENIMTA(21) I 0 021 - DAC ATN RENIMTA(21) I 963 96331DAV RFD ATN RENI UNL 1 1219 25641 - DAC ATN RENI UNL I 1669 45051DAV RFD ATN RENIMLA(14) I 3242 157361 - DAC RENI 2e .1 3973 73171DAV RFD RENI 52 RI 5502 152981 - DAC RENI 52 RI 5900 39891DAV RFD RENI 45 EI 6170 270

101 - DAC RENI 45 EI 6303 133111DAV RFD RENI 56 VI 6572 269121 - DAC RENI 56 VI 6705 133131 DAV RFD RENI 3f ?I 6974 269141 - DAC RENI 3f ?I 7107 133151DAV RFD RENI d I 7376 269161 - DAC RENI d 1 7509 13317\DAV RFD RENI a I 9936 2427 END18 DAC RENI a I 10068 13219 DAV RFD ATN RENIMTA(14) I 16359 629120 DAC ATN RENIMTA(14) I 16998 63921 DAV RFD ATN RENI UNL 1 18571 157322 DAC ATN RENI UNL I 19021 45023 DAV RFD ATN RENIMLA(21) I 19278 25724 RENI 0 1 19727 44925 DAV RFD RENI 33 31 21060 133326 DAC RENI 0 I 21174 11427 DAV RFD RENI 30 01 21501 32728 DAC RENI 0 I 21615 11429 DAV RFD RENI 32 21 21942 32730 DAC RENI 0 I 22056 11431 DAV RFD RENI 33 31 22401 34532 DAC RENI 0 I 22515 11433 DAV RFD RENI d I 22909 39434 DAC RENI 0 I 23022 11335 DAV RFD RENI a I 23364 342 END36 DAC RENI 0 I 23477 113

/ / /Delta time

State of control lines, a dash End of messageindicates the inactive state. Decoded data lines

Cumulative time

Figure 83. View of decoded data

44

Internal Use Only

# Control lines I Data IElpsd time 1 Delta I END-------------------------------1-------1------------1------------1----

1 DAV RFD ATN REN IMTA(21) I 0 02 DAC ATN RENIMTA(21) I 963 9633 DAV RFD ATN RENI UNL I 1219 2564 DAC ATN RENI UNL I 1669 4505 DAV RFD ATN REN MLA(14) I 3242 15736 DAC REN 2e . I 3973 7317 DAV RFD REN 52 RI 5502 15298 DAC REN 52 RI 5900 398 Packet9 DAV RFD REN 45 EI 6170 270 #1

10 DAC REN 45 EI 6303 13311 DAV RFD REN 56 VI 6572 26912 DAC REN 56 VI 6705 13313 DAV RFD REN 3f ?I 6974 26914 DAC REN 3f ?I 7107 13315 DAV RFD REN d 1 7376 26916 DAC REN d I 7509 13317 DAV RFD REN a I 9936 2427 END18 DAC REN a I 10068 132

191DAV RFD ATN RENIMTA(14) 16359 6291201 - DAC ATN RENIMTA( 14) 16998 639211DAV RFD ATN RENI UNL 18571 1573221 - DAC ATN RENI UNL 19021 450231DAV RFD ATN RENIMLA(21) 19278 257241 - RENI 0 19727 449251DAV RFD RENI 33 3 21060 1333261 - DAC RENI 0 21174 114 Packet271DAV RFD RENI 30 0 21501 327 #2281 - DAC RENI 0 21615 114291DAV RFD RENI 32 2 21942 327301 - DAC RENI 0 22056 114311DAV RFD RENI 33 3 22401 345321 - DAC RENI 0 I 22515 114331DAV RFD RENI d I 22909 394341 - DAC RENI 0 I 23022 113351DAV RFD RENI a I 23364 342 END361 - DAC RENI 0 I 23477 113

Figure 84. Packet definition

45

Internal Use Only

# I Control lines I Data IElpsd time I Delta I END--1-------------------------------1-------1------------1------------1----

11DAV RFD ATN REN[MTA(21) I 021 - DAC ATN REN MTA(21) I 96331DAV RFD ATN REN UNL ! 121941 - DAC ATN REN UNL I 16695!DAV RFD ATN REN MLA (14) I 324261 - DAC REN 2e . I 3973 Byte71DAV RFD REN 52 RI 5502 Delivery

Time81 - DAC REN 52 RI 590091DAV RFD REN 45 EI 6170

101 - DAC REN 45 EI 630311IDAV RFD REN 56 VI 6572121 - DAC REN 56 VI 670513IDAV RFD REN 3f ?I 6974 Interbyte

141 - DAC REN 3f ?1 7107 QuietTime

151DAV RFD REN d I 7376161 - DAC REN d I 7509171 DAV RFD REN a I 9936 END181 - DAC REN a 1 10068

191DAV RFD ATN RENIMTA(14) I 16359 ( 6291)201 - DAC ATN RENIMTA(14) I 16998 639

" Interpacket211DAV RFD ATN RENI UNL 1 18571 1573221 - DAC ATN RENI UNL I 19021 450 Quiet231DAV RFD ATN RENIMLA(21) I 19278 257 Time

241 - RENI 0 I 19727 449251 DAV RFD RENI 33 31 21060 1333261 - DAC RENI 0 I 21174 114271DAV RFD RENI 30 01 21501 327281 - DAC RENI 0 I 21615 114291DAV RFD RENI 32 21 21942 327301 - DAC RENI 0 1 22056 114311DAV RFD RENI 33 31 22401 345321 - DAC RENI 0 I 22515 114331DAV RFD RENI d I 22909 394341 - DAC RENI 0 I 23022 113351 DAV RFD RENI a I 23364 342 END361 - DAC RENI 0 I 23477 113

Figure 85. Definition of analysis terms

46

Internal Use Only

ISource-destination P k h d.> acetea.r.-----

Packet body

0000001 D 21-14 MTA(21) UNL MLA(14) 'R' 'E' 'V'0000001 DT - 4 d= 6 Thru=893.9213349225269 Start= 0 Stop= 0.010068 Duration= 0.010068 Bd_tirne= 0.003206Ib~tirne= 0.006862 Ib_rnin= 0.000402 Ib_rnax= 0.00256 Ib_avg= 0.001242 Ib_sdev=0.0009126268209326933 Abd_tirne= 0.002144 Abd_rnin= 0.00045 Abd_rnax= 0.000963Abd_avg= 0.0007146666666666666 Abd_sdev= 0.0002568897299101957 Cbd_tirne= 0Cbd_rnin= 0 Cbd_rnax= 0 Cbd_avg= 0 Cbd_sdev= 0 Dbd_tirne= 0.001062 Dbd_rnin=0.000132 Dbd_rnax= 0.000398 Dbd_avg= 0.000177 Dbd_sdev= 0.000108268185539428Ibq_rnin= 0.000256 Ibq_rnax= 0.002427 Ib~avg= 0.00085775 Ib~sdev=

0.0008595794237383102 sl= 1 s2= 18

Interpacketquiet time Packet statistics

~,=-----0000002 IQ BU-BU SEC Start= 0.010068 Stop= 0.01635~Duration= 0.006291)

0000003 D 14-21 MTA(14) UNL MLA(21) '3' '0' '2' '3' 015 0120000003 DT 14-21 units= SEC Lost= 0 N= 9 Na= 3 Nb= 6 Nc= 0 Nd= 6 Thru=1264.400112391121 Start= 0.016359 Stop= 0.023477 Duration= 0.007117999999999999Bd_tirne= 0.00222 Ib~tirne= 0.004898 Ib_rnin= 0.000441 Ib_rnax= 0.002212 Ib_avg=0.000875625 Ib_sdev= 0.0007070356502428189 Abd_tirne= 0.001538 Abd_rnin= 0.000449Abd_rnax= 0.0006389999999999999 Abd_avg= 0.0005126666666666666 Abd_sdev=0.000109409018519194 Cbd_tirne= 0 Cbd_rnin= 0 Cbd_rnax= 0 Cbd_avg= 0 Cbd_sdev= 0Dbd_tirne= 0.000682 Dbd_rnin= 0.000113 Dbd_rnax= 0.000114 Dbd_avg=0.0001136666666666667 Dbd_sdev= 5.163977794943227e-07 Ib~rnin= 0.000257Ibq_rnax=0.001573 Ib~avg= 0.0006122499999999999 Ib~sdev= 0.0005242068157838905sl= 19 s2= 36

Figure 86. View of packetized data

47

Internal Use Only

Appendix C Test case summary

This appendix contains an example of the set of plots and test case summaries whichwere created for each test case.

Two test summaries are generated. The first is an overall test summary showing themaximum, minimum and average values for various parameters of interest. Anabridged example is shown in table Cl. The second is a summary of the bus traffic ona per instrument basis. An example is shown in table C2.

A list of the most common mnemonics used in the test case is provided along with thesource and destination for each mnemonic and the number of times the mnemonicwas sent. An example is shown in table C3.

A series of seven plots were generated for each test case. The following sectionsdescribe each of the seven plots:

Histogram of packet throughputThis plot shows the distribution of the throughput for all logged packets. All thepacket throughputs are collected in a list and passed to the analysis package where ahistogram is created.

We expect to see a bifurcation of packet throughputs: a large number of slowerthroughputs and a smaller number of faster throughputs.

An example is shown in figure Cl.

Histogram of packet sizeThis plot shows the distribution of the packet size for logged packets. All the packetsize fields are collected in a list and passed to the analysis package where a histogramis created.

We expect to see a bifurcation of packet sizes: a large number of smaller packet sizesand a smaller number of larger packet sizes.


Plot of throughput versus packet sizeThis plot shows packet throughput versus packet size. The corresponding packetthroughputs and packet sizes are plotted on an x-y plot using the analysis package.

We expect to see larger packet sizes corresponding to faster throughputs.


Plot of cumulative bytes transferred versus test timeThis plot shows the areas of high data throughput. A list of cumulative bytestransferred is created and plotted versus the packet stop times.

We expect to see a series of staircase steps corresponding to larger packet sizes and arelative smooth sloped line where there are a lot of smaller packets. An example isshown in figure C2.

48

Internal Use Only

Data source: spd3

OVERALL THRUPUT

Number of address bytes 273 bytes

Number of control bytes 5 bytes

Number of data bytes 32830 bytes

Total bytes transferred 33108 bytes

Total test time 21.8 sees

Overall thruput 1514.8 bytes/sec

PACKET THRUPUT

Min packet thruput 3.69469 bytes/sec

Max packet thruput 123 Kbytes/sec

PACKET TIMING

% oftest time in address byte delivery time 0.34%

% oftest time in control byte delivery time 3.2%

% of test time in data byte delivery time 0.13 %

% of test time in interbyte quiet time 91.5 %

% of test time in interpacket quiet time 4.82%

Minimum interbyte time 4e-06 sees

Maximum interbyte time 4.8582 sees

Average interbyte time 0.000608 sees

PACKET SIZE

Min packet size 4 bytes

Max packet size 8195 bytes

NUMBER OF PACKETS

Number of data packets 83

Number of control packets 5

Number of mixed data and control packets 0

Total number of packets 88

UNILINE COMMAND USAGE

Number of SRQ occurences 0

Number of IFC occurences 0

Table Cl: Test case summary

49

Internal Use Only

Data source: spd3

TALKER PACKETS:

Talker Packets Total bytes Max packet Max thru-address sent sent size put(bytesl

sec)

0 72 1035 29 2.8ge+03

5 12 31989 8195 1.23e+05

22 4 84 21 24.7

LISTENER PACKETS:

Listener Packets Total bytes Max packet Max thru-address received size put(bytesl

sec)

0 16 32073 8195 1.23e+05

5 40 526 24 1.68e+03

9 25 404 29 2.8ge+03

20 5 76 20 1.24e+03

22 2 29 16 632

Table C2: Talker/listener summary

50

Internal Use Only

Most common HP-ffi commands used in this test: spd3

Count Source-destination Command sequence

4 00-09 IMP 0

4 00-09 FREQ 100097.66

4 00-09 DCRES HIGH

4 00-09 DCOFF 0

4 00-09 APPLY DCV 0

4 00-05 REST

4 00-05 *OPC?

4 00-05 *OPC

4 00-05 GET

2 00-09 APPLY ACV 2

2 00-05 SSIZE 512

2 00-05 SOUR A

2 00-05 SAMP;DEL 8.E-7

2 00-05 NUM;DISP NUM;EXP ON

2 00-05 MEAS;STAR;SLOP POS

2 00-05 MEAS;STAR;CHAN A

2 00-05 MEAS;FUNC CTIN

2 00-05 INT;OUTPUT FPO

2 00-05 BLOCK 1

2 00-05 ARMEDIN

Table C3: Most common HP-IB commands in test case

51

iI'0 ~

Internal Use Only

HP·IB packet ttTUput, SPDj, 12/18/91

21XXlJ 41XXlJ &llIO 81XXlJ IIXXXXI 121XXlJ 140iXXl

!!

I'0 ~

J

. '"

, ,

2COO

"

HP4B packa size, SPDj, 12/18/91

4iXXl

po:k"lize,O/1JS

Throughput versus pocket size, SPDj, 12/18/91

8iXXl

• I

10 50 100

po:kltlize,O/1JS

500 liXXl 5iXXl IIXXlJ

Figure C1. Distribution of packet throughput and packet size

52

Internal Use Only

B~es transferred, SPDJ, 12/18/91

oooo(')

I/)

2>..a 0

ii g(J) 0:: C\I(J)....I/Jc:~... 0I/) 0(J) 0>. 0aJ ...

•

I.-,-..,..------.._.,-,,-.-...I.-.-....

o - --.- .

o 5 10

test time, sees

15 20

Active HP·IBtime, SPDJ, 12/18/91

activ

50 packets/ramp

(J)...(lJ

'0(J)

>:;:;o(lJ

I/J::laJ

inacti e

...--""---

,..--""'--

-

o 5 10

Test time, sees

15 20

Figure C2. Cumulative bytes transferred and active time plots

53

Internal Use Only

Plot of active HP-IB timeThis plot gives an indication of active and quiet times during the test. A pulse isplotted for each packet duration. The pulse rises to one at the packet start time anddrops to zero at the packet stop time.We expect to see either pulses or bands of black corresponding to HP-IB activity andareas without pulses corresponding to no HP-IB activity. Care must be taken in theinterpretation of the white areas. If the white area has no pulses it corresponds to along interpacket quiet time. If the white area is a long pulse it means the packet tooka long time to execute.

An example is shown in figure C2.

Distribution of HP-IB activityThis plot indicates the percentage of test time spent in each of five categories: 1)address byte delivery time, 2) control byte delivery time, 3) data byte delivery time,4) interbyte quiet time, and 5) interpacket quiet time.

In general we expect to see a large percentage of time spent in interbyte quiet timeand interpacket quiet time. A larger percentage of time will be spent in interpacketquiet time if the test is relatively long and the bus is not loaded. A larger percentageof time will be spent in interbyte quiet time if there are mnemonics which take a longtime to execute or if the bus is loaded and the time between packets is short.An example is shown in figure C3.

Distribution of transmitted bytesThis plot indicates the percentage of transmitted bytes which were address, controland data bytes.

We expect to see the majority of the bytes transferred to be data bytes, however if themajority of the packets are small then there will be a larger percentage of addressingbytes. A test which performs intensive serial polls may have a higher percentage ofaddressing and control bytes.An example is shown in figure C3.

54

Internal Use Only

Distribution of Hp·IB activity, SPDJ,12/18/91

•91,51

80

Q)

E:p

t? 60Q)......oQ)

~ 40...cQ)

~Q)

a. 20

•4,820,13•3,20,34•o'----r--------,----------,--------r--------.,.----'

Address BDT Control BDT Data BDT Interbyte quiet Interpkl quiet

Bus activity category, Note: BDT =byte delivery time

Distribution of Hp·IB transmission, SPD_3, 12/18/91

10C99,16

IIIQ)

>. 80.0'0Q);::'E 60IIICCIl.........o 40Q)ClscQ)

~ 20Q)

a.

0,020,82o'----r-----------------,--------------.,.----'

Address Control

Information type

Data

Figure C3. Distribution of HP-IB activity and HP-IB transmission

55

Internal Use Only

Appendix D: Examples of different HP-IB instrument parser/driversThis appendix contains examples of four different timing behaviors we observed inthe test cases.

1. No noticeable difference in BDT or IBQT. The bus is released quickly. Themnemonic appears to be executed in the interpacket quiet time. An example ofthis is an HP Modular Measurement System module.

An example of such a packet is shown in figure D1. The interbyte quiet times areshown in bold type. Note also the very short byte delivery times.

2. A longer time is observed for the IBQT associated with a carriage return (CR)implying the mnemonic is executed after this character is parsed. The bus is heldoff. An example is the HP 3335A.


3. A longer time is observed for the IBQT associated with a line feed (LF) implyingthe mnemonic is executed after this character is parsed. The bus is held off. Anexample is the HP 8340A.


4. A longer time is observed for the BDT on every byte except for CR or LF. Anexample is the HP8902A.

An example of such a packet is shown in figure D4. The longer byte deliverytimes are shown in bold type.

56

Internal Use Only

Address 18, HP MMS moduleSAD_I, 1/14/92

# 1 Control lines 1 Data IElpsd time 1 Delta 1 END--1-------------------------------1-------1------------1------------1----l24521DAV RFD ATN124531 - DAC ATN124541DAV RFD ATN124551 - DAC ATN124561DAV RFD ATN124571 - DAC ATN124581DAV RFD124591 - DAC12460lDAV RFD124611 - DAC12462\DAV RFD124631 - DAC124641DAV RFD124651 - DAC124661DAV RFD124671 - DAC124681DAV RFD124691 - DAC12470lDAV RFD124711 - DAC12472 DAV RFD12473 DAC12474 DAV RFD12475 DAC12476 DAV RFD12477 DAC12478 DAV RFD12479 DAC12480 DAV RFD12481 DAC12482 DAV RFD12483 DAC12484 DAV RFD12485 DAC

RENIMTA(21) IRENIMTA(21) 1RENI UNL lRENI UNLREN MLA(18)REN MLA(18)REN 49 I

REN 49 I

REN 4e NREN 4e NREN 50 PREN 50 PREN 55 UREN 55 UREN 54 TREN 54 TIREN 4d MIREN 4d MIREN 4f 01REN 4f 01REN 44 DIRENI 44 DREN1 20RENI 20RENI 20RENI 20RENI 31 1RENI 31 1RENI 3f ?

RENI 3f ?RENI dRENI dRENI aRENI a

149605098149605339149605371149605489149605521149605641149605812149605813149605910149605911149606090149606091149606232149606232149606412149606413149606553149606554149606700149606701149606978149606979149607119149607120149607479149607480149607573149607574149607760149607761149607930149607931149608031149608032

1253241

32118

32120171

197

1179

1141

o180

1140

1146

1277

1140

1359

193

1186

1169

1100 END

1

Figure 01. MMS module timing example

57

Address 12, HP 333SASAD_I, 1/14/92

Internal Use Only

# 1 Control lines 1 Data IElpsd time 1 Delta 1 END--1-------------------------------1-------1 -----------1------------1----7531DAV RFD ATN RENIMTA(2l) 33520457 1376257541 - ATN RENIMTA(21) 33520594 1377551DAV RFD ATN RENI UNL 33520627 337561 - ATN RENI UNL 33520744 1177571DAV RFD ATN REN IMLA(12) 33520777 337581 - DAC RENI 2c 33520897 1207591DAV RFD RENI 46 F 33521601 7047601 - DAC RENI 46 F 33521644 43761jDAV RFD RENI 34 4 33523485 18417621 - DAC RENI 34 4 33523528 43763\DAV RFD RENI 35 5 33524070 5427641 - DAC RENI 35 5\ 33524117 477651DAV RFD RENI 30 01 33524606 4897661 - DAC REN\ 30 01 33524653 477671DAV RFD RENI 30 01 33525142 4897681 - DAC RENI 30 01 33525189 477691DAV RFD RENI 30 01 33525678 4897701 - DAC RENI 30 01 33525725 477711DAV RFD RENI 30 01 33526214 4897721 - DAC RENI 30 01 33526261 477731DAV RFD RENj 30 01 33526750 4897741 - DAC RENI 30 01 33526797 477751DAV RFD RENI 30 01 33527286 4897761 - DAC RENI 30 01 33527333 477771DAV RFD REN 2e .1 33527822 4897781 - DAC REN 2e .1 33527869 477791DAV RFD REN 30 01 33528082 2137801 - DAC REN 30 01 33528129 477811DAV RFD REN 30 01 33528397 2687821 - DAC REN 30 01 33528444 477831DAV RFD REN 30 01 33528708 2647841 - DAC REN 30 01 33528755 477851DAV RFD REN 48 HI 33529034 2797861 - DAC REN 48 HI 33529081 477871DAV RFD REN d 1 33530948 ( 1867 )7881 - DAC REN d 1 33530995 477891DAV RFD REN a 1 33531149 154 END7901 - DAC REN a I 33531196 47

Figure 02 HP3335A timing example

58

Internal Use Only

Address 17, HP 8340ASAD_I, 1/14/92

# I Control lines I Data IElpsd time I Delta I END--1-------------------------------1-------1------------1------------1----21697\DAV RFD ATN REN MTA(21) I 436550015 190216216981 - ATN REN MTA(21) 436550166 15121699\DAV RFD ATN REN UNL 436550199 33217001 - DAC ATN REN UNL 436550316 117217011DAV RFD ATN REN MLA(17) 436550349 33217021 - DAC REN 31 1 436550469 12021703 IDAV RFD REN 43 C 436550631 162217041 - DAC REN 43 C 436550632 1217051DAV RFD REN 57 W 436550845 213217061 - DAC REN 57 W 436550846 1217071 DAV RFD REN 20 436551877 1031217081 - DAC REN 20 436551877 021709 IDAV RFD REN 35 5 436557628 5751217101 - DAC REN 35 5 436557629 121711IDAV RFD RENI 2e 436558079 450217121 - DAC RENI 2e 436558080 121713 IDAV RFD RENI 45 E 436558759 679217141 - DAC RENI 45 E 436558760 1217151DAV RFD RENI 2b + 436559264 504217161 - DAC RENI 2b + 436559265 121717IDAV RFD REN\ 37 7 436559946 68121718\ - DAC RENI 37 7 436559946 0217191 DAV RFD RENI 48 HI 436560397 451217201 - DAC RENI 48 HI 436560397 021721!DAV RFD RENI 5a ZI 436561077 680217221 - DAC RENI 5a ZI 436561077 0217231DAV RFD RENI d 1 436561543 466217241 - DAC RENI d I 436561544 1217251DAV RFD RENI a I 436596935 ( 35391 END)217261 - DAC RENI a I 436596936 1

Figure 03 HP 8340A timing example

59

Internal Use Only

Address 14, HP 8902ASAD_I, 1/14/92

RENIMTA(21) 1 148307632RENIMTA(21) 1 148307859RENI UNL 1 148307891RENI UNL I 148308009RENIMLA(14) 1 148308041RENI 2e .1 148318279REN 54 TI 148318321REN 54 TI 148328815REN 30 01 148328821REN 30 01 148339347REN 20 1 148339356REN 20 1 148352161REN 4c LI 148352169REN 4c LI 148362622REN 47 GI 148362640REN 47 GI 148373155REN d 1 148373162REN d 1 148373233 71REN a \ 148373252 19 ENDREN a 1 148373252 0

# I Control lines 1 Data IElpsd time 1 Delta 1 END--1-------------------------------1-------1------------1------------1----123641DAV RFD123651 123661DAV RFD123671 123681DAV RFD12369\ 12370lDAV RFD123711 123721DAV RFD123731 123741DAV RFD123751 - DAC123761DAV RFD12377 I 123781DAV RFD123791 - DAC12380\DAV RFD123811 - RFD123821DAV RFD123831 -

Figure 04. HP8902A timing example

60

an analysis of hp-ib performance · hp-ib,performance, measurement systems, test systems,...

Documents