« Applescript Studio Applications | Main | Business »
April 3, 2005
Network Innovations
Wireless Networking and The AirPort
Apple and Lucent redefine easy networking with the AirPort, and 802.11
About the author(s)...
John Welch <jwelch@aer.com> is the Mac and PC Administrator for AER Inc., a weather and atmospheric science company in Cambridge, Mass. He has over fifteen years of experience at making computers work. His specialty is figuring out ways to make the Mac do what nobody thinks it can .
Welcome
This article covers Apple’s AirPort, the wireless networking system introduced in July at MacWorld Expo, as well as the standards and technology behind the AirPort. Along the way, we’ll look at other wireless networking schemes and products, to see how they stack up against the AirPort. We’ll start with a basic introduction to the AirPort, and its connection to the iBook, and to other members of the Macintosh family. We will also go into a basic history of wireless networking, as it pertains to the AirPort and the 802.11 standard. We’ll also take a close look at the 802.11 standard itself, and some of the work Lucent Technologies has done to get the speed and capabilities that now exist out of that standard. Next we’ll take a look at some of the power management and other features that are integral to the Lucent work. Then we’ll look at the AirPort itself, and see how Apple has applied their philosophy of “It just works” to wireless networking. Finally, we’ll compare the AirPort and 802.11 to some of the other wireless networking schemes.
Airport Introduction
The biggest news to come out of the New York MacWorld was the iBook, and its wireless networking capabilities. Although I have no doubt the iBook will become as much a success as the iMac, I think the really astounding part of this announcement was the AirPort, Apple’s release of an 802.11-compliant wireless networking system. The AirPort is a one-stop wireless networking system that runs at common Ethernet speeds. It is cheap enough to become an impulse buy for iBook, and other Mac customers.
Now for the iBook, the AirPort is a great enhancement. The iBook’s card, which, in classic Macintosh fashion, is insanely easy to install, is about a hundred bucks; then add about 300 bucks for the AirPort Pod, which is the base station for AirPort-enabled Macs; a person or company can set up a fast, reliable, easy to use and maintain wireless network in relatively short order. Even for other Macs, the AirPort is as much of a blessing. With PC cards available, and more on the way from Apple and other vendors, such as Farallon, and PCI cards for the tower and desktop Macs, even non-iBooks can take full advantage of the AirPort. (Although not mentioned, I’ll hazard two predictions about the iMac. The first is that we will be quickly seeing a USB-connected AirPort device, and the second is the iMac will eventually have AirPort networking built-in.)
The extra plum in this bowl is the IEEE 802.11 wireless networking standard. Since the AirPort is based on this standard, any computer with an 802.11-compliant interface device can plug into the AirPort network with no more trouble than connecting Macs and PCs or Unix workstations via conventional Ethernet. So much of the AirPort technology is based on the 802.11 standard, we shall go into the history of 802.11 devices and the details of the standard itself.
The IEEE 802.11 Specification
Let’s start with some background information on the foundation for the AirPort, the IEEE 802.11 standard. This standard, , defines the way that 802.11-compliant devices communicate with each other. It operates at the physical, or hardware layer, and the Media Access Control, or MAC layer. It is not concerned with TCP/IP or AppleTalk, but rather the underpinnings. 802.11 defines wireless networking across a number of bands, or frequencies. These frequencies, in the Industrial, Scientific, and Medical, or ISM bands, range from just over 900MHz to approximately 5.8 GHz. The ISM bands were chosen because of their worldwide availability. In practice, due to differences of availability worldwide, 802.11 is primarily concerned with the 2.4 to 2.5 GHz bands. The differences in band availability, power usage, and modulation rules in various parts of the world are shown below in Table 1.
Table 1. Frequency bands and power levels for wireless LANs.
|
Countries |
Frequency range |
Maximum RF power level |
Rules for DSSS and FHSS |
|
U.S., Canada,1 and Latin America (FCC Part 15,247) |
902–928 MHz 2,400–2,483.5 MHz 5,750–5,850 MHz |
1W (at ERP,2 and maximum 6 dBi antenna gain) |
DSSS: Receiver processing gain >10 dB FHSS: 75 hops or more |
|
Europe ,3 (ETS,4 300 328) |
2,400–2,483.5 MHz |
100 mW (at EIRP,5) |
DSSS: Power spectrum density maximum 10 mW/MHz FHSS: 20 hops or more |
|
Japan (MPT ,6Ordinances 78 and 79) |
2,471–2,497 MHz |
Not specified |
DSSS/FHSS: Power spectrum density maximum 10 mW/MHz |
|
Australia |
2,400–2,450 MHz |
500 mW |
|
1) In Canada, not the 5,750–5,850-MHz band
2) In France/Spain, only the 2,445–2,483.5/2,475-MHz band
3) ERP-Effectively radiated power
4) EIRP-Equivalent isotropically radiated power
5) ETS-European Telecommunication Standard
6) MPT-Ministry of Posts and Telecommunications (in Japan)
As we can see, the 2.4 GHz band is the only one implemented worldwide. The 802.11 standard only is concerned with the MAC and physical layer parts of wireless networking. For those of you unfamiliar with the layers of networking, in general, a complete network stack, or system, is visualized as having up to seven layers. Each layer sits on top of the other, and receives information from the layers above and below, and passes information the same way. The MAC layer sits on top of one or more physical layer systems, as shown below in Figure 1.
Figure 1 The physical layers handle the actual connections and transmitting/receiving of electrical or optical signals that represent data.
802.11 Physical Layer
The physical layer of 802.11 is where the bits hit the wire. It is concerned with how transmission and reception of data happens, and how data is encoded into the corresponding RF signals by the transmitter, and decoded by the receiver. There are three implementations of 802.11: Infrared (IR), Frequency Hopping Spread Spectrum (FHSS), and Direct Sequence Spread Spectrum (DSSS). The IR implementation uses infrared light to move data, much like a television remote, and the last two are radio frequency, (RF) implementations.
Infrared - IR
The IR 802.11 implementation is based on diffuse IR. Rather than trying to line up the transmitter and receiver, like a television and its remote, an IR-based 802.11 device transmits a wideband, or diffuse signal at the ceiling, which reflects the data around the area until it reaches its destination. Likewise, incoming data is bouncing off the ceiling. While better than narrow-beam IR, this implementation can only be used indoors, and requires the ceiling to be reflective to its wavelength, which is in the 850 to 950 nm range. In addition to the ceiling material requirements, 802.11 IR only has a range of about 10 meters, which makes it suitable for a small room, say, such as a work area with an IR-enabled printer.
802.11 IR supports 2 data rates, 1Mbps and 2 Mbps. At the 1Mbps rate, the data stream is broken into quartets. Each quartet is then encoded into one of sixteen pulses during modulation and transmitted. This modulation technique is called 16 Pulse Position Modulation. At the 2Mbps rate, the modulation is somewhat different, with the data stream being divided into data bit pairs, and each pair being modulated into one of 4 pulses.
Frequency Hopping Spread Spectrum - FHSS
FHSS systems break up the total bandwidth into narrower sub–bands, or channels, and hop from channel to channel during transmissions. As the signal hops, it sends a packet at one frequency, then hops to the next channel, and sends another packet, and so on. The FHSS signal dwells on each band a predetermined amount of time. In the case of 802.11, the time is up to 300msec. The hopping sequence is pseudo-random, (computers can’t generate true random sequences, but they can come very close, hence the term pseudo random.) The sequence and pattern of the frequency hops are partially determined by the geographical location. For example: Japan specifies three sequences with four patterns, Spain specifies three sequences with nine patterns, France specifies 3 sequences with eleven patterns, and the U.S. and the rest of Europe use three sequences with 26 patterns. This frequency-hopping also has the serendipitous side-effect of assisting with the collision avoidance process. Since the signal is transmitted on any given channel for a fairly short period of time, collisions happen less often. Within the overall bandwidth are a number of 1MHz wide channels, the number of which depends on the locality of the system. In Japan, there are 23 of these channels between 2.473GHz and 2.495GHz, whereas in the U.S. there are 79 channels between 2.402GHz and 2.48GHz. Another important item in the FHSS algorithm is all available channels must be used before a repeat use of a channel. The FHSS transmitter converts the bitstream from the transmitting device to a symbol stream, where each symbol represents one or more bits. The signal is modulated via a Frequency Shift Keying (FSK) method, with the specific type of FSK depending on the number of modulating frequencies desired. If two modulating frequencies are used, then binary FSK is used, and if four frequencies are used, then quaternary FSK is used. This FSK-modulated signal is what hops frequencies during the data transmissions and receptions. 802.11 FHSS uses a third type of FSK modulation, Gaussian FSK. Finally, although the Gaussian FSK used by 802.11 FHSS gives higher bitrates in its channels, it has more sensitivity to noise and other poor conditions. (Interesting historical tidbit: Spread Spectrum using frequency hopping was invented in 1940 by actress Hedy Lamarr when she was 26.)
Direct Sequence Spread Spectrum - DSSS
The final 802.11 physical implementation is DSSS. This is the implementation used by Apple, Lucent, Farallon and others to create 802.11 wireless networks. DSSS differs from FHSS – instead of subdividing the bandwidth into channels and switching between them, DSSS spreads the signal across the entire bandwidth, thereby increasing bandwidth utilization. As in FHSS, bitstreams are converted into symbol streams, with each symbol containing one or more bits. The number of bits is determined by the modulation technique used, however unlike FHSS, DSSS bases its modulation on Phase Shift Keying, or PSK. The PSK-modulated symbol stream is converted to a complex-valued signal, which is then fed into a spreader chip. The spreader chip multiplies this signal with a pseudo-noise, PN signal, called a chip sequence. 802.11 DSSS bases its chip sequence on the eleven-chip Barker sequence. The Barker sequence is just a series of positive and negative values that is used to force transitions in the signal. For example, you have a pulse that looks like Figure 2.
Figure 2. Basic Pulse
If you modulate that signal with the following sequence:
+1-1+1+1-1+1+1+1-1-1-1
and you invert the pulse on every transition, (going high if it was low, going low if it was high), and keeping state if no transitions are called for, you get a modulated pulse that looks like Figure 3.
Figure 3. Sample Modulated Pulse
Although the pulse seems to be out of sequence for the last half of the pulse, the sequence starts over once the 11th key is used, so although the last key is a –1, and the first key is a +1, this is a restart/reset, not a transition. No phase shift occurs until the second key, which is a –1, and a transition. Spreading the signal on this sequence makes the total occupied bandwidth larger, and brings the effective bandwidth up to 11 MHz from 1 MHz, while still allowing fallback to 5.5, 2, or 1Mbps if needed. Spreading the signal also makes it less susceptible to interference, as to completely block the signal, the interference must occur across the entire band. However, spreading also reduces overall transmitted signal power, as the output power is applied over a wider bandwidth. Both effects are shown in the diagram below, with signal strength as the y-axis, signal bandwidth as the x-axis, data in blue, and noise in pink.
Figure 4 Bandwith vs Amplitude
The outputs of the spreader are then fed into a quadrature modulator, and then into the transmitter front end. 802.11 DSSS specifies 2 bitrates: 1Mbps using Binary PSK, BPSK, and 2Mbps using Quadrature PSK, QPSK.
FHSS v. DSSS
In comparing FHSS and DSSS, we notice that DSSS has some immediate advantages over FHSS. The first is more robust modulation, and greater range, even when operating at half the signal strength of a comparable FHSS system. While the channel-hopping behavior of FHSS gives it more overall frequencies, interference between adjacent channels limits the total number of collocated FHSS systems. However, FHSS does have an advantage over DSSS because it degrades more gracefully than DSSS, and can work better under worse conditions. Much of this advantage is due to FHSS not being spread out like DSSS. Since the FHSS signal is concentrated across a much narrower bandwidth, its amplitude is greater, and FHSS can therefore ‘punch through’ interference better. Also, the hopping aspect of FHSS assists with frame collision avoidance. These advantages are minimized by the fact that DSSS works reliably at much greater distances than FHSS, as shown in Figure 5 below.
Figure 4 Probability of a reliable link for DSSS vs. FHSS
Another advantage to DSSS is efficiency. DSSS is able to give better performance with fewer access points than FHSS., Plus, FHSS reaches a point of diminishing returns much faster than DSSS, as shown in Figure 6.
Figure 5 Throughput efficiency
In addition, DSSS can use a higher number of access points to get an overall higher aggregated bandwidth than FHSS.
Figure 6 Throughput as a function of the number of access points
Also, in collocated networks, DSSS gives higher speeds with fewer access points than FHSS.
802.11 MAC Layer
Now that we have taken a look at the physical layer of 802.11, let’s move on to the next part of the standard, the Medium Access Control or MAC layer. As a wireless network standard, the MAC for 802.11 is different from the MAC for a wired network such as Ethernet. One example of this is the expectation that 802.11 Access Points (AP) are always acting as bridges between the wired network, and the wireless network, which is not an assumption in wired networks. Plus 802.11 frames have some unique features that assist in wireless data transmission and reception. Each frame has sequence control and retry fields that help to minimize interference between stations. Since RF is omnidirectional, regardless of which AP a particular end node is connecting to, its frames are received by every AP in range, so the sequence control fields help deal with this. In conjunction with the sequence control fields, you have the type/subtype and duration fields, that help ensure reliable communications with ‘hidden’ stations. The sequence control fields also work with the fragmentation fields, which allow each frame to be further subdivided into smaller fragments if conditions are bad. There are also To DS and From DS fields that assist in setting up and use of single-channel wireless backbones.
Carrier Sense Multiple Access/ Collision Avoidance - CSMA/CA
802.11 uses a MAC scheme that is similar to Ethernet’s CSMA/CD, called CSMA/CA. The main difference is that 802.11 practices collision avoidance (CA), as opposed to Ethernet’s collision detection (CD). The reason is that in a distributed wireless network, it is highly impractical to attempt to detect collisions, because a weak incoming signal could either be a frame or noise. The CA in 802.11 is designed to avoid collisions entirely. It reduces the chances for a collision during the period of time that has the highest probability of a collision, which is the time just after a station stops transmitting. At that point, many other stations are waiting for access, and will attempt to transmit their data. To avoid collisions, 802.11 uses a random back-off arrangement.
Figure 7 CSMA/CA diagram
As shown in Figure 8, after the busy medium period, there is an Interframe spacing period (IFS), which for 802.11 is 50µsec. All devices on the segment must wait for that IFS period. Following the IFS, devices wait an additional random number of 20µsec slots, the number of which is determined by a binary exponential backoff algorithm. If after this time has passed, the medium is still free, (no other stations transmitting), then the stations can attempt to transmit. Each station uses its own random, (actually pseudorandom) amount of wait time, the chance of a collision is reduced. If a collision is detected, the devices go back into the slot time wait mode, until the medium is free. Another difference is in the frame acknowledgement. Although most LAN systems require some form of frame reception acknowledgement, the wireless nature of 802.11 forces some unique requirements in this area. As with other LANs, 802.11 does all its frame acknowledgement at the receiving end. However, unlike most LANs, 802.11 handles this at the MAC layer, whereas other LANs handle this at higher layers. The reason is the timing requirements imposed by 802.11. With the IFS lasting for only 50µsec, the receiver is required to send an acknowledgement within 10µsec, only after verifying the CRC for the frame. By performing all of these functions within 10µsec of receiving the frame, the receiver can immediately send the acknowledgement, because other stations are still in the IFS period, and the medium is clear. However, these response times preclude handling the acknowledgement at a higher layer, hence the MAC layer acknowledgement. This speed becomes critical in certain topologies, which we will discuss later. A general diagram of the acknowledgement, (ACK) behavior is shown below.
Figure 8. Acknowledgement (ACK) Behavior
At the beginning of the MAC section, I mentioned different 802.11 frame fields, and how some of them are used to deal with hidden stations. Hidden stations are somewhat unique to wireless networking. Unlike wired networks, where every station on a LAN has an almost direct connection to any other station on the same LAN, the transmit range limitations for wireless can result in two nodes in the same cell that cannot physically see each other. An example of this is an AirPort cell within the 150’ range of each node and AP. Node A is 150’ from node B, which is 150’ from the AP, but 300’ from node A. The only way that nodes A and B can communicate with each other is through the AP, as they are ‘hidden’ from each other, as shown below.
Figure 9 Invisible node problem
In this case, nodes A and B could easily transmit at the same time, causing collisions. The solution is the combination of the To/From DS fields and 802.11’s use of Clear To Send/Ready To Send frames. The To/From DS fields tag which way the frame is headed, unlike Ethernet where only the origination and destination MAC addresses are used. In the CTS/RTS system, B sends the AP a RTS frame, signaling the AP that B is ready to transmit a frame. Included in this frame is a time value that represents the amount of time takes B to transmit the data frame. The field that holds this data is the length field, shown below.
Figure 10 Field diagram
Node B then goes into a wait mode. As soon as the IFS and backoff period passes, the AP broadcasts a CTS frame for B, but received by all stations in using the AP. This CTS frame has the same time value that was in the RTS frame. All stations that aren’t B receiving this frame immediately cease transmitting for the amount of time in the CTS frame. Once B receives the CTS frame, it begins transmitting its data frame. The first diagram below illustrates this process in a basic way, and the one following shows a more detailed view of the RTS/CTS structure in conjunction with the CSMA/CD backoff behavior.
Figure 11 RTS/CTS flow
Figure 12 RTS/CTS diagram
One of the other benefits of RTS/CTS, besides avoiding congestion, is that the 802.11 implementation incurs a relatively low overhead. In the example below, even in a ‘pure’ RTS/CTS environment, the throughput is only reduced about 13% over an environment with no RTS/CTS.
Figure 13 RTS/CTS impact on speed
The low impact of RTS/CTS on throughput, along with its collision reduction capabilities, make it a very attractive feature to look for in an 802.11 product, although the RTS/CTS feature is optional under 802.11, and can be removed for cost savings.
Miscellaneous 802.11 MAC features
Another feature of the 802.11 MAC is fragmentation, which is a technique for dealing with poor transmission conditions. Unlike wired LANs, 802.11 networks must deal with things like interference from nearby antenna, or microwave sources such as mobile television transmission units. To overcome interference, 802.11 allows a frame to be fragmented, or split into smaller chunks. (See Figure 15 below.)
Figure 14 802.11b fragmentation
Since fragments are smaller, they allow both end nodes and APs to recover more quickly from both transmitting and receiving them. In addition, the smaller fragment size means that errors in fragment exchange have a lower overall effect on data throughput. This is also assisted by the fact that the frame is not considered to be sent until all fragments have been sent and ACK’d. Thus the sender of the fragments has control of the medium for that period of time. Finally, in the case of interference such as microwaves, the interference itself is ‘bursty’, so the smaller fragment size means the fragments handle this type of interference better. 802.11 requires fragmentation support on receivers, but it is optional on transmitters. 802.11 also allows for dynamic fragmentation, to suit the nature of the interference encountered. By allowing for the possibility of full-time fragmentation, the vendor can build its receiver cheaper, by avoiding the cost of adding enhanced fragmentation support. However, since fragmentation means more transmissions, the overhead is higher, and can reduce throughput.
Roaming is another important part of 802.11. Roaming is not a requirement, but it is an important feature to corporate 802.11 customers. It is usually left out of 802.11 devices, to reduce cost, as in Apple’s 10-User AirPort pod, (which is designed for home and school use, where roaming is not necessary), i One major advantage to roaming is for laptop users going from meeting to meeting in different areas of a floor or building. In a wired setup, the user must either power off, or sleep the laptop, and disconnect the network wire. They must then reverse this process at their destination,. In 802.11 roaming, the laptop is put to sleep, carried to its destination, and woken back up. The 802.11 device in the laptop connects to the nearest AP, and reinserts itself on the network. The actual procedure that allows this to happen is not much more complicated.
In an 802.11 network, each AP sends out regular beacons, (around every 100msec) to all end nodes in range. Included in the beacon are such data as a current timestamp, (for any needed synchronization purposes), a map of current traffic, and supported data rates. Upon receiving this beacon, each end node can judge the clarity and strength of the signal and use it to determine whether or not to attempt a connection to the AP, or if another AP, (if multiple APs are being used) would be a better choice. An end node can send out a beacon of its own, or a probe request message to any APs in range, which then respond with a probe response message, or solicited beacon. In either case, the end node, not the AP, determines the communications quality (CQ) of the signal from the AP, and uses the CQ level to determine which AP would make the best connection. If the CQ of a connected AP signal drops below a certain threshold, (which is determined by a number of factors, including vendor design, usage, speed, etc.), due to either interference, outage, or our roaming laptop above, the end node actively searches for a new AP. Once a new AP is found, the end node moves into a handover state, and reassociates with the new AP. The new AP communicates with both the end node, and the end node’s previous AP to re-establish the end node’s place on the network. The APs use an inter-access point protocol to inform each other of handovers and roaming end nodes. This allows 802.11 networks that use MAC address authentication to hand over that information from the old AP to the new AP, thereby allowing the network to prevent unauthorized roaming, (via the use of MAC address/password tables, etc.). Although a way to easily move a laptop from room to room, roaming is also handy for PDAs and other handheld devices. For example, a 802.11 handheld computerized chart with roaming would allow medical personnel to easily move from patient to patient, without having to re-connect if they moved out of an AP’s range. As noted earlier, Apple’s 10-user AirPort Pod doesn’t support roaming, although Apple recently announced a 40-50 user Pod that would support roaming. The roaming features of 802.11 are specifically supported by companies such as Lucent, Digital Ocean, and Aironet, (who helped developed the InterAccess Point Protocol), Apple, IBM, and other companies. This helps companies thinking about building an 802.11 system avoid being tied to one vendor for roaming support, and is critical in 802.11’s acceptance.
Finally, the 802.11 MAC has certain security features, to help prevent unauthorized ‘guests’ on a wireless network. First of all, DSSS itself makes snooping difficult. The data is encoded and spread across an entire band, any snooper must have the 11-chip Barker code used for a given LAN, and has to be able to re-assemble the signal, which requires them to cover the entire portion of the 2.4 GHz ISM band being used. Also, 802.11 allows for data transfers to be encrypted using a 40-bit RCA key. Although not the best key length available, the 40-bit key was chosen because of the complete lack of U.S. export restrictions on encryption technology based on that key-length. Regardless of the key length, between the DSSS characteristics and the RCA key encryption, 802.11 signals are at least as secure as data traveling over a wired network, with the same encryption.
Topologies
802.11 supports three basic topology schemes, Independent Basic Service Set, (IBSS), Basic Service Set, (BSS), Extended Service Set, (ESS). IBSS is an ad-hoc peer to peer topology. There is no dedicated AP acting as a central point, and is limited in size and scope. IBSS would be used in a situation where a temporary connection was required between a small number of computers. BSS is the more common topology used for 802.11 networking. This is also the common arrangement for a single cell within a larger network. BSS uses a dedicated AP that is the logical server for the cell or wireless LAN (WLAN). All node communications go through the flow through the AP, which can be connected to a wired network. In this case, the AP acts as a bridge for the wired to wireless networks. ESS is the final, and largest topology of 802.11. An ESS topology consists of multiple BSS cells connected by a wired or wireless backbone. The cells can either be on the same channel or multiple channels. If the cells are on the same channel, then the overall bandwidth is shared by all cells on the backbone. If multiple channels are used, then the aggregate bandwidth is boosted. In the case of an ESS topology, 802.11 has certain specific features that increase its usefulness as a backbone technology. Normally, for an AP to act as a backbone node, it would need a separate transmitter for each cell it was bridging. This would quickly make wireless backbones too expensive to use. 802.11 circumvents this by allowing single-channel frame forwarding. If the AP receives a frame for a station it can’t see, it forwards the frame to any other APs it can see that aren’t the one that sent it the frame. This is an economical solution with good performance characteristics, although like any single channel backbone, overall bandwidth can be a limiting factor.
Power Management Support
Since the majority of wireless LAN users are mobile devices, 802.11 includes specifications for power management support. When a station transmits a frame, that frame contains a power management, PM bit. That bit indicates the station’s current power management mode. If the PM = PS, then the station is in power saving mode, and if the PM = A, then the station is in active mode. In a network using access points, such as the AirPort Pod, the access points uses the status of the stations to determine traffic management for the stations. If the station is in PS mode, then the access point will buffer any messages for that station. On a regular basis, for example, every 100msec, the access point sends out a beacon frame. This frame contains the addresses of the station(s) for which the access point is buffering messages. The stations come out of DOZE mode, (a.k.a. sleep) on a regular basis, based on the beacon frame timing. The station(s) read the beacon frame, and check for buffered messages. If the frame indicates that the station has waiting messages, the station stays in the AWAKE mode, and polls the access point for its buffered messages, at which time those messages are sent. This is how power management works for unicast, or station specific messages.
In the case of multicast messages, or network-wide messages, there is a different procedure. For multicast messages, there is a change to the beacon frame. At a predetermined multiple of the unicast beacon transmission time, another field in the beacon frame is used to indicate that there are multicast messages being buffered. Once the multicast-beacon has been received, the multicast messages are immediately sent. When a station receives a beacon frame showing multicast messages being buffered, it stays in AWAKE mode to receive the multicast messages. An example of a queuing structure used by an 802.11 access point, the WaveLAN from Lucent is shown in the diagram below. All stations that aren’t B receiving this frame immediately halt all transmission
Figure 15 Power Management diagram
The frame transfer block is the only section that works directly with the RF section. The frame transfer has two input queues, normal transmit and priority transmit. The priority queue is used to schedule internal management and control protocol frames, and the normal queue is used for data frames coming from higher layers in the networking stack, such as user-generated data. There is a single multicast queue for all stations connecting to this access point, and an individual unicast queue for each station as well. When polled by a station, the message at the head of that stations unicast queue is passed directly to frame transfer for highest priority transmission. When a station that was in PS mode, (PM=PS), sends a message, (not a poll), to the access point that shows it is now in A mode, (PM=A), all of the buffered unicast messages are forwarded to the normal transmit queue. When a station that was in active mode sends a message to the access point indicating that it is now asleep, (PM=PS), all messages in the normal transmit queue are moved to that stations unicast sleep queue.
The diagram below shows a block diagram of two power management schemes, both the ‘standard’ 802.11 scheme, and an ‘enhanced’ scheme developed for the WaveLAN.
Figure 16 Second power management diagram
The end node stations, when not actually transmitting, switch between the DOZE and ‘listening for a beacon’ state. The station’s timer wakes the station up just prior to the beacon frame. If there are no messages buffered, the station immediately drops back into DOZE mode. This cycle, used in both the 802.11 ‘standard’ scheme, (shown in blue and light gray) and the WaveLAN ‘enhanced’ scheme, (shown in blue and dark gray) allows the station to spend up to 99% of its time in DOZE mode.
In the standard scheme, when buffered messages are detected, the station stays AWAKE, and either waits for multicast messages, or actively polls the access point for its messages. Once all messages are received, it then goes back to DOZE mode. The enhanced scheme adds a ‘holdover’ state that is used when a transmission is detected, or buffered messages are present. This holdover state temporarily switches the station from DOZE to ACTIVE mode, and sets (PM=A). The access point then transmits all buffered messages, and halts unicast queuing for that station. The station stays active until the holdover period, (usually .5 to 3 seconds) has passed with no transmit or receive activity occurring for that station. The advantages to this holdover state are due to the fact that most LAN activity is bursty. Bursty is, periods of no traffic followed by periods of heavy traffic. By keeping the station in the active state for the holdover period, the formation of queues is avoided. Also, the message polling system used to get buffered messages is rather inefficient. Finally, if the station has been asleep for awhile, it is handy to keep the station awake long enough for any applications on the station to tend to their own network-related housekeeping, and to receive any traffic related to that housekeeping. As an example of the differences in power usage, for the WaveLAN, the transmit mode draws 300mA, receive mode draws 250mA, and DOZE mode draws 9mA, so the power savings can be considerable.
802.11 Devices
Now that we have covered most of the 802.11 specification, let us look at some of the devices that actually use 802.11. The WaveLAN is viewed in more detail than the others, since there is more detail available. In general, most of the non-device specific features of the WaveLAN, will apply to all 802.11 devices.
WaveLAN
History
The WaveLAN was introduced by NCR in 1991 for wireless networking. The WaveLAN was designed to operate in the 915MHz band, and was originally produced as an ISA (Industry Set Architecture) card for desktop PCs. During the product’s lifecycle, other cards were produced for other buses, and WaveLAN was upgraded to operate in the 2.4GHZ band. The WaveLAN was improved with regard to operating systems supported, card size, power consumption and software support. The heart of the card, namely the NCR digital signal processing (DSP) application specific integrated circuit (ASIC) and Intel Ethernet controller were not. The WaveLAN is not technically an 802.11 device, as it preceded the standard, but many of its features were used by the 802.11 committee.
Now
The current version of the WaveLAN has made considerable improvements on the base 802.11 standard, while retaining full compatibility. It allows for bit rates in the 10-11Mbps range, while being able to decrease its speed, or ‘fall back’ when communicating with a different 802.11 device that can only run at 1 or 2Mbps. This is because the training preamble/header of the transmission, looks the same regardless of bit rate. The preamble takes 200µsec to send/receive, and is modulated at a bit rate of 1Mbps. The data portion of the transmission, which can take longer to process, (maximum data size is 2.3KB/frame), can be sent different speeds, up to the maximum speed of the device. Both devices can negotiate the proper speed because the preamble is recognizable by any device that is 802.11-compliant. (This is a more complicated version of the way two modems handshake with each other to determine the best communications speed.)
In standard DSSS, the 11-chip Barker code is used to carry 1 or 2 bits of data per pulse. This gives us the standard 1 or 2Mbps speeds on standard 802.11 devices. This signal, or lobe is one chip wide, with the 10 additional chip positions in the symbol period creating sidelobes that are 11 times smaller than the main lobe. (Note: In any RF transmission, the main signal is the main lobe. Other, weaker versions of that lobe transmitted, are called sidelobes. This is noticeable when you drive by a radio station transmitter, and hear a station interfering with other stations that operate close to that station’s frequency. The interference is caused by, among other things, the sidelobes of the signal, which are normally to weak to be picked up. Sidelobes are also used to help jam radar.) Each of the other chips in the Barker sequence can also be modulated, in addition to the normal QPSK modulation. Lucent discovered a way to use this additional modulation to increase the number of bits per symbol from 1 or 2 to 10 or 11, which is being used in the 802.11 to enhance the existing throughput rates. This gives us, (and the AirPort), Ethernet speeds without wires. There are some downsides to this, namely that with higher performance, signal-to-noise, s/n, ratios become more of a concern, with the higher speed transmissions requiring s/n’s of 6dB.
The WaveLAN card has a number of physical traits, which are common to all 802.11 PCMCIA card devices, so we will use it as an example for other 802.11 devices. Note: The diagrams and chipset names were as of late 1997, so some details may have changed, but the basic structure is the same today.
Figure 17 WaveLAN block diagram
The first section is the antenna, used for transmitting and receiving. The card uses 2 L-shaped inverted-F antennas. These antennae are spaced between .25 and .5 of a wavelength apart, which gives good separation. The antennae act as a “leaky” 2.45GHZ resonator, +/- 100MHz, which aids in the function of the antenna. Plus, the shape of the antennae ensures that it is no bigger, overall, than .125 of a wavelength, which helps to make it very omnidirectional. This characteristic allows the WaveLAN to avoid the need for a line-of-site requirement in its operation. (NOTE: Antenna are cut/sized to specific multiples of the wavelength of the signals it transmits or receives. By using even multiples or fractions of the wavelength, the antenna can be made much smaller than the full wavelength, which, in the case of shortwave, low frequency signals, can be hundreds of meters. Wavelength and frequency are inversely related, with the wavelength going down in size as the frequency becomes higher.) The next section is the RF front-end. This performs up/down conversions of outgoing/incoming signals based on a 352MHz intermediate frequency (IF). This section also includes a low-noise amplifier. Side Noteà(NOTE: Up/down conversion is done to save space and components. At higher frequencies, if you want one unit to operate across multiple frequencies, which receives signals from the low MHz range into the 30+ GHz range, you must either use multiple antenna and RF sections, one per frequency, OR, you use a wider range antenna and a mixer, set at a known intermediate frequency, such as the 11GHz IF in radar detectors. This mixer separates the incoming signals from the 11GHz IF, and allows signal discrimination and analysis to be handled behind the antenna, saving space and weight. This mixer approach also uses less power than the multiple antenna/RF section method.)
Behind the RF front-end is the IF transceiver. This section handles IF-baseband up/down conversions via a (de)modulator chip derived from a Global Systems for Mobile Communications, (GSM) chip. Following along the component chain, we next have the DSP ASIC, named Theseus. This chip handles the analog/digital and vice-versa conversions between symbol streams and RF signals. This DSP is required because the speeds at which the WaveLAN runs require about 2000 multiply-add operations/µsec, which is too much for standard DSP chips. This chip is the main engine of the WaveLAN card, and has 2 digital to analog converters and 2 analog to digital converters, all of which run at 22MHz with a 6-bit digital representation.
The final ASIC in this line is the Wireless MAC (WMAC), protocol ASIC, called Hermes. This chip handles the 802.11 frame transmit and receive functions, as well as power management, Automatic Rate Fallback (ARF), Multi-channel roaming and handover management. The other two hardware components are the flash ROM and the RAM chips, which handle configuration information and message buffers respectively.
Finally, the WaveLAN is a scalable system, which can contain as many, or as few, access points and their cells as is needed. The power level of the WaveLAN transmitter is 15dBm, or 30mW. As a station communicates with an end node, the signal levels increase and decrease as the station moves closer to, or further from, the access point. Each access point has a configurable carrier detect threshold (CDT). Each access point usually employs 2 levels of CDT in an inner / outer cell configuration. Within the smaller inner cell, the CDT is higher, and faster communication rates, up to 11Mbps can occur. The larger outer cell has a lower CDT, and communication speeds are limited to 2 or 1 Mbps. If the signal level falls below the outer cell’s CDT, the station cannot communicate with that access point, and must either connect to another point, or network communication is interrupted. By configuring the CDT levels, more access points can be located closer together, and share the same channels. Sharing is assisted by another configurable threshold, the defer threshold (DT). The DT is lower than the CDT, as its purpose is different. When an access point detects a signal above the DT level, the station holds up a pending transmission. This behavior is called deferral. Within the deferral radius, which coincides with the inner cell, all stations defer to each other as part of the 802.11 CSMA/CA rules and behaviors. Outside of the deferral radius, in the outer cell, deferral is not guaranteed, so the RTS/CTS rules are used to avoid collisions. The total cell area is called the Basic Coverage Area, or BCA. The part of the cell with guaranteed coverage is called the Shared Coverage Area, or SCA. Ideally, we want the SCA and BCA to be identical. The sizing of the SCA and BCA are important in a multiple access point/cell network. If many cells are used, then the SCA and BCA areas can be equal, as the access points are close enough together to allow handover to happen more often, keeping the station in the higher-speed SCA areas at all times. If for any reason fewer cells are available, then the BCA is larger than the SCA, and only the areas outside the SCA in the cells overlap. This is a benefit, as fewer access points are needed, but can be a hindrance, as connection speeds rise and fall as a station roams throughout the network. To allow smooth transition between the high and low-speed areas of the cell or cells, an automatic rate fallback, or ARF, is used. The ARF allows the WaveLAN to decrease its speed as it moves farther from the access point. The station to remains connected for greater distances instead of only allowing the highest speeds. In addition, the ARF allows the stations and access points to communicate if the signal quality degrades for some reason, allowing for reliable communication in more adverse conditions. The ARF is relatively simple in function. It keeps track of the ratio of successfully transmitted frames to unsuccessful transmissions. As the number of unsuccessful transmissions increases, it slows down the bit rate until the ratio is at proper levels. When the ratio improves, it increases the bit rate back to the normal maximum.
Farallon SkyLINE
The second 802.11 product found was SkyLINE by Farallon. Similar to the WaveLAN, SkyLINE is a DSSS device that operates in the 2.4GHz spectrum, allows for easy wireless networking by a variety of devices. However, even though both are 802.11-compliant, there are some important differences. SkyLINE operates on a more standard 802.11 scheme, with top speeds limited to 2Mbps, which gives the SkyLINE a stated range of up to 1000ft outside, and 300ft indoors.
The SkyLINE is based on the Harris PRISM chip set, and comes with software for both the MacOS and Windows. The user can set various configurations for connecting to access points, or other end nodes in an ad-hoc setup.
Figure 18 Skyline Control Panel
As you can see in Figure 19, the software controls the modes of access and addressing, as well as keeping track of the signal strength of the current connection. Although not an interesting statistic, the strength meter does give you the ability to tell if you are attempting to connect to an access point that has a good enough signal to maintain a reliable connection.
The SkyLINE card is a standard PCMCIA card. The antenna and status lights protrude from the end of the laptop, when the card is inserted. There have been some complaints when comparing the AirPort card in the iBook to systems such as the SkyLINE regarding the protruding antenna in non-AirPort devices. The reason for this is simple. In the iBook, and the high-end G4s, the antenna is built into the case, so the card can be completely internal to the computer. With other computers, the antenna is not a part of the structure, but is part of the 802.11 card, hence, the protruding antenna, as seen below.
Figure 19 SkyLine card
The antenna is an internal dipole, similar to the WaveLAN, (One thing that you will notice about products that have similar requirements, is that the construction does not tend to be terribly different.) Transmit and receive power levels are also similar to the WaveLAN, (2.4w Transmitted, and 1.6w Received.) The SkyLINE also follows similar power saving methods, as most of these are dictated by the 802.11 standard, and the requirements of a PCMCIA card. Farallon has stated that tests show the SkyLINE to be operable with the AirPort and other 802.11 devices, such as the WaveLAN. The SkyLINE and AirPort cards can easily connect to an AirPort pod.
The Skyline operates on 14 channels within the 2.4Ghz band, and uses the channels in a number of ways. When connecting to an access point, it goes through the channels until it finds a point with enough signal strength for a reliable connection. By splitting the band into channels, the SkyLINE can avoid problems with end nodes and access points interfering with each other. Also, it uses the channels to search for an access point if the one its currently connected to should fail, or loose strength. This is similar to the WaveLAN’s methodology for roaming and reacquisition after signal loss. Finally, if a laptop or other portable with a SkyLINE card is put to sleep, upon awakening, the SkyLINE card automatically attempts to reconnect to the network.
Apple AirPort
The final 802.11 device in our examination is Apple Computer’s AirPort. The AirPort consists of 2 parts: The end node device, such as the AirPort cards in the iBook and G4, and AirPort Base Station, or Pod. One of the obvious differences between the AirPort card and other 802.11 end node devices is the lack of an antenna. Apple has built the antenna into the case of the iBook, and the high-end G4s. By doing this, Apple is able to make the AirPort card completely internal, so as not to mar the lines of their newest computers. It reduces the cost of the card, because the antenna cost is a part of the computer cost, and not the AirPort cost. This design also allows more room, so they can use a bigger antenna which gets better reception from a weaker signal than the .125 wavelength antenna used in devices such as the WaveLAN.
Apple has announced two access points as well. The first model is the Pod, shown at the MacWorld Expo ’99 in New York, supports ten users, with a range of 150 feet. The Pod has two wired inputs, one 56K modem port, and one 10/100Mbps Ethernet port. Simple math gives the reason for Apple stating a 10-user limit on the Pod: With a maximum bandwidth of 100Mbps, 10 users is the max that could get the 11Mbps advertised speed from their AirPort cards. In reality, you can connect more users to a Pod, but the bandwidth drops in proportion to the number connected. The range numbers reflect this as well. 150 feet is the maximum reliable range for an 11Mbps connection. As you go farther from the Pod, your speed drops until you either disconnect, or connect to a new Pod. In addition, the wired connection is an either / or proposition. You can’t have both running simultaneously. Concurrent connections would require the Pod to act as a router, and driven the cost up along with that functionality. Finally, the 10-user pod does not support roaming. Considering the target market for this model, this is not surprising. Most home and K-12 educational users don’t need roaming, as one pod can easily cover most homes completely. In a K-12 setting, the students are disconnected between classes, so roaming is not an issue there either. Also, by eliminating the roaming feature, Apple was able to keep the Pod cost down to the $300 range. Apple recently announced a 40-50 user Base Station that does support roaming, but no details have been released as yet.
802.11 competitors
At present, there are only about two well-known competitors to 802.11 in the wireless networking world. (I know I am leaving out a host of vertical market systems, but I am limiting this to non-proprietary systems, so as to compare similar systems.)
IrDA
The first and better-known system is IrDA, or InfraRed Data Association. While IrDA is best known as a laptop to printer connection, the IrLAN specification does allow for a wireless infrared LAN. IrLAN is designed to run at speeds of up to 4Mbps, and is a fairly cheap hardware specification. Even with good speed, and cheap hardware, IR in general has limitations that make it unsuitable for general-purpose networks. One of the problems is that walls, people, or sources of heat, such as the Sun, stop IR. So right away, IrLAN is pretty much indoor only. Also, since IR cannot go through walls, to use it in an office situation, the only way to avoid having everything be in a direct line of site, the IR signal must be reflected somehow. This involves ensuring the ceilings, and sometimes the walls of a building are made of an IR-reflective material. Reflective materials are expensive and aesthetically unappealing, as it rather limits wall treatments and paint colors. Finally, the range on IR tends to peter out at about 10 meters, so the number of APs required to cover a given area is larger than for 802.11. This is not to say that IrLAN is not useful. In a warehouse situation, or an assembly situation, it can be a cheap alternative to wiring computers together. Also, since virtually every shipping laptop has an IR port, in a college lab situation, it is an easy way to allow students to print with their own laptops, as opposed to using email or a sneakernet to get the files to a computer on the school network. In specialized situation, IrDA can be useful, but speed, range and other limitations relegate it to a niche networking technology.
Bluetooth
The other currently popular standard is Bluetooth. Sponsored by a computer and telephony consortium of companies such as IBM, Nokia, Intel, and Ericcson. Bluetooth has been getting a lot of press lately as a new networking standard. Bluetooth operates in the same ISM band as 802.11, but it is designed around a much smaller scale than 802.11. Bluetooth is designed to give vendors of cell phones, PDAs, handheld computers, etc, a way to create piconets and connect these devices easily. Bluetooth has a range of 10 meters normally; 100 meters with amplifying repeaters. The maximum data rate is 1Mbps, although 720Kbps is normal. Due to these range and speed limits, obviously Bluetooth is not a true competitor for 802.11, or Ethernet. So what space does Bluetooth occupy? Interestingly enough, Bluetooth seems to be more of a RF competitor to IrDA. Its a low-cost way to create wireless connections between devices that don’t have high data or range requirements, such as keyboards, joysticks, cellular modems, etc. An example is a wireless joystick used to play a flight simulator that is using an 802.11 connection to share a cable modem or DSL line. Another valid comparison would be USB vs. FireWire, with Bluetooth filling the USB role. Bluetooth is very attractive to cell phone manufacturers and PDA vendors, as those devices take on more of each other’s features. Since Bluetooth is an RF specification, it carries all the advantages of RF, such as omnidirectional broadcasting. . Another example is two Bluetooth-enabled PDAs communicating without being pointed at each other as IR ports require. Bluetooth can also enable short-range cell phone communications without having to place a traditional phone call. You can look at the list of Bluetooth phones in range, and talk to one, just like a set of walkie-talkies. Another use could be easier printing from PDAs, cell phones, or even Bluetooth-enabled pagers. In conclusion, Bluetooth looks to be a good, smaller companion to 802.11, instead of a competitor.
Conclusion
Both the AirPort and the 802.11 specification are poised to make an enormous impact on the computer world. Apple is leading the way to increased usefulness of networks, and the number of networked computers overall by introducing a high-speed, easy to use, inexpensive, standardized wireless networking system,. Especially in the home market, where many users are reluctant to run wires, or buy hubs, etc., the ability to wire your home in a few steps, at a more than reasonable price should create an marked upswing in the number of networked homes. In addition, by ensuring that the AirPort is an 802.11-compliant system, Apple avoids proprietary hardware problems, and which makes them an attractive vendor for corporate wireless solutions. Also, the publicity generated by the iBook and the AirPort system will create a swell of demand for these systems, resulting in sales for all 802.11 vendors. Increased sales help promote the 802.11 standard itself, and drive upgrades to the speed and capability of the standard at a faster rate.
Bibliography and References
Kamerman, Ad and Leo Monteban. “WaveLAN-II®: A High Performance Wireless LAN For The Unlicensed Band”. Bell Labs Technical journal (Summer 1997), pp. 118–133. Lucent Technologies.
Stallings, William. “Local and Metropolitan Area Networks” Fifth Edition Prentice-Hall Inc., 1997.
Hayes, Vic, and Vesuna Sarosh. “Wireless LAN Standard” PowerPoint presentation, Lucent Technologies.
http://grouper.ieee.org/groups/802/11/
http://www.farallon.com/products/wireless/skylinespec.html
http://til.info.apple.com/techinfo.nsf/artnum/n60440
http://til.info.apple.com/techinfo.nsf/artnum/n58414
http://til.info.apple.com/techinfo.nsf/artnum/n58415
http://til.info.apple.com/techinfo.nsf/artnum/n60422
http://til.info.apple.com/techinfo.nsf/artnum/n58431
April 3, 2003
test
test
Posted by John C. Welch at 09:45 | Permalink
March 30, 2003
OS X Network Prep
created 19 Feb 2001
Preparing your network for Mac OS X
So last time we talked about general preparation work for the full OS X release. This time, we are going to take a look at one of the more specific items you will need to prepare, specifically your network.
OS X is a much more networkable, and network-oriented operating system than previous editions of the MacOS. Indeed, if you look at the lowest level of your system in the OS X Finder, you see two things, the hard drive volumes, and an item called Network. As you add OS X to your environment, you will find your network being used much more heavily and constantly than before. In my own tests, 200MB file transfers proceed smoothly, and quickly, even if you are doing three or four at once.
Not only does MacOS X support AppleShareIP, but you also have things like NFS, Network File System to think about. NFS, the traditional way of networking Unix partitions, is designed to be transparent. In other words, in a traditional Unix you should be able to use NFS without noticing that you are working off a different machine than the one in front of you. Now, in the Apple UI environment, this is not the way things work, and I have yet to see that NFS will be any different. But the point is, that in a Unix-based environment, you can easily be running major applications across a network, while you are running heavy apps locally. Depending on your environment, you may have other people logging into your OS X machine, and using applications they need that are only on your machine.
This is doubled when you consider, that while NFS is primarily for drive access, when compared to products such as XTools, from Tenon, or one of the XFree86 ports, you can now have multiple users on multiple operating systems making use of your Mac's resources from all across your network. So if you have a copy of the GiMP, the open source image manipulation program, on your Mac, someone on a different Mac is going to be able to use it, if you set things up correctly. This is also one of the more exiting features of the BSD base of OS X. The fact that the Mac is no longer a closed box to the rest of the world, or at least your network. If you need more horsepower for a given task, and you have a bright, shiny G4 sitting on a VPs desk, you can now use it while he's not there. The inherent economies that an integrated network gives to Unix are now going to be available to the Mac.
You also have Samba, which is going to provide services from OS X for Windows users. While you aren't going to be running windows binaries on your Mac with Samba, the opposite could happen with PC users. Have a group of PC users that need to get to data on an OS X Mac? No problem, Samba is there. Have a bunch of Mac OS X users that need to use data on Windows boxes? DAVE, from Thursby Systems, and Sharity, from Objective Development are here for you, or will be here for you native on OS X.
Because OS X is designed to make such extensive networking so easy, you have to take a serious look at your infrastructure.
First of all, if you are still using hubs, start looking at switches. Even with a gigabit backbone, shared bandwidth will bring your network to it's knees. Switches also allow you to consider such other networking features, such as virtual LANs, vLANs, Quality of Service, QoS monitoring and allocation, better use of Simple Network Management Protocol, SNMP features, etc. Hubs are cheaper than switches, but you are going to quickly be paying a much higher price in wasted bandwidth and lost capabilities.
Secondly, start looking at making your minimum internal wired connection speed 100Mbps Fast Ethernet. It's standard on every desktop since the iMac, and on every laptop since the 1999 G3 PowerBooks. It's not noticeably more expensive to implement than 10Mbps Ethernet, and the time you save on backups alone will make up for any increased costs.
Take this as a chance to look at upgrading wiring if you can. Not just new wires, but organize things, trace things, find out why you still need that odd connection that's just there. Look into management packages, such as InterMapper, LanSurveyor, netOctopus, Timbuktu Pro, etc. If you are having weird network problems, this is the time to get a product like EtherPeek, and check them out.
MacOS X is going to be a networked OS like nothing the Mac community has seen before. (And no, A/UX doesn't count, neither does AIX on the Network Servers.) If you take the time to plan your infrastructure upgrades, not only will your OS X users benefit, but other OS's on your network will see the benefits as well. In addition, if you take this chance to organize your network, you may find that what you have is a lot better than you thought. Finally, things like video conferencing, internal usage of streaming media, network attached storage, Storage Area Networks are not going to go away. If nothing else, they may get more intense. Preparing now is like getting a ton of cure for that same ounce of preparation.
Posted by John C. Welch at 12:18 | Permalink
OS X Prep
created 11 Feb 2001
Preparing for Mac OS X
Now that the GM release of MacOS X is only about six weeks off, network administrators are now faced with how to really handle this new OS. A lot of them are quite concerned with how to handle it. If you are in a pure desktop environment, you have more ways to control the roll out of new environments, those of us with laptop users have to face the fact that some of our users simply will not be able to keep their hands off a new sparkily toy.
So we have to start planning for March 24th now. This means a lot more to administrators with hundreds, or even thousands of Macs than it does to one with only thirty or forty. But nonetheless, there are still some things that apply equally to all.
First of all, recognize that this OS will require more training than any previous release since perhaps System 7. The UI is different, the operational modality is different, the way it's designed to be used is different. Whether you like what has been done to the interface or not, the fact is, OS X is not the same OS we are all used to, and if you are one of the companies that is using NeXTStep or OpenStep, it's not the same interface you are used to either. So you are going to need to take special care to remind users that simply slapping this OS on their Mac is not going to be like going from OS 8.5 to OS 9.0. Ask them to be patient, so that you will have the time you need to deal with all the new issues that OS X is going to raise, and help ensure that they will have a smoother transition to the new OS.
You are going to need to inventory the applications you and your users depend on, and find out what those vendors are doing as far as Carbon, and / or Cocoa versions of those applications. One of the best resources for checking on updates to Mac applications in general, but OS X applications in particular is VersionTracker's OS X page. If an application is running native in the public beta, then start working with it now, see what's changed and what hasn't. As an administrator, you are going to be a, if not the focal point for questions on the new OS, so the more knowledge you have, the better off you are. If you can, start accumulating applications that will help you now, so that you are ready to go when March 24th rolls around. If you have a good relationship with a software vendor, see if you can get on any beta teams for the OS X version of their products. It may not seem like a good use of your time at first, but having hands on experience with a beta release often gives you not only a heads up on any changes in the new version, (and there will always be changes; as a certain science fiction doctor once said, "I know engineers, they just love to change things."), but quite often gives you a chance to find the lesser known features of a product that really take it from merely handy to indispensable. This in turn, helps you help your users get the most out of the new release sooner than they normally would have.
You are also going to need to review your procedures that deal with backup and recovery of user systems. With any new interface, people are going to make the 'newbie' mistakes that they wouldn't normally make. They're going to lose or delete things, or do other minorly catastrophic things that they wouldn't normally do. So if you've been getting by with minimal backups, this is perhaps the time to rethink that. Get familiar with not only the traditional MacOS ways of doing things, but take a look at Unix-based ways of accomplishing the same tasks. While no one way is absolutely perfect, clever combinations of methodologies can produce excellent results, in ways you may not have anticipated.
When I said that OSX will require more training, I wasn't only speaking of user issues. Adminstrators as well are going to have to get at least comfortable, if not adept at using the functionality provided by the BSD plumbing in OS X. While users should never have to use a command line, or the Unix layer directly, as an Administrator, you are missing out on a lot of features and time savers if you do not start learning how to use these things. Remote administration, in OS X, is a lot more capable out of the box than the current MacOS. The first time you are easily able to SSH into a box, and kill a runaway process, so that the user doesn't have to reboot the Mac, you'll know what I mean. (If you don't know what SSH stands for, or how it is used, that's an excellent starting point.) Things like 'top', and 'ps -f |more', and 'kill -9' are going to be a part of your vocabulary. You can resist them as alien concepts that Mac administrators have no need to know, or embrace them as valuable new additions for your toolbox. Personally, I think the latter is the better way to go. You also will find new ways to use existing tools. Those of you familiar with AppleScript are going to find that you have a new world to work with, as you find ways to link the power of AppleScript and shell scripts to get things done. Is it going to be like falling off a boat? Nope, but it'll be worth the work in the end. Change is happening, and we need to start planning for it, not avoiding it, or hoping that it will fix itself for us.
In the next couple of columns, I'm going to start presenting things that administrators need to look at for OS X, and the new challenges it will present us with.
Posted by John C. Welch at 12:16 | Permalink
Pentium 4
created 7 Dec 2000
The Pentium 4
For some time now, the Mac community has been in a state over the lack of clock-speed improvements in the G4. "We know that's not important, and that the G4 is faster than the Pentium III, but it looks bad, and besides, what happens when the Pentium 4 comes out and is running at 1.4GHz or faster?"
Well, Intel finally released the Pentium 4, and so far, the results have been disappointing to say the least. Simply put, unless you are running Quake III or have the 2 pieces of software that have been rewritten for the Pentium 4's SIMD extensions, you will see almost no improvement over a Pentium III. This is great news for AMD, as the Athlon is easily beating the Pentium 4 at similar clock speeds.
But this is even better news for Apple and Motorola. If you read the reviews, the reasons for the failure of the Pentium 4 to offer any real reason to upgrade can be laid squarely at Intel's "clock speed is all" philosophy. There aren't any real improvements in the Pentium 4 in any area other than allowing for faster clock speeds except for some improvements in the SIMD units.
SIMD is Intel's take on Altivec, although looking at the implementation, Motorola's experience as a DSP maker helped them create a much better implementation. But as with Altivec, unless you recode for the SIMD units, you aren't going to see an improvement there.
What Intel did do is double the pipeline size and added some execution caching steps and other clock speed - related improvements. This is all neat, but it relies on much faster clock speeds, and RAMBUS to work. But in almost any test, even when the Pentium 4 does beat the Pentium III, or the Athlon, if you compare results at the same clock speeds, it's by 5 percent or less in many of the tests. This is not the amazing performance boost that the Pentium 4 is supposed to have. But now we hear Intel saying, "Well, when we get the Pentium 4 to 2GHz, then you'll see the performance increase". Well I would hope that doubling the clock speed gives you something.
But what do you pay for when you put clock speed over everything else? Remember, engineering is a balancing act. For every gain, there is a cost. The trick is, having enough gain to outweigh the costs. Has Intel done this? Well, in many real-world ways, no.
First of all, the Pentium 4 has different power requirements, which require new power supplies. This is annoying more than anything else, and in my world not even a blip, as it's not worth my time to upgrade machines. I end up saving money by buying new machines over trying to do CPU upgrades. But for a home user, it's another expense to consider. Secondly, the Pentium 4 dissipates a lot of power. As in 55 watts of power. To compare, the latest version of the G4 from Motorola only dissipates 6 watts max, and even the previous model G4 dissipates 8 watts max. This is a huge difference. The results of this are that the heat sinks are big enough that Intel is now specifying motherboard attachments for them, so they don't damage the chips, which has happened with some of the bigger heat sinks on the Athlons. This means new motherboards, and new cases for most. So the upgrade path to a Pentium 4 is essentially a new computer.
But here's another issue with the heat output of the X86 architecture: Noise. Most Pentium IIIs and Athlons are generating, (due to the number of fans needed to keep those beasts cool), something like 55 to 60 decibels, (dB) of noise. This is similar to heavy traffic noise levels. Now multiply that times the number of computers in an area with cubicles. This is not minor, some of these boxes sound like DC-3s taking off. In contrast the Cube, or the iMac, or even a G4 Tower are much quieter, almost silent. Even the fan on the G4 Tower's power supply is very quiet compared to the three or so fans in a Pentium III box. A constant ~60dB noise level for eight hours a day, every day is not a good way to work, and with the Pentium 4, it's not going to get any better. (This would make an interesting ad campaign. "The Cube, because it won't make you deaf".
The upshot of this, is that for the first time, rigid focus on clock speed is burning Intel. Will the chip flop? Hardly, Intel is too pervasive for that. But it is finally making people say, "Why do I need this?" They are tired of spending money every six months for low-level speed gains that just don't show up in daily use. I type all my articles in BBEdit on a 400MHz G3 PowerBook. I've done a couple on a G4 at work. Other than a slightly faster speed when opening BBEdit, I'm not working any faster at 500MHz than I am at 400MHz. I just am not going to ever type fast enough to bog down a modern processor.
Does Motorola need to get the G4 running faster? Certainly, Mac users as a group hammer their machines harder than typical Wintel users. But I for one am more impressed with faster done correctly, and as part of an overall improvement, rather than a goal unto itself. There is much more to a computer than clock speed, and this truth has finally caught up with Intel. Hopefully, some of the naysayers are watching.
Posted by John C. Welch at 12:14 | Permalink
Netscape 6 Final
created 19 Nov. 2000
Netscape 6, Is It Really Worth The Effort?
Okay, so here it is, after a few years of waiting, the successor to Netscape 4. Finally out of beta, I've been able to work with it for a while now, and the impressions, unfortunately, are consistent with my earlier impressions of the various PR, (Public Release) versions.
The installation went smoothly enough, although it did take four or five attempts for the initial download. I'm not going to get upset about this, I'm willing to bet that every router that's ever heard of netscape.com is being hammered pretty heavily right now. The install creates about 480 items in the Netscape Folder, and it takes up about 29 MB of drive space. This is less space than Communicator 4.7.X, although about twice as many items, and more space and files than for Outlook Express 5 and Internet Explorer 5. One instantly annoying part of Netscape 6 is that thanks to a new plugin architecture, which is evidently incompatible with 4.7.X's plugins, Netscape ships with only Java and Shockwave plugins, no Quicktime, or any other plugins are evidently available.
Initial impressions are the same as the PR versions. The HTML rendering is faster than 4.7.X, but not noticeably faster than IE5, with the exception of long text pages, which has always been a sore spot with IE. The appearance of Netscape 6 can be changed via Netscape's themes mechanism, and the final release ships with 2 themes, the new theme associated with Netscape 6, and the older, 4.7.X-ish theme. I personally don't have a problem with the new appearance, and find it cleaner in some ways than the 4.7.X appearance.
One problem I do have is with the fact that the interface itself is slow and buggy. Popup text hints for button usage take longer than for IE, and the amount of artifacts that get left behind by either the popup text, the dropdown lists, etc. are much higher than is acceptable for a non-beta product. Netscape's insistence on using a common interface is part of the problem here, but a bigger problem is that it appears that in its quest to be platform neutral, Netscape decided that it would be better to completely duplicate all window, and scrolling routines that already exist in any OS. The MacOS Appearance Manager settings are ignored, and a severe speed penalty in scrolling long pages seems to be one of the results of this. Other interface bugs include the inability, at least on my PowerBook's external monitor, to widen web and email windows past the width of the PowerBook's LCD screen. When switching between windows within Netscape, the refresh of the windows can take up to 3 seconds, which is annoyingly slow. Scrolling is jumpy, much more so than in IE or 4.7.X. Another entry in the interface/OS incompatibility problem list is the utter ignoring of the Internet Control panel/Internet Config that Netscape does. Considering that 4.7.5 finally started to use the MacOS internet preferences settings, and that Netscape 6 ships with out any pre-defined helper applications, this distancing of the product from the interface is all the more annoying.
But the worst offenses are in the area of keyboard equivalents. Now, to mark a message as read, instead of the 4.7.X keyboard command of CMD-/, the command is the letter 'M'. Not CMD-M, (which is still 'New Message'), or CTRL-M, or even OPT-M. Just 'M'. To mark all messages in a folder as read, you use the letter 'A'. I'm amazed at this, as it is not too hard to see where you could accidently hit the letter 'A' in a window, and mark all messages as read without wanting to. Considering that other email clients allow you to use letters to quickly jump to other folders, the use of unmodified alphabet characters for program functions is mindboggling in the potential for causing all sorts of problems. This insistence on 'doing it all ourselves', on platform neutrality at all costs has caused far more problems than it will ever fix. It seems to have made the product much more complicated than it should be for any reason, and caused an even more serious issue in the area of RAM usage.
Netscape 6 doesn't just use RAM, it inhales it. I normally double the manufacturer's recommended RAM allocation for any application. So for Netscape 6, I set the minimum RAM to 20MB, and the preferred size to 40MB. Just sitting there, with only my home page open, Netscape was using 29.5MB of RAM, which tells me that the default preferred RAM settings are too low to be functional. By the end of 3 hours of use, including IMAP email, and my standard web browsing, Netscape 6 was using 47.3MB of a new allocated amount 60.7MB of RAM. So at this point, even my doubled RAM allocation was too low, and Netscape had vampired an additional 20MB of RAM from the system. Even with only one browser window, simply changing web sites, scrolling, and refreshing pages drove the RAM usage up an additional 1.7MB, and stayed there, even with the program doing nothing, for over an hour, no surfing, no emailing, nothing. This seems to indicate a pretty radical memory leak, as with nothing going on, Netscape should have returned RAM back to the system. As a comparison, for my normal usage, I have both Internet Explorer 5 and Microsoft Entourage set to use 16MB of RAM each, and that's the limits they stay within. Netscape starts out with 8MB more than both of those applications, and needs another 20+MB of RAM in addition to do the same amount of work. This is simply not acceptable behavior for an application that is in its fifth or sixth iteration, and especially not for an iteration that has been in development for over a year now.
When it comes to email, Netscape 6 isn't even able to keep up with its predecessors, much less its competitors. Netscape 4.7.X allowed me to download over 3000 IMAP email headers in under 5 minutes over a 33.6Kbps modem. Netscape 6, on a cable modem that was giving me T-1 level throughput took 50 minutes to download 1500 IMAP email headers. In both cases, the email server was the same Netscape/iPlanet IMAP server running on Solaris on a dual UltraSparc server. Netscape 6's email filtering capabilities are essentially unchanged over 4.7.X's, and when compared to the filtering capabilities of products such as Outlook Express, Eudora, Entourage, or even Emailer, quite pitiful. The lack of LDAP address book capability limits Netscape even further, by removing a valuable and useful way of condensing company and university - wide address books into one, easily administered and maintained listing. To be blunt, the lack of LDAP is forcing not only my company, but the company of almost every administrator I've talked to into starting the process of either removing Netscape from the list of supported software, or freezing Netscape at the 4.X.X level.
This is the first version of Netscape I find myself unable to recommend in any capacity, unless you are a web designer, and need to preview pages with Netscape's Gecko HTML engine. However, judging by the opinions of most web designers that I know, they are probably just going to redirect Netscape 6 users to pages that are compatible with Netscape 3. This is due to Netscape's overly rigid requirements that HTML conform to current W3C standards. Don't misunderstand me here, compliance with those standards should be the goal of every web designer. But there is a lot of old code out there that will never be revamped, for various fiscal and time reasons. Unfortunately, if your code used Netscape 4.X specific tags such as the layer tag, Netscape 6 won't work with those pages. Being compliant with the current CSS, DOM, XML and other standards is good, but to be incompatible with older versions borders on ridiculous. Considering the public lambasting that IE5 took over not being too accepting of older HTML, for Netscape to be even more restrictive with it's HTML engine is incomprehensible, especially considering their current market share.
I'm disappointed that AOL chose to release as final a product that is so obviously not a final release. It may have been a large helping of crow to release a PR4 version of Netscape 6, but it would have surely been less than the crow AOL is going to eat with the first service pack fix for Netscape 6. I'm also saddened at the way that AOL is ignoring, and even thumbing their nose at any of the non-home user market with this release. While the business and Higher Education markets may not have been AOL's traditional markets, they were Netscape's, especially higher education. But it looks like AOL has ceded these to Microsoft, Opera, and iCab. I don't see how they can afford to do this, unless they really mean for this to be the last commercial browser released under the Netscape name, and for Mozilla to take all of this function as their own. If so, I will mourn the passing of one of the companies that helped make the internet a tool for all of us.
Posted by John C. Welch at 12:12 | Permalink
Integrating OS X
created 15 Nov. 2000
Integrating OS X into existing network systems
In the previous articles in this series, we've looked at connecting the PB to specific types of servers, AppleShareIP, Windows, Unix. But there's another aspect of network connectivity, and that is integration. In other words, besides just connecting to specific machines, how well does OS X fit in with other network management schemes? The answer is, it depends.
If you are talking about a NetInfo network, which is OS X's native networking management scheme, the answer is, almost perfectly. This is what we expect of course. OS X ships with NetInfo built into the OS. Indeed, most of the essential parts of the OS are managed via NetInfo. If you are running a NetInfo network, then OS X will fit in perfectly, with very few integration issues.
The problem is, not many networks are based on NetInfo. This is not a technical failure on NetInfo's part. As I have been digging up information on NetInfo, and wrapping my head around it, I am very impressed by much of what it can do. As a directory service, it is easily as capable as LDAP, or Novell's NDS, and head and shoulders above Microsoft's Active Directory. It uses a heirarchal domain model, ala LDAP and NDS, and one NetInfo domain can contain as many computers, printers and users as your server configuration will allow. But again, not many places use NetInfo, so we have to look at how OS X fits into other vendors systems.
NIS(+)
NIS, and NIS+ is the network management concept used primarily by Sun Microsystems. NIS, or Network Information Service allows for administrators to manage resources such as computers, printers, users, user rights, storage access, etc. from an NIS server. NIS runs on most Unix systems, and is widely used in the computing world. NIS+ is an enhancement to NIS that added encryption capabilities and security enhancements to NIS, and is usually only seen in Solaris networks, although it does retain backwards compatibility with NIS.
NetInfo in OS X can be configured to use NIS services, and ships with the basic components to set this up. I'm not going to go into the details here, as they can be quite extensive. An excellent 'howto' page can be found at http://www.bresink.de/osx/nis.html. This site not only covers the OS X public beta, but also MacOS X Server from 1.0 to 1.2, MacOS X DP4, and even Rhapsody DR2 for Intel, and there is some references to the Darwin OS as well. The NIS services in OS X currently allow for user/group management via NIS, and the site mentions how to set up the PB to automount any NIS home directories into the PB.
Having said that, there is almost nothing intuitive about setting up NIS in OS X, unless you have a solid background in NetInfo. Getting the necessary settings into NetInfo is a somewhat arcane and tedious process, and there is a very small, but necessary amount of config file editing required. As well, once you have set OS X up for NIS, if you boot it in a situation where you cannot connect to the NIS domain, then it will sit at the NIS part of the boot process, endlessly looking for the NIS domain. (It may time out eventually, I've only waited for a half-hour or so before rebooting.) This means that PowerBook owners, such as myself, get very good at EMACS and hostconfig files. Obviously, Apple needs to fix this process to a more intuitive way of connecting to NIS domains.
But once you get NIS working, it works fairly well, and doesn't seem to need a lot of care and feeding, which is the general idea.
LDAP
The next network management system that OS X supports is LDAP, or Lightweight Directory Access Protocol. The support here is less extensive than NIS, seemingly limited to user login authentication. Part of this may be due to LDAP's relative lack of experience as a network management directory, so I expect this will improve. Most of the available information on using LDAP with NetInfo is in this TIL from Apple. Even though LDAP is a newcomer to the network management arena, many other directory and management services are based on, or compatible with LDAP to varying degrees, such as NIS, Novell, and Microsoft.
LDAP has the advantage of being a public RFC, and as such is 'owned' by no one company, and you can find LDAP servers that run on almost every OS available, including one that runs on the current MacOS, ClickMail Central Directory, from Gracion Software. If you are unfamiliar with LDAP, and would like to know more, Gracion's site is a good place to start, as it explains many of the basics of LDAP in a concise, understandable manner.
Novell NDS
Third on our list of network management systems is Novell Directory Service, or NDS. This is not yet shipping, but was announced on November 7th. The actual product name is Native File Services for Macintosh, and will be a downloadable addon for NDS 5.X, and a native part of NDS 6.0. It promises to provide native support for MacOS clients on the server side, with no client software needed on the Macs. It will integrate Novell Modular Authentication Services with Apple's own authentication systems, and provide not only access to network storage, but user management and directory access as well. The product should be shipping in the first quarter of 2001, so you may be able to get a look at it at MacWorld Expo in San Francisco.
Again, this is only an announcement, not a shipping product, and as Mac administrators well know, especially with Novell's history of Mac support, much can change in 6 or so months, but it's a good announcement, and would give Novell an essentially uncontested foothold in the MacOS market. What that will translate to remains to be seen, but it's evidently quite tempting for Novell at least.
Microsoft AD
Our final entry is Active Directory from Microsoft. This is a quintessential Microsoft management product in that it really doesn't support much outside of Windows PCs beyond very basic file and print services. Luckily, it seems to support LDAP reasonably well, so you may be able to get away with having your OS X boxes treat the AD servers like LDAP servers. I have yet to really try this, but if anyone does, then please, let me know how it works.
I've probably left out a few other systems, but we've covered the 'big four' as far as MacOS X is concerned. It is good that systems other than NetInfo are supported natively, although the implementation procedures need a lot of work. The Novell announcement is good news for administrators using that system, or considering it, and if Microsoft's LDAP support is close to as complete as they indicate, then there is a way to at least partially integrate OS X into AD networks, although the reality of this remains to be seen. OS X is still a beta, so there is time for Apple to create proper interfaces for integrating with NIS and LDAP, and I would really like to see NetInfo made a lot more intuitive to use. I'd also like to see Apple release a LOT more documentation on NetInfo than it has. But the basics are there, so that's a good start.
Posted by John C. Welch at 12:10 | Permalink
OS X To Unix
created 30 Oct. 2000
Connecting OSX to Unix
Well, last time we talked about connecting the OS X PB to Windows machines, and the products available to test for that purpose. This time we are going to focus on connecting to Unix networks.
There is an interesting dichotomy here, as this is both some of the easiest, and most convoluted connections of the group.
First off, the standard Unix connection tools are all here, telnet, rsh, rlogin, ftp, nfs, lp, etc. Things like Telnet, rsh, rlogin are all currently command line only applications, although the Carbon version of MacTelnet is due quite soon now, and even in its current state, shows great promise, as it is scriptable, something the command line remote access tools are not.
This is of great benefit to those of us with time, effort and money invested in AppleScript, as porting those to various shell scripts would be non-trivial in both time and effort. For those of us who are used to things like shell scripts and PERL, the PB includes those capabilities as well, so that regardless of your scripting preferences, you have all the basic tools you need, although I imagine that AppleScript will give you better access to the GUI elements and the applications that aren't command line applications. Apple is being good about giving us low level access to AppleScript, so that regardless of your language choices, you should be able to integrate that language into AppleScript in some fashion.
FTP is there as well, again, no big shock, this is a Unix based OS. For those of you who prefer a GUI - based FTP client, (like me), there are products such as Transmit, from Panic. You can of course use web browsers for downloads, but I prefer the functionality from an FTP client. Although there are more Mac FTP clients available, as of yet, only Transmit has been Carbonized. As with things like MacTelnet, the primary advantages to a product like Transmit are that you don't need to start dealing with command lines, and you get AppleScript.
The next connectivity issue is NFS. At the moment, this is primarily one way, that is, the PB can easily mount other Unix NFS shares, but sharing PB drives is a bit trickier. This is primarily due to unresolved issues with NFS and HFS+. If you use UFS for the PB, you avoid the NFS issues, but you loose the ability to run the Classic environment, so it's a trade-off. As well, although I have found a reliable method for accessing other NFS drives, I haven't found a reliable method for creating NFS mounts in the PB, so I'm waiting for either Apple, or a third party to handle this.
In any event, the NFS procedure I use is relatively simple. You have to start NetInfo Manager, and unlock it. To unlock it, you must authenticate as root, with root's password. Considering that unlocking NetInfo unlocks the 'keys to the kingdom', this is a sensible precaution. Once in NetInfo, you will want to select the /mounts directory. This should be empty. You will want to create the following properties and values, one for each mount:
- property: value
- vstype: nfs
- dir: (local directory where the remote share attaches, i.e. /Network/public)
- name: (remote server and that server's share, as computer:/sharepath, i.e. server:/home/myhomedirectory)
- opts: bg
A sample NetInfo screen shot is shown below, (names changed to protect the innocent.)
One thing to make sure of is that you create the dir parameters manually. I personally create the destination/local directory before I create the mount entry. Once this is done, then you should be able to access the remote files from within the Finder window. I found that I sometimes had to reboot to see the mount, but this wasn't consistent. I presume this will not be required in the release. Another note is that the remote volume does not show up on the desktop in the same manner as AppleShareIP volumes. I would sincerely hope that Apple allows for this behavior to be selectable. That way, both Mac and Unix people can have the behavior they expect from remote volumes. Finally, because you statically create the destination directory, even if you are not on the network, the directory is still on your Mac, albeit empty. For those administrators with Unix experience, this is the norm, for the Mac administrators without this experience, this will be something new to watch out for. This works very well with Sun Solaris boxes. I have not had a chance yet to test it with Linux or SGI shares. It should work okay, although there does tend to be issues with the way Linux and SGI approach NFS. These aren't insurmountable, but beware of them.
The final connectivity protocol we'll look at is the X Window System. This is the basis for most Unix GUIs, and is also the primary method for running applications that physically exist on other servers in the Unix world. Before we start with X products for OSX, a brief overview of what X is should be looked at. (I would like to thank Sandy Nicholson for this explanation, posted as a comment to an earlier column I did.)
2. An `X server' is a program that implements the X protocol on a given computer, by actually rendering graphics and text for you to see, and by converting your mouse clicks and key presses into appropriate X protocol messages.
3. An `X client' is any program that communicates with an X server (using the X protocol), in order to interact with the user of the machine on which the X server is running. To the end user, it appears as though each X client is running on their machine, though in fact some or all of them could be running remotely.
4. An `X window manager' is a specialized X client, often (but not necessarily) running on the same machine as the X server. It provides basic window management functionality (things like raising and lowering windows, moving them around and iconizing them). To use X, you don't actually need to use a window manager, but it's pretty awkward if you don't!
Okay, so the X-Window app I have been playing with is Tenon Intersystems' XTools. This is a commercial X Window product that allows you to run X applications, such as GIMP, Netscape, etc. on your OS X Mac, or other computers to run X applications that reside on an OS X Mac. For example, there is no Carbon or Cocoa version of Netscape 4.7.X. So, without XTools, I am stuck with trying to use the Classic version, or booting into OS 9 to use Netscape, or trying to run the Carbonized version of Mozilla. But with XTools, I can log into one of our Unix servers, and run the Solaris version, shown below.
So with XTools, or the free port of XFree86, I can run any X application that exists on my network, from Netscape to MatLab, to IDL, and the only slowdown is if the network is running slow. This gives OS X users access to an exponentially higher range of applications that span the entire spectrum of application types, from vertical market high-end applications, to games. Admittedly, this capability existed for OS 9, with similar products such as