| Platform Notes: The SunHSI/P Device Driver |
|
| Platform Notes: The SunHSI/P Device Driver |
|
| A P P E N D I X A |
hsip_init Options |
This appendix provides more information about using the hsip_init utility to accommodate differing T1 or CEPT transmission equipment. It also describes the operating modes you can set using hsip_init . Refer to the hsip_init man page for more information about using this command.
The version of the hsip_init command shipped with the SunHSI/P software has options that enable you to invert data and clock signals to accommodate the requirements of T1 or CEPT transmission equipment.
The hsip_init parameters that enable for inversion are:
txd - transmit data signal
rxd - receive data signal
txc - transmit clock signal
rxc - receive clock signal
When these parameters are at their default settings, the SunHSI/P software does not invert the data or clock signal controlled by the parameter. To invert a signal, you specify a setting of the form param_name=-paramname , for example, txc=-txc .
As an example, suppose you want to invert the transmit and receive data signals on the first SunHSI/P port (port 0) on the second SunHSI/P adapter in your system. To do so, enter the following command:
To invert both clock and data signals, you would type:
The following section discusses the background and requirements for these inverted settings. The reason for inverting data signals is distinct from the reason for inverting clock signals.
The requirement for inverting data signals arises from the "ones density" problem you encounter with most T1 transmission lines in North America. The T1 transmission scheme uses a signaling mechanism known as Alternate Mark Inversion (AMI), in which one bits are represented by a positive or negative pulse, while zero bits are represented by the absence of a pulse. In this scheme, the polarity of each pulse must be the opposite of the polarity of the pulse that immediately preceded it. This signaling scheme makes it possible to embed a reference clock for the data into the data stream itself.
Various types of T1 transmission equipment, such as Data Service Units (DSU), Channel Service Units (CSU), repeaters, and various telephone central office equipment, must be able to keep a phase locked loop (PLL) circuit locked on to this reference clock. This PLL circuit uses the pulses generated when one bits are transmitted to lock the embedded clock to a local reference oscillator. To keep the PLL circuit locked on the extracted clock, a certain density of pulses (one bits) must be guaranteed. For North American T1 lines, the density requirement dictates that at least one out of every 16 bits must be a one (see AT&T Technical Publication 62411 ). In other words, no more than 15 consecutive zero bits can occur anywhere in the data stream.
T1 lines were originally intended to carry voice traffic, wherein the digitized voice signals could be altered to meet the ones-density requirement by forcing every eighth bit of a voice channel to be a one. This practice introduces a small--but virtually inaudible--amount of distortion in the voice signal. Digital data streams between two computers are another matter, since the corruption of even one data bit causes a packet to be rejected. Note that in a typical data packet, it is quite easy to produce bit patterns that violate the ones-density requirement. A random file could easily contain a sequence of bytes that would produce 16 or more consecutive zero bits if transmitted serially.
There are many different schemes for circumventing the ones-density requirement. The most common technique simply reserves every eighth bit of the signal for a "density bit" and forces this bit to be a one. Obviously, these bits are not available for data transmission, which means that 12.5 percent of the bandwidth of the T1 line is wasted. When you consider that the lease cost for a coast-to-coast T1 line can be exceedingly expensive, this waste of bandwidth can be unacceptable.
There are other alternatives. One of them uses a special code that transmission equipment can generate when using the AMI signaling scheme. This special code depends on the fact that two successive one bits that are represented by pulses of the same polarity result in a signal known as a "Bipolar Violation." A CSU can be designed so that it will automatically replace any string of eight consecutive zeros with a special code pattern that contains two of Bipolar Violations. A compatible, receiving CSU recognizes this special code and converts it back to a pattern of eight zeros. This technique is known by the acronym B8ZS, which stands for Bipolar with 8-Zero Substitution.
All CEPT lines (the European equivalent of T1) mandate the use of a variant of B8ZS that holds the density requirement down to no more than three consecutive zeros. However, telephone companies in North America have been slow to adopt B8ZS, because it would entail a significant capital investment. Therefore, the B8ZS solution will not solve the ones-density problem in the short term.
An alternative to B8ZS--an alternative used by the SunHSI/P product--makes use of the fact that the HDLC framing rules, which specify that any data stream that contains five or more consecutive one bits requires that the transmitting end insert a zero bit after the fifth one bit. This guarantees that the HDLC flag pattern, 01111110 (hex 7E), does not occur randomly inside a frame. The receiving end must automatically discard the zero bit that follows a pattern of five consecutive ones. So, the HDLC framing used by the SunHSI/P software guarantees that in any set of six bits, at least one bit will be a zero (except for the flag pattern). If you include the flag pattern, you can say that in any set of seven bits, at least one bit will be a zero.
By inverting the data signal with HDLC framing on both ends of a link, the HDLC zero insertion algorithm becomes a ones insertion algorithm. This guarantees that in any set of seven bits, at least one bit will be a one. Thus, the HDLC data stream meets the density requirements of North American T1 lines without sacrificing any bandwidth.
The need to invert clock lines is separate from the need to invert data lines. Most computer, modem, and terminal vendors adhere to an industry standard specification known as RS-334. This specification defines the relationship between a data bit and a reference clock on a synchronous serial link. The specification also says that a device should transmit data with reference to the rising edge of the clock signal and that data should be received with reference to the falling edge of the clock signal.
When using long cables or cables not carrying a clock signal, a phase shift may occur, causing a high number of errors. In such cases, inverting the clock signal may correct the phase shift. You may also need to invert the clock signal when connecting a SunHSI/P port to equipment not adhering to the RS-334 standard.
The SunHSI/P driver operates in two main operating modes: the high-level data link control (HDLC) mode and the IBM (SDLC) mode. The HDLC mode always operates in a full-duplex, point-to-point fashion. While the IBM mode defaults to a full-duplex, point-to-point, operation, you can also set this mode to be either a half-duplex or a multi-point operation.
The default operating mode used by the SunHSI/P driver is the HDLC full-duplex protocol ( mode=fdx ). In this mode, the transmitter is always enabled, and it sends flag bytes continuously when it is not sending a data frame.
If no message is currently being transmitted, the driver attempts to start sending its next message. At this point, the driver indicates that it is busy transmitting to prevent the transmission of another message concurrently. The driver also activates a mechanism that ensures that the transmit operation will not hang if the hardware is not responding.
When the transmission is completed, the busy mechanism previously set is cleared and the next message can be transmitted. If the transmission is hung, an abort sequence is sent instead of the cyclic redundancy check (CRC) so that the receiver will not interpret the frame as valid data. The message is discarded, and the output error statistic is incremented, which allows for a proper recovery by higher level protocols.
The received data is buffered until a complete frame has been received. If any error occurs during the reception of a frame, the appropriate statistic is incremented and the frame is discarded.
This mode is designed to support IBM system network architecture (SNA) communications. It uses most of the same protocols used in HDLC mode, with two major exceptions:
When the SunHSI/P software is set to this mode ( mode=ibm-fdx ), the software uses a full-duplex point-to-point communication protocol. Both ends of the link are expected to have RTS and CTS signals asserted at all times when data is being exchanged. When starting a message transmission, the interface raises the RTS signal and expects the CTS signal to be asserted immediately. If this is not done, all messages currently queued for transmission are discarded, and the write operation returns an error.
If the CTS signal drops before the frame transmission is complete, the frame is discarded and the abort error statistic is incremented. If the transmission underruns, an abort sequence is not sent and the frame is silently discarded. The RTS signal remains asserted until the data transmission is complete.
Half-duplex is a sub-mode of the IBM mode ( mode=ibm-hdx ). Half-duplex mode operates in the same manner as full-duplex mode, except that transmission cannot occur while receiving, and vice versa. When a transmission is completed, the RTS signal is dropped. Dropping the RTS signal tells the remote station to begin transmitting if needed.
In a multi point configuration ( mode=ibm-mpt ), more than two stations "share" a link. This configuration designates one station as a primary station and the rest as secondary stations. In this mode, the port acts as a secondary station. The primary station arbitrates traffic on the link by polling the secondary stations, asking them all if they are ready to transmit.
If a secondary station has data to transmit, it will raise its RTS signal and check for CTS signals. When a CTS signal comes up, the station may begin transmitting, following the same rules for RTS and CTS signals used in half-duplex mode. When the transmission is complete, the secondary station drops the RTS signal, which enables another station to respond to a poll and begin transmitting. The RTS signal cannot be dropped until the transmission is complete.
| Platform Notes: The SunHSI/P Device Driver | 816-2346-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.