SYNCHRONIZATION STRATEGIES FOR IP NETWORKED HOME AUDIO EQUIPMENT
TOM BLANK AND ROBERT ATKINSON
Microsoft Corporation, Redmond, WA, USA
By using Internet Protocol (IP) interconnections for both audio/video (A/V) media movement and control, personal computers and A/V devices can seamlessly interact. This allows a variety of previously difficult scenarios -- such as whole house audio -- to be easily implemented. However, the non-isosynchronous (not all running on one common clock) IP network design must be overcome. We describe a variety of techniques that can coordinate IP interconnected home A/V devices to sufficient accuracy so that speakers and displays can synchronously render common content. Both hardware and software techniques are described. Our software implementation achieves sufficient accuracy for multi-channel synchronization and lip-sync. and would have the lowest implementation cost. Tests on different IP network technologies and load conditions demonstrate the software solution quality. We dont envision significant changes to the existing power distribution network. For the data network, we believe that the Internet Protocol (IP) is the best candidate to unify all device interconnections in keeping with the ongoing computer revolution. However, using IP networks for A/V pose a number of challenges: IP networks have no timing guarantee, Device physical locations are unspecified by their connection point (e.g. which speaker is the front left is not specified by its use of an 802.11g wireless network), Relationships between devices are not assigned by dedicated wiring. In a previous paper,1 we described an audio system that overcomes these limitations. The system completely used an IP wired 10BaseT interconnect implementing a 5.1 surround sound system down to the individual speakers. For example, a PC acting as a jukebox would stream the audio information over the IP network to the six individual speakers. The basic solution uses the following approach: 1) All devices synchronize their clocks to a clock master 2) The A/V source (e.g. the jukebox) transmits all A/V packets with a rendering timestamp that is sufficiently far in the future so that all devices will have suficient time to both receive and render the packet at the specified time. 3) The A/V rendering devices receive and buffer all packets until the specified time.
INTRODUCTION Computer systems and Consumer Electronic components are starting to converge with numerous products bridging the gap between the two environments. Ideally, the convergence would yield a world with only two home networks: one for power (e.g. 120 or 220VAC) and one for device intercommunication. Our primary motivations include: Simplicity A new home consumer electonic device should have only two logical connections: power and data (inlcuding control) which is simple to install correctly. Our model contrasts the current home media systems with a plethora of point to point connections (e.g. front left speaker to the front left speaker output on the A/V receiver) and connection types (e.g. S/PDIF, HiFi, optical, speaker, etc.), Convenience The new system allows any source device (e.g. tuner, DVD player, etc.) to connect to any rendering device (e.g. speakers or displays). This complete interconnection freedom allows previsously difficult scenarios like whole house audio or watching the living room DVD jukebox in the bedroom to be easily implemented. Extensibility the new system can be easily expanded simply by adding the new components to the network and letting the system automatically reconfigure itself.
CONVERGENCE~THE IMPACT OF COMPUTERS & NETWORKING ON FUTURE AUDIO TECHNOLOGY AES 19

UK CONFERENCE 2005

BLANK AND ATKINSON
4) The A/V rendering devices play the material at a rate locked to the source device. Without adequate clock synchronization, the system cannot work. The necessary level of clock synchronization is based on the consequences of time missalignment on a A/V system. The following are a few important facts conerning audio, video, and human responses: 1) Sound travels in air at very roughly one foot per millisecond. 2) Lip-sync between audio and video is maintainted if the delay between an image flash and the arrival of the correlated audio event meets the following constraint: -20ms < delay < +40ms.2 3) The AES11-1997 standard specifies a 1 s clock accuracy for digital studio operations. 4) Humans can detect interaural click arrival differences down to roughly the 10 s level. Therefore, multichannel sound alignment imposes a more difficult design requirement than the lib-sync requirement (Unfortunately, we have discovered no studies that provide a detailed analysis of timing requirements for multi-channel audio playback). However, the speed of sound provides a critical reference point: a 100 s missalighment would represent approximately a 1.2 inch speaker missplacement. We argue that any speaker displacement this small would be very difficult to hear. Thus, a clock sychronization goal on this order of magnitude will be sufficent for our target, home use. The remaining sections of the paper describe different approaches and issues to achieve clock synchronization in a home networking environment down to the 100 microseconds level. The next section outlines both hardware and software time synchronization techniques. QUALITY TIME AND SYNCHRONIZATION TECHNIQUES There are a number of possible approaches providing high quality time synchronization within a home network. The ideal solution has both low cost and high frequency accuracy. Hardware Synchronization Options Numerous hardware options are possible but all have the same basic approach: all the hardware devices have a receiver tuned to a common synchronization source.

