UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

On the feasibility of using StarLAN to implement the FASTBUS Serial Network Cam, Richard 1989

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1989_A7 C35.pdf [ 10.42MB ]
Metadata
JSON: 831-1.0085036.json
JSON-LD: 831-1.0085036-ld.json
RDF/XML (Pretty): 831-1.0085036-rdf.xml
RDF/JSON: 831-1.0085036-rdf.json
Turtle: 831-1.0085036-turtle.txt
N-Triples: 831-1.0085036-rdf-ntriples.txt
Original Record: 831-1.0085036-source.json
Full Text
831-1.0085036-fulltext.txt
Citation
831-1.0085036.ris

Full Text

O N T H E FEASIBILITY  OF USING S T A R L A N TO I M P L E M E N T T H E  FASTBUS SERIAL  NETWORK  By Richard C a m B . A . Sc. (Engineering Physics) University of British Columbia  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF T H E REQUIREMENTS FOR T H E D E G R E E OF M A S T E R OF APPLIED  SCIENCE  in T H E FACULTY OF GRADUATE STUDIES PHYSICS  We accept this thesis as conforming to the required standard  T H E UNIVERSITY  OF BRITISH COLUMBIA  October 1988  © Richard C a m , 1988  In  presenting this  degree at the  thesis  in  partial  fulfilment  University  of  British  Columbia,  of  the  requirements  I agree that the  freely available for reference and study. 1 further agree that copying  of  department  this thesis for scholarly or  by  his  or  her  for  It  is  permission for extensive  understood  head of my  that  publication of this thesis for financial gain shall not be allowed without permission.  Department-of  THV<, I CS  The University of British Columbia Vancouver, Canada  Date  DE-6 (2/88)  3-8  OCTOggR  /^gF  advanced  Library shall make it  purposes may be granted by the  representatives.  an  copying  or  my written  Abstract  During the inception of F A S T B U S , an autonomous data link, informally known as the F A S T B U S Serial Network, was conceived as an auxiliary communications channel to be used in diagnostic applications for debugging F A S T B U S systems. Since then, there have been several attempts at implementing this serial network, all of which have produced somewhat mixed results. This thesis describes the latest attempt to implement a prototype F A S T B U S serial network. B y using a new L A N specification called S t a r L A N , some promising results have been obtained. These results show that S t a r L A N can be successfuDy adapted to implement the serial network without requiring major modifications. Furthermore,  StarLAN  seems to have the desirable characteristics of simplicity, low cost, an 'acceptable'  data  rate, and having multiple vendor support — advantages that previous implementation attempts had not possessed simultaneously.  As such, S t a r L A N is the most promising  solution to the serial network problem to have appeared so far. This document will begin with a background discussion of F A S T B U S , the F A S T B U S Serial Network, and S t a r L A N . It will then discuss, in detail, how the prototype network was built, followed by a description and analysis of the performance measurements that were taken. It will also discuss considerations and options for a practical implementation of the serial network, based on experience from the work done with the prototype. Finally, a summary of the key results and an assessment of the S t a r L A N approach is given to conclude the thesis. It is hoped that this document will be able to resolve many outstanding about a StarLAN-based serial network.  questions  Perhaps, F A S T B U S users can now decide on  whether or not to use S t a r L A N to implement the F A S T B U S Serial Network.  m  Table of Contents  Abstract  ii  List of Tables  vi  List of Figures  vii  Acknowledgement 1  Introduction  1  1.1  FASTBUS  1  1.1.1  Basic Operational Description of F A S T B U S  2  1.1.2  Motivation for the F A S T B U S Serial Network  5  1.1.3  Historical Background of the F A S T B U S Serial Network  7  1.2  StarLAN 1.2.1  2  xi  14  S t a r L A N i n the Framework of the OSI M o d e l and Other I E E E 802 Protocols  15  1.2.2  Basic Operational Description of S t a r L A N  21  1.2.3  S t a r L A N and the F A S T B U S Serial Network  32  1.2.4  Variations to Standard S t a r L A N  36  Building the Prototype Serial Network  40  2.1  A Simple S t a r L A N Network  40  2.2  Using S t a r L A N in a F A S T B U S Environment  43  IV  3  4  5  Measurements  55  3.1  Electrical Characteristics of S t a r L A N Signals i n the F A S T B U S Backplane  55  3.2  Network Performance Measurements  65  System Implementation Options  97  4.1  Topology  97  4.2  B i t Rate  99  4.3  Access Scheme  100  Summary of Results and General Assessment  103  Appendices  105  A  P A L A S M Listing, Notes on Transceiver and H u b Circuits  105  A.l  P A L Device Logic Equations  105  A.2  Functional Description of the S t a r L A N - F A S T B U S Transceiver  105  A.3  Functional Description of the S t a r L A N H u b Circuit  107  B  Photographs and Table of Electrical Measurements  109  C  Tables of Preliminary Performance  129  D  Calculation of Software Overhead T i m e  135  E  Notes on the A u t o m a t e d Network Driver P r o g r a m  138  Data  Bibliography  152  v  List of Tables  B. l  Propagation delay and pulse jitter measurements  110  C. 2  Network configurations for preliminary performance measurements.  C.3  General transmission data for 72-byte frames  130  C.4  General transmission data for 532-byte frames  131  C.5  General transmission data for 1526-byte frames  131  C.6  Distribution of Collision Resolution Interval for 72-byte frames  132  C.7  Distribution of Collision Resolution Interval for 532-byte frames  133  . . .  129  C. 8 Distribution of Collision Resolution Interval for 1526-byte frames  134  D . 9 Overhead times for different field lengths  137  VI  List of Figures  1.1  F A S T B U S Segments  3  1.2  Interconnected F A S T B U S Segments  6  1.3  Single line direct routing scheme  8  1.4  Single line repeater-based scheme  9  1.5  Two-line connection  11  1.6  OSI 7-Layer Reference Model  17  1.7  I E E E Local Area Network Architecture  19  1.8  I E E E 802 Protocols  20  1.9  Star Topology  22  1.10 Bus and Ring Topologies  23  1.11 Manchester Encoding and RS-422 Voltage Levels  24  1.12 Token-passing Access Method  26  1.13 S t a r L A N framing format  26  1.14 Worst-Case Scenario for Collision Detection  28  1.15 Collision Presence Signal  30  1.16 Infinite Loop i n a S t a r L A N Network  31  1.17 S t a r L A N i n an integrated office  33  1.18 S t a r L A N network using intra-building telephone cables  34  1.19 StarLAN-based serial network on F A S T B U S  35  1.20 Bussed S t a r L A N network  36  1.21 Node connection schemes for bussed S t a r L A N  37  vii  1.22 Bussed S t a r L A N i n the F A S T B U S Serial Network  39  2.23 S t a r L A N Network Configurations  42  2.24 Schematic diagram of the S t a r L A N - F A S T B U S tranceiver  45  2.25 Block Diagram of Hub Circuit: I / O Section  50  2.26 Block Diagram of Hub Circuit: Downstream Section  51  2.27 Block Diagram of Hub Circuit: Upstream Section  52  2.28 Schematic Diagram of Hub Circuit with W D 8 3 C 5 1 0 Controller  53  3.29 Sample capacitor load for the F A S T B U S backplane  58  3.30 Reference points for edge transitions  60  3.31 Schematic diagram of electrical measurements  62  3.32 Schematic diagram of electrical measurements (continued)  63  3.33 Typical oscilloscope traces (ref. 25)  64  3.34 Oscilloscope trace of bumpy edge transition (ref. 17)  65  3.35 Average throughput for a single-PC network  72  3.36 Average throughput for a 2 - P C network  74  3.37 Average offered load for a 2 - P C network  75  3.38 Number of deferrals expressed as a fraction of offered load  76  3.39 Average throughput for a 3 - P C network without frame receptions  80  3.40 Fractional standard deviation of throughput  81  3.41 Average offered load for a 3 - P C network without frame receptions  82  3.42 Fractional standard deviation of offered load  83  3.43 Number of collisions expressed as a fraction of offered load  84  3.44 Number of deferrals expressed as a fraction of offered load  85  3.45 Number of unresolved collision intervals as a fraction of offered load . . .  86  3.46 Average throughput for a 3 - P C network w i t h frame receptions  87  vin  3.47 Average offered load for a 3 - P C network with frame receptions  88  3.48 Deferred transmissions expressed as a fraction of the offered load  89  3.49 Collisions expressed as a fraction of the offered load  90  3.50 Lost frames expressed as a fraction of the total number of received frames.  91  3.51 Buffer overflows expresssed as a fraction of the total number of received frames  92  3.52 Number of unresolved collision intervals as a fraction of offered load . . .  93  3.53 Fractional standard deviation of throughput  94  3.54 Fractional standard deviation of offered load  95  A . 55 Logic Equations for P A L device of Intel S t a r L A N board  106  B . 56 Reference number 7  Ill  B.57 Reference number 8  112  B.58 Reference number 9  113  B.59 Reference number 10  114  B.60 Reference number 11  115  B.61 Reference number 12  116  B.62 Reference number 13  117  B.63 Reference number 14  118  B.64 Reference number 15  119  B.65 Reference number 16  120  B.66 Reference number 17  121  B.67 Reference number 18  122  B.68 Reference number 19 .  123  B.69 Reference number 20  124  B.70 Reference number 21  125 ix  B.71 Reference number 23  126  B.72 Reference number 24  127  B.73 Reference number 25  128  E.74 Subroutine Flowchart of Driver Program, Part 1 of 3  139  E.75 Subroutine Flowchart of Driver Program, Part 2 of 3  140  E.76 Subroutine Flowchart of Driver Program, Part 3 of 3  141  E.77 Header Files  142  E.78 Header Files (continued)  143  E.79 Header Files (continued)  144  E.80 Header Files (continued)  145  E.81 Header Files (continued)  146  E.82 Header Files (continued)  147  E.83 Header Files (continued)  148  E.84 Sample Master Program  ,  149  E.85 Sample Slave Program  150  E.86 Sample Output File  151  x  Acknowledgement  T h e author gratefully acknowledges the contributions of the following individuals for their assistance in the course of the project that has culminated in this thesis.  Of the  staff at T R I U M F ' s microprocessor laboratory, Brian Evans and David Morris gave useful technical advice. T h e work area in the lab was borrowed from Robert Skegg. Layouts of all the printed circuit boards were done by Peter Bennett. Graham Waters was most helpful in showing how to access the laser printer through the network.  P C ' s for the  later performance measurements were generously provided by Prof. Glen Young and the Department of Harvesting and Wood Science at U B C . Consultation was sought on several occasions from D r . H . Lee, formerly with the Department of Electrical Engineering at U B C , but who has since moved to Carleton University. Finally, I would like to thank my three supervisors, B o b Dobinson (now at C E R N ) , K e n Dawson of T R I U M F , and Dr. E d A u l d of the Department of Physics at U B C , for guiding me safely through the past two years.  xi  Chapter 1  Introduction  1.1  FASTBUS  F A S T B U S is a data bus system used primarily in nuclear and particle physics experiments for high-speed data acquisition, processing, and control. It was developed from the late seventies through the early eighties in response to requirements from the high-energy physics community for a bus system with higher throughput in data acquisition and processing. Its development was prompted by the realization that existing data busses would be unable to cope with requirements imposed by future experiments.  Improve-  ments in accelerator technology as well as the increasing complexity of many experiments were leading to faster event rates and more measurements for individual events—factors which demanded higher data throughput than ever before in spite of the fact that most of the events measured in those experiments did not contain relevant data.  FASTBUS  was designed to alleviate this problem through two routes: first, by having higher data transmission rates (i.e., by 'brute force'), and second, by offering a multisegment architecture that allowed simultaneous data acquisition and processing (and therefore, real-time data reduction),  thus reducing the load placed on the bus by the transmission of largely  irrelevant data. F A S T B U S has been and still is used i n many experiments at virtually all major nuclear and particle physics research facilities around the world.  Although F A S T B U S  was designed for high-energy physics experiments, its capabilities do not limit it to those  1  Chapter 1.  Introduction  2  applications. In general, it is feasible for any system that requires a bus with high data rates and multiprocessing capability. In 1984, F A S T B U S was adopted as a formal A N S I and I E E E specification, the A N S I / I E E E 960 Standard.  1.1.1  Basic Operational Description of F A S T B U S  FASTBUS  1  is a modular, segmented bus system: a typical application might have several  'Segments', each with its own set of devices. Each of these Segments operate independently but can also dynamically link with other Segments for inter-segment operations. A Segment has 32 multiplexed address/data lines plus additional lines for power distribution, control, timing, arbitration, and other functions. There are two types of Segments: One is a 'Crate Segment' where devices (i.e., electronic circuit cards) plug into connectors on a backplane i n much the same way as peripheral cards plug onto the motherboard of a microcomputer. T h e other is called a 'Cable Segment' which, as the name suggests, links attached devices by multi-conductor cable. There are five types of devices which can attach onto a segment: 'Masters', 'Slaves', 'Processor Interfaces', 'Segment Interconnects', and 'Terminators'. A Master is a device which can acquire control of a segment (or other segments, in the case of inter-segment operations) and initiate operations.  Slaves can  only respond to instructions issued from Masters and cannot independently take control of the bus. Processor Interfaces link a Segment to a host processor (e.g., an external computer).  Segment Interconnects link two or more Segments together temporarily so  that inter-segment operations can be done. Segments are terminated at both ends by Terminators, which provide impedance-matching (to reduce reflections on signal lines). Crate segment Terminators are usually mounted on cards which contain electronic circuits to support functions related to timing, control, and addressing. Figure 1.1 shows the simple schematic diagrams of these two segments along with some attached devices. see [1], [2], and [3] for more details.  1  er 1.  Introduction  CRATE  0  SEGMENT  © HDST PRDCESSDR  CABLE  SEGMENT  HDST PRDCESSDR part  K E Y : Slave SI  ^\J_^J Segment  ^  e  r  n  i  n  a  ^  o  r  o f cable PI  segment  Processor  Interconnect  Figure 1.1: F A S T B U S Segments  M  Interface Master  Chapter 1.  Introduction  4  F A S T B U S is different from man}' other busses in that more than one Master can be attached to the bus. This allows independent multiprocessing operations but complicates the system since a bus arbitration scheme is needed to decide which Master takes control of the Segment(s) i n the event that more than one Master wants to use the bus at the same time. Furthermore, there is the possibility of 'starvation' among other Masters if one Master controls the bus for a disproportionate amount of time.  Such a situation  can occur because a bus Master may not be interruptible. (In F A S T B U S , this problem can be avoided i f all masters abide by the Assured Access protocol.) Nevertheless, the advantages of a multiple-master bus outweigh the added complexity by such a large margin that the current trend of high-performance  busses is towards multiple-master  systems (e.g., N u B u s , used i n the Apple Macintosh II microcomputer). Inter-segment communications are dynamically established by Segment Interconnects attached to the corresponding Segments.  A Segment Interconnect physically couples a  Backplane to a Cable Segment. These devices are responsible for handling inter-segment information traffic i n a 'transparent' manner such that devices in different segments can be accessed as if they were intra-segment devices. They perform the dual tasks of isolating a segment from the rest of the system during intra-segment operations and connecting two or more segments together as if those were one contiguous segment when inter-segment operations are required. Route tables are used to determine the data path during intersegment operations. The capability of inter-segment operations allows a multiple-master system to exploit its multiprocessing power not just within isolated segments (with their limited number of attached devices) but to the whole system. Furthermore, does not specify the topology for Segment interconnections.  FASTBUS  It does not specify which  Segments should be linked or which should not. This gives the system designer maximum flexibility i n adding inter-segment connections to suit the particular application and to maximize system throughput.  For example, segments which often communicate with  Chapter 1.  Introduction  5  each other should be grouped closely together so as to reduce inter-segment propagation delay. In addition, they should also have direct links to each other instead of indirect links (which pass over other Segments) so as not to disrupt intra-segment operations in those Segments. Figure 1.2 shows schematic diagrams of several interconnected Segments. The number of Segments used in a F A S T B U S application can run from as few as one to as many as several hundreds.  1.1.2  Motivation for the F A S T B U S Serial Network  Regardless of the number of Segments, problems with a F A S T B U S system can occur. Because of its complexity, it is usually not a trivial task to debug the bus system, especially if there are many inter-connected Segments and a large number of attached devices. Hence, as F A S T B U S evolved, the F A S T B U S Serial Network ( F S N ) was conceived to provide a system-wide communication network for diagnostic purposes. This network is autonomous from the rest of the bus system. Hence, it can remain effective even when the remainder of the system is not functional. A typical F A S T B U S diagnostic scenario might occur as follows: A faulty Segment Interconnect device is suspected to be causing problems with inter-segment  operations.  D a t a traffic between the affected Segments must be examined to determine if this is indeed the case. However, the F A S T B U S system cannot be used to transfer data between those Segments because it is not operating properly—a broken F A S T B U S system cannot be used to diagnose itself. Hence, the data must be sent either through an external facility or through an unaffected, internal, autonomous communication link. Although the F A S T B U S Serial Network was originally conceived for diagnostic purposes, its scope of application is not restricted to that area alone. T h e F S N can be used as the data channel i n a 'backdoor initialization' scheme for starting up a F A S T B U S system. For example, data for initializing route tables could be sent through the serial  Chapter 1.  Introduction  6  Chapter  1.  Introduction  7  network. Another application that could use the F S N is a system sentinel which monitors the F A S T B U S system for abnormal operating temperature and power supply voltages. F A S T B U S devices could periodically send data through the serial network to inform the sentinel of their operating conditions without placing an additional load on the intersegment links. The F S N can also be used for remote switching of F A S T B U S devices. A device can be controlled from a remote terminal through the serial network, which would be used to transmit programming data to the device and send back status information to the terminal. A n operator would no longer have to open a crate and physically access the device to change its switches or read its status lights. In spite of the wealth of applications which could use a separate data network, the F A S T B U S Serial Network is, as of 1988, not yet operational. Formal specifications have not yet been given or agreed upon for either its implementation or applications. A brief history of the F S N (from [4]) is given i n the next paragraphs to summarize past efforts and to put the current work into perspective.  1.1.3  Historical Background  of the F A S T B U S Serial Network  In mid-1979, a single line (SL) on the Crate backplane Segment was reserved for the F A S T B U S Serial Network. This was done with the idea that some single-line, industrystandard network, such as Ethernet, could be used. However, there were problems with using only one line. For example, it was not practical to route the serial links in from one end of the Segment and out at the other end because each Segment would then contribute a large lumped capacitance to the line, resulting in impedance mismatches which, in turn, would cause enormous signal reflections (see figure 1.3). the network would be very high since all transmitters  T h e line capacitance of  and receivers (along with their  load capacitances) were connected to the same line. A repeater could be used to link the external line to the Segment (figure 1.4). It would act essentially as a bridge, relaying  Chapter 1.  Introduction  Ethernet  line  y  y  y  EQUIVALENT  CIRCUIT:  L a r g e capacitances due t o devices a t t a c h e d t o e a c h segment.  Figure 1.3: Single line direct routing scheme  Chapter 1.  Introduction  Figure 1.4: Single line repeater-based scheme  Chapter 1.  Introduction  10  signals between the line and the Segment, while isolating the Segment's capacitive load. This was an expensive solution. Moreover, Ethernet, the candidate standard at that time, limited the number of such repeaters to only two per network.  So, by October  1980, a second line ( S L R ) was added. (The current F A S T B U S standard refers to these lines as 'Serial T X ' and 'Serial R X ' . ) W i t h this scheme (figure 1.5), one line would be used by all devices for transmitting while the other line would be used for receiving. A network 'bridge' would link data between the two lines and an external line.  Overall  capacitance load on the transmit and receive lines was also reduced since transmitters and receivers i n each Segment were now connected to their respective lines instead of having to share one line. A t this point, Ethernet looked to be a very promising standard for the F A S T B U S Serial Network. If integrated circuits that implemented Ethernet became available (as usually happens for popular industry standards), then it would be an easy task to use Ethernet for the F S N . However, Ethernet, was also an evolving local area network ( L A N ) standard at that time and its specifications were not yet fixed. T h e data rate of Ethernet was initially set at 1 Mbps. This would have been ideal for the F S N since simple collisiondetection circuitry could be used. However, that data rate was changed to 10 Mbps for higher L A N throughput, complicating not only the task of detecting collisions but also that of processing data faster.  It was still possible, in principle, to use Ethernet, but  it would require more expensive electronic circuits and, more significantl}', more circuit board area.  Hence, the idea of using Ethernet for the F A S T B U S Serial Network was  dropped and the search was on for suitable alternatives. In October 1980, a research group at the Stanford Linear Accelerator Center ( S L A C ) began to develop a prototype serial communication network based on an S D L C (Serial D a t a Link Control) chip (the Zilog Z80-SIO). This system had a data rate of up to several hundred kbps and occupied only 13 c m of circuit board area. T h e hardware was built in 2  Chapter  1.  Introduction  Figure 1.5: Two-line connection  Chapter  1.  Introduction  12  1981 and some support software was developed shortly afterwards.  However, the S L A C  group was reluctant to implement the prototype because they were still hoping for an industry standard network to evolve that would fit their needs. The same group then tried to use the AppleTalk(tm) network.  This network was  based on a newer S D L C chip, the Zilog Z8530, and required only 1 in  2  of board area. It  had a data rate of 230400 bps, which was slow enough for data processing without using a D M A (Direct Memory Access) controller (which would have been required for higher data rates, such as that of Ethernet). It was also compatible with the two-line serial network scheme and was already supported by commercial software for data transfer. This system was not implemented either, in spite of its promising characteristics, because the group wanted to delay standardization until the 'last possible moment' just i n case a better system became available. A n d , perhaps, a better system may have arrived. S t a r L A N , a new L A N standard, seems to have most, if not all of the features desired for the F A S T B U S Serial Network. It has a data rate of 1 M b p s , which is not too slow, but slow enough to allow the use of simpler collision detection schemes and less expensive electronic circuitry.  It still  requires D M A support, but D M A controllers are less expensive now than they were before.  Furthermore, C P U s with built-in D M A controllers are now available. B u t the  most important aspect of S t a r L A N is that it is an industr}' standard, with wide multivendor support. S t a r L A N is similar i n many respects to Ethernet (already a very popular and widely used L A N standard) and hence, can be easily connected to that network by a StarLAN-Ethernet 'bridge'. M a n y integrated circuit manufacturers have developed chips for S t a r L A N controllers, making it possible to build circuits occupying very little board space. Although S t a r L A N is more expensive than AppleTalk(tm), it has better prospects for long-term use and expansion.  As of this time (late 1988), a better alternative to  S t a r L A N has yet to come. S t a r L A N is a fairly young standard (it was standardized in  Chapter 1.  Introduction  13  early 1987) and thus, is not expected to become 'obsolescent' at least for the next fewyears. Preliminary work on a StarLAN-based serial network has been done at T R I U M F (and perhaps also i n other places). The contribution from T R I U M F is the subject of this thesis.  Chapter 1.  1.2  Introduction  14  StarLAN  S t a r L A N , officially known as the I E E E 802.3 1 B A S E 5 standard  2  , is a new local area  network ( L A N ) standard designed for office integration and automation.  (Local Area  Networks are short-distance data communication facilities connecting computers at distances of between a few meters to several kilometers apart, typically within a single or a localized cluster of buildings.) It was developed as a low-cost alternative to Ethernet (an earlier L A N standard)  3  for use i n systems based on personal computers.  These  systems typically do not require the high performance of Ethernet, and consequently, cannot justify the higher connection cosis associated w i t h "those networks. A t that time (early 80's), existing L A N standards were designed primarily for centralized mainframe and minicomputer systems. A study dome i n 1985 [7] showed that only a small fraction of the estimated 10 milhon P C s being used were networked. This finding was especially significant i n office environments, where P C s have become increasingly popular but function more efficiently when networked together with other resources i n the office such as printers and mass storage media (data l)ases).  These unconnected P C s represented a  huge, untapped base of users waiting for a more affordable L A N . W i t h the number of P C s expected to reach up to 20 million units by 1990, the development of cheaper L A N ' s became ever more urgent—and lucrative. S t a r L A N i s one of the most recent entries in this class of L A N ' s . S t a r L A N derives its lower costs from three characteristics. Firstly, it uses a relatively low data rate (1 Mbps), so that slower, said therefore cheaper, electronic circuits can be used. Secondly, it is designed to use, as the "transmission medium, existing spare telephone cables i n a building, eliminating additional costs of Touting new cable. Telephone companies typically put more telephone "wiring i n a building than is initially required see [6] see [5]  2  3  Chapter 1.  Introduction  15  because it is cheaper and easier to tap spare telephone wires than to route new cable through the building when more telephone lines are needed. an international standard with wide, multi-vendor support.  Finally, S t a r L A N is  Users can select S t a r L A N  products from many manufacturers instead of being 'captive' customers, which usually happens with communication protocols developed by a single vendor (because they are not compatible with those of other vendors).  1.2.1  S t a r L A N in the Framework  of the O S I M o d e l and Other I E E E  802  Protocols. A complicated series of operations is usually required when data are sent between computers.  These operations comprise two basic sections: coding and routing. The coding  section is concerned with how data from the source computer is presented or 'shown' to the destination computer.  Source and destination computer systems may use different  internal character collating sequences (e.g., A S C I I and E B C D I C ) , in which case text messages will have to be translated so as to have the same appearance in the destination computer. Data containing confidential material may have to be encrypted for the purpose of privacy. T h e routing section is responsible for sending the coded data reliably and efficiently from source to destination.  Error detection and/or correction codes are  usually appended for use by the destination system to check for integrity of the message received. In a complicated network, the source data must be sent through intermediate points before reaching its final destination. Efficient and robust routing algorithms are required i n such cases to select the (sub-)optimal path through the available intermediate points. The physical media for data communications are diverse and include, to mention a few, coaxial or fibre-optic cable, point-to-point radio-frequency Hnks, and microwave satellite channels.  Protocols, or sets of rules, are agreed upon between the sender and  receiver for all aspects of data transfer such as the operations described above, as well as  Chapter 1.  Introduction  16  for initiating and terminating transfers and recovering from situations where some part of a message is either lost or received with error(s). T h e operations involved i n moving data from one point to another are components in a communication system which help to implement its only goal: to send data reliably from the source to its destination. T h e sheer complexity involved in sending computer data (of which only the essential details were outlined above) requires a 'structured' scheme for all data-transfer operations. Several computer corporations, as well as national and international organizations have developed schemes, or 'architectures', for organizing these data-transfer operations. Of these, two will be discussed briefly as they are very closely related to S t a r L A N . T h e first is the 0S1 (Open System Interconnection) 7-Layer Reference Model specified by the International Standards Organization (ISO) and the second comprise the I E E E protocols, which are being developed by the I E E E 802 Standards Committee of the Institute of Electrical and Electronics Engineers ( I E E E ) in the United States.  T h e O S I Reference M o d e l OSI is a complete architecture for data communication. It is defined by a hierarchy of seven operational 'layers', each of which has its own set of functions, independent of the other layers.  O S I does not specify the protocols for these layers, it only outlines the  duties and responsibilities for those protocols. Figure 1.6 shows a schematic diagram of the seven layers. T h e application layer contains application-specific programs for the data communication requirement at hand. T h e presentation layer is responsible for functions such as character code conversion, text compression, and data encryption. The session layer sets up and maintains connections between applications. It is responsible for user authentication and for re-establishing interrupted or lost connections.  The transport  layer makes data transfer between applications as independent of the underlying network  Chapter 1.  Introduction  APPLICATION  17  DESTINATION \  SDURCE /  \  \  \/  / \ \ / PRESENTATION  PRESENTATION 7K  ,  APPLICATION  / \  ^ SESSION  Layer  Interface  \ / SESSIDN / \ \ / TRANSPORT  TRANSPORT  / \ NETWORK  \ / . NETWORK  / \  / \  . . .  NETWORK 7\  NETWORK /  \  \ /  DATA LINK "7J\~ PHYSICAL  DATA /  \ /  LINK  DATA  \  /  \ /  \  PHYSICAL  LINK \  PHYSICAL  I n t e r n a l N e t w o r k (if any)  Figure 1.6: OSI 7-Layer Reference Model.  \ / DATA LINK / \ \ / PHYSICAL  Chapter 1.  Introduction  18  as possible. These four highest layers cover 'end-to-end' protocols because they concern source and destination applications only and are independent of the network used to physically connect them. T h e lowest three layers specify network access protocols, whose functions concern only the network, independent of the particular application involved on the higher layers. The network layer provides services for setting up and maintaining the flow of messages in a network.  It is responsible for directing message packets towards their destinations.  Since source and destination users may not be connected by a direct physical link, the network layer is also responsible for routing and switching data messages through any intermediate junction in a network. The data link layer is responsible for message frame synchronization as well as error detection and correction. It is responsible for retransmission of message frames received i n error. In general, it provides an apparently error-free connection between a transmitter and receiver.  The physical layer specifies electrical  and mechanical parameters for a direct physical link. These include the type of medium used (such as coaxial or fibre-optic cable), the signalling method (modulation technique, amplitude and period of electrical signals, etc.), as well as the connection scheme (e.g., number of connector pins, types of connectors or plugs). It is concerned with transmitting and receiving bit streams of message frames sent by the data link layer. A communication network may not require all of the layers. Local area networks for example, typically do not use the transport, session, and presentation layers. Each layer must be 'open' to adjacent layers, that is, a protocol implemented at any one layer should be able to interface to any protocol of the adjacent layers. This means that a protocol at a layer should not have to know the implementation details of the other layers. If the implementation of one layer has to be changed for any reason, only the interfaces connecting that layer to adjacent layers will have to be changed, while protocols for the other layers remain unchanged.  The OSI reference model provides an architecture for  Chapter  1.  Introduction  ISD  19  IEEE  APPLICATION PRESENTATION ;ESSIDN  HIGHERLEVEL PROTOCOLS  TRANSPORT NETVDRK DATA  LINK  PHYSICAL  LOGICAL LINK CONTROL MEDIUM ACCESS PHYSICAL  Note slight functional overlap between layers.  Figure 1.7: I E E E Local Area Network Architecture. easing the task of developing and, just as important, maintaining a data communication S3 stem. r  T h e I E E E 802 Protocols The I E E E , through its 802 Standards Committee, has developed protocols for local area networks.  These protocols are designed to resolve incompatibilities that could exist in  L A N equipment supplied by different vendors. They do not conform exactly to the OSI model but are based on a closely related architecture shown i n figure 1.7. As can be seen, the differences involve primarily the network access protocols. T h e I E E E model essentially splits the OSI data link layer into two sublayers, one responsible for logical link control ( L L C ) , the other for medium access control ( M A C ) . The M A C layer implements the access method used in the network, which may be C S M A / C D , token ring, or token bus (to be discussed later). The L L C layer provides the remaining  Chapter 1.  Introduction  20  IEEE  ISO  HIGHER PROTOCOLS LDGICAL LINK CONTROL MEDIUM ACCESS  HIGHER LAYERS  I E E E 802.1  802.2  802.3  802.4  DATA LINK 802.5  802.6  PHYSICAL  PHYSICAL  includes S t a r L A N Figure 1.8: I E E E 802 Protocols data link services, independent of the medium access technique used. I E E E 802 protocols conform to this modified architecture.  They are enumerated below and a diagram  showing where these protocols He i n the I E E E local network reference model is given in figure 1.8. I E E E Standard 802.1 Describes the relationship between other 802 protocols and their relationship to the OSI reference model. I E E E Standard 802.2 Common logical link control. I E E E Standard 802.3 Group of protocols that use the C S M A / C D access method. I E E E Standard 802.4 token-passing access method, bus topology. I E E E Standard 802.5 token-passing access method, ring topology.  Chapter 1.  Introduction  21  I E E E Standard 802.6 metropolitan area network. S t a r L A N is a subset of the 802.3 group. It defines the implementation for a local area network at the physical and M A C layers. As such, it defines parameters for physical connections and the access method which, in the case for 802.3 protocols, is C S M A / C D .  1.2.2  Basic Operational Description  of S t a r L A N  S t a r L A N , as the name suggests, has a star topology as shown i n figure 1.9. The simplest form of the star topologj is analogous to a bicycle wheel with a hub at the center, from r  which spokes radiate outwards. Message frames transmitted by connected nodes are sent to 'hubs' which i n turn relay them to higher-level hubs i n the network. Of course, there are a finite number of hub levels. T h e single hub at the highest level, at which there is no further connection to a topologically 'higher' level, is called the header hub. A l l other hubs are called intermediate hubs. W h e n a message reaches the header hub, it is sent back down by that hub to be propagated to the rest of the network by lower-level hubs. There are essentially two other network topologies for interconnecting nodes in a network. These are the bus and ring topologies, shown in figure 1.10. T w o I E E E standards, 802.4 and 802.5, use bus and ring connection schemes respectively. Ethernet, another I E E E 802.3 protocol, also uses the bus topology. This is one significant difference between Ethernet and S t a r L A N . S t a r L A N does not specify which transmission medium should be used to connect hubs and nodes in the network. It only requires any node-node or hub-node link to have a maximum propagation delay of 4 bit times and no more than 6.5 d B attenuation in the signal frequency spectrum between 500 k H z and 1 M H z . There is no limit to the number of connections at each hub layer but a maximum of only five hub layers are allowed in the network. D a t a bits are transmitted at a rate of 1 M b p s using Manchester encoding  4 < HUB  LAYER  3  signal l o o p e d b a c k  lower <  layers,  Header  (at  •S  to  n  Hub (HHUB)  highest  >1  layer)  o  c n  o' HUB  LAYER  2  J  on  <  Intermediate (IHUB)  6  C!  'UPSTREAM'I/D  5? HUB  LAYER  <  node  1  v  Data Data  Hub  l  A d j a c e n t numbers indicate t h e event sequence o f d a t a p r o p a g a t i o n f r o m s o u r c e n o d e A.  d i r e c t i o n t o w a r d s HHUB => u p s t r e a m d i r e c t i o n . d i r e c t i o n a w a y f r o m HHUB = > d o w n s t r e a m d i r e c t i o n .  N o t e : s e p e r a t e u p s t r e a m and d o w n s t r e a m l i n k s a r e shown a s s i n g l e lines c o n n e c t i n g h u b s t o nodes or o t h e r hubs. to to  Chapter 1.  23  Introduction  Figure 1.10: Bus and R i n g Topologies  Chapter 1.  24  Introduction  BIT  DATA 1  DATA  mid-cell transition t  0  MAN. CODE  VoUcf M a n c h e s t e r d a t o atwoys hove rttd-ceU t r a n s i t i o n s .  RS-422  >t 1 m i c r o s e c . (= 1 b i t t i n e ) Figure 1.11: Manchester Encoding and RS-422 Voltage Levels. and RS-422 voltage levels as shown i n figure 1.11. Since no signal multiplexing scheme is used, only one channel is available for all users connected to the network.  It has to be shared and this means that only one user or  node can be in the process of transmitting a message frame at any given time. T w o or more simultaneous transmissions will result i n a 'collision' where the messages involved become superimposed and consequently garbled. In S t a r L A N (and Ethernet as well), all nodes employ an access method called C S M A / C D (Carrier Sense Multiple Access with Collision Detection) when sending message frames. This method is described below. W h e n a node has a message to send, it first checks its receive line to make sure that no other node is transmitting. If no one else is using the network, the node begins transmission. Otherwise, it waits for the other node to complete transmission first. That was the 'carrier sense' part of the access method. follows.  The 'collision detection' part* now  Because there is a finite propagation delay (due to hub processing and cable  transmission delays) for a signal from one node to reach all the others, the remaining  Chapter 1.  Introduction  25  nodes i n the network will, for a brief interval, not know that a transmission has already started.  If one or more of those nodes begin transmission on the erroneous assumption  that no one else is transmitting, then a collision will occur. W h e n a transmitting node detects a collision (by monitoring the signal on its receive line), it halts its current transmission and sends a brief j a m pattern to enforce the collision (i.e., increase the level of collision) so as to ensure its detection by other nodes involved with the colliding transmissions.  After the j a m pattern has been transmitted, each node 'backs off' by  ceasing transmission for a random length of time before retransmitting the entire message. This reduces the probability of having two or more nodes with the same back-off period, which will result in another collision when those nodes begin retransmission. W h e n the backoff period expires, the node then waits until the channel is free before retransmitting its message frame.  A collision can occur again during any retransmission attempt. If  that happens, the backoff process described earlier is repeated again. C S M A / C D belongs to a class of access methods which rely on channel contention or 'channel grabbing' to send messages. Another way for accessing a common channel avoids contention altogether by providing a transmission sequence for users connected to the network.  This technique, called token passing, involves the passing of a 'token'  (a special message frame giving the node receiving it the sole right to transmit) around the network (see figure 1.12). A node possessing the token uses the network during its allocated time for any messages to be transmitted. W h e n its time is up, the node passes the token onto the next node in the ring. In that way, only one node transmits at a time, avoiding collisions. As mentioned before, this is the access method used in two related I E E E protocols, 802.4 and 802.5. A S t a r L A N message frame is composed of several fields as shown i n figure 1.13. Message transmission always starts with the preamble which is used for synchronization. The end of the preamble is marked by a start-of-frame  delimiter ( S F D ) . Source and  Chapter 1.  Introduction  TDKEN  BUS  Figure 1.12: Token-passing Access Method.  NUMBER DF BYTES  7  1  6  6  2  PREAMBLE  SFD  DA  SA  LEN  PREAMBLED SFD  =  DA  =  SA  =  SERIES  S t a r t  of  Destination Frane  DF  MAX = 1500 MIN = 4 6 INFORMATION  10101010....  Fr-one  Delimiter:  10101011  A d d r e s s  A d d r e s s  FCS  =  F r o n e  LEN  -  Length  Check of  Sequence  Information  Field  Figure 1.13: S t a r L A N framing format  4 res  Chapter 1.  Introduction  27  destination address fields then follow the S F D . These identify the node from which the message originated and the node to which the message is intended respectively. A l l nodes check the destination address field of an incoming frame to determine whether or not they should receive the remainder of the frame, which consists of the information field followed by the frame check sequence ( F C S ) . The information field contains data used for the particular communication application while the F C S is a cyclic redundancy check ( C R C ) code which is calculated by an algorithm that uses the bits of the address and information fields. W h e n a node receives a frame, the C R C is recalculated and compared with the F C S , which was calculated when the message was originally transmitted.  If  the two do not match, then an error exists in the frame (which may have been caused by, among others, noise in the tranmission medium).  Not all errors can be detected  by a C R C . T h e effectiveness of a C R C (and F C S ) depends on the algorithm as well as the amount and distribution of bit errors in a message. 100% error detection cannot be guaranteed for all circumstances by any C R C algorithm. S t a r L A N specifies a m i n i m u m interframe spacing (LFS) of 96 bit times (96  fisec).  This is the m i n i m u m time between adjacent frames sent in the network. Its purpose is to give processors in receiving nodes enough time to 'recover' between receptions of backto-back frames. Received frames are usually not processed immediately on reception, but are temporarily stored in buffers. The interframe spacing gives receivers some time to do short tasks after receiving a frame such as switching receive buffers so that each received frame is stored i n its own buffer area.  A node waiting for another one to complete  transmission has to wait an additional IFS period before transmitting, to ensure that all frames are spaced apart by at least this m i n i m u m separation time. W h e n a S t a r L A N node detects the absence of carrier (when no other node is transmitting), it waits for an additional IFS period, after which it transmits regardless of whether or not the channel has become busy (by another transmitting node) after that period.  Chapter 1. Introduction  A  _  ^  1 JT^.  28  A  begins _ t r o n s n i s s i o n  IB A f t e r A's But j u s t A's  '///A <J  The  g a r b l e d  including an  A,  jan  which  u n s u c c e s s f u l  p a t t e r n should  eventually realize  transmission)  r e a c h e s  t h a t  has  a  a  signol  B  began b e f o r e  while  (propagation  r e a c h e s "to  ^oinui  E,  transmit  receiving  signal.  all  collision  nodes, (and  hence,  o c c u r r e d .  Figure 1.14: Worst-Case Scenario for Collision Detection. S t a r L A N specifies several parameters related to collision detection and recover}*. M i n imum j a m time (set at 32 bit times), is the m i n i m u m length of time that a node transmits a j a m pattern when a collision is detected. Slot time (set at 512 bit times), determines the backoff times when a collision occurs as well as the m i n i m u m message frame length. The slot time is computed as the j a m time plus the longest time taken for a signal to reach the farthest node and return back (the 'round-trip' propagation delay). It is the worst-case time for a collision to be detected. is arrived at.  Figure 1.14 shows how this conclusion  A node must still be i n the process of transmitting a message to detect  a collision. If it completes its transmission without detecting a collision and a collision actually occurred, the frame is not retransmitted and is lost. For this reason, message  Chapter 1.  Introduction  29  frames sent in a C S M A / C D environment must be longer than the slot time. A colliding node backs off an integral number of slot times so as to avoid overlapping into any collision interval that might occur with nodes retransmitting (and still colliding) at an earlier time. This number is determined i n S t a r L A N by what is called a 'truncated binary exponential backoff' algorithm. The number of slot times to back off after the kth retransmission attempt (of the same frame) is randomly selected from the range of [0, 2"), where n is the smaller of k and 10. Hence, the range of slot times from which a colliding node randomly selects its backoff time is doubled each time a backoff period fails to resolve the initial collision. This doubling stops after the 10th retransmission attempt to simplify the algorithm's implementation. Clearly, the probability of having a collision on retransmission decreases as the range for selecting the backoff period increases. S t a r L A N limits the number of retransmission attempts (stemming from the original collision) to 15.  In other words, a node has up to 16 chances to successfuDy transmit a frame. If  that limit is reached, the node ceases further retransmission and informs the higher layer protocol of the unsuccessful frame transmission, otherwise, it indicates that the frame was successfully transmitted. In a S t a r L A N network, collision detection is performed first by the hubs. When a hub senses that more than one of its 'downstream' input bnes is transmitting simultaneously it begins to transmit a collision presence signal ( C P S ) . This is nothing more than a bit stream with Manchester code violations (see figure 1.15). Other hubs higher up in the network will receive this signal and transmit their C P S upstream.  T h e header hub  then relays this signal back down the network so that all nodes receive the C P S and are thus informed that a collision has occurred. Collision enforcement and backoff is then performed by the nodes which transmitted the colliding frames. Hubs stop transmitting their C P S when transmission ceases on all of their downstream inputs. Hubs are also responsible for jabber inhibition— a hub should shut off its link to  er 1.  Introduction  E n s u r e s t w o missing m i d - c e l l t r a n s i t i o n s will o c c u r e v e r y 5 m i c r o s e c o n d s ( c y c l e time) f o r e i t h e r b i t c e l l r e f e r e n c e point.  Figure 1.15: Collision Presence Signal  Chapter 1.  Introduction  31  Figure 1.16: Infinite Loop in a S t a r L A N Network. any downstream input that transmits for an inordinately long time. This prevents long transmissions from tying up the network. Such a situation can occur if an upstream and downstream line are accidentally connected together.  W h e n that happens, the down-  stream signals will be coupled upstream and be transmitted through the network in an infinite loop (see figure 1.16). W h e n one of a hub's downstream inputs is transmitting much longer than it should, the hub responds by sending a C P S (forcing a collision backoff sequence) to get all nodes to cease transmission momentarily. If its offending input does not cease transmission, then that input is logicahy disconnected from the network  Chapter 1.  Introduction  (by simply being ignored by the hub).  32  A n inhibited input will be readmitted to the  network only when the hub receives a transmission from that input while no signal is being sent downstream from the higher hub layers—this will never occur if the upstream and downstream lines are short-circuited together as discussed previously. Figure 1.17 gives a schematic diagram of a 'typical' S t a r L A N network i n a hypothetical office. Users can up/download files and application programs from remote data bases and computer systems. Electronic mail can be sent between users while output devices such as printers can be shared. The wiring details for a sample office are shown i n figure 1.18. Note how the star topology blends neatly with the structure of the telephone wiring system. S t a r L A N was designed with this environment i n mind.  1.2.3  S t a r L A N and the F A S T B U S Serial Network  As mentioned earlier, S t a r L A N also seems to be a very promising candidate for implementing the F A S T B U S Serial Network. One more reason for why this is so is the star topology, which allows F A S T B U S crate segments to be easily connected to a S t a r L A N network. Figure 1.19 shows a schematic diagram of a StarLAN-based serial network on a hypothetical F A S T B U S system. Masters, Slaves, and Segment Interconnects attach to the serial network as S t a r L A N nodes.  The S E R I A L T X line is used by the nodes for  transmission while the R X line is used for reception.  A S t a r L A N hub, mounted on a  card, is plugged at a slot i n the back of each F A S T B U S crate segment. These hubs are connected to higher-level hubs as i n an orthodox S t a r L A N network. So, it can be seen that the serial network is just like an ordinary S t a r L A N network except for the lowest hub level (at each F A S T B U S crate), where the nodes and hubs' downlink portions are connected i n a bus topology, using different voltage levels ( E C L as opposed to RS-422 for orthodox S t a r L A N ) . Crate segments can be easily connected to or disconnected from the network by adding or removing their own link to the higher-level hubs.  Although  Chapter 1.  33  Introduction  modem  Mainframe  IX1XEIII3S BBXI!!!  microcomputers  File  StarLAN  Server  components Intermediate Hub (IHUB)  Header Hub (HHUB)  LAN  Bridge  Figure 1.17: S t a r L A N in an integrated office  M  a  s  s  Storage  er 1.  Introduction  i <<<  \  |&!Mjj]]!J]]j]j]J]l i t i i  / ~o a =0  D_ D B=  Telephone System Components Wiring C l o s e t  •  Telephone  Jack  Figure 1.18: S t a r L A N network using intra-building telephone cables  Figure 1.19: StarLAN-based serial network on F A S T B U S  Chapter 1.  Introduction  36  Figure 1.20: Bussed S t a r L A N network F A S T B U S segments can be connected in an arbitrary fashion, data paths during intersegment operations are determined by route tables which prevent crosspoints and loops from occurring (they do not occur in S t a r L A N because of jabber inhibition as well as the star connection topology). Hence, operations in the StarLAN-based serial network and inter-segment operations in a F A S T B U S system function with equivalent topologies.  1.2.4  Variations to Standard  StarLAN  S t a r L A N without Hubs Spurred by the drive to reduce network connection costs even further, some designers, principally at Advanced Micro Devices ( A M D ) , took the step of designing a variant of S t a r L A N which ehminated hubs entirely ([18], [19]). This variation, known as 'bussed' or 'hubless' S t a r L A N , eliminates hubs, the most expensive component in a standard S t a r L A N network. In this scheme, all nodes are connected together in a bus topology as shown in figure 1.20. Figure 1.21 shows two possible ways for connecting the nodes  Chapter  1.  37  Introduction  i  node  T" CDNNECTIDN  i  it  i  i  i  i i  node  DAISY  CHAIN  Figure 1.21: Node connection schemes for bussed S t a r L A N together. In the T connection, the cable (typically coaxial cable) is tapped by a connector which penetrates the insulation and outer shield to make contact with the inner conductor (which carries the signal). In the daisy-chain configuration, adjacent nodes are connected by pieces of cable. Each node splits the cable terminations into two, one for the node itself, the other for connection by another length of cable to the next node in the chain. As of this time, the daisy chain configuration seems to be the more feasible mode of connection. Two observations can be made immediately about a bussed S t a r L A N network.  First,  intra-building telephone cable can no longer be used because of the bus topologj-. This means that additional wiring has to be used, increasing network connection costs to some extent. Second, node connection and disconnection is now more complicated, especially for the daisy chain scheme favored by A M D . Furthermore, bussed S t a r L A N is not yet an official I E E E standard.  Detailed specifications are still being developed for approval  by the I E E E 802 Standards Committee. A t any rate, bussed S t a r L A N may have some useful features in the context of the F A S T B U S Serial Network. T w o possible connection  Chapter 1.  Introduction  38  schemes are shown i n figure 1.22. Figure 1.22a shows a completely bussed network while figure 1.22b shows a hybrid scheme using both standard and bussed S t a r L A N . Finally, it must be emphasized that, unlike the connection scheme illustrated in figure 1.19 (using standard S t a r L A N ) , the bus schemes have not yet been prototyped for feasibility studies and performance evaluation.  10 M b p s S t a r L A N In the latest twist to the S t a r L A N saga, a high-speed, 10 Mbps version of standard S t a r L A N is being developed [8]. This version was conceived in response to consumer demand for a local area network that was faster than S t a r L A N but could still use intrabuilding telephone cable. Apparently, many L A N users (or budding L A N users) prefer the data rate set by Ethernet at 10 Mbps and are unwilling to use a cheaper 1 Mbps L A N even though the lower data rate is perfectly suitable for their applications. The lOBaseT Study Group of the I E E E 802.3 Standards Committee is i n charge of the development for this new L A N standard and has discussed specifications to be adopted. The Electronic Industries Association ( E I A ) is expected to publish the maximum running length of unshielded twisted-pair wire for 10 Mbps S t a r L A N soon.  Chapter 1.  Introduction  Figure 1.22: Bussed S t a r L A N in the F A S T B U S Serial Network.  39  Chapter 2  Building the Prototype Serial Network  2.1  A Simple S t a r L A N Network  A t the start of the research (early 1987), S t a r L A N was still an emerging local area network ( L A N ) standard.  Nobody in the laboratory staff had any working knowledge of  S t a r L A N i n both hardware and software. Hence, two S t a r L A N design kits were procured from Intel to expedite the task of building a working network.  These kits contained  a total of four printed circuit boards designed to plug into I B M P C expansion slots. T h e kits also included some components (such as the Intel 82588 L A N controher chip), software for driving the boards, as well as documentation that proved to be helpful for newcomers to S t a r L A N ([9], [7], [10]). Other parts, including wiring and a S t a r L A N hub, were obtained separately.  A P A L (Programmable Array of Logic gates) chip was also  required for each board. This chip's programming instructions were given in the Abel P A L programming language. However, only one P A L 'compiler', called P A L A S M 2 (from Monolithic Memories), was available at the laboratory. Hence, the programming instructions had to be translated to P A L A S M 2 code before the chips could be programmed. A short simulation program was' also written to verify the translated code. A listing of the programming code and simulation results is given i n appendix A . l . Experience i n electronics hardware development had shown, time and time again, that hardware bugs could be very difficult to solve (much more so than software bugs). Hence, a very cautious approach was taken which, though somewhat tedious, greatly reduced  40  Chapter 2.  Building  the Prototype  Serial  Network  41  the chances of unpleasant surprises and frustration when everything was soldered and plugged i n . T h e Intel circuit design was thoroughly checked so that the circuit's operation was understood in detail. The schematic was also cross-checked with the printed circuit layout.  A l l minor board components were tested before being soldered or plugged i n .  Intermediate  hardware tests were done at various stages of assembly.  Nothing (well,  almost nothing) was left to chance. A l l of these precautionary steps were also taken during the construction of other electronic circuits that followed.  The boards were carefully  assembled and then tested with three I B M X T compatible computers using the software supplied with the kits (see [9] for more details).  No problems, major or minor, were  encountered. A diagram of the network connections for the tests is shown in figure 2.23a. Three sets of twisted-pair telephone cable, each 25 feet long, were used to connect the Intel boards from their telephone jacks to the telephone jacks of a Retix H B - 6 S t a r L A N hub.  1  This hub could connect up to six nodes together. It could also be switched to  function as either an intermediate or a head hub. W i t h this rudimentary S t a r L A N network, message frames could be sent from one P C to another.  The Intel software allowed the user to load a message in hexadecimal  or A S C I I format and to set the message length. Another useful feature was a 'repeat transmit' mode which was used to continuously send messages. However, the transmission rate could not be altered.  S t a r L A N parameters,  such as source and destination  addresses, could also be set by the user. A 'transmission session' could be initiated by starting transmissions i n repeat-transmit entry.  mode and terminated at any time by keyboard  Statistics from transmission and reception of frames were updated in real time  on the terminal screen.  Detailed collision data (i.e., the distribution of the number of  retransmission attempts to resolve a collision) could be displayed at the end of a transmission session. To check the system for reliable operation, each P C was set to transmit see [11] for more details.  1  Chapter 2.  Building  the Prototype  Serial  42  Network  (a) o r t h o d o x S t a r L A N connection.  (b) s i n p l e F A S T B U S repeater,  RS-422  - ECL  interface  <  TX line s i g n a l s r e p e a t e d  RX  line  on  > <^>  BUBHEIIi  (c) S t a r L A N - F A S T B U S hub with o r t h o d o x connection t o higher S t a r L A N hub layer,  Figure 2.23: S t a r L A N Network  link f o r o p e r a t i n g FASTBUS hub a s an IHUB  Configurations  Chapter 2. Building  the Prototype  Serial Network  43  to another P C in a circular fashion. Three transmission sessions were done, one each for information field lengths of 48, 512, and 1500 bytes. T h e 48-byte length corresponds to the shortest field length that can be transmitted without producing a 'short frame' error in the program. Although the shortest field length allowed by S t a r L A N is 46 bytes, a small bug in the L A N controller chips restricted the shortest length to 48 bytes.  The  1500-byte length corresponds to the longest field length for S t a r L A N frames while a 512byte length was chosen to be the 'intermediate length' frame. A transmission session was started by programming each P C , one by one, to transmit repeatedly. After some time had elapsed, say 5 minutes, the P C transmissions were stopped in the same sequence as they were started.  The statistics displayed on each terminal were first checked for  unusually large transmit or receive errors. Only a few errors were observed, so they were assumed to be caused by random processes in the course of the transmission session. Next, the number of 'good' transmissions from each P C was compared to the number of 'good' receptions at the corresponding destination P C . The good receptions were either equal to the good transmissions or were slightly less by only a very small amount. These implied that the number of lost frames were miniscule i n comparison to the total number of transmissions that were reported as being 'good'. Hence, it was concluded from the tests that reliable communications were established in the network.  2.2  Using S t a r L A N in a F A S T B U S Environment  After the completion of this rudimentary S t a r L A N network, an interface system that would enable S t a r L A N signals to be routed through a F A S T B U S backplane was developed after verification tests on the basic S t a r L A N network were completed. system consisted of two major parts:  T h e interface  the first was a S t a r L A N - F A S T B U S transceiver  (essentially an R S - 4 2 2 - E C L signal translator; the F A S T B U S backplane uses E C L logic  Chapter 2.  Building  the Prototype  Serial  Network  44  whereas S t a r L A N uses RS-422 voltage levels) and the second was a S t a r L A N hub designed to work on the F A S T B U S backplane.  A Transceiver  Between S t a r L A N and F A S T B U S  A schematic diagram of the S t a r L A N - F A S T B U S transceiver is shown in figure 2.24. This circuit is a transceiver between standard S t a r L A N and the F A S T B U S backplane that provides a transparent interface between three-state RS-422 S t a r L A N signals and two-state E C L voltage levels. Figures 2.23b and 2.23c shows how The transceiver is used to connect the Intel S t a r L A N boards (constructed earlier) to a F A S T B U S backplane. Standard S t a r L A N signals are fed into the transceiver, converted to E C L voltage levels, and sent through a line in the backplane. Signals received from the corresponding backplane line are converted back to StarLAN-specification RS-422 signals and relayed to the S t a r L A N board. A not-too-small part of the transceiver's design was borrowed from a section of the Intel S t a r L A N boards.  The task of incorporating some of Intel's design was not too  difficult after some reverse-engineering was done on the board's schematic diagram. A T T L - t o - E C L translator chip was used to drive the backplane while an E C L - t o - T T L translator received the backplane signals.  Special E C L bus driver and receiver chips  were not used because other F A S T B U S circuits developed in the laboratory were known to work without the use of these chips. A description of how the transceiver works is given in appendix A . 2 . The transceiver is more than just a voltage level translator.  E C L logic has two  states: high (1) and low (0), and the low logic level is used for the quiescent state when nothing is being transmitted. O n the other hand, S t a r L A N RS-422 signalling for twistedpair telephone cable has three states: differential high (1) (when the voltage difference between the reference wire to its pair is positive), differential low (0) (when the difference  Chapter 2.  Building  the Prototype  Serial  Network  > fo  UJ :f\J cr O J  r  o —  -t r—•  -I 5  •  Figure 2.24: Schematic diagram of the S t a r L A N - F A S T B U S tranceiver.  Chapter 2.  Building  the Prototype  Serial  Network  46  is negative), and inactive (when the line is released to its quiescent state by shutting off the RS-422 driver's output). S t a r L A N transmissions begin with a differential low from the inactive state and voltage swings occur as defined by the Manchester-encoded bit stream, whose end is marked by a differential high lasting approximately two microseconds long, after which the line is released back to its inactive state.  Hence, it takes more than  just a simple voltage translation to map the three S t a r L A N RS-422 signal states to the corresponding E C L logic levels and vice versa. Four boards were made, one for each Intel S t a r L A N board. repeater was constructed as well.  A simple backplane  This repeater would simply relay the logic levels at  the transmit line (B57) to the receive line (B58). Thus, the backplane could be tested as a bus topology network without a hub. The repeater consisted of an E C L - t o - T T L translator which was cascaded to a T T L - t o - E C L translator.  The input of the first chip  was connected to the transmit line while the output of the second chip was connected to the receive line. Those particular chips were chosen simply because they happened to be immediately available (spare chips for the transceiver boards). The connection diagram for this simple bussed network is shown in figure 2.23b. Three X T compatible microcomputers were used, as was done before when the S t a r L A N boards themselves were tested. The transceiver boards and repeater were plugged into the rear section of an unused F A S T B U S crate. Three sets of 25-foot telephone cable were used to connect the telephone jacks of the transceivers to similar jacks on the S t a r L A N boards. Again, the tests of the simple S t a r L A N network were repeated in this network. No anomalies were observed and, as with the previous network, it was concluded that reliable communications were achieved.  Chapter 2.  Building  the Prototype  Serial  Network  47  A S t a r L A N H u b for the F A S T B U S Backplane The development of the S t a r L A N - F A S T B U S hub (or 'crate hub') was complicated because it was not at all certain that one could obtain, in a reasonable time, an integrated circuit which would implement the functions of a S t a r L A N hub. This chip, the Western Digital W D 8 3 C 5 1 0 , was just about to be introduced to the market at that time 2  (May-June 1987). It was not possible to obtain this chip from local sources or even directly from Western Digital. No other semiconductor company was known to be closer to mass-production of a S t a r L A N hub I C than Western Digital. A n attempt was made to obtain this chip indirectly through an associate at the University of Illinois Center for Supercomputing. Nevertheless, the possibility of obtaining even one sample chip was not assured.  So, in the mean time, a crate hub that did not use the W D 8 3 C 5 1 0 was  designed. In general, standard S t a r L A N hubs cannot be coupled directly to a bussed line. This is because a collision in S t a r L A N is defined as the condition where more than one node is transmitting at the same time. Since collision detection is a function of the hub and only one node is assumed to be connected to each 'downstream' input channel, a hub would only have to watch out for simultaneous transmissions from any of its 'downstream' channels in order to detect collisions. In the case of a F A S T B U S backplane, the transmit line can be connected to several nodes. If the signals on this line were simply connected to a standard S t a r L A N hub by, say, the transceiver circuit described previously, the S t a r L A N hub would 'see' only one channel and erroneously assume that only one node was connected to that channel even though that would not generally be the case. It is possible that a collision involving any of the nodes in a F A S T B U S backplane could slip through without being detected by the hub. That of course depends on the particular 'details given in [12]  Chapter 2.  Building  hub's design.  the Prototype  Serial  Network  48  The only way to 'rigorously' catch these bus collisions as well as any  anomalous signals i n the backplane is to detect them by a separate circuit that watches for missing mid-cell transitions and pulses of improper width.  T h e output of such a  circuit could then be connected to another hub input. It would transmit an arbitrary S t a r L A N signal to that input upon detecting a collision.  The hub would then sense  at least two inputs transmitting simultaneously (one from the backplane line, the other from the auxiUiary collision detection circuit) and flag the collision. This scheme would require two hub inputs per F A S T B U S crate, a somewhat clumsy, but nevertheless feasible idea. Later on, it became clear that a rigorous collision detection function was a major design component of a crate hub anyway and the decision was made to design a complete self-contained crate hub for the F A S T B U S backplane rather than implement the separate collision detector - external hub scheme as described above. The effort required to go all the way and design a crate hub was justified by the hub's elegance. T h e crate hub would be connected to all the nodes of the crate in a bus topology and itself would connect with a higher-layer hub as part of a star topology network. The first version of the hub (that did not use a S t a r L A N hub chip) was a fully synchronous digital circuit whose block diagram is shown in figures 2.25, 2.26, and 2.27. A n initial attempt was made to design the entire circuit heuristically, but it soon proved to be not only an awkward but ultimately, an impossible method given the complexity involved. So, the circuit was designed with a combination of formal and heuristic digital design techniques. complicated.  One technique would be used when the other seemed to be more  This circuit never got past the design phase because a prototype sample  of the W D 8 3 C 5 1 0 arrived, thanks to the efforts of Bob Downing from the University of Illinois.  The hub controller chip probably saved at least a month of work to get a  functioning hub, even though this meant starting over to design a new circuit based on the W D 8 3 C 5 1 0 . Figure 2.28 shows a schematic diagram of the resulting circuit, showing  Chapter 2.  Building  the Prototype  Serial  Network  49  a dramatic simplification of this implementation over the design that did not use the a hub chip. This was due, i n part, to the design of the W D 8 3 C 5 1 0 itself, which 'rigorously' detected collisions in each of its inputs, ehminating the need for a robust external collision detector (the 83C510 will flag a collision if an input receives pulses of improper widths or with missing mid-cell transitions, as well as if more than one input is receiving data). Another chip used in the circuit that is worth mentioning here is the SN75061 from Texas Instruments.  This chip is a T T L - R S - 4 2 2 transceiver designed especially for S t a r L A N  applications. It provides the functions that would have previously required two separate chips (e.g., Am26LS30 and Am26LS32, which were used by the transceiver circuit when the T I chip was not yet obtained). Appendix A . 3 explains how the hub circuit works. T h e circuit was built (very carefully, since only one W D 8 3 C 5 1 0 was available and it was unlikely that another one could be quickly obtained) and tested. a diagram of the system used to test the circuit.  Figure 2.23c shows  As was done during previous tests,  three X T compatibles with Intel S t a r L A N boards were used. Twenty-five-foot lengths of telephone cable coupled the S t a r L A N boards to their corresponding S t a r L A N - F A S T B U S tranceivers, which were plugged at the back of a F A S T B U S crate. The hub circuit was also plugged into the back of the F A S T B U S crate to connect its 'downstream' channel to the transceivers.  Its 'upstream' channel was connected to the Retix H B - 6 S t a r L A N  hub. This system allowed one to test the hub circuit for proper operation either as an intermediate or a header hub (by leaving the 'upstream' link connected or disconnecting it respectively). It also allowed the hub-detection logic of the W D 8 3 C 5 1 0 to be tested. Briefly, the hub-detection logic is used by the W D 8 3 C 5 1 0 to sense if it is connected to a hub at a higher level i n a S t a r L A N network. The hub-detection logic works as follows. Suppose the chip is functioning as an intermediate hub. If, after a short waiting period, no signal is received from its upstream channel, it assumes that it is not connected to a higher hub level and automatically proceeds to function as a header hub (if there was a higher  Chapter 2.  Building  the Prototype  Serial Network  50  V A  o  CL  LJ  3  •  a t—t  2 U —!i i—i 2 PQ  o  a  CJ  h-  C/) 1 CL u U  <n :z a  U  A A  A  A  •  _l CJ  \  O •  CJ  o  _j u  N X  a  CJ  a _i  o o  u  CJ  LJ CJ  •_ l  CJ C£  ZD  • o C/)  i—i  a: LJ  A  • _i  LJ  >\3Vr 3NDHd Figure 2.25: Block Diagram of H u b Circuit: I / O Section  Chapter 2. Building the Prototype Serial Network  51 a ^/  LJ LD O LJ L_  Q ->-  o o •  A  o  a o Ld ^ 0 0 U  u  hU 00 LJ C£  ->-  Q  ZD  •  _\  A  a:  LJ  • =5  ^  L J L_  b l LJ ~ ZD  o  i a  a  L_  A  A  A  A  u  A  ->-  cn  J A  . LJ _ l _J _ l Q£  A  CJ LJ LJ CD I— Q LJ  <C UJ (_) 0 0  LJ \  —  7\ oo  a  LJ  A  a i— u u  u a o  a t—  A  00  A 00  LJ CQ CQ <E ~)  3 •  «/\  V  LJ I— <X hO0  i—i X CJ <E 21  ->-  L J Q,  I £ d  id  A  en  CP L J 00  X  A  ->-  a.  or  A  00  a 5-9=  a g 3 CJ  • _J  I  M  00 CJ  o LJ U  o  CJ  'So  A 00 I—  \  m  CJ 00 Q_ CJ  o _i u \  A  Aa  CJ  _i  zM o o  <3-  A =3 a;  A  LJ Qi U  Figure 2.26: Block Diagram of Hub Circuit: Downstream Section  Chapter 2. Building the Prototype Serial Network  52  ^0 \ ZD  u n _i u \  o a _i u  o a _i u  Figure 2.27: Block Diagram of Hub Circuit: Upstream Section  Chapter 2.  Building the Prototype Serial Network  9 § a s p p p p  =17  lis 5_ 55 Son  l§  3 S S|^  S11111$  si  5*, <r » S  8  AlAlA  3  Figure 2.28: Schematic Diagram of H u b Circuit with W D 8 3 C 5 1 0 Controller  Chapter 2. Building the Prototype Serial Network  54  hub level, the higher hub would have either repeated the lower hub's transmission or, in the event of a collision, sent a collision presence signal ( C P S ) ). W h e n the chip operates as a header hub, all downstream signals are immediately looped back. Now suppose that signals are received on the upstream channel of the hub chip in header hub mode. The hub-detection logic assumes that these signals must have come from a higher-level hub and the hub chip switches its operation from a header hub to an intermediate hub. A frame will be lost i f it is transmitted  during an intermediate-to-header  hub transition  because the hub chip will loop back only the remainder of the frame downstream when it switches to a header hub. This usually results i n a C R C error. T w o or more frames may be involved i n a colhsion during a header-to-intermediate  hub transition if a frame  is received on the upstream channel while the hub is looping back a downstream frame. As before, the Intel program was used to drive the system and collect performance statistics.  Fortunately, everything worked perfectly right away without any problems.  T h e on-chip hub-detection logic was tested by alternately connecting and disconnecting the link to the Retix S t a r L A N hub. without causing a major disruption.  The hub chip was observed to switch properly The tests showed that data could be transferred  reliably when the circuit was operating i n either intermediate or header-hub mode. For the first time, data communications were successfully established i n a prototype of the envisioned two-line StarLAN-based serial network.  Chapter 3  Measurements  3.1  Electrical  Characteristics of S t a r L A N Signals in the F A S T B U S  Back-  plane S t a r L A N describes a protocol for data communications at the media access control ( M A C ) sublayer and the physical layer. The M A C sublayer specifications are fixed but the physical layer has some flexibility. In particular, S t a r L A N does not specify the medium of propagation for data transmission between a node and a hub (or between two hubs). It only requires the propagation delay of a node-hub/hub-hub link to be no greater than 4 bit times and that the signal (pulse) jitter should not exceed 62.5 ns per link (pulse jitter is defined as the amount of time by which a pulse edge deviates from when it is expected to occur). Furthermore, up to five hub levels are allowed, with no restriction on the number of nodes per hub level. In an ordinary S t a r L A N network, RS-422 signals are sent through unused intrabuilding twisted-pair telephone lines in a star topology. O n the other hand, E C L signals must be used to transmit data on the serial lines in the F A S T B U S backplane, which connect the nodes within the crate in a bus topology. In departing from standard StarL A N , it is important to stay within any specified timing parameters at the physical layer so that reliable performance will not be compromised. To this end, measurements were taken to compare parameters and characteristics of the StarLAN-based serial network to those required i n an orthodox S t a r L A N network. Measurements of propagation delay and  55  Chapter 3. Measurements  56  pulse jitter were made for different capacitive loading configurations in the backplane. E C L signals have very small voltage swings (of the order of I V difference between logic states) and short transition times (typically, Ins). Because of these characteristics, they are used in high-speed applications but are more difficult to work with than slower logic signals such as those from C M O S or T T L . In general, electrical connections for E C L signals have to be treated as transmission lines because the propagation delays of such connections are often much longer than E C L transition times. To keep this thesis from getting any longer than it already is, a detailed discussion of E C L characteristics and transmission lines will not be given here. Instead, the reader is referred to journal articles and books listed in the bibliography ([13], [14], [15], [16], [17]). Nevertheless, in order to relate the effect of capacitive load in the backplane to electrical parameters such as propagation delay and pulse jitter, it is necessary to introduce some of the results from transmission line theory. T w o transmission line parameters of interest are the propagation delay and the characteristic impedance of the line. For an unloaded line, the propagation delay, tpd, and the characteristic impedance, Z , are constants at high frequencies (relevant to fast signals 0  like E C L , which have significant high-frequency components) and are given as follows.  tpd — V LC  (sec./m.)  Z - y/L/C .  {ohms)  0  L and C are the inductance and capacitance per unit length respectively. For a loaded backplane bus, the corresponding parameters,  and Z i, 0  relations.  {sec./m.) Z  0  {ohms)  are given by the following  Chapter 3. Measurements  Cl  is the additional load capacitance (from attached devices) per unit length.  57  It  can be seen from the equations above that the effect of added capacitance is to increase the propagation delay and to reduce the characteristic impedance of the line. Since the characteristic impedance changes with the backplane load, it is not possible to terminate a backplane line with a perfect impedance match for all loading conditions. W h e n an impedance mismatch exists at any point in the line, the incident signal is reflected back, the extent of which depends on the amount of mismatch. Small amounts of reflections can influence the characteristics of signal transitions and hence, contribute to pulse jitter. If reflections become large enough, it may even be impossible to transmit reliably at all. It is because of the reasons given above that one has to consider the effect of loading conditions on the characteristics of a backplane. Capacitors were used to approximate the loading effects of E C L devices connected to the backplane lines. The maximum signal line capacitive load for a F A S T B U S device is 12 p F . Since F A S T B U S cards can be plugged into both the front and back of a F A S T B U S crate, the maximum load per slot position is 24 p F . As a first attempt, the backplane's serial lines were loaded with 33 p F capacitors per slot position to simulate an overloaded backplane. A diagram of one capacitive load is shown in figure 3.29 (which shows a 15 p F capacitor, the load that was used later on). Twenty-six of these capacitor loads were made, one for each slot position in the F A S T B U S crate. The leads of the capacitors were terminated with gold-coated A M P 87000 series contacts which were crimped on by an A M P crimp tool (model number 90340-1). T w o termination cards were built, one for each end of the backplane. Each card consisted of a F A S T B U S card edge connector and a 20-turn trimmer resistor, both of which were mounted on a piece of phenolic plugboard. The trimmer resistors were adjusted to 56 ± 0.1 ohms. A P C was connected to a transceiver and was set to transmit continuously to generate  Chapter 3. Measurements  FASTBUS  15 p F  square  capacitors  56-ohm termination resistor  B57  B58 JLJL 15 p F load capacitor  Figure 3.29: Sample capacitor load for the F A S T B U S  backplane.  Chapter 3. Measurements  59  S t a r L A N signals i n the backplane. Waveforms of the signals were observed by attaching an oscilloscope probe to a short stub that could be inserted into slot pins at the backplane. The oscilloscope system was based on a Tektronix 7904 mainframe which used a 7B92A dual time base and two 7A18 amplifiers, which had a bandwidth of 75 M H z . Standard 10 M o h m 13pF oscilloscope probes were used. There was some concern as to whether or not the system would be capable of tracking the fast E C L signal swings. However, the oscilloscope was observed to adequately track l V / n s square waves (simulating E C L pulses) from a signal generator. Hence, the existing setup was used. Observations showed that there was an enormous amount of reflection when E C L signals were sent through the serial line. These reflections were causing oscillations in the E C L signals, resulting in spurious state transitions. A less 'stressful', but more realistic capacitive load was then evaluated instead. A new set of 26 15pF metal film capacitor loads were made (see figure 3.29). Each capacitor was checked to be within ± 1 0 % of 15 p F with a capacitance meter.  Two-line  capacitor loads were made although only one line had to be loaded for the measurements because these loads would be required for communication tests later on. A board with an E C L - t o - T T L translator was also built to convert E C L signals at the receiver end to T T L . Signals were measured at the input to the T T L - E C L translator at the transmitter (signal source) and at the E C L - T T L translator output at the receiver.  These  measurement  points were chosen because they were buffered from the backplane and, as a result, showed cleaner transitions, leading to more consistent measurements.  Figure 3.30 shows  the reference transition points for the signal source and the receiver. Clearly, it was impractical to consider all possible backplane loading configurations. Hence, only a 'canonical' subset was selected for the measurements of propagation delay and pulse jitter. Diagrams of these test configurations are shown in figures 3.31 and 3.32. Capacitor loads were placed in each slot position at the loaded sections.  Measurements  60  Chapter 3. Measurements  _4.5V_  74HCT00:  2.35V 0.2V  HIGH reference logic l e v e l  points f o r transitions  LDW  Figure 3.30: Reference points for edge transitions.  Chapter 3. Measurements  61  of pulse jitter and propagation delay were made for each configuration and are tabulated in appendix B . The amount of pulse jitter was obtained by taking the absolute value of the difference i n propagation delay between the rising and falling edge of the source pulse to the corresponding pulse edges that were triggered at the receiver. Photographs of oscilloscope traces were taken. They are also shown in appendix B . Each photograph shows three traces, one on the top half, and two on the bottom. T h e top trace shows the E C L signal as seen at the receiver. T h e bottom traces show two T T L edge transitions. The first edge corresponds to the source at the input to the T T L - E C L translator.  The  second edge that occurs afterwards is from the receiver at the output of the E C L - T T L translator. Most of the traces appeared to be well-behaved, as a sample in figure 3.33 shows. However, there was one exception (as shown in figure 3.34) where there is a bumpy transition in the output of the E C L - T T L translator (bottom trace).  This is a little  strange because the E C L signal on the top trace is not oscillating and thus, should not trigger the gbtch at the translator output.  A t any rate, an L S T T L logic gate  was connected to the translator output in that configuration and was not observed to be affected by the glitch.  The largest amount of pulse jitter was measured to be 6 ns  and this occurred in the fully loaded backplane when the source and receiver were both near the midpoint of the line (reference number 18). The longest propagation delay was measured to be 16.2 nsec. and this occurred, as expected, when the source and receiver were placed at opposite ends of a fully loaded backplane (reference number 21). These measured values for the worst-case pulse jitter and propagation delay are well within the S t a r L A N limits of 62.5 ns and 4 microseconds respectively.  Chapter 3. Measurements  LEGEND:  approximate .  approximate  position  signal  s o u r c e  (e.g.,  near  end  of  of  backplane  <e.g.,  near  position  midpoint  unloaded  ECL  (no  o f  o f  ECL  receiver  backplane  capacitors)  line)  section  line) loaded  REFERENCE NUMBER  /  (w/  capacitors)  section  REFERENCE NUMBER  A  12  unloaded end-to-end  half-loaded (at  y unloaded  y half-loaded loaded  unloaded  y  T  unloaded  end  loaded  y  15  end-to-midpoint  end  to  unloaded  A half-loaded  T y  end-end  midpoint  half-loaded  midpoint  unloaded  to  14  midpoint-midpoint  A  10  section)  13  midpoint-to-end  _3L  end-end  loaded  to  unloaded  end  16  half-loaded midpoint  to  loaded  Figure 3.31: Schematic diagram of electrical measurements.  end  f  end  Chapter 3. Measurements  REFERENCE NUMBER  REFERENCE NUMBER  17  half-loaded  fully-loaded  unloaded  nidpoint-to-end  end  unloaded  end  24  fully-loaded "nc'poin-t-ii;dpoin"t  half-loaded unloaded  end  t o  nidpoint  19 fully-loaded end-to-nidpoint  half-loaded unloaded  end  t o  loaded  end  20 fully-loaded end-end  fully-loaded end-to-end  Figure 3.32: Schematic diagram of electrical measurements (continued).  Chapter 3. Measurements  Figure 3.33: Typical oscilloscope traces (ref. 25).  64  Chapter 3. Measurements  65  Figure 3.34: Oscilloscope trace of bumpy edge transition (ref. 17). 3.2  Network Performance  Measurements  The fully loaded prototype serial network was expected to behave just like an orthodox S t a r L A N network after the pulse jitter and propagation delay were found to be very small. Nevertheless, there was still a lingering trace of doubt in that expectation because the nodes in the crate were connected in a bus topology whereas standard S t a r L A N nodes are connected in a star topology. Perhaps a difference in the connection topologies could lead to different network behaviour. Hence, tests were made to compare the performance characteristics of the serial network to that of standard S t a r L A N . The equipment setups for the performance measurements were identical to those used when the serial network was built and tested.  This time, however, the backplane was  fully loaded with 15 p F capacitive loads i n every slot position. T h e four configurations for these measurements are shown in figure 2.23. As was the case with the earlier tests,  Chapter 3. Measurements  66  the Intel program was used i n all three computers to drive the network. A better program than the one supplied by Intel would have been more helpful since the frame transmission rate could not be controlled through the program and all of the data had to be manually copied from the terminal screen from each computer.  To make matters more difficult,  the numbers i n the screen were shown in hexadecimal format which had to be converted to decimal base later. The program was used anyway to obtain some preliminary results. As before, three different information field lengths were used: a 'short' length 48 bytes long, a 'medium' length of 512 bytes, and a 'long' 1500-byte length.  The P C s  were programmed to transmit to an address that was different from any of their source addresses. This would allow the P C s to transmit as fast as they could without receiving frames.  Statistics from the data transmissions were recorded at the end of each trans-  mission session (using the software i n 'repeat transmissions' mode).  The software was  an interactive program that responded to input from the keyboard. Hence, it was not possible to 'trigger' all three computers to start and stop simultaneously with the Intel program. Instead, the following procedure was adopted. One computer was selected to start transmissions first. The second computer would start its transmissions 10 seconds after the first one and the third 10 seconds after the second. T h e transmissions were then stopped five minutes after the first computer was started, beginning with the first, followed by the second and the third computers 10 seconds apart. The duration of the transmission sessions was chosen to be long enough such that the 20-second starting and ending sequences would not comprise a considerable portion of the transmission session. The results of these transmissions are tabulated i n appendix C . It can be seen that the data from all four configurations do not differ very much. They all tend to behave similarly for the frame lengths chosen.  T h e differences in the data between different  configurations are due in part to statistical fluctuations and differences in overall propagation delay and hub characteristics. From the data, one can conclude that the serial  Chapter 3. Measurements  67  network behaves just like a standard S t a r L A N network. In other words, the subnetwork of nodes in a F A S T B U S crate 'look' like star-topology nodes to hubs at higher levels in the network. W h i l e the performance data showed encouraging results, there was a peculiar pattern in the distribution of the retransmission attempts.  The distribution of the number of  retransmissions i n a collision resolution interval should taper off to zero as the number of retransmissions required to resolve an initial collision increases.  Such a distribution  is expected because the range of the random backoff periods is doubled for each of the first ten unsuccessful retransmission attempts.  This means that the probability of two  or more stations choosing the same backoff period becomes smaller with more retransmission attempts.  However, the data showed a gap in the distribution from about nine  retransmissions to the maximum of 15. It seemed that if a collision was not resolved within a short number of retransmissions, then it would not be resolved at all. This peculiarity could be due to the pseudorandom nature of the way the backoff period is computed by the L A N controllers. Perhaps, two or more L A N controllers may happen to compute identical backoff periods in some collision intervals. One question that was not addressed by these measurements was the amount of variability i n the data if the transmission session was repeated over and over again. A few transmission sessions were repeated and the resulting data were found to change only slightly. Nevertheless, the general statistical variability of the data was not yet known. The performance data would be more meaningful if some measure of their variability could be given as well. Hence, an extension of the preliminary performance measurements was planned. This new set of measurements small increments.  would span the entire range of frame lengths allowed by S t a r L A N in T h e measurements for each frame length would be repeated so that  the variance in the data could be estimated. T h e deficiencies of the Intel program (as a tool for data collection) gradually became  Chapter 3. Measurements  68  more obvious as more performance measurements  were made.  Each transmission ses-  sion involved the monotonous task of manually starting and stopping the transmissions, followed by copying the data off the screen and converting them from hexadecimal to decimal base. Clearly, it would be impractical to use the Intel program to collect data from a large number of transmission sessions, as would be the case for the new set of measurements.  T h e initial test transmissions and performance measurements had shown  that data could be transmitted reliably over both the orthodox S t a r L A N and the serial networks. It would seem ironic i f further performance measurements did not involve an automated scheme which would use the network itself to collect data from all the P C s . So, an automated network driver program was conceived to replace the Intel program for the next set of performance measurements.  There would be two versions of the driver  program, a 'master' program which would control the 'slave' programs. T h e two versions would work as follows. The network master program sends initialization data through the network to each slave prior to a transmission session (the master also initializes itself). The initialization data sets the length of the frame, its destination address, the duration of the transmission session, and a delay parameter to control the transmission rate. A 'start transmitting' signal is then broadcasted by the master to begin the transmission session. Each slave pauses for a short time before starting so that the master can prepare itself. During the transmission session, data are collected by the master and every slave. Slaves do not respond to commands that the master may give until after the end of the transmission session. programmed duration.  A l l transmissions cease after the elapsed time has exceeded the However, frames will continue to be received for a short time  afterwards to allow for a margin of error i n the local timing of each P C . After a pause at the end of the session, the master prompts each slave, one by one, for the data collected during the session. Each slave responds to the prompt by sending the data over to the master via the network. T h e master then stores the data in a disk file, which completes  Chapter 3. Measurements  69  the data collection for a transmission session.  B y programming the master to set up  transmission sessions i n sequence, the task of obtaining performance  data can be left  to the networked computers, thus saving a poor graduate student from what would be repetitive, boring, and tedious (as well as humbling!) work. T h e first attempt to write the driver program was a dismal failure. It was written in Pascal and was compiled with the Microsoft Pascal (version 3.2(2)) compiler running under D O S 3.2.  Pascal was chosen because the author had a lot of experience with  writing programs i n this language. T h e Microsoft compiler was selected because it had been used before without any problem (although none of the earlier programs compiled under it were anywhere as long as the driver program). These choices for the language and compiler thus seemed sensible initially as program development could proceed without delays from having to learn another language (such as C ) or to use another compiler. So, the program was expected to be completed quickly without too much trouble. However, events that were to come later on soon extinguished all traces of the initial optimism. T h e basic problem with the program was that it would crash and render the operating system inoperable when an interrupt from the Intel board occurred. of the problem has never been determined.  The exact cause  O f course, the possibility of a subtle bug  in the source code cannot be ruled out but it is also possible that the compiler was not generating the correct code for handling interrupts.  The compiler had either been  stalling or generating spurious compiler-failure messages from time to time when the driver program was compiled. This annoying problem was eventually fixed by reducing the compiler's stack size, a solution that came only by chance after attempts to solve the problem by increasing the stack size were unsuccessful.  None of the compiler problems  occurred when short programs were compiled. The problems seemed to occur only if the compiler was 'stressed' by long programs (the driver program was about 1500 lines long). A t any rate, the compiler's behaviour only fueled doubts of its overall reliability.  Even  Chapter 3. Measurements  70  if compilation was successful, the executable code could not be 'trusted' to have been generated correctly.  This lack of trust made the task of debugging the program very  difficult. One could not determine which part of the program's problems were due to the compiler (if any) and which were caused by programming errors. The interrupt nature of the problem did not make debugging any easier because of its random nature.  The  exact behaviour of any program crash could not be repeated. After about three months of fruitless work, the effort was abandoned and the decision was made to switch to a different programming language (C) and compiler (Borland Turbo C v l . 5 ) . Rather than translate the Pascal program into C (and possibly copying any bugs over as well), a new driver program was written from scratch. After some time was spent to debug and enhance the code, a working driver program was completed A T L A S T . One 'slave' version and four 'master' versions of the driver program were developed.  Each  version of the master program collected data for a particular network configuration. D a t a analysis programs were then used to reduce the data down to a few meaningful parameters.  Input data files containing (x,y) coordinates of data points were then made  from the reduced data and were transferred from the P C system to M T S at U B C . Plots of these files were made by using Cuechart and Tellagraf (plotting programs). For each network configuration, transmission data were collected from each P C for information field lengths ranging from 50 to 1500 bytes long in 50-byte increments.  Ten 5-minute  transmission sessions were run for each field length. This allowed means and standard deviations to be computed for-a sample size often. A l l P C s were programmed to transmit as much as possible (without any delay loop to reduce their transmission rate) during the transmission sessions.  A n orthodox S t a r L A N topology was used for all configurations.  The earlier performance data (from the Intel program) had shown that there was no fundamental  difference between the behaviour of the serial network and an ordinary  S t a r L A N network. Therefore, it was felt that the new data could be safely generalized  Chapter 3. Measurements  71  to the case of the serial network as well. Appendix E contains a flowchart of the entire driver program. Figure 3.35 shows a plot of the average throughput for a single-PC network (throughputs for a 2- and 3 - P C network (discussed later) are also shown for comparison). Throughput, often abbreviated as S, is denned as the number of successful transmissions per unit time, normalized to the bit rate, which i n the case of S t a r L A N , is 1 M b p s . It is always less than 1. A n estimate of the software overhead time used by the program to prepare a frame for transmission was calculated (see appendix D ) and translated to the field length of a frame which would take a L A N controller the same amount of time to transmit. T h e calculated values for overhead time varied for different frame lengths, but not by much. The mean overhead time was computed to be 5632 microseconds, which is the time required to transmit a frame whose information field length is 678 bytes long. The translated longest and shortest overhead times were 682 and 674 bytes respectively. The significance of the overhead time will be discussed later. T h e throughput for a P C running the driver program was calculated to be about onesixth (for short frames) to about seven-tenths (for the longest frame) of the throughput when the Intel program was used.  This showed that the Intel program was far more  efficient (shorter overhead time) than the driver program.  Therefore, results obtained  with the driver programs were not expected to reproduce the performance data collected with the Intel program. A t any rate, no attempt was made to compare the data because the amount of variance in the earlier data was not known. Furthermore, the old data covered only three field lengths while the new data covered a comprehensive range of field lengths. Figure 3.36 shows a plot of the average throughput for a 2 - P C system ( ' P C 3 ' and ' P C 4 ' are just labels for the two P C s ; note also that they have the same curve and cannot be distinguished separately i n the graph). The individual throughputs level off  Figure 3.35: Average throughput for a single-PC network.  Chapter 3. Measurements  73  at approximately 700 bytes when the total throughput approaches the channel bit rate. Figure 3.37 shows a plot of the corresponding offered load. Offered load, or G , is defined here as the total number of attempts to access the channel (successful transmissions, collisions, and deferred transmissions) per unit time, normalized to the bit rate. It can be greater (even much greater) than 1. A t about 650-700 bytes, it increases sharply due to a sudden increase in the number of deferred transmissions, as shown in figure 3.38, which plots the number of deferrals as a fraction of the offered load. These transitions occur at just about the equivalent software overhead time of 678 bytes.  Before the  transition point, the frame transmission time is longer than the time it takes to prepare a frame for transmission.  The frame transmitted by one P C is completed before the  other P C has prepared the next frame for transmission. Hence, the two P C s more or less take turns when transmitting and deferrals are relatively rare. ( P C 4 defers more often than P C 3 because it probably runs somewhat faster, and therefore, can prepare a frame for transmission sooner than P C 3 . Every now and then, it 'catches up' with P C 3 and is consequently forced to defer transmission until P C 3 finishes.) Beyond the transition point, when the frame transmission time becomes longer than the overhead time, one P C will still be transmitting while the other has already prepared another frame. The other P C then has to defer transmission until the transmitting P C has  finished.  Both  P C s still take turns transmitting but must now defer transmission at every attempt to transmit.  Collisions rarely occurred i n the t w o - P C system. T h e amount of  fluctuation  in throughput and offered load was very small and will not be shown. Figure 3.39 shows the average throughput for a 3 - P C network where frames are not received by any P C (the destination addresses of the frames are different from their source addresses).  ' P C I ' , ' P C 3 ' and ' P C 4 ' are labels to identify the three P C s . Throughput  saturation occurs at approximately 350 bytes but fluctuations i n the average throughput do not occur until after 650-700 bytes.  A plot of standard deviation in throughput  Chapter 3. Measurements  Figure 3.36: Average throughput for a 2 - P C network.  74  Chapter 3.  Measurements  Figure 3.37: Average offered load for a 2 - P C network.  Chapter 3. Measurements  Figure 3.38: Number of deferrals expressed as a fraction of offered load.  Chapter 3. Measurements  77  expressed as a fraction of the average throughput is shown i n figure 3.40. Note the sudden increase in the fractional deviation at about 650-700 bytes. B y contrast, the fractional deviation of the total throughput remains close to zero. Similar behaviour is observed in the fractional deviation and the average of the offered load, as can be seen i n figures 3.41 and 3.42. Plots of the number of collisions, deferred transmissions, and exhausted retransmission attempts, all expressed as a fraction of the offered load, are shown i n figures 3.43, 3.44, and 3.45. A t the point of throughput saturation (350 bytes), all P C s begin to defer at about every other transmission attempt.  Note the large number of  deferrals by P C I before the 350-byte point. This indicates that P C I is probably running faster than the other P C s (as explained earlier in the 2 - P C case for figure 3.38). Collisions are rare until about 700 bytes, where there is a sharp increase i n the number of collisions and exhausted retransmission attempts (which indicate unresolved collision intervals). As with the 2 - P C configuration, the transition point occurs when the frame transmission time becomes as long as the overhead time. For field lengths equal to or longer than the equivalent overhead time of about 678 bytes, two P C s will have prepared their frames for transmission while the third P C has not yet finished transmitting. This ensures that channel contention between two P C s will occur once the third P C has  finished.  The  chaotic situation that results from the contention leads to more unpredictable behaviour as is shown in the plots of fractional deviations. The last configuration to be discussed is a 3 - P C network where one P C transmits to the other P C in a circular manner so that each P C is the receiver of another P C ' s transmissions. Since the P C s are now receiving as well as transmitting frames, the effective overhead time for preparing a frame for transmission is somewhat longer. (Received frames have to be processed before a transmit command can be sent to the L A N controller.) Hence, the transition point is expected to shift to a longer field length. Figures 3.46 and 3.47 show the average throughput and offered load for different field lengths.  Chapter 3. Measurements  78  Note the dip in both graphs at 800 bytes and the increased fluctuation of the individual P C curves which begin at about the same field length. T h e cause of the dip in both graphs is seen i n the average number of deferrals on figure 3.48, which shows a notch (indicating a sudden drop i n the fraction of deferrals by all three P C s ) at about 800 bytes. Associated with this notch is a sharp increase in the number of collisions which shows up as a spike i n figure 3.49. This shows that the frequent collisions obviously had a detrimental effect on not only the throughput of the individual P C s , but also the total throughput of the network as well. T h e drop in deferrals (figure 3.48) is a peculiarity that probably arises from the transmission sequence of the P C s and the nature of their transmissions (to transmit as often as possible whenever there are no received frames to process). A plot of the number of lost frames (good transmissions which were not received at all), expressed as a fraction of the total number of frames received is shown in figure 3.50. A sharp increase in the number of lost frames occurs at 800 bytes for one P C while slight increases occur for the two other P C s at 850 bytes.  A satisfactory explanation  has not been found for this observation. T h e number of buffer overflows (frames which could not be received because the frame buffers were full; the driver programs have 16 receive buffers) is shown in figure 3.51. Note the sudden increase which begins at around 800-850 bytes. The increase is probably due to the increased frequency of bad received frames, which take a longer time to process (to identify the type of error) than good frames. This indicates that the transmission rate for any P C is generally faster than the processing rate of bad received frames. To round out the remaining graphs, plots for the number of exhausted retransmission attempts, and fractional deviations of throughput and offered load are shown in figures 3.52, 3.53, and 3.54. A l l three parameters increase sharply at around 800 bytes (although the fractional deviation of the offered load is also high between 50 and 450 bytes). B y extending the results from the configurations  Chapter 3. Measurements  79  discussed earlier, it was concluded that the effective overhead time increased to approximately 800-850 information field bytes since this was the region in the graphs where the onset of drastic changes i n network behaviour and adverse performance were observed.  characteristics  T h e increased overhead time is expected in view of the fact that each  P C has to process received frames.  If a frame is received, the currently running task  is interrupted and another buffer is allocated for the next incoming frame.  Hence, the  time to prepare a frame for transmission is lengthened i f frames are received during the preparation interval for a transmission. The results of these measurements have implications that should be considered when a small number of nodes are continually transmitting frames at a high rate i n a network where the propagation delay is short. A reduction i n communication reliability as well as throughput can occur if the frame transmission and overhead times are roughly equal. Sharp changes i n network behaviour occur when the frame transmission time is equal to or longer than the overhead time. In general, fluctuations of throughput and offered load increase sharply beyond a critical transition point. Before the critical point, channel access can be characterized as essentially free from contention. Beyond the critical point, there is a marked increase in the amount of contention for channel use, which influences the variability of many transmission characteristics. Network performance may be optimized to some extent i f test transmissions are evaluated to determine the transmission and reception behaviour for the application at hand. T h e results of these performance measurements also show that one can indirectly estimate the software overhead time for frame transmission by locating the critical transition point from transmission data of a 2- or 3-node network (as described earlier). One interesting question about the performance data obtained here is how they compare to theoretical results and measurements from other network configurations (such  Chapter 3. Measurements  Figure 3.39: Average throughput for a 3 - P C network without frame receptions.  Chapter 3. Measurements  20  I n f o r m a t i o n Field L e n g t h ( b y t e s )  Figure 3.40: Fractional standard deviation of throughput.  1600  Chapter 3. Measurements  2.2  Figure 3.41: Average offered load for a 3 - P C network without frame receptions.  82  Chapter 3. Measurements  20  I n f o r m a t i o n Field L e n g t h ( b y t e s )  Figure 3.42: Fractional standard deviation of offered load.  1600  Chapter 3. Measurements  Figure 3.43: Number of collisions expressed as a fraction of offered load.  84  Chapter 3. Measurements  85  I n f o r m a t i o n Field L e n g t h ( b y t e s )  Figure 3.44: Number of deferrals expressed as a fraction of offered load.  1600  Chapter 3. Measurements  o  86  10  0  200  400  600  800  1000  1200  1400  1600  I n f o r m a t i o n Field L e n g t h ( b y t e s )  Figure 3.45: Number of unresolved collision intervals as a fraction of offered load  Chapter 3. Measurements  Figure 3.46: Average throughput for a 3 - P C network with frame receptions.  87  Chapter 3. Measurements  2.2  OH 0  i 200  i i i i i i 400 600 800 1000 1200 1400 Information Field L e n g t h (bytes)  1600  Figure 3.47: Average offered load for a 3 - P C network with frame receptions.  Chapter 3. Measurements  Figure 3.48: Deferred transmissions expressed as a fraction of the offered load.  89  Chapter 3. Measurements  Figure 3.49: Collisions expressed as a fraction of the offered load.  90  Chapter 3. Measurements  91  14  Legend  12  PCI PC3 PC4  10  0  s  E  8-  00 0)  o  6  00  4-  2-  200  400  600  800  1000  1200  1400  1600  Information Field Length (bytes)  Figure 3.50: Lost frames expressed as a fraction of the total number of received frames.  Chapter 3. Measurements  92  Figure 3.51: Buffer overflows expresssed as a fraction of the total number of received frames.  Chapter 3. Measurements  Figure 3.52: Number of unresolved collision intervals as a fraction of offered load  93  Chapter 3. Measurements  Figure 3.53: Fractional standard deviation of throughput.  94  Chapter 3. Measurements  Figure 3.54: Fractional standard deviation of offered load.  95  Chapter 3. Measurements  96  as, say, 10 or more nodes). N o comparisons were made in either case, but a comparative analysis for a related C S M A / C D standard, Ethernet, is given in [20]. The general results from that reference may be extended to some extent to the case of S t a r L A N , which is similar i n many respects to Ethernet. For Ethernet, the influence of the number of stations on throughput for a given offered load is minor for long frames but can be significant in a network with a small number of nodes (less than 20) if the frames are short and the offered load is large.  A discussion on the similarities (and differences)  between measurements of and theoretical results for maximum throughput can be found in [20] and will not be given here. In general, the data obtained from the performance measurements are somewhat restricted i n the sense that they apply only to a system with a short propagation delay where a few nodes transmit continually.  A part of the  difficulty here is due to the fact that it is essentially impossible to generalize results from a very small number of nodes. Nevertheless, the results obtained here provide the basis for, i f necessary, more exhaustive measurements.  Chapter 4  System Implementation Options  Several alternatives are available to the system designer should S t a r L A N be selected as the bottom-layer protocol for the F A S T B U S Serial Network. These alternatives fall into roughly three areas: topology, bit rate, and access scheme.  4.1  Topology  As was discussed earlier in the Introduction, two topologies are available for S t a r L A N . The first one is a star topology that uses hubs, as was originally conceived by the I E E E 802.3 Working Group. The second one is a bus topology which does not use hubs. This topology has been promoted most notably by Advanced Micro Devices. The choice of interconnection topology depends on a number of practical considerations and these are discussed below. T h e star topology allows nodes and hubs to be easily attached or removed from the network. In a star topology serial network, each F A S T B U S crate would contain a hub that connects to higher hub layers i n an orthodox star configuration while linking the nodes downstream (the devices plugged into the crate) as a two-line backplane bus. Only nodes are allowed to be connected downstream of a crate hub. This means that F A S T B U S crates can be removed from the network by simply disconnecting the crate hub from the upstream hub. There is no need to reconnect lower hub layers back to the network since there aren't any. However, there is a problem with jabber control. If a crate hub cannot stop a node from jabbering, all nodes in the same crate are disconnected 97  Chapter 4. System Implementation Options  98  from the network. This form of collective punishment can occur because the nodes are connected together i n a bus topology which appears to the hub as just one node input. T h e crate hub cannot select the node to be disconnected. the erring node(s) within the crate.  In fact, it cannot identify  Granted that jabbering nodes are expected to be  very rare, the only solution to this problem is to provide all nodes with jabber control circuits, transferring the jabber control function from the hub to each and every node. T h e Am7961 bussed S t a r L A N transceiver has such a function. However, the chip uses RS-422 ( S t a r L A N ) signal levels for the bus data lines which would have to be translated to E C L logic voltages. Another concern centres on the reliability of the hubs themselves. A single hub failure can disable the network to different extents, depending on where it is located. In the worst case, the entire network could be disabled. Hence, all hubs in the network must be very reliable, much more so than the nodes. In fact, the S t a r L A N specifications require hubs to have a mean time between failures ( M T B F ) of at least five years of continuous operation. In a bussed (hubless) network, each node communicates by a bus transceiver, such as the Am7961, which is connected to the L A N controller. In the case of the Am7961, an R S 4 2 2 - E C L converter is needed since its bus interface uses S t a r L A N - t y p e RS-422 voltage levels. Insofar as the Am7961 is the only S t a r L A N bus transceiver on the market today, the need for a voltage converter could prove to be a nuisance. A t least one chip will be needed to convert between RS-422 and T T L signals (e.g., T P s SN75109) while two chips will be needed for T T L - E C L conversion (e.g., Motorola M C 1 0 K 1 2 4 for T T L - t o - E C L , and M C 1 0 K 1 2 5 for E C L - t o - T T L ) . Hence, at least five chips are needed per node ( L A N controller, bus transceiver, three voltage converters) if the Am7961 is used. Note that this figure does not include support chips that may be required by the L A N controller (it does, however, include a clock source since the Am7961 has a clock output). A node in a hub-based network would not require a bus transceiver, although such a device might be  Chapter 4. System Implementation Options  99  useful if it has a jabber control function, as was mentioned previously. Another aspect of a bus topology serial network is that repeaters are required at each crate if E C L voltage levels cannot be used in the cables that connect the crates together. Even if E C L voltages could be used, repeaters would probably be needed anyway to avoid impedance mismatches between crate-connecting cables and the backplane.  Repeaters are crucial  elements i n the operation of a bussed network. Even a single malfunctioning repeater can disable the entire network, depending on the nature of its defect. Just as the reliability of hubs is a matter of concern in a star-topology network, so is the case with the reliability of repeaters in a bus network. As mentioned in the introductory section on S t a r L A N , there are two ways for connecting crates together in a bussed S t a r L A N scheme. The first is a T connection while the second is a daisy chain. For either connection scheme, the task of attaching a crate to (or disconnecting it from) a bussed serial network seems to be less straightforward compared to that in a hub-based network.  4.2  Bit Rate  The decision on whether to use a bit rate (the rate in which data is transmitted and received) of 1 M b p s or 10 M b p s involves a trade-off between implementation complexity and network capacity. A higher bit rate will involve a probably more costly and complex hardware solution since higher clock speeds and faster circuits are involved compared to that for a lower bit rate.  T h e higher bit rate may also result in a somewhat less  robust operation in heavily loaded backplanes compared to a lower bit rate. There has to be a serious discussion among F A S T B U S system 'experts' as to what data rates are expected for the proposed applications of the serial network. It is important to look not only into average capacity requirements but also into peak demand. Depending on the application, a 1 M b p s network may be sufficient during normal operations but may suffer  Chapter 4. System Implementation Options  100  from unacceptable delays during peak transmission periods.  4.3  Access Scheme  S t a r L A N , being a C S M A / C D protocol, is inherently a random access system. There is no guarantee that a frame will be transmitted immediately after it is sent to the L A N controller. This may be a problem in some applications if, for example, a response must be received before a certain time limit. A deterministic access scheme may be required in such cases. S t a r L A N can still be used for a deterministic access system i f higher-layer collision-avoidance protocols are used. Of course, it then becomes a valid question to ask if S t a r L A N is really suited for implementing the serial network i n the first place. Token-passing is one scheme that allows all nodes in the system to have guaranteed access to the network i n a deterministic time interval. The performance characteristics of a token bus ( I E E E 802.4) have been compared to a C S M A / C D standard ( I E E E 802.3 Ethernet) in [21]. The results from that reference may also apply to the case of StarL A N as well since S t a r L A N is quite similar to Ethernet in many respects.  In general,  shorter delays are associated with C S M A / C D compared to token-passing (token bus) while token-passing achieves greater m a x i m u m throughput than C S M A / C D . In particular, the maximum throughput for a token bus is much less affected by the network propagation delay than is C S M A / C D . It is not known, however, just how much more complicated the serial network's implementation will become if token-passing is used instead of S t a r L A N although it is expected to be much more complex. A description of a protocol that effectively implements token-passing will be described later. Another deterministic scheme is the master-slave method that is currently used in F A S T B U S systems. A n analogous system is described here for the serial network. A t any point i n time, the network is composed of slaves and, at most, one network-master.  Only  Chapter 4. System Implementation Options  101  the master node can initiate transmissions. The rest of the nodes in the network can only transmit in response to prompts or commands from the master. W h e n the master has completed its operations, it relinquishes control of the network, after which other nodes can contend for network mastership. A l l contending nodes 'apply' for network mastership to the master arbitrator by transmitting 'request frames' using ordinary C S M A / C D to a centralized 'master arbitrator'. T h e arbitrator decides on which node becomes the next master (by a first-come-first-served rule, for example) and broadcasts the address of the next master. This scheme has two attractive features. Firstly, it can be programmed to assign network mastership to all nodes sequentially, thus effectively implementing a tokenpassing scheme if that is desired. Secondly, it acts as a network 'super master' that settles 'master disputes' where, because of a misunderstanding, more than one node thinks it is the network master, or when one or more non-master nodes initiate transmission without realizing that a master has been assigned control over the network. In such cases, the arbitrator can simply rebroadcast the address of the valid master to correct the erring nodes.  However, the centralized arbitrator system is not robust for if anything goes  wrong with the arbitrator, the entire master-slave scheme collapses. One way out of this problem is to do away with the central arbitrator altogether. In this 'distributed' scheme, a node contends for network mastership by broadcasting a master-request frame and relinquishes its mastership by broadcasting a master-release frame. 'Master disputes' (as defined previously) are resolved by a pre-determined prioritization order that is known by each and every node. If a master finds that other nodes are initiating transmissions, it can rebroadcast a master-request frame to reassert its mastership. If it receives a master-request frame from a higher-priority node, then it loses its mastership immediately. To reduce transmission overhead, commands or prompts may be piggy-backed onto master-request  frames.  Likewise, single-frame responses can be  piggy-backed on master-relinquish frames (In this case, the responding node relinquishes  Chapter 4. System Implementation Options  102  the mastership of the prompting node. This is useful for simple command-response applications.). Note that it is possible for starvation to occur in the two master-slave schemes described above just as starvation can occur in a F A S T B U S system. It should also be noted for either the centralized or the distributed schemes that some time can elapse before a node gains complete mastership of the network (when there is only one master and all other nodes are aware of it). This can occur if the L A N controller of a node happens to be deferring transmission to a master request frame of another node. In this case, the deferring node will transmit after an IFS interval at the end of the master request frame because its transmission cannot be aborted immediately. The received request frame has to be processed first before the node finds out that it can no longer initiate transmissions. Application programs should make allowances for this possibility. It is expected that some applications running i n the F A S T B U S Serial Network will involve mainly command-response-type operations (where the response has to be received within a time limit) and other operations which do not require deterministic access to the network. If that indeed is the case, then S t a r L A N , along with a higher-layer master-slave protocol, can be used to allow both groups of operations to coexist. A node will first have to contend for mastership of the network before proceeding with a time-critical operation. Operations that do not depend on a time limit can proceed (without having to reserve the network) during the intervals when network access is not restricted by a master. The arrangement described above takes advantage of the throughput and simplicity of a C S M A / C D scheme for random access applications, yet will allow deterministic access when required.  Chapter 5  Summary of Results and General Assessment  The following section is given below to summarize the major points of the three previous chapters. • The prototype network was composed of a F A S T B U S crate, a standard S t a r L A N hub, a S t a r L A N hub specially constructed for the F A S T B U S backplane, and three P C compatible computers which accessed the backplane via R S - 4 2 2 - E C L tranceiver cards. • Signal jitter and propagation delay in the backplane were measured for different configurations of capacitive loads. The largest amount of signal jitter was measured to be 6 ns while the longest propagation delay was measured to be 16.2 ns. B o t h of these values fall well within the S t a r L A N specifications of 62.5 ns for jitter and 4 bit times for node-hub / hub-hub propagation delay. • D a t a communications were established by the three P C s through the prototype network without any problems whatsoever. T h e crate hub was successfully operated either as an intermediate hub (where the standard hub was used as the header hub) or as a header hub. T h e general behaviour of data transmissions in the threenode prototype network were similar to those for an orthodox S t a r L A N network, indicating that the F A S T B U S hub level appears as just another S t a r L A N hub level to the rest of the network. It also indicates that the bus topology of a F A S T B U S hub level does not cause the network behaviour to differ from that of a star topology. 103  Chapter 5. Summary of Resulis and General Assessment  104  • Performance measurements of a three-node orthodox S t a r L A N network show some interesting results. The length of the transmitted frame and the preparation time for frame transmission can have a profound effect on network performance.  In  particular chaotic behaviour and reduced reliability were observed if the frame transmission time is equal to or greater than the preparation time. Most of the work for the StarLAN-based serial network has been done as far as the physical and media access control layers are concerned. A n implementation of the bussed S t a r L A N scheme is one area of work that has yet to be done. A t this stage however, there does not seem to be an overwhelming advantage i n using bussed S t a r L A N as opposed to standard S t a r L A N to implement the serial network. Protocols for the higher layers have yet to be developed and are expected to depend very much on what F A S T B U S users want to use the serial network for in the first place. The prototype network was built without much difficulty at all and this shows a certain amount of inherent 'compatibility' between S t a r L A N and the F A S T B U S Serial Network. The work on the prototype network has shown that S t a r L A N is an effective, simple, affordable and easily adaptable standard to implement the F A S T B U S Serial Network. The onus should now be on the detractors, if there are any, to make their case against a serial network based on S t a r L A N .  Appendix A  P A L A S M Listing, Notes on Transceiver and H u b Circuits  A.l  P A L Device Logic Equations  A listing of the P A L programming program is given below in figure A.55. The logic equations are equivalent to the programming information given in [9]. A fuse plot and results from simulations produced from the P A L A S M 2 program have not been included. The simulations essentially show that the equations are correct while the fuse plot shows connections i n the logic device that were specified by the equations. A.2  Functional Description of the S t a r L A N - F A S T B U S Transceiver  The following section explains how the transceiver circuit of chapter 2 works (see figure 2.24). The transceiver is composed of two subcircuits: one for signals i n the downstream direction (into the backplane) and another for signals in the upstream direction (from the backplane). U6 and U7 are used for clocking the two subcircuits. RS-422 signals from the upstream source appear at lines U D P and U D N . R l is an impedance-matching resistor, nominally 100 ohms for twisted-pair telephone wiring. T l is a dual transformer used for D C isolation of the differential RS-422 signals. U 2 is an RS-422 receiver that converts RS-422 signals to T T L . Resistors R 2 to R5 are used for voltage squelch (as specified by S t a r L A N ) . O U T A of U2 is the unsquelched signal while O U T D has the squelched signal which is used by U4, U 7 , and U 9 to filter the signal from O U T A . U9 also doubles as a T T L to  105  Appendix A. PALASM Listing, Notes on Transceiver and Hub Circuits  TITLE T r a n s l a t e d PAL program f o r I n t e l StarLAN D e s i g n K i t . PATTERN S t a r L A N . p a l REVISION 2 AUTHOR ( o r i g . , A d i G o l b e r t , I n t e l ; t r a n s l a t e d by R i c h a r d Cam) COMPANY I n t e l , TRIUMF DATE 22 May 1987 CHIP M u l t i f u n c t i o n PAL16L8 A9NANDA8 A7 A6 A5 A4 IOWR AO AEN REQ1 GND REQO LDPORT RESET DACK3 DACK1 DREQ3 DREQ1 CS BUSEN VCC EQUATIONS /CS = /AEN * /A9NANDA8 * /A7 * /A6 * /AS * /A4 * /AO /LDPORT • = /AEN * /A9NANDA8 * /A7 * /A6 * /A5 * /A4 * AO * /IOWR /DREQ1 = /REQO * /DACK1 + /REQO * /DREQ1 + RESET /DREQ3 = /REQ1 * /DACK3 + /REQ1 * /DREQ3 + RESET /BUSEN = /DACK1 + /DACK3 + /AEN * /A9NANDA8 * /A7 * /A6 * /A5 * /A4 ;/CS.TRST •» VCC ;/LDPORT.TRST = VCC ;/DREQ1.TRST = VCC ; /DREQ3.TRST = VCC ; /BUSEN.TRST • = VCC  Figure A.55: Logic Equations for P A L device of Intel S t a r L A N board.  106  Appendix A. PALASM Listing, Notes on Transceiver and Hub Circuits  107  E C L translator that drives the Serial Transmit line of the F A S T B U S backplane. E C L signals from the Serial Receive line of the backplane are converted to T T L by U8 and from T T L to RS-422 by U l , an RS-422 driver. Capacitors C 2 and C3 are used for trapezoidal modulation (they increase the slew rate of RS-422 signals to reduce rf emissions from unshielded telephone cable. T w o J K flip-flops (U5) are used to implement a divide by 4 circuit whose output is used to clock U 3 , a shift register which is used to enable the output of U l . U 3 disables the output of U l at the end of a S t a r L A N transmission (when a high logic level is detected for approximately 2 microseconds). The other capacitors are used for power supply bypass purposes. They reduce the magnitude of supply voltage spikes that occur when T T L devices change states.  A.3  Functional Description of the S t a r L A N H u b Circuit  This section describes how the S t a r L A N crate hub of chapter 2 works (see figure 2.28). Note that there are two corrections to the original schematic diagram (dated 30 July 1987).  First, a 100-ohm resistor across pins 10 and 8 of T l is missing.  Second, the  S E R - T X (A58) and S E R - R X (A57) lines are interchanged (A58 should connect to U5 while A57 should connect to U6). E C L signals from the Serial Transmit line (going in the upstream direction) are converted to T T L by U6 whose output is fed into U 4 , the hub controller. The output and output enable pins of U4 are connected to U 3 , a S t a r L A N driver/receiver, which converts the T T L output to RS-422 and drives the telephone cable via an isolation transformer, T l . RS-422 signals from the telephone cable (in the downstream direction) are isolated  by T l and filtered by an R C L circuit which has a cut-off frequency of approximately 2 M H z . The filtered signal is then converted to T T L by U 3 (which has a built-in squelch circuit). The signal and squelch output of U3 is connected to the upstream port of U4.  Appendix A. PALASM Listing, Notes on Transceiver and Hub Circuits  108  The retimed output is then converted to E C L by U 5 , which drives the Serial Receive line of the backplane.  U5's output is enabled by a high logic level through R 7 . U2 is  used to clock U4. A debounced switch (to reset U4) is implemented by S I , R 5 , D l , C l , and U l . U4 has three outputs for driving L E D ' s (pins 15, 16, and 19) and these are buffered by U l , which drives the L E D ' s through dropping resistors R 2 to R 4 . R l and DS1 implement a power-on indicator. The remaining capacitors are used for bypassing the -5.2V and 5.0V power supply lines.  Appendix B  Photographs and Table of Electrical Measurements  Measurements of propagation delay and pulse jitter are tabulated in table B . l . The corresponding oscilloscope photographs are shown in figures B.56 to B.73.  109  Appendix B. Photographs and Table of Electrical Measurements  Reference Propagation Delay (nsec.) Number first edge second edge 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 23 24 25  11.6 7.8 6.2 9.2 7.0 9.4 12.2 14.8 10.8 9.2 14.6 .13.2 13.8 9.6 16.2 7.8 12.8 15.2  Pulse Jitter (nsec.)  9.4 9.4 7.6 8.4 6.2 9.6 12.2 12.6 10.2 9.6 12.4 7.2 12.8 9.0 16.0 6.8 12.2 14.2  Table B . l : Propagation delay and pulse jitter  2.2 1.6 1.4 1.2 0.8 0.2 0.0 2.2 0.6 0.4 2.2 6.0 1.0 0.6 0.2 1.0 0.6 1.0 measurements.  Appendix B. Photographs and Table of Electrical Measurements  Figure B.56: Reference number 7  111  Appendix B. Photographs and Table of Electrical Measurements  Figure B.57: Reference number 8  Appendix B. Photographs and Table of Electrical Measurements  Figure B.58: Reference number 9  113  Appendix B. Photographs and Table of Electrical Measurements  Figure B.59: Reference number 10  114  Appendix B. Photographs and Table of Electrical Measurements  Figure B.60: Reference number 11  Appendix B. Photographs and Table of Electrical Measurements  Figure B.61: Reference number 12  116  Appendix B. Photographs and Table of Electrical Measurements  Figure B.62: Reference number 13  117  Appendix B. Photographs and Table of Electrical Measurements  Figure B.63: Reference number 14  118  Appendix B. Photographs and Table of Electrical Measurements  Figure B.64: Reference number 15  119  Appendix B. Photographs and Table of Electrical Measurements  Figure B.65: Reference number 16  120  Appendix B. Photographs and Table of Electrical Measurements  m II li 1E3I311  aw  F1HHTT1P  Figure B.66: Reference number 17  121  Appendix B. Photographs and Table of Electrical Measurements  Figure B.67: Reference number 18  Figure B.68: Reference number 19  Appendix B. Photographs and Table of Electrical Measurements  Figure B.69: Reference number 20  Appendix B. Photographs and Table of Electrical Measurements  Figure B.70: Reference number 21  125  Appendix B. Photographs and Table of Electrical Measurements  Figure B.71: Reference number 23  126  Appendix B. Photographs and Table of Electrical Measurements  Figure B.72: Reference number 24  Photographs and Table of Electrical Measurements  Figure B.73: Reference number 25  Appendix  C  Tables of Preliminary Performance D a t a  This appendix contains tables of preliminary performance data that was obtained with the Intel program. Three P C compatibles were used to drive the network. Tables C.3, C.4, and C.5 show general transmission statistics for three frame lengths while the detailed collision data are shown i n tables C.6, C.7, and C.8. A l l numbers are in base 10. The 'mode' field code is used to identify the network configuration of the data and is described below i n table C.2. T h e data show that each P C behaves similarly under different network configurations. There are only minor differences i n performance, and they should not be a cause for concern at all.  Mode A B C D  Description  Figure  crate header hub crate intermediate hub with Retix H B - 6 header hub simple repeater orthodox S t a r L A N network  2.23c 2.23c 2.23b 2.23a  Table C.2: Network configurations for prehminary performance  129  measurements.  Appendix C. Tables of Preliminary Performance Data  PC PCI PCI PCI PCI PC3 PC3 PC3 PC3 PC4 PC4 PC4 PC4  Mode A B C D A B C D A B C D  Total tx 155904 140551 155606 139762 220139 218546 220886 221227 89026 103543 89939 105835  Collisions 1727 1861 1733 1826 1318 1318 1345 1369 2201 2127 2184 2153  Good tx Deferred tx 154177 142438 138690 127256 153873 141697 137936 126490 218821 217307 217228 215763 219541 218062 219858 218462 86825 75860 101416 89727 87755 77257 103682 93044  Table C.3: General transmission data for 72-byte frames.  130  Appendix C. Tables of Preliminary Performance Data  PC  Mode  PCI PCI PCI PCI PC3 PC3 PC3 PC3 PC4 PC4 PC4 PC4  A B C D A B C D A B C D  Total tx 26197 25747 26326 26715 25245 24651 25175 25599 25946 27048 25972 25356  Collisions 1460 1564 1540 1480 1489 1542 1527 1472 1519 1452 1529 1568  Good tx 24737 24183 24786 25235 23756 23109 23648 24127 24427 25596 24443 23788  131  Deferred tx 21850 21359 21835 22337 23044 22416 22859 23368 21542 22684 21585 20695  Table C.4: General transmission data for 532-byte frames.  PC PCI PCI PCI PCI PC3 PC3 PC3 PC3 PC4 PC4 PC4 PC4  Mode A B C D A B C D A B C D  Total tx 10181 10321 9916 10532 9583 9903 9885 9881 10417 10032 10456 9828  Collisions 1398 1401 1465 1436 1463 1439 1407 1431 1415 1484 1430 1487  Good tx 8783 8920 8451 9096 8120 8464 8478 8450 9002 8548 9026 8341  Deferred tx 7260 7400 7021 7560 7474 7766 7756 7731 7478 7041 7456 6917  Table C.5: General transmission data for 1526-byte frames.  Appendix C. Tables of Preliminary Performance Data  PC  Mode  "PCT PCI PCI PCI PC3 PC3 PC3 PC3 PC4 PC4 PC4 PC4  A B C D A B C D A B C D  132  Collision Resolution Interval (number of retransmission attempts) 8 698 663 687 610 962 979 1030 1024 441 499 408 506  100 67 91 84 44 51 51 51 43 67 44 56  11 9 2 8 2 8 25 T 14 27 8 8 25 9 7 38 _6_ 4 7 3 2 14 3 1 9 2 1 17 8 2  1  10  11  12  13  14  15  Failed 49 64 52 64.  5 5 4 6 101 89 101 89  Table C.6: Distribution of Collision Resolution Interval for 72-byte frames.  Appendix C. Tables of Preliminary Performance Data  PC  Mode  PCI PCI PCI PCI PC3 PC3 PC3 PC3 PC4 PC4 PC4 PC4  A B C D A B C D A B C D  1 452 487 458 489 469 451 484 480 502 474 495 450  2 15 17 19 14 14 22 23 22 18 17 23 17  3 23 31 27 15 26 12 22 22 19 21 32 26  4 15 14 16 20 14 25 20 15 21 19 13 13  Collision Resolution Interval 'number of retransmission attempts) 5 6 7 8 9 10 11 12 13 14 7 5 10 2 9 1 11 4 1 9 1 1 8 3 3 11 2 10 1 1 10 1 10 2 1 9 1 12 5  133  15  Failed 49 52 53 47 50 52 49 47 49 46 49 54  Table C.7: Distribution of Collision Resolution Interval for 532-byte frames.  Appendix C. Tables of Preliminary Performance Data  PC  Mode  "PCT PCI PCI PCI PC3 PC3 PC3 PC3 PC4 PC4 PC4 PC4  A B C D A B C D A B C D  378 361 382 407 357 404 351 397 391 366 390 353  21 2 23 1 25 1 22 5_ 20 2 30 1 22 3 19 J_ 23 1 23 1 18 2 21 2  12 9 5 12 11 6 7 14 11 11 11 19  Collision Resolution Interval (number of retransmission attempts) 6 _8_ 10 11 12 13 14 17 11 3 20 11 3 2 22 11 6 3 18 7 10 _2_ 21 16 3 25 12 1 1 20 13 6 1 20 2 1 9 17 14 6 17 14 6 18 14 4 15 3 9  134  15  Failed 47 47 48 44_ 49 46 46 47_ 45 50 47 52  Table C.8: Distribution of Collision Resolution Interval for 1526-byte frames.  Appendix D  Calculation of Software Overhead T i m e  Software overhead time is defined as the time required to prepare a frame for transmission. For a system that uses an Intel 82588 L A N controller, several operations have to be done before a frame can be transmitted by the L A N controller. These include, as a minimum requirement, initialization of a D M A controller (for data transfer to the L A N controller) and sending a T R A N S M I T command to the 82588.  The software overhead time per  frame transmitted, t /,, can be estimated by computing the difference between the total D  time to prepare and transmit a frame, t , and the time required to transmit a frame tot  through the network (by the L A N controller), t . tx  toh  The frame transmission time, t  tX}  — ttot ~~ ttx  in seconds per frame, is given by  where L is the frame length in bits, I is the interframe spacing (96 bits), and C is the channel bit rate (1 Mbps for S t a r L A N ) . The total transmission time, t , i n seconds per tot  frame is given by  _L ttot - ~  s  where S is the measured throughput of the transmitter. This calculation does not take into account the time involved in deferring transmission or i n resolving a collision. Hence, it can only be used for data obtained from a single-node 135  Appendix D. Calculation of Software Overhead Time  136  network where there is no contention for channel use. The overhead time for different information field lengths is given in table D . 9 . (to obtain the frame length, add 26 bytes to the field length). The average overhead time was calculated to be 5632 microseconds, which can be converted to the field length of a frame that would take roughly the same amount of time to transmit. For a 1 M b p s channel, this would correspond to a frame whose information field length is 678 bytes ((678+26fo/fes ){&bits/byte)/(1Mbps)  = 5632microseconds ). The  longest overhead time was 5661 microseconds while the shortest was 5596 microseconds. These values correspond to transmission times for frames with field lengths of 682 and 674 bytes respectively.  So, the mean field length is bound to within approximately 4  bytes from the data obtained.  Appendix D. Calculation of Software Overhead Time  Field Length (bytes) 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 1000 1050 1100 1150 1200 1250 1300 1350 1400 1450 1500  Throughput  toh (u.secs.)  0.096 0.149 0.197 0.240 0.279 0.313 0.345 0.373 0.399 0.423 0.445 0.467 0.486 0.504 0.521 0.536 0.550 0.564 0.576 0.589 0.600 0.612 0.622 0.632 0.640 0.649 0.657 0.665 0.673 0.682  5629 5661 5643 5629 5610 5628 5615 5633 5640 5644 5651 5620 5624 5620 5612 5624 5638 5631 5652 5631 5643 5615 5621 5615 5646 5641 5651 5651 5641 5596  Table D.9: Overhead times for different field lengths.  137  Appendix E  Notes on the A u t o m a t e d Network Driver P r o g r a m  Flowcharts of the routines in the program are shown in figures E.74 to E.76. A brief description of each routine is given i n the header files of the different program modules as shown in figures E.77 to E.83. Figures E.84 and E.85 show a sample master and slave program respectively. A sample output file (as produced by a master program) is given in figure E.86. Apart from the flowcharts, no documentation has been produced for this program. However, there are many comments (in the source files) at device-dependent subroutines which interact with the 82588 L A N controller of the Intel board (these are expected to be more difficult to understand than other parts of the program). Interested readers should contact the author for more details.  138  Appendix E. Notes on the Automated Network Driver Program  139  2. DO_ SC-Al/E.  •START!. S £ L F _ TK  STATISTICS  QU(£TFRAMES  S€TTUP_ (A.  588  BU<= R S R S  5??  TRAAJSA^T '— 5S?  RCA/_ S T A B L E .  5S8  585?  BOARD  ALLOCATE,  Figure E.74: Subroutine Flowchart of Driver Program, Part 1 of 3  Appendix E. Notes on the Automated Network Driver Program  140  CcorvrTD.")  A B e>£T_ PR/N'T-FIUE  <5£"T^?TAT5  T •START. -r/AYg  "/M£_ UP  SEt-F_ IA  S&TUP_ ( A .  FRAMES  PEVA/IT_  AJOD6  $TAtT_Ty  ABORT-TV.  T R A A V S M / T _ sa?  Figure E.75: Subroutine Flowchart of Driver Program, Part 2 of 3  Appendix E. Notes on the Automated Network Driver Program  58?  TRANSMIT. 5XS  141  "STOP. 5g^  683?  Qute~T. DMA  5S2  VUMP-588  PRER_ P M A  6>u ( £TT_ PROCESS-  FRAME?  5eTuP_tA. 5 ^  £TATlSTlC5  Figure E.76: Subroutine Flowchart of Driver Program, Part 3 of 3  142  Appendix E. Notes on the Automated Network Driver Program  /•  Richard Cam 93523827 Primary set of l o c a l a p p l i c a t i o n r o u t i n e s . Header f i l e : a u t o u t l l . h System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C v e r s i o n 1.5 ml Compact memory model V e r s i o n : 2.1 20 June 1988  v o i d 1n1t_node t ) ; / • I n i t i a l i z e b u f f e r s and 82588 v o i d change_self_conf1g /•  ( Int int 1nt change 82588 c o n f i g u r a t i o n  V  confO, Int c o n f l . Int conf2, conf4, Int conf5. 1nt conf6, conf8. 1nt conf9 ): of l o c a l node •/  void change_self_1a  1nt conf3, Int conf7,  ( int new_1a0, int new_ia1, int new_ia2, int new_ia4, int new_1a5 ); / * change 82588 i n d i v i d u a l address of l o c a l node "/  int  new_ia3,  v o i d program_se1f_tx  /•  ( unsigned int tx_durat1on. unsigned 1nt d e l a y _ p e r i o d , unsigned Int 1nfo_f1eld_1en, 1nt targO. Int t a r g l . 1nt targ2, int targ3, 1nt targ4, int targ5 ); change repeated-transmission parameters of l o c a l node •/  v o i d s t a r t _ s e l f _ t x ( int master ); / • i n i t i a t e repeated transmissions void do_slave_tx ( Int master ); / * slave v e r s i o n of start_se1f_tx void abort_self_tx /* forcefully halt  V  Richard Cam 93523827  V  t); l o c a l nodes transmissions  void deinit_node ( ) ; / * normal termination of program /•  •/  •/  •/  Buffer Management Routines. Header f i l e : buffmgr.h System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C version 1.5 w/ Compact memory model V e r s i o n : 2.1 06 June 1988  #def1ne MAX_*LLOC_TRIES 3  / • max. number of attempts for make_buffer to a l l o c a t e memory space In the heap for the s p e c i f i e d buffer s i z e without c r o s s i n g page boundaries. •/  void a l l o c a t e _ b u f f e r ( address *buff, unsigned int num_elements ); / • a l l o c a t e memory space for a block of s i z e num_elements bytes such that i t does not cross page boundaries * /  Figure E.77: Header Files  Appendix E. Notes on the Automated Network Driver Program  v o i d create_buffer9  /'  allocate  ( address *config_buff, address *1a_buff, address 'dump_buff, address *tx_buff, address r x _ b u f f l ) . int num_rx_buffs, address *sub_tx_buff, address *sub_rx_buff memory space for buffers used In the program. V  143  );  v o i d exchange_buffers ( address *buff_a. address *buff_b ); / * exchange contents of address s t r u c t u r e s . */ /• Richard Cam 93523827 Global D e c l a r a t i o n s . Header f i l e : g l o b a l s . h System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C version 1.5 w/ Compact memory model V e r s i o n : 2.1 06 June 1988 V fdefine fdefine  TRANSMIT 1 RECEIVE 0  fdeflne fdefine  CHANNEL_1 1 CHANNEL_3 3  fdeflne  MAX_RX_BUFFS 17  / * equate CHANNEL_1 to channel 1 of 8237A OMAC / * equate CHANNEL_3 to channel 3 of 8237A OMAC / • max. number of r e c e i v e data buffers  V V  V  f d e f i n e CONFIG_BUFF_SIZE 12 / • s i z e of 82588 c o n f i g u r a t i o n block V f d e f l n e IA_BUFF_SIZE 8 / * s i z e of 82588 6-byte i n d i . addr. block V f d e f l n e DUMP_BUFF_SIZE 63 / • s i z e of 82588 r e g i s t e r dump block */ fdeflne MAX_TX_BUFF_SIZE 1508 / ' s i z e of largest 82588 transmit data block f d e f l n e MAX_RX_BUFF_SIZE 1514 / • s i z e of largest 82588 receive data block fdeflne  0CW2 0x20  / • 8259A E0I or s p e c i f i c  E0I r e g i s t e r  fdeflne fdeflne  UNMASK LINE_5 OxDF / • AND mask b i t pattern to enable l i n e 5 SE0I_LINE_5 0x65 / • s p e c i f i c E0I code for l i n e 5 V  fdeflne  INTR_VECT_13  fdeflne  INTR_LINE 5  V V  V V  13  / • vector table entry for hardware Interrupt 1ine 5 * / / • hardware Interrupt l i n e V  typedef s t r u c t { / * memory block information record * / unsigned char *ptr; / • pointer to block •/ unsigned int segment, o f f s e t ; / * 8088/8086 segment-offset of b l o c k ' s s t a r t i n g address" ' / unsigned char lowaddr. hlghaddr, page; / " 8237A DMA paged-memory form of b l o c k ' s s t a r t i n g address, lowaddr and highaddr ere the low and high bytes for the DMA s t a r t address; the page r e g i s t e r (of the DMA channel) in the IBM PC is loaded with the value of page. V unsigned char lowcount, highcount; / • low and high bytes of block s i z e */  Figure E.78: Header Files (continued)  144  Appendix E. Notes on the Automated Network Driver Program  /•  unsigned Int s i z e ; / * s i z e of block in bytes •/ unsigned Int frame_1en; / • actual s i z e of block •/ ) address; Richard Cam 93533827  fdeflne fdeflne fdeflne fdeflne fdeflne fdeflne fdeflne  Routines for simple appl Icat1on-layer commands. Header f i l e : m l d u t i l . h System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C version 1.5 w/ Compact memory model V e r s i o n : 2.1 10 June 1988  N0_0PERATI0N 0 / * nop • / PR0GRAM_TX 1 / • command code for program transmission parameters CHANGE_IA 2 / ' . . . for remote i n d l v . address change V CHANGE_C0NF1G 3 / • " . . . for remote c o n f i g u r a t i o n parameter change GET_STATS 4 / • command code for t x / r x s t a t i s t i c s fetch bperation START_TX 5 I' ... for I n i t i a t i o n of transmission session •/ AB0RT_TX 6 I' ... for forced termination of transmission session  V */ •/ •/  typedef s t r u c t { unsigned Int s r c _ a d d r t 6 J , dest_addr16], configurat1on[10]; unsigned 1nt d e l a y , d u r a t i o n ; unsigned int frame_len; unsigned long good_tx, bad_tx, good_rx, bad_rx; unsigned long co 111s 1on9[ 17 ) , d e f e r s , l o s t _ c t s , l o s t _ c r s , under_runs; unsigned long buffer_overflows; unsigned long c r c _ e r r s , s r t _ f r m s , a l g _ e r r s , no_eofs, over_runs; ) stats_record; v o i d c l e a r _ s t a t 1 s t i c s ( s t a t s _ r e c o r d ' s t b l k ); / * c l e a r performance data part of s t a t i s t i c s block  V  v o i d program_tx ( Int master. Int destO. int d e s t l , Int dest2, int dest3, Int dest4, int dest5. unsigned Int tx_durat1on, unsigned int delay_per1od, unsigned int Info_f1eld_len, Int targO, Int t a r g t , int targ2. int targ3, int targ4, int targ5 / ' remote-programs the repeated-transmission parameters of a node V void change_1a /•  changes  ( 1nt int int the 82588  master, int destO, Int d e s t l , int dest2, int dest3, int dest4, dest5, int new_iaO, Int new_ia1, int new_ia2, int new_ia3, new_ia4, Int new_ia5 ); 1ndiv. address of another node * /  v o i d change_conf1g  / * changes  ( int master, Int destO, int d e s t l , Int dest2, int dest3. int dest5, int confO, int c o n f l , int conf2, int conf3, int conf4. int conf5, int confB. int conf7, 1nt confS, int conf9 ); the 82588 c o n f i g u r a t i o n of another node V  v o i d g e t _ s t a t s ( int master, int destO. int d e s t l , 1nt dest2, Int dest5, s t a t s _ r e c o r d "tx_rx_stats ); / * fetches s t a t i s t i c s from another node * / void s t a r t _ t x  );  ( 1nt destO,  1nt d e s t l ,  int dest2,  int dest3.  int dest3,  int dest4.  Figure E.79: Header Files (continued)  int dest4,  int dest4.  145  Appendix E. Notes on the Automated Network Driver Program  /*  initiates  Int dest5 ); repeated-transmission sequence of other node(s)  •/  void abort_tx ( int destO, int d e s t l , int dest2, int dest3, int dest4, int dest5 ); / * h a l t s repeated-transmission session of other node(s) */ void pr1nt_screen ( s t a t s _ r e c o r d tx_rx_stats ); / * p r i n t s contents of s t a t i s t i c s block to console  */  v o i d pr1nt_f11e ( FILE ' f i l e p t r . s t a t s _ r e c o r d tx_rx_stats ); / • p r i n t s contents of s t a t i s t i c s block to an output f i l e V /• Richard Cam 93523827 Routines for 82588 Operations and Events. Header f i l e : opevents.h System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C v e r s i o n 1.5 w/ Compact memory model V e r s i o n : 2.1 06 June 19B8 V • d e f i n e LAN_CTRLR 0x300  / * I/O port address of 82588  V  •define fdefine fdefine fdefine fdefine #def1ne fdefine  DONE 1 / * f l a g value: operation was acknowledged by 82588 V PENOING 0 / • f l a g value: acknowledgement pending •/ PASSED 2 / • f l a g value for diagnose-passed event •/ FAILED 3 / * f l a g value for d i a g n o s e - f a i l e d event */ SUCCESSFUL 4 / * f l a g value for successful transmission •/ COLLISION 5 / • f l a g value for c o l l i s i o n during transmission •/ N0T_0K 6 / • f l a g value for unsuccessful transmission not caused by a co111s ion •/  fdefine fdefine fdefine fdefine fdefine fdefine fdefine fdefine fdefine fdefine  NOP 0 / • 4 - b i t operation f i e l d code for no-operation command IA_SETUP 1 / • . . . c o d e for ia-setup command • / CONFIGURE 2 / • . . . c o d e for configure command • / TX 4 / • . . . c o d e for transmit command * / DUMP 6 / * . . . c o d e for dump command V DIAGNOSE 7 / • . . . c o d e for diagnose command V RCV_ENABLE 8 / " . . . c o d e for enable r e c e i v e r command • / RCV_DISABLE 10 / • . . . c o d e for d i s a b l e r e c e i v e r command V ST0P_RCV 11 / • . . . c o d e for stop r e c e i v e r command V RETX 12 / * . . . c o d e for retransmit command * /  fdefine fdefine fdefine fdefine fdefine fdefine fdefine fdefine fdefine  IA_SETUP_DONE 1 / • 4 - b i t event f i e l d code for 1a_setup-done event CONFIGURE_DONE 2 / ' . . . c o d e for configuration-done event V TRANSMIT_D0NE 4 / • . . . c o d e for transm1t-done event •/ DUMP_D0NE 6 / • . . . c o d e for dump-done event V DIAGN0SE_PASSED 7 / • . . . c o d e for diagnose-passed event */ ENO_0F_FRAME 8 / * . . . c o d e for end-of-frame event V RECEPTI0N_AB0RTED 10 / • . . . c o d e for reception-aborted event •/ RETRANSMIT_D0NE 12 / • . . . c o d e for retransm1t-done event •/ DIAGNOSE_FAILED 15 / • . . . c o d e for diagnose-fa 1 led event V  f d e f i n e CHNL_588_0 0x00 f d e f i n e CHNL_588_1 0x10 typedef  V  / • 1-bit CHNL f i e l d to s e l e c t channel 0 of 82588 / * . . . c h a n n e l 1 of 82588 V  void i n t e r r u p t (* 1 n t r f n _ p t r ) ( ) ;  Figure E.80: Header Files (continued)  V  V  146  Appendix E. Notes on the Automated Network Driver Program  typedef  / ' 1ntrfn_ptr <--> p o i n t e r to an Interrupt function •/ intrfn_ptr *ptr_intrfn_ptr; / • p t r _ 1 n t r f n _ p t r <--> p o i n t e r to Interrupt function p o i n t e r  void Install /•  ( 1ntrfn_ptr newhandler, unsigned 1nt int_num, 1ntrfn_ptr 'oldhandler ); save o l d Interrupt vector of table entry int_nura and replace new Interrupt vector •/  1t with  v o i d Interrupt event_handler (); / • 82588 i n t e r r u p t handler •/ v o i d setup_1a_588 ( address 1a_buff. address dump_buff I; / • set up and v e r i f y 82588 i n d i v i d u a l address V v o i d conf1gure_588 ( address conf1g_buff. address dump_buff ); / • configure and v e r i f y 82588 c o n f i g u r a t i o n •/ v o i d dump_588 ( address dump_buff ); / • dump 82588 r e g i s t e r s •/ v o i d d1agnose_588 (); / • run i n t e r n a l 82588 diagnosis  test  V  v o i d rcv_enable_588 (); / • enable 82588 r e c e i v e r and prepare f i r s t r e c e i v e buffer v o i d rcv_d1sable_588 ( ) ; / * immediately d i s a b l e 82588 r e c e i v e r  */  */  void stop_rcv_588 ( ) ; / • d i s a b l e 82588 r e c e i v e r as soon as no frame is being received v o i d quiet_transmit_588 ( address tx_buff / • no-screen-echo v e r s i o n of transm1t_588  ); •/  void qu1et_process_frames ( 1nt master ); / * no-screen-echo v e r s i o n of process_frames v o i d transm1t_588 ( address tx_buff / • transmit frame * /  •/  •/  );  v o i d process_frames ( Int master ); / * process r e c e i v e d frames ( i f any) */ /• Richard Cam 93523827 Timer U t i l i t i e s Header f i l e : s y s c l o c k . h System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C v e r s i o n 1.5 w/ Compact memory model V e r s i o n : 2.1 10 June 1988  Figure E.81: Header Files (continued)  .*/  Appendix E. Notes on the Automated Network Driver Program  v o i d pause ( Int master, unsigned Int i n t e r v a l ); / * pause for Interval seconds ( and continue to process  147  Incoming frames).  void delay ( unsigned int i n t e r v a l ); / * delay for Interval for loops */ v o i d start_t1me ( unsigned 1nt / • I n i t i a l i z e the timer •/  interval  );  long t1me_up ( ); / • check If i n t e r v a l seconds have elapsed, r e t u r n -1 i f i n t e r v a l seconds have not yet elapsed, r e t u r n the excess seconds otherwise */ I'  Richard Cam 93523827  V fdeflne fdefine fdefine fdefine fdefine fdeflne fdefine  U t i l i t y Routines for DMA/Interrupt Operations. Header f i l e : s y s u t l l . h System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C v e r s i o n 1.5 w/ Compact memory model V e r s i o n : 2.1 06 June 1988  DMA_MASK OxOA FLIPFLOP OxOC CH1_ADDR 0x02 CH1_C0UNT 0x03 CH3_AD0R 0x06 CH3_C0UNT 0x07 0MA_M0DE OxOB  f d e f i n e CH1_PAGE 0x83 f d e f l n e CH3_PAGE 0x82 f d e f i n e CH1_TX 0x49 f d e f l n e CH1_RX 0x45 f d e f l n e CH3_TX 0x4B f d e f l n e CH3_RX 0x47  / • 8237A s i n g l e mask r e g i s t e r •/ / • 8237A f i r s t / l a s t byte pointer f l i p - f l o p V / • 8237A channel 1 base address r e g i s t e r •/ / • 8237A channel 1 block length r e g i s t e r V / • 8237A channel 3 base address r e g i s t e r •/ / • 8237A channel 3 block length r e g i s t e r •/ / • 8237A mode r e g i s t e r V / • page r e g i s t e r / * page r e g i s t e r  /• /• /* /*  memory-to-I/O I/O-to-memory memory-to-I/O I/O-to-memory  in PC for channel 1 in PC for channel 3  transfer transfer transfer transfer  on on on on  f d e f l n e MASK_CHANNEL_1 0x05 / * mask channel 1 f d e f l n e UNMASK_CHANNEL_1 0x01 / * unmask channel f d e f l n e MASK_CHANNEL_3 0x07 / • mask channel 3 f d e f i n e UNMASK_CHANNEL_3 0x03 / • unmask channel f d e f i n e 0CW1 0x21  / • 8259A mask r e g i s t e r  channel channel channel channel  V 1 V 3  1 1 3 3  V */ */ •/ */ */  •/ V  •/  f d e f i n e B0AR0_P0RT 0x301 / ' I/O address of StarLAN board enable port * / f d e f l n e ENABLE_ALl_ OxFF / * enables a l l board functions '/ void disable_dma ( unsigned int dma_channel ); / * d i s a b l e dma channel * /  Figure E.82: Header Files (continued)  148  endix E. Notes on the Automated Network Driver Program  v o i d prep_dma ( address b u f f e r , unsigned char dma_channe1, unsigned char d i r e c t i o n / * prepare dma channel for transmission or r e c e p t i o n •/  );  v o i d quiet_prep_dma ( address b u f f e r , unsigned char dma_channel, unsigned char d i r e c t i o n / * prepare dma channel for transmission or r e c e p t i o n •/ / ' no screen echo version •/ void 1n1t_pic ( unsigned int i n t e r r u p t _ l i n e ); / * I n i t i a l i z e programmable Interrupt c o n t r o l l e r v o i d enable_board ( ) ; / * enable a l l functions  in the I n t e l  •/  82588 StarLAN board  V  Figure E.83: Header Files (continued)  );  Appendix E. Notes on the Automated Network Driver Program  Richard Cam 93523827 Master D r i v e r Program for 82588 StarLAN Network. Source f i l e : run 1m.c System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C version 1.5 w/ Compact memory model V e r s i o n : 1.0 24 June 1988  flnclude •Include #Include (Include Unclude (Include (define  <stdio.h> / • standard I/O l i b r a r y •/ "globals.h" / * g l o b a l d e f i n i t i o n s V "opevents.h" / • Interrupt handler & loader: 82588 commands "mldut 11 .h" / * remote programming c a l l s •/ "autout 11 .h" / * l o c a l c o n t r o l c a l l s •/ "sysclock.h" / • timer c a l l s */  •/  MASTER 100  extern s t a t s _ r e c o r d s t a t s _ b l k , saved_stats_blk; extern Int repeat_transm1ssions; stats_record  foreign_stats;  unsigned int ia_block[ IA_BUFF_SIZE J = { 8, 0, 1, 1, 0, 0. 0, 0 ); unsigned 1nt conf1g_b1ock[ C0NFIG_BUFF_SIZE ] = ( 10, 0. 0x08. 0x00, 0x28. 0x00, 0x60, 0x00. 0xF2, 0x04, 0x88. 0x40 }; FILE ' f i r o u t f i l e . •secoutflle. unsigned 1nt 1, j ; main( ) ( p u t s ! ' Run puts!"  'thloutf11e;  #1: r i n g pattern tx data for 50 In 50-byte increments . \ n " ) ;  1500-byte i n f o ,  f i r o u t f i l e = fopenl"run 1m.mOI", ' i f s e c o u t f l l e = fopenl"run 1m.s03", wt" t h l o u t f l l e = fopenl "run 1m.s04", ' i f 1nit_node(); i f ( MASTER ) ( for ( j = 0; j < 10; j*+) { for (1 = 50; 1 <= 1500; 1 •= 50) { program_tx( MASTER, 1, 3, 0. 0, 0. 0. 300, 0, program_tx( MASTER, 1, 4. 0. 0, 0, 0. 300, 0, program_self_tx( 300, 0 i . 1. 3. 0, 0, 0, 0 s t a r t _ t x ( OxFF, OxFF. OxFF, OxFF. OxFF, OxFF ); 3 t a r t _ s e l f _ t x ( MASTER ); g e t _ s t a t s ( MASTER, 1, 3, 0. 0. 0, 0, 8foreign_stats pr1nt_screen( fore1gn_stats ); print_f11e( s e c o u t f i l e , f o r e i g n _ s t a t s ); g e t _ s t a t s ( MASTER, 1. 4, 0, 0, 0, 0. &foreign_stats p r i n t _ s c r e e n ( f o r e i g n _ s t a t s ); p r i n t _ f i l e ( t h i o u t f i l e , fore1gn_stats ); pr1nt_screen( saved_stats_b1k ); p r i n t _ f i l e ( f i r o u t f i l e , saved_stats_blk );  )  )  )  puts! " » > End of runlm. ");  )  Figure E.84: Sample Master Program  fields  \n");  0, 0,  ); );  0. 0,  150  Appendix E. Notes on the Automated Network Driver Program  Richard Cam 93523827 Slave Oriver Program for 82588 StarLAN Network. Source f i l e : run1s3.c System: IBM P C ' s , compatibles, and v a r i a n t s thereof. Compiler: Turbo C version 1.5 w/ Compact memory model V e r s i o n : 1.0 25 June 1988  •I  (Include (Include (include (include linclude (Include (define  <std1o.h> / * standard I/O l i b r a r y •/ "globaIs.h" / • global definitions */ "opevents.h" / • i n t e r r u p t handler & loader; 82588 commands "midut11.h" / * remote programming c a l l s 'I "autout11.h" / • local control c a l l s */ "sysclock .h" / • timer c a l l s */  */  MASTER 0  extern s t a t s _ r e c o r d s t a t s _ b l k , saved_stats_b1k; extern 1nt repeat_transm1ss1ons; stats_record  J  fore1gn_stats;  unsigned Int 1a_block[ IA_BUFF_SIZE ) = { 6 . 0 , 1, 3 , 0 , 0 , 0 , 0 ) ; unsigned 1nt conf1g_block[ CONFIG_BUFF_SIZE 1 = ( 10, 0, 0x08. 0x00, 0x26. 0x00, 0x60. 0x00, 0xF2, 0x04. 0x88. 0x40 ): Int  1;  main!) { putst" Slave Program (1: for use with a runtm m a s t e r . \ n " ) ; puts!" S t a t i o n Number 1 3 0 0 0 0 , \ n " ) ; 1n1t_node(); If ( MASTER == 0 ) { 1 = 0; for ( ; ; ) { process_framesl MASTER ); if ( repeat_transm1ss1ons ) {  )  )  )  p r 1 n t f ( " \ n repeated tx session number: %d.\n",  1 );  do s1ave_tx( MASTER );  de1nit_node(); puts!" » > End of Slave Program (1 for s t a t i o n  1 3 0 0 0  )  Figure E.85: Sample Slave Program  0.");  Appendix E, Notes on the Automated Network Driver Program  Sample O u t p u t F i l e ( p a r t o f r u n l m . m O l ) : E a c h ' p a r a g r a p h ' o f numbers c o r r e s p o n d s t o d a t a f o r one PC f r o m a t r a n s m i s s i o n s e s s i o n .  1 1 0 0 0 0 8 0 38 0 96 0 242 1 3 0 0 0 0 300 50 0 40156 253 39966 0 28869 0 0 0 253 126 49 8 0 1 0 0 0 0 0 0  4  0  136  0  0  1 1 0 0 0 0 8 0 38 0 96 0 242 4 136 1 3 0 0 0 0 300 100 0 37649 23 37749 0 26309 0 0 0 23 12 4 1 0 0 0 0 0 0 21 0 0 0 0 0 1 1 0 8 0 38 1 3 0 300 150 35556 0 20456 0 0 0 0 19 0 0 0  0  1 1 0 8 0 38 1 3 0 300 200 33934 0 11994 0 0 0 0 17 0 0 0  0  0  0  0 0 96 0 0 0  0 35657 0 0 0 0 0 0 0 0  0  0  4  0  136  0  0  0  0  0  0  0  0  0  0  0  64  0  64  0  0  0  0 0 96 0 0 0  0 34034 0 0 0 0 0 0 0 0  242  64  242  0  4  0  136  0  0  64  0  0  Figure E.86: Sample Output File  Bibliography  [1] Costrell, L . , Dawson, W . K . , " F A S T B U S Modular High-Speed D a t a Acquisition System", repr. from I E E E Int'l Conf. on Communications, I C C '82, June 13-17, 1982, Phila., P A . [2] Costrell, L . , Dawson, W . K . , " F A S T B U S for D a t a Acquisition and Control", IEEE  Trans, on Nuclear Science, V o l . NS-30, No. 4, August 1983.  [3] IEEE Standard FASTBUS Modular Data Acquisition and Control System, I E E E Inc., 1985. [4] personal communication from David Gustavson to W . K . Dawson and R . W . Dobinson, 31 July 1987 electronic mail.  [5] 802.3-1985 (ANSI/IEEE)  Networks:  (Draft International  Standard) Standard for Local Area  Carrier Sense Multiple Access with Collision Detection  (CSMA/CD),  I E E E Standards Catalog (Fall 1988) order number SH09738.  [6] 802.3a,b,c and e - 1988 (ANSI/IEEE)  Supplements to Carrier Sense Multiple Access  with Collision Detection (CSMA/CD)  Access Method and Physical Layer Specifica-  tions, I E E E Standards Catalog (Fall 1988) order number SH11411.  [7] Golbert, A . , Gandhi, S., Implementing StarLAN with the Intel 82588, Intel Application Note AP-236, Intel Corp., 1986. [8] Derfler Jr., F . , " M a k i n g Connections: Fast Performance over Telephone W i r e " , PC  Magazine, V o l . 7, No. 15, 13 Sept. 1988. 152  Bibliography  153  [9] 82588 Design Kit Users Guide, Order Number 296098-001, Intel Corp., 1986. [10] Local Area Networking (LAN)  Component User's Manual, Order Number 230814-  003, pp. 6-1 to 7-60, Intel Corp., Sept. 1985. 11] Retix, 1547 N i n t h St., Santa Monica, C A 90401, U . S . A . , phone: (213) 829-4922. 121 W D 8 3 C 5 1 0 S t a r L A N Hub Controller, Document Number 79-000104, Western Digital Corporation, 1987. 13] Gustavson, D . , Theus, J . , " W i r e - O R Logic on Transmission Lines", IEEE Micro, June 1983. 14] W i l s o n , R . , " T h e Physics of Driving Backplane Buses", Microprocessors and Mi-  crosystems, V o l . 10, No. 2, March 1986. 15] Southard, R . , "Interconnection System Approaches for Minimizing D a t a Transmission Problems", Computer Design, March 1981. 16] Blood Jr., W . , MECL System Design Handbook, 4th ed., 2nd printing, Motorola Inc., 1983. 17] D e l Corso, D . , et al., Microcomputer Buses and Links, Academic Press, 1986. 18] Mokhoff, N . , "Transceiver Does Away W i t h Central Hub i n S t a r L A N " , Electronic  Design, June 25, 1987. 19] personal communication with Ray Duley ( A M D Austin, Texas). 20] Hammond, J . , O'ReiLby, P., Performance Analysis of Local Computer Networks, Addison-Wesley, 1986. pp. 381-390. [21] Ibid., pp. 390-401.  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0085036/manifest

Comment

Related Items