Table 1 provides representative examples and a brief comparison. The ability to receive a Time-code partitions the possible hardware solutions into two important groups. The solutions that dont receive the actual time only provide frequency a lock. Therefore, an additional software mechanism is required to provide the phase alignment (e.g. the time reference) which increases the complexity of the complete solution. The primary strength of the hardware based solutions is that a number of the solutions provide very precise time synchronization better than the microsecond AES studio time synchronization requirements. The primary weaknesses include the additional hardware costs and difficulty using some form of a transmitter/receiver pair. All hardware approaches have additional cost. In contrast, the software solutions described in the next section have negligible incremental cost (just more software and a slightly larger ROM) since the system must already have a software system as an IP network device. Therefore, if a software solution can be found that provides sufficient time accuracy, it offers considerable advantages. Software Synchronization Options Software synchronization techniques have two basic components: a local precision time source and a method to compare the local clock with the synchronization peer(s). The following sections describe alternatives and suitable solutions on a PC based platform. Specifically, the next two sections describe PC clocks and counters. Finally, a brief overview of the NTP (Network Time Protocol) is provided. PC Clocks Modern PC clocks are implemented using a hybrid approach which combines a battery backed-up clock using an inexpensive crystal (typically +/- 100ppm), and the operating system (OS) periodic scheduling interrupts. The OS reads the hardware clock once at boot time then stores the value in an internal memory location. The OS clock value is then updated at the scheduling interrupt rate (typically 64 to 1000Hz) where the Hardware Abstraction Level (HAL) provides the number of microseconds (the exact precision is implementation dependent) since the last interrupt. Applications that request the OS time get the stored value that was updated at the last clock scheduling interrupt.
CONVERGENCE~THE IMPACT OF COMPUTERS & NETWORKING ON FUTURE AUDIO TECHNOLOGY AES 19TH UK CONFERENCE 2005
GPS Receiver PowerLine Sync. AM Radio Receiver Cell Phone Receiver

Basic Mechanism Receives satellite signals Phase locks to power line zero voltage crossings. Everyone phase locks to a common radio station. Snoop on cell phone sync broadcasts. All clients phase lock to a home transmitter e.g. 802.11 or custom signal
Timing Resolution ~ns 1/60 or 1/50 second ~s
Frequency Stability Excellent Short term is poor. Over 24 hours is Good. Excellent

TimeCode Yes No

Primary Strength Best universal time system Low cost
Primary Weaknesses Requires outside antenna with clear view of sky. Poor timing resolution. Requires clients to elect station that everyone can receive. Regulatory issues. Standard will change as cell phone tech. changes. Expensive. Network access is charged-for service. Wireless versions have weak signal strength to meet home transmitter government rules. Wired versions have strong signals but require additional wiring. Not a global solution.

Low cost

Excellent
Widely accessible quality time. Simple and reliable
Home Transmitter (wireless or wired)

~s - ns

WWV Receiver
Clients tune to NIST time broadcast.

Very Good

Simple and low cost
Table 1 - Example Hardware Synchronization Techniques Unfortunately, this hybrid approach doesnt provide very precise time since the accuracy is a function of the system scheduling interrupt rate and the quality of the system clock crystal. Applications that require better than tens of millisecond timing precision always use counters described next.
CONVERGENCE~THE IMPACT OF COMPUTERS & NETWORKING ON FUTURE AUDIO TECHNOLOGY AES 19 TH UK CONFERENCE 2005
PC Counters PC Timing mechanisms have evolved from external programmable interval timing chips (e.g. an 8254) to integrated processor chipset functions. Two mechanisms have emerged as the best timing sources for timing measurements in current generation PCs: The processor Time Stamp Counter. This hardware register in the microprocessor counts the number of CPU cycles since system start. This value is accessible using the RDTSC instruction. The advantage of this counter is that is runs at very high speeds in current generation processors and is very fast to access (see Table 2). However, there are two critical disadvantages: the cycle time of many modern processors is dynamically and frequently modulated based on the necessary workload to minimize power consumption and/or heat; secondly, multi-core processors are becoming the standard where each has its own Time Stamp Counter. Typically, the processors will run off of the same crystal but the values will be different due to different startup sequences and power saving events. The system Performance Counter is a software abstraction provided through Microsoft Windows APIs through the QueryPerformanceCounter (QPC) routine. The exact mechanism used is HAL dependent but the behavior is well defined: o Monotonically increasing ticks at a fixed frequency which is readable. o Provides a single value common across multiprocessor systems. o On newer generation machines has a frequency greater than 2 MHz. Other timing mechanisms exist in Microsofts Windows such as GetTickCount, and GetSystemTimeAsFileTime. However, these functions provide resolution which is interrupt rate dependent which at the highest rate only provides 1 ms ticks.

When making precision timing measurements, the clock/counter accuracy, resolution, and access time are all important in determining the measurement quality. Table 2 shows detailed measurements for both the RDTSC and QPC operations across a variety of CPU types. As mentioned earlier, the implementation of QPC is not only a function of CPU type but also of the HAL implementation. This table provides representative samples. Table 2 provides one critical observation: the mechanisms all provide timing resolution at the microsecond level or better. Therefore clock synchronization techniques are bounded at roughly the microsecond level which is more than sufficient for use in A/V consumer synchronization. The Network Time Protocol The Network Time Protocol (NTP)3 allows time clients to query a server for the proper time (See 4 for a History of NTP developments). Based on the premise that on average, the forward and reverse network times and OS times are equal, a time difference can be calculated as shown in Figure 1Error! Reference source not found. If any asymmetry exists in either the network or OS processing path, the difference will be included as part of the clock offset. Equation 1 provides the time offset between two machines. Equation 2 provides the network delay (note: the delay computation is accurate independent of the clock offsets).

Offset

(t 2 t1) (t 4 t 3) 2
Delay (t 4 t 1) (t 3 t 2)
Figure 1 - NTP Packet Timing Diagram
Processor Type P-III 1 Ghz CPU Frequency (GHz) QPC Frequency (MHz) RDTSC Latency (clocks) RDTSC Latency (s) QPC Latency (clocks) QPC Latency (s) User-Kernel transition (clocks) User-Kernel transition (s) KeQPC Latency (clocks)* KeQPC Latency (s)*

Notes: -

Athlon XP 1.5 GHz

P4-M 1.6 GHz

P4 3.2 GHz
Prescott Athlon64FX Opteron 2P 3.2 GHz 2.2 GHz 2.2 GHz

.99758 3.0.1.0.1.1147

1.5336 3.0.0.0.0.6149

1.5954 3.0.1.0.1.0361

3.88 0.0.0.0.0388

3.104 0.0.0.0.0451

2.201 3.0.1.0.1.4057

2.8 0.0.0.0.0041

Kernel QPC costs are estimated by subtracting the user-kernel transition time from the user mode QPC time On systems where QPC freq == CPU Freq, the QPC is implemented using the RDTSC instruction. Times where the QPC frequency is 3.58 MHz uses an 8259 Programmable Interval Timer All data was taken using Windows XP SP2.
Table 2 - Timer Performance Measurements Once the offset has been determined, the client adjusts its clock to minimize the offset. A technique for clock adjustment will be described latter. The accuracy of the offset measurement technique is primarily bounded by the following: 1) clock accuracy 2) timestamp accuracy 3) asymmetric network delays Weve described the clock access accuracy bounds in the microsecond range for accessing a counter (e.g. QPC). However, the stability of the clock also affects the system behaviour. Typically, inexpensive crystals are used in consumer equipment with +/- 100ppm specifications over their specified temperature operation range (typically -20C to +65C). This specification bounds both the device-to-device variation and the variation over the temperature range. Since consumer equipment is typically operated in human-acceptable environmental conditions, smaller variations are typical. The timestamp accuracy depends on the systems ability to receive an IP timestamp packet, read the clock, and put the timestamp value into the packet. The greatest variance lies between the network adapter

receiving the packet and the moment when the clock is read. The dominant variances are: Stamping software location The routine can be located either in the kernel (e.g. a Windows NDIS driver) or as a user mode program. System performance on older systems (e.g. 500MHz vs. 2GHz), the time for a kernel to user mode transitions and general OS maintenance can be tens of microseconds.
network loads will vary from basically zero to potentially heavily loaded causing substantial network delays which may be highly asymmetric. The critical observation is that a lightly loaded system provides small delay values which we believe will provide the best offset measurement since the network asymmetry should be the smallest. Data measurements in the next section prove this conjecture. HOME NETWORK MEASUREMENTS
Asymmetric network delays also provide a difficult challenge since they are a function of many variables including network interconnection technology, vendor networking components, end devices, and network usage. The most common home network interconnect technologies are: wired Ethernet, wireless 802.11b, 802.11g, 802.11a, and powerline (e.g. IP connections over home power wiring). Common home networking components include switches, home routers, and adapters (e.g. Ethernet to powerline). End devices include PCs, media servers, fileservers, and a growing number of IP connected A/V devices. For typical home networks, the number of network components and connected devices today total less than ten even for large homes. Network usage is highly variable in home networks where the typical variation is from zero network load (e.g. when people are sleeping) to a heavy load network when streaming audio and video or copying a large file between machines. A simple file copy between two machines can consume half or more of the network bandwidth on a 100 Mbps link. When streaming new high definition TV signals, each one may use roughly 20 Mbps, again providing substantial load. The challenge is that the variable load in the network devices significantly changes the number of packets in the network device queues which significantly affects the network delay. Unfortunately, these network delay changes can be very asymmetric. However, we can surmise that the lowest network delays will likely have the smallest asymmetries (and certainly the smallest asymmetry variance) since they are subject to the least queuing. The next section will empirically support this. Interestingly, the size of these changes on a home network can be significantly larger than the changes on typical Internet paths since the large number of Internet users tends to keep the network loads at a more uniform level. Overall, with current computer systems, clock accuracy is far superior to the network asymmetries and packet time stamping issues. In typical home networks,

In this section, we measure three representative network configurations to analyze network and time stamping behaviour. Three configurations were tested: a direct 100BaseT wire interconnect, a one-hop 802.11a wireless link through a router, and finally a HomePlug 1.15 IP over powerline carrier device. The data for all the tests are summarized in Table 3 with representative graphs in figures 2-4. In order to calibrate and measure the software measurement errors produced by our network synchronization algorithms, we constructed a combined hardware/software test system. We used two basic laptops (~2GHz machines) each with a FPGAbased custom hardware clock on an external module connected using the PCMCIA interface. In addition to the network connection between the two processors over which the synchronization algorithm was executing, this hardware design provided a direct backchannel connection between the two hardware clocks. Use of this back-channel connection provided a highly accurate hardware-implemented measurement of the degree of synchronization actually achieved by the algorithm. Hardware access times were below 400ns providing suitable accuracy for microsecond measurement accuracy. The test software used a Windows NDIS driver to access the packets in the kernel as quickly after receipt as possible. Further, we used the FPGA clock which was running at 30 MHz. The first and simplest network configuration tested directly connected two PCs together with a 100BaseT interconnection using a simple 100BaseT cross-over cable. Such a configuration obviously has no network asymmetries; therefore, all variations observed are due to the previously described time stamping issues. The first row of Table 3 and Figure 2 show the results. These data were recorded under a 10 Mbps unidirectional load flowing from the time server to the client.
For this direct connection test, the Network Asymmetry vs Sample # graph shows significant outliers, but most have only positive asymmetry; these we verified were caused by the unidirectional load. This impact of load on the asymmetry of the network is a reoccurring phenomenon in all the tests and is due to the probability that a timing packet was delayed due to being queued with data traffic. On the direct connection Network Asymmetry vs. Network Delay graph, note the rough cone shape that starts at a delay of 135us. As the network delay increases the width of the error cone correspondingly increases. In contrast to the Asymmetry vs Sample # graph the slight negative bias is not influenced by the load direction. The striations of width roughly 1.7 s in the delay is as yet unexplained. However, the key observation is that the error is both bounded and small if only packets with a small delay are used. The second configuration illustrated uses an 802.11a network in combination with a home router (see Table 3 row two and Figure 3). In this test, the first 5000 samples were taken without any network load, then for the test remainder, a 10Mbps unidirectional load started. Notice that the scales on these graphs are significantly larger than for the preceding 100BaseT case showing roughly a factor of ten larger delays, asymmetries, and Test Configuration

variances. In this test, the error distribution is more normal; this allows the statistical processing of the synchronization algorithm to achieve higher quality. Again, the asymmetry verses delay graph shows the characteristic cone which grows proportionally with delay. Two distinct clumps of data are evident; these are have been verified to be a function of processing internal to the wireless network; they are due neither to the router nor the direction of the imposed load. The final test configuration uses a first generation powerline carrier device (see Table 3 row three and Figure 4). Since the peak achievable data rate of this technology (note the devices were located next to each other on a simple power strip) is only 6 MB/sec, a smaller load was used than in the previous tests. In Figure 4, the graph Asymmetry verses sample number clearly shows three distinct unidirectional load phases: no load (0-4000), a 2 Mbps load (400014000), and a 4 Mbps load (14000 end). In Figure 4 the sample # graph, the cluster of points with 16ms error are a function of the microcode implementation of the powerline device. On the delay graph, the square cluster of points are again a function of the microcode implementation and show the strength of the using the delay as an approach to chose data points with low network asymmetry. No Load Mean STD. Asym DEV. (ms) Asym (ms) -0.01 0.02 -0.09 0.65 0.11 0.39 Loaded Mean STD. Asym DEV. (ms) Asym (ms) 0.01 0.04 -0.11 1.62 0.80 4.82

Peak BW (MB/sec) 6

Min Delay (ms) 0.12 1.11 1.81
PC1PC2 PC1Router ++AirAdapterPC2 PC1 PowerLine1 ** PowerLine1 PC2

Notes:

Load statistics were collected at 10 Mbps using 1.4 MB packets except for the powerline test which were run at 4 Mbps. All wired connections used 100BaseT interfaces (shown with a in the table) Only 802.11a Air links were used (shown with ++ in the table). Powerline carrier links are shown using ** in the table. Equipment list: o Router: Linksys WRT55AG Version 2 o AirAdapter: 100BaseT to 802.11a Linksys WGA54AG o PowerLine1: Linksys PLEBR10 version 2 (HomePlug 1st generation) o PC1: Compac Evo N800c (2GHz system with 512MB) o PC2: Compac Evo N610c (2GHz system with 512MB)
Table 3 - Representative Network Configuration Statistics
Network Asymmetry (us) vs Sample # 0 -50 -100 -8000

-5 -10 -15 -20 -120 140

Network Asymmetry (us) vs Delay (us)
Figure 2 - Wired 100BaseT Network Asymmetry
Network Asymmetry (us) vs Sample # -2000 -4000 -35000
Network Asymmetry (us) vs Delay (us) 1800 -20 -40 -60 -80 -2400 2500
Figure 3 - Wireless 802.11a Network Asymmetry
Network Asymmetry (us) vs Sample # -2000 -4000 -6000 -8000 -15000 20000
-200 -400 -600 -800 -Network Asymmetry (us) vs Delay (us)

Figure 4 - PowerLine Network Asymmetry The primary observations to be made from this data are the following: Both the mean and error standard deviation change as a function of load. Simple data sampling approaches likely fail to achieve errors in the low tens of microseconds Using the network delay as a surrogate for error is highly correlated.
A NTP Implementation Optimized for Home Networks The following sections describe an NTP implementation optimized for home networks using the previous home network observations. The work of Mills6 and Levine7,8 guided the approach. Our goal was to provide as close as theoretically possible time synchronization across a variety of home networks. Based on the previous data, we targeted accuracy better than one hundred microseconds across a range of network configurations. To achieve this goal, we removed as many operating system variances as possible and used a precisions clock. Specifically, we implemented an NDIS driver for packet time stamping and used the performance counter (both were also used in network measurements described earlier). We also used the basic structure proposed in the NTP RFC with prefilters connected to the primary clock control loop. The prefilters eliminate suspected bad samples and the clock control loop takes the input sample and adjusts both the phase and frequency of the local clock. Our implementation uses three prefilters: InsaneData, PercentMinDelay, and MinDelaySelector. The InsaneData prefilter eliminates illogical data such as a packet with packet with negative network delay (see equation 2) following RFC-1305. The second prefilter, PercentMinDelay, builds on the home network observations. This filter tracks the lowest historical round trip network delay observed within the previous 24 hours; the history is restarted if the system looses network connectivity. As the synchronization algorithm runs, packets containing time offset measurements are only passed if the network delay they experienced was less than 150% of the historical smallest network delay; packets not passing this test are entirely discarded. This heuristic seems to have reasonable balance between eliminating too many samples and allowing the previously described error cone to become too large. The third prefilter, MinDelay, simply selects the packet with the lowest delay value within a polling group (see below) since there is high correlation between delay and network asymmetry error. This packet is then forwarded to the Clock control loop. Our implementation of the clock control loop is a hybrid of the Mills and Levine approaches. The following are its key attributes:

At each polling interval, a burst of a small number packets (e.g.: 5-10) are sent with relatively small inter-packet spacing (e.g.: 100ms). We term such a burst packets a polling group. Classic NTP implementations send only one packet per polling interval. At startup, after one polling group, we step the clock to the detected offset (note, this is highly prone to error). After a user selectable startup interval, the frequency difference is measured and the offset slewed to zero. If the polling interval is less than 40 seconds, then a classic second order type II phase lock loop is used with a damping coefficient of 0.7 and a natural frequency of 600 times the polling interval. If the polling interval is more than 40 seconds, a straight forward implementation of the Levine Frequency Locked Loop is used with an Allen Intercept Point9 value of 180 seconds. This intercept value was a compromise selected based on typical consumer grade equipment design and typical home temperature variation estimates.
This hybrid implementation works well across a variety of home networking scenarios. The performance is described in the next section.
Crystal quality and the typical physical environment determine the Allen Intercept Point. The problem is that an A/V device may sit close to an air-conditioning vent where substantial temperature swings (e.g. 1 degree centigrade per minute) are possible as the heating/cooling system cycles during the day. Typical consumer devices use inexpensive quartz crystals that may have a +/- 100ppm variation over an 80 degree centigrade temperature range. The simplest problem is that the base frequency will start with an offset between two devices (typically less than 50ppm difference). However, the more challenging problem is the temperature dependent frequency variations causing the clocks to drift apart. The exact function is manufacturer and operation dependent with a typical number less than.5 ppm per degree centigrade around room temperature. Even though the temperature change has a relatively small impact, over time, even a small difference will quickly become noticeable. For example, a 1 ppm clock difference adds an additional 1 ms error every 17 minutes.
CLOCK PERFORMANCE MEASUREMENTS Table 4 shows the performance tests of our clock synchronization over a variety of different physical network configurations. The mean error column represents the calculated average value over the entire test duration. The standard deviation error is also derived from the error measurements. Only the test probe network traffic existed in the no load case. In the loaded case, 10 Mbps was used except for the Powerline1 case which used 4 Mbps. The first three configurations all use wired 100BaseT interconnections through direct cabling, a switch and router. All tests were run using a polling group size of five with a polling interval of 4 seconds. The load tests were all run at 10Mbps using a packet size of 1.4 MB. All three tests show similar behavior indicating that neither the switch nor the router add much variance or contributed to a shift in the mean. Note that both the mean errors and standard deviations have been greatly reduced from what they otherwise would have been by the combination of the prefiltering and clock maintenance algorithms). Compare the mean network asymmetry in Table 3 to the mean clock error in Table 4. For example, in the simplest case of a direct wire interconnection under load, the average network asymmetry error (Table 3) remained the same at roughly 10s verses the average clock error (Table 4)

whereas the standard deviation error was reduced 30s to below 10s. For the 802.11a wireless link, again the mean and variances were greatly improved. Under load (the same as in the wired tests), the average error improved from -110s to 4 s and the standard deviation error from 1620s to 33s. The first generation powerline product load test was performed at a different rate (4 Mbps) since its peak was substantially lower than the other technologies. This technology also showed over a factor of ten improvement in both mean and standard deviation errors. A final powerline test was done using a beta test powerline unit from Corinex Communications (AV200 Powerline Ethernet Adapter). Even though this prototype wasnt using the final chip set, it showed far superior data throughput performance over the first generation powerline product. With a peak sustained throughput of 64 Mbps, it was easily capable of sustaining the 10 Mbps load condition of the other high performance networks (e.g. wired and 802.11a). However, it did have the largest error and variance but this certainly could be the result of the beta firmware. During this test, we lengthened the polling interval to 64 seconds since the measurement variance was so high. This interval solely used the frequency locked loop approach which is less sensitive to large measurement variances than the PLL approach. No Load Mean STD. DEV. Error (us) Error (us) -8.5 3.2 -2.5 3.8 -3.5 3.1 -14.5 3.3 -1.1 16.0 47.8 237.7 Loaded Mean STD. DEV. Error (us) Error (us) -11.3 7.8 -6.5 4.1 -b6.0 2.5 3.9 32.8 6.2 38.0 415.7 417.0
Test Configuration PC1PC2 PC1SwitchPC2 PC1RouterPC2 PC1Router ++AirAdapterPC2 PC1PowerLine1**PowerLine1PC2 PC1 PowerLineBeta **PowerLineBetaPC2

Notes:

All wired connections used 100BaseT interfaces (shown with a in the table) Only 802.11a Air links were used (shown with ++ in the table). Powerline carrier links are shown using ** in the table. Equipment list: o Router: Linksys WRT55AG Version 2 o Switch: CentreCom FS708 o AirAdapter: 100BaseT to 802.11a Linksys WGA54AG o AirPCI: LinksysWPC55AG o PowerLine1: Linksys PLEBR10 version 2 (HomePlug 1st generation) o PowerLineBeta: Corinex AV200 Powerline Ethernet Adapter (beta test unit) o PC1: Compac Evo N800c (2GHz system with 512MB) o PC2: Compac Evo N610c (2GHz system with 512MB)

Table 4 - Time Synchronization Tests
None of the tests used packet link prioritization techniques used like 802.1p, or 802.11e. As these new prioritization schemes become standard, even higher quality time synchronization should become possible since there should be nearly no difference between the loaded and unloaded cases. CONCLUSIONS We have described a variety of both hardware and software techniques that can be used for clock synchronization in home networked systems. Even though some hardware solutions can deliver very tight time alignment, we believe that a software based solution provides an adequate and very cost effective solution over a wide range of home network technologies including wired, wireless, and powerline. Our software time synchronization approached used a combination of: a precision PC timer, group polling, prefiltering, and either a phase locked loop for short intervals or a frequency locked loop for larger intervals. The two critical prefilters were both based on the observation that home networks have large network variations ranging from no load to potentially very large loads and that the network asymmetry (critical to our time difference measurement) was strongly correlated to the network delay. Therefore, we built our prefilters to only use polling packets that have small network delays. Using our approach, we achieved time synchronization results that had both mean and standard deviation errors in the low tens of microseconds except for the beta test second generation powerline carrier unit which we believe will be dramatically improved with the final microcode that includes prioritization technology. With time synchronization over a variety of home network technologies solution, weve demonstrated that A/V media can stream in a synchronized fashion down to the individual speaker even for multi-channel audio systems. Audio/video lip synchronization has less stringent requirements so is also solved. This technology provides the basis for a unified Audio, video, and computer interconnection system providing a platform for many new consumer scenarios.

ACKNOWLEDGEMENTS Richard Russel in the Microsofts Performance Measurement team provided the detailed QPC and RDTSC measurements. Also, Judah Levine (NIST) provided excellent phone consultations. REFERENCES: Tom Blank, Bob Atkinson, Michael Isard, James D Johnston, and Kirk Olynyk, An Internet Protocol (IP) Sound System, in Audio Engineering Society 117th Convention, October, 2004.
2 Wilkinson, James H., Communications in the Digital Audio Studio, Paper 7-038; The AES 7th International Conference: Audio in Digital Times; pp 263-267, April 1989. 1
Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992. Mills, D.L., A Brief History of NTP Time: Memoirs of an Internet Timekeeper, ACM SIGCOMM Computer Communications Review, vol. 33, issue 2, pp 9-21, April 2003.

See www.homeplug.com.

Mills, D.L, Adaptive hybrid clock discipline algorithm for the network time protocol, Networking, IEEE/ACM Transactions on, Vol. 6, Issue: 5, Pages: 505 514, Oct. 1998.
7 J. Levine, An algorithm to synchronise the time of a computer to universal time, IEEE/ACM Trans. Networking, vol. 3 no. 2, pp. 42-50 Feb. 1995
J. Levine, Time Synchronization of the Internet Using an Adaptive Frequency-Locked Loop, IEEE Trans. On Ultrasonics, Ferroelectronics, and Frequency, Vol. 46 no 4, pp 888-896, July 1999.
D.W. Allan et al., "New inexpensive frequency calibration service from NIST," in Proc. Syrup. Frequency Contr. (Baltimore, MD), June, 1990, pp. 107-116.

Installing the Game Adapter

Set up the Game Adapter

Insert the Setup Wizard CDROM into your CD-ROM drive. The Setup Wizard should run automatically, and the Welcome screen should appear. If it does not, click the Start button and choose Run. In the field that appears, enter D:\setup.exe (if D is the letter of your CD-ROM drive). To install the Game Adapter, click Click Here to Start. The Setup Wizard will search for the Game Adapter. When the Game Adapter has been located, enter its default password, admin. Then click Enter.
Connect the Game Adapter to Your Game Console
A Division of Cisco Systems, Inc.
The Game Adapter can automatically connect to your wireless network if your network has its encryption disabled and SSID broadcast enabled. If your network has its encryption enabled or SSID broadcast disabled, then follow the instructions in this Quick Installation.
Now that the Game Adapter is properly configured, you can connect the Game Adapter to your game console and play head-tohead or Internet gaming.

A B B C

Connect the Game Adapter to Your Computer B C
Unplug the Game Adapters power adapter from the electrical outlet. Unplug the Ethernet network cable from your computer. Make sure your game console is powered off. Then plug the Ethernet network cable into the Ethernet network port of your game console. Plug the Game Adapters power adapter into an electrical outlet, preferably a surge protector. Power on your game console, and set it for multiplayer gaming.
For additional information or troubleshooting help, refer to the User Guide on the Setup CDROM. You can also call or e-mail for further support. 24-hour Technical Support 800-326-7114 (toll-free from US or Canada) E-mail Support support@linksys.com Website http://www.linksys.com or http://support.linksys.com RMA (Return Merchandise Authorization) http://www.linksys.com/support FTP Site ftp://ftp.linksys.com Sales Information 800-546-5797 (800-LINKSYS)
Linksys is a registered trademark or trademark of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. Copyright 2004 Cisco Systems, Inc. All rights reserved.

WGA54AG-QI-41026NC JL

NOTE: Before you begin, make sure the
switch on the Game Adapters back panel is set to the Infra position. Plug the included Ethernet network cable into the Game Adapters Network port. Then plug the other end into the Ethernet network port of your router or computer.

Package Contents

Wireless A/G Game Adapter CD-ROM with User Guide Quick Installation Network Cable Registration Card Power Adapter
NOTE: For best results, plug the Game Adapter into a router for setup.
Choose whether you will use the Game Adapter for headto-head or Internet gaming. This will determine how the Setup Wizard will configure the Game Adapter. After you have made your choice, click Next. Follow the on-screen instructions of the Setup Wizard.

Dual-Band

Plug the included power adapter into the Game Adapters Power port. Then plug the other end into an electrical outlet, preferably a surge protector.
Congratulations! The installation of the Wireless A/G Game Adapter is complete.

5 GHz 2.4 GHz

802.11a

802.11g

Wireless A/G

Game Adapter

Quick Installation

Wireless

Model No.WGA54AG Model No.