| ||||||
| Search Microsoft.com for: |
| ||||||
| Search Microsoft.com for: |
NetMeeting 2.1 Resource KitNetwork Bandwidth ConsiderationsThis chapter describes how Microsoft® NetMeeting™ optimizes network bandwidth usage, and provides detailed information about test scenarios and sample results for NetMeeting audio, video, and data conferencing. You can learn about the bandwidth characteristics associated with NetMeeting conferencing on the intranet, and the factors that affect bandwidth usage. Note This chapter documents the results of network bandwidth scenarios that tested NetMeeting 2.0. Microsoft plans to update this chapter with network bandwidth testing results for NetMeeting 2.1. OverviewThis chapter addresses the concern that corporations have expressed about the impact of NetMeeting on network bandwidth. Corporations are familiar with data applications and their bandwidth use, but experience with audio and video, in many cases, is limited. In response, Microsoft has tested multiple bandwidth scenarios for data, audio, and video conferencing to demonstrate the ability of NetMeeting to optimize bandwidth usage with minimum impact on network bandwidth traffic. Microsoft designed NetMeeting as a "bandwidth-smart" application with built-in mechanisms for caching, compressing, and optimizing information dynamically. NetMeeting includes system policies to limit throughput for audio and video and to restrict audio and video features. These system policies provide additional assurance that corporations can control the impact on bandwidth utilization. NetMeeting bandwidth testing confirms these assumptions. Corporations can use the sample bandwidth scenarios and results documented in this chapter as a baseline for comparison with their own bandwidth testing. Results may vary based on a corporation's network configuration and other networking considerations, such as router or hub speed, backbone, and shared or unshared ethernet segments. In general, corporations may find that NetMeeting bandwidth usage is significantly less than expected, particularly for audio and video conferencing scenarios. How NetMeeting Optimizes Bandwidth UsageNetMeeting achieves optimal bandwidth use by focusing on the most efficient and effective methods for minimizing network traffic while maximizing performance. This effort encompasses two areas described in the following paragraphs:
NetMeeting Intelligent Bandwidth Management and ControlThe intelligent bandwidth feature in NetMeeting comprises two components: management and control. NetMeeting intelligently manages the throughput (average bandwidth use) of audio, video, and data over the network on a per-client basis to ensure the smooth operation of the separate NetMeeting components and the bandwidth resources of the network. NetMeeting can also control bandwidth intelligently by using the system policies feature of Windows® 95 and Windows NT® 4.0 to enforce a limit on the combined throughput of audio and video. The audio, video, and data subsystems in NetMeeting each create streams for network transmission at their own rates. The audio subsystem creates a stream at a fairly constant rate when speech is being sent. The video subsystem produces a stream at a widely varying rate that depends on motion, quality, and size settings. The data subsystem also produces a stream at a widely varying rate that depends on a number of factors, including the use of file transfer, file size, the complexity of a whiteboard session, and the complexity of the graphic and update information of shared applications. The Bandwidth Management SystemIn priority order, the most important stream in a NetMeeting call is the audio stream, followed by the data stream, and then the video stream. NetMeeting is pre-configured with the typical bandwidths available on four different network types: 14.4 kbps modem, 28.8 kbps or faster modem, ISDN, and local area network. The user specifies the network type in NetMeeting, and the corresponding bandwidth value is used as the available throughput for the call (for example, NetMeeting uses a default setting of 435,190 bps over a LAN connection.) The intelligent bandwidth management system ensures smooth operation of NetMeeting by continuously balancing the network load of the audio and video subsystems with the requirements of the data subsystem and the expected availability of network resources. This means that audio will sound clear, data conferencing will be functional, and video quality will be visually useful, even at low bit rates. During a call, the management system operates continuously. The bandwidth use of the audio stream is deducted from the available throughput. The data subsystem is queried for the current average size of its stream. This value is also deducted from the available throughput. Then, the video subsystem uses the remaining throughput to create a stream of corresponding average size. If no throughput remains, the video subsystem will operate at a minimal rate and will compete with the data subsystem to transmit over the network. In this rare case, performance will degrade momentarily as flow control mechanisms engage to decrease the transmission rate of the data subsystem. Controlling Bandwidth With NetMeeting System PoliciesIntelligent bandwidth control enables the administrator to set a specific number value for "the average audio/video throughput limit" using NetMeeting system policies. These policies enable corporations to manage audio and video streams and were implemented based on customer requests for this type of control. (For more information about setting NetMeeting system policies, see Chapter 5, "System Policies.") The average limit is an average because there is no absolute throughput ceiling. While the rate for audio traffic is fairly stable, the rate for video traffic varies widely, because large movements in the captured image require significantly more information to describe than small movements. The following screen shows the NetMeeting "set limit for audio/video throughput" system policy setting displayed in the Windows 95 Policy Editor.
During a call, the NetMeeting bandwidth management system uses the limited audio/video throughput value as follows:
For example, a NetMeeting call with full audio, video, and data is initiated over the network. The LAN has 400 kbps of bandwidth available and no limited audio/video throughput. Audio typically consumes 8 kbps, so in an audio call, the management system would have 392 kbps of available throughput remaining. The data subsystem reports that 150 kbps on average is being consumed by complex application sharing and numerous file transfers. By deducting 150 kbps from 392 kbps, 242 kbps would remain in the available throughput. This number would be reported to the video subsystem, which could transmit a stream of up to 242 kbps. The video system, though, may be limited by user settings or hardware limitations, which may affect factors, such as frame rate, size, and quality settings, and produce a video stream of only 100 kbps. In this scenario, the user could manually increase video image size or quality, with a corresponding increase in throughput. Consider the same example, except that the administrator limits the audio/video throughput to 50 kbps. The management system would deduct 8 kbps from both the 400 kbps available throughput and 50 kbps limited audio/video throughput values, resulting in 392 kbps and 42 kbps, respectively. The 150 kbps in the data subsystem stream would be deducted only from the available throughput value, for a remainder of 242 kbps. The management system would then compare the two remaining throughput values. Because 42 kbps is less than 242 kbps, the management system would report the 42 kbps value to the video subsystem as its throughput limit. The video subsystem would respond by lowering frame rate or image quality, or both, to achieve the average 42 kbps throughput limit. Optimizing Data: Compression, Caching, and Other ToolsNetMeeting performs a comprehensive set of steps to ensure that it minimizes the amount of data transmitted over the network and maximizes performance for the end user. NetMeeting must adjust dynamically to network and CPU resources, and to the amount of graphical output being generated by the application. The following paragraphs describe the steps used by NetMeeting to optimize the end-user experience and discuss some of the trade-offs that NetMeeting makes to optimize performance. Sending Graphical Information as OrdersInstead of sending graphical updates as bitmap information exclusively, NetMeeting uses the more efficient method of sending information as "orders," or the actual graphical commands used by the application to draw information to the screen. For example, applications use a function called "TextOut()" to draw text to the screen. An application might call "TextOut()" to write "The quick brown fox jumped" to the screen. Instead of copying the pixels on the display after the text has been drawn, NetMeeting sends a TextOut "order" requesting that remote nodes draw some text to the screen. The order includes graphical commands, such as the position (x,y), fonts, and colors. In most cases, this type of transmission is not only more efficient than sending bits, it lends itself very well to fast, efficient forms of compression, such as smart-order encoding. Smart-Order EncodingWindows applications often repeat graphical function calls. NetMeeting application sharing is designed to leverage this feature of Windows applications. Smart-order encoding depends on the assumption that if an application makes one TextOut() call, most likely another will follow immediately thereafter. If this repeated call occurs, NetMeeting transmits a "just like the last order" order. NetMeeting does not need to send any other information except the new data to be displayed. For example, building on the previous example, the application might call TextOut() with "over the lazy dog." In this case, NetMeeting could send a "just like the last order" order with the new text "over the lazy dog" and a new position, but no new font, color, or other information. Caching Graphical ObjectsAnother way that NetMeeting optimizes bandwidth is by caching graphical objects. Most Windows applications use a variety of graphical objects, including bitmaps, cursors, and brushes. NetMeeting transmits the data that comprises a graphical object only once, and then stores the object in a cache. Then, the next time that NetMeeting needs to transmit the object, it can be sent by reference—a cache ID—instead of sending the actual graphical data. This is a very important NetMeeting feature, particularly for bitmaps, because they can be very large and are commonly drawn to the screen many times. A good way to see how NetMeeting uses caching is to share an Internet browser. You will notice that the first time you view a page the bitmaps are relatively slow to appear, but the next time the bitmaps appear very quickly. The second time the browser draws the bitmap, NetMeeting draws the object from the cache. Specialized Bitmap CompressionA special compression algorithm for Windows bitmaps is another tool that NetMeeting uses to minimize the amount of network bandwidth used by graphical objects. This algorithm is tuned to operate specifically with the bitmaps that Windows applications most often generate. This means that even if a bitmap is not yet in the cache, NetMeeting will still attempt to minimize its impact on the end user and network. Outgoing Data QueueIn some instances, the application may call graphical functions faster then NetMeeting can transmit the graphics to remote conference participants. In this case, NetMeeting uses special techniques, including an outgoing data queue, smart spoiling, and smart monitoring, to minimize data on the network and maximize performance for the end user. These techniques are especially important over slow links, where NetMeeting can more easily fall behind the application. From its beginning, NetMeeting was designed to deliver multipoint collaborative application sharing—arbitrarily slowing down a hosted application because of a slow network is an intolerable situation. Therefore, NetMeeting maintains a queue of outgoing data. This unique design feature is substantially different from other conferencing products, which typically synchronize their data. NetMeeting asynchronous output means that the hosted application does not need to wait for the network. The graphical commands are queued as they are drawn to the screen, and the graphical functions are immediately returned so that the application can continue. Later, an asynchronous process transmits the graphical commands over the network. This NetMeeting architecture ensures that the impact on the local user is minimal. The local application slows down, but is not forced to wait for network traffic. Smart SpoilingThe NetMeeting asynchronous design results in a queue of outgoing data that NetMeeting can leverage using a technique called "spoiling"—throwing away existing graphical output in the queue that will be obscured by new graphical output. The obscured output never gets transmitted over the network. Prior to adding a new piece of graphical output to the queue, NetMeeting checks for existing output that the new graphical output might obscure. For example, an application might draw a bitmap that completely covers a block of text drawn immediately before the bitmap. In this case, NetMeeting removes the text order from the queue, because the new graphical output obscures the text. Smart MonitoringIn some cases, with extremely graphic-intensive programs, such as a CAD application drawing thousands of lines per second, NetMeeting goes another step further. NetMeeting actually stops adding information to the queue and begins accumulating regions of the screen that it can collect later and send as a bitmap. This technique significantly enhances performance and is key to the ability of NetMeeting to handle slow connections. Rather than continue to queue data and fall further behind the application, NetMeeting intelligently monitors changes in the output queue. When the queue becomes to large, NetMeeting begins to accumulate the areas of the screen impacted by the graphical orders, instead of the orders themselves. Then, NetMeeting can return later, retrieve the necessary portion of the screen, and transmit the information over the network. For example, consider the CAD application drawing thousands of lines per second and the information being drawn to a 100x100-pixel area of the screen. NetMeeting quickly falls behind, and begins to collect the bounding rectangle of the orders. Soon, the bounding rectangle will measure 100x100, but never larger. After the rest of the queue empties, NetMeeting can simply copy a 100x100 region of the screen, compress the information, and transmit it. So, NetMeeting avoids sending thousands of lines and instead, sends a single compressed bitmap. NetMeeting Bandwidth Use SummaryThe following paragraphs describe the bandwidth characteristics of NetMeeting audio, video, and data conferencing, as well as some of the conferencing factors that affect NetMeeting bandwidth usage. Corporations can use this information as a guideline when interpreting their own NetMeeting bandwidth testing results. Overall, Microsoft determined that NetMeeting average bandwidth measured as follows:
Bandwidth Characteristics of NetMeeting Data ConferencingThe following characteristics are typical for NetMeeting data conferencing scenarios:
Bandwidth Characteristics of NetMeeting Audio and Video ConferencingThe following characteristics are typical for NetMeeting audio and video conferencing scenarios:
Data Conferencing Factors that Affect Bandwidth UsageAttempting to determine the "typical" average bandwidth for a NetMeeting data conference is difficult. Many variables may impact bandwidth use on any given network. Also, users can incorporate one or all of the NetMeeting data conferencing tools (application sharing, chat, whiteboard, and file transfer) into their meeting. Through their own testing, though, many corporations have found that NetMeeting uses reasonably low bandwidth, and has little or no impact on their overall network operation. The following factors affect the amount of network bandwidth that NetMeeting data conferencing scenarios will use:
Using a variety of NetMeeting data conferencing scenarios, Microsoft tested these factors by using applications, files, and tasks of varying complexity to demonstrate the variable bandwidth results that corporations will obtain with their own testing. Audio and Video Conferencing Factors that Affect Bandwidth UsageThe following factors affect the amount of network bandwidth that NetMeeting audio and video conferencing scenarios will use:
Microsoft tested a variety of audio and video conferencing scenarios to demonstrate the range of bandwidth results that corporations may obtain with their own testing. NetMeeting Bandwidth Testing ScenariosNetMeeting bandwidth testing was performed in a controlled environment. Nineteen scenarios were tested, and individual results were measured during each scenario using RADCOM networking utilities. The following general conditions applied for bandwidth testing:
Data Conferencing Test ResultsThe first group of bandwidth tests focuses on data conferencing scenarios with users sharing applications, using whiteboard and chat, and transferring files. Testers performed common application sharing tasks, such as typing and scrolling, as well as more complex actions, such as spreadsheet calculation changes. Note Typically, these scenarios represent a "worst case" situation, where multiple data conferencing tasks were completed within the allotted 60 seconds, with only brief pauses. Therefore, results may be higher than expected for a typical user, who would not complete multiple tasks at this speed, and would pause more frequently. The following table provides a summary of the test results for data conferencing scenarios.
The following sections provide detailed information and graphs for each data conferencing scenario. Scenario 1: Windows 95 Application Sharing with NotepadTest ConditionsScenario 1 used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsThe following graph shows that bandwidth usage spiked briefly as the first person shared Notepad with the second person, and then collaborated. During these initial spikes, NetMeeting was transmitting computer and application capabilities and graphic information over the network. Traffic is minimal as the two people took turns typing text. Average bandwidth measured ~15 kbps, with bandwidth usage ranging from 0-170 kbps.
Scenario 1 Windows 95 application sharing with Notepad Scenario 2a: Windows 95 Application Sharing with Word 97Test ConditionsScenario 2a used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsThe following graph shows that bandwidth usage spiked briefly midway through the scenario as the tester scrolled to and formatted the bitmap graphic. These spikes occurred as NetMeeting transmitted and cached graphic information over the network. The color graphic was a NetMeeting screen that was captured and pasted as a large bitmap into the document. Traffic was minimal as the two people took turns typing text, and dropped to zero when no activity was occurring (during pauses). Average bandwidth measured ~125 kbps, with bandwidth usage ranging from 0-925 kbps.
Scenario 2a Windows 95 application sharing with Word 97 Scenario 2b: Windows NT Application Sharing with Word 97Test ConditionsScenario 2b used the following test conditions:
Test StepsFollow Scenario 2a "Test Steps." Bandwidth ResultsThis scenario repeated the steps used in Scenario 2a, running on Windows NT rather than on Windows 95. The following graph shows that bandwidth usage spiked similarly, with peaks during graphic scrolling and formatting. In comparison to the Scenario 2a results, though, the average bandwidth (~45 kbps) and peaks (~125 kbps) measured significantly less because of the more advanced methods for Windows NT data compression. Also noticeably different between these results is the constant bandwidth traffic for Windows NT, which may be due to several variables, including cursor or mouse movement.
Scenario 2b Windows NT application sharing with Word 97 Scenario 2c: Application Sharing with Word97—Four Computers in One CallTest ConditionsScenario 2c used the following test conditions:
Test StepsFour testers completed the following steps:
Bandwidth ResultsThis scenario repeated the steps (except step 7) used in Scenarios 2a and 2b with four computers involved in the data conference. The following graph shows that bandwidth usage spiked similarly, with peaks during graphic scrolling and formatting. As expected, the average bandwidth (~210 kbps) was higher with four computers in the call. The peaks in Scenario 2c with four computers, though, were lower (~690 kbps) than the peaks measured in Scenario 2a with two computers. In a data conference with more people, NetMeeting actually transmits fewer packets of data to each person, so peaks are smaller, but require more time to transmit, which increases the latency.
Scenario 2c Application sharing with Word 97—four computers in one call Scenario 3a: Windows 95 Application Sharing with Excel 97Test ConditionsScenario 3a used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsThe following graph shows that bandwidth usage peaked at the beginning of the scenario when NetMeeting transmitted and cached graphic information over the network, and again toward the end of the scenario as NetMeeting transmitted new chart information. Typically, NetMeeting compares the latest data revisions to the most recently transmitted data, and then transmits only information that is different. If the number of differences is too great, NetMeeting transmits the entire segment again, which occurred when the chart was revised to show data values. As expected, average traffic was less than 50 kbps (~42 kbps), and bandwidth usage peaked at 185 kbps, dropping to zero when no activity occurred (during pauses).
Scenario 3a Windows 95 application sharing with Excel 97 Scenario 3b: Windows NT Application Sharing with Excel 97Test ConditionsScenario 3b used the following test conditions:
Test StepsFollow Scenario 3a "Test Steps." Bandwidth ResultsThis scenario repeated the steps used in Scenario 3a, running on Windows NT instead of Windows 95. The following graph shows that bandwidth usage spiked similarly, with peaks during the initial sharing and collaboration, and also when the testers updated the chart. In comparison to the Scenario 3a results, though, the average bandwidth (~40 kbps) and peaks (~140 kbps) measured less because of the more advanced methods for Windows NT data compression. Also noticeably different between these results is the constant bandwidth traffic for Windows NT, which may be due to several variables, including cursor or mouse movement.
Scenario 3b Windows NT application sharing with Excel 97 Scenario 4a: Windows 95 Application Sharing with PowerPoint 97Test ConditionsScenario 4a used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsThe following graph shows that bandwidth usage spiked briefly when graphic-intensive slides were shared. As expected, the simple bulleted list and agenda slides required little bandwidth. Overall, traffic was intermittent, dropping to zero when no activity was occurring (during pauses between slides). Average bandwidth measured ~40 kbps, with bandwidth usage ranging from 0-650 kbps.
Scenario 4a Windows 95 application sharing with PowerPoint 97 Scenario 4b: Windows NT Application Sharing with PowerPoint 97Test ConditionsScenario 4b used the following test conditions:
Test StepsFollow Scenario 4a "Test Steps." Bandwidth ResultsThis scenario repeated the steps used in Scenario 4a, running on Windows NT instead of Windows 95. The following graph shows that bandwidth usage spiked similarly, with peaks occurring when the tester displayed graphic-intensive slides. In comparison to the Scenario 4a results, though, the average bandwidth (~30 kbps) and peaks (~295 kbps) measured significantly less because of the more advanced methods for Windows NT data compression.
Scenario 4b Windows NT application sharing with PowerPoint 97 Scenario 5: Windows 95 with WhiteboardTest ConditionsScenario 5 used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsThe following graph shows that bandwidth usage spiked briefly as both people opened the whiteboard. During this initial spike, NetMeeting was transmitting computer and application capabilities over the network. Traffic was intermittent, dropping to zero frequently, as the two people took turns drawing shapes. Drawing operations resulted in low bandwidth usage because the NetMeeting whiteboard does not send bitmaps over the network, but instead sends messages with the drawing operation. As expected, a second spike occurred when the bitmap graphic was pasted on the whiteboard. Overall, traffic was minimal, with the average bandwidth measuring less than 5 kbps, and bandwidth usage ranging from 0-80 kbps.
Scenario 5 Windows 95 with whiteboard Scenario 6: Windows 95 with ChatTest ConditionsScenario 6 used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsThe following graph shows that bandwidth usage spiked briefly as both people opened the chat program. During this initial spike, NetMeeting was transmitting computer and application capabilities and graphic information over the network. Traffic was minimal throughout the remainder of the scenario as the two people took turns typing messages. This graph demonstrates the minimal impact of chat on network bandwidth, with the average bandwidth measuring ~1 kbps, and bandwidth usage ranging from 0-22 kbps.
Scenario 6 Windows 95 with chat Scenario 7: Windows 95 with file transferTest ConditionsScenario 7 used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsThe following graph shows that bandwidth usage spiked briefly as file transfer was initiated, and then spiked for a longer period (~25 seconds) as the file was sent over the network. Because NetMeeting breaks large data blocks into a series of smaller packets for transfer over the network, file transfer will use less bandwidth than a typical file copy (shown in Scenario 8) but will take longer to transmit the information. The graph confirms this assumption, showing an average bandwidth of ~55 kbps, and bandwidth usage ranging from 0-140 kbps.
Scenario 7 Windows 95 with file transfer Scenario 8: Network File Copy with Windows 95This scenario does not test NetMeeting, and provides results for comparison purposes only. Test ConditionsScenario 8 used the following test conditions:
Test StepsTwo testers completed the following steps:
Bandwidth ResultsFor the file copy, the same Microsoft PowerPoint 97 file used in the previous scenario was transmitted over the network to provide a comparison against the bandwidth results for NetMeeting file transfer. As expected, the graph shows that a file copy uses significantly more bandwidth for the actual copy, peaking at ~2,800 kbps, but transmits over the network for a short period of time (~3 seconds).
Scenario 8 Network file copy with Windows 95 Audio and Video Conferencing Test ResultsThe second group of bandwidth tests focuses on audio and video conferencing scenarios with users sharing conversations, using different video window sizes and image qualities, and varying the amount of movement and talking. Testing included scenarios that modeled typical audio and video use during a meeting, as well as best and worst case scenarios. The following table provides a summary of the test results for audio and video conferencing scenarios.
The following sections provide detailed information and graphs for each audio and video conferencing scenario. Scenario 9: Half-Duplex Audio ConversationTest ConditionsScenario 9 used the following test conditions:
Test StepsTwo testers spoke to each other in a normal, conversational voice. Bandwidth ResultsThis scenario tested a typical audio conversation between two people using Windows 95 computers. The following graph illustrates results that can easily be reproduced for any half-duplex audio conversation. Using the G.723.1 audio codec, NetMeeting consistently generates predictable bandwidth results, with the average bandwidth measuring 6.4 kbps, plus ~40% for IP packet header and overhead (~9 kbps for each direction of audio). The continuous rise and fall on the graph is due to several variables, including conversation pauses and standard network operation, which queues up audio data and sends it in packets.
Scenario 9 Half-duplex audio conversation Scenario 10a: Half-Duplex Audio with Small Window/Low-Quality Video—Normal ConversationTest ConditionsScenario 10a used the following test conditions:
Test StepsTwo testers spoke to each other in a normal, conversational voice and faced the camera using a normal amount of movement (typical for a conversation). Bandwidth ResultsThis scenario tested a typical audio and video conversation between two people using the least bandwidth-intensive video settings—a small video window with low quality. The following graph shows that the average bandwidth measured ~24 kbps, which is easily within the range for transmission of audio and video over a standard 28.8 kbps modem.
Scenario 10a Half-duplex audio with small window/low-quality video—normal conversation Scenario 10b: Half-Duplex Audio with Medium Window/Medium-Quality Video—Normal ConversationTest ConditionsScenario 10b used the following test conditions:
Test StepsTwo testers spoke to each other in a normal, conversational voice and faced the camera using an average amount of movement (typical for a conversation). Bandwidth ResultsThis scenario tested a typical audio and video conversation between two people using normal video settings—a medium video window with medium quality—which are the default settings over the local area network. The following graph shows that the average bandwidth measured ~36 kbps, with bandwidth usage ranging from 0-78 kbps. The highest peaks occur when NetMeeting sends a complete video frame every 15 seconds, which is significantly larger than the total deltas sent in the interim.
Scenario 10b Half-duplex audio with medium window/medium-quality video—normal conversation Scenario 10c: Half-Duplex Audio with Large Window/High-Quality Video—Normal ConversationTest ConditionsScenario 10c used the following test conditions:
Test StepsTwo testers spoke to each other in a normal, conversational voice and faced the camera using an average amount of movement (typical for a conversation). Bandwidth ResultsThis scenario tested a typical audio and video conversation between two people using the most bandwidth-intensive video settings—large video window with high quality. The following graph shows that the average bandwidth measured ~70 kbps, with bandwidth usage ranging from 0-155 kbps.
Scenario 10c Half-duplex audio with large window/high-quality video—normal conversation Scenario 11a: Half-Duplex Audio with Small Window/Low-Quality Video—Mix of Conversation and MovementTest ConditionsScenario 11a used the following test conditions:
Test StepsTwo testers completed the following steps: 0-15 seconds: Person #1 called Person #2; initial video images transmitted. 16-20 seconds: Both people did not talk and used little movement. 21-23 seconds: Both people paused. 24-33 seconds: Both people spoke and used little movement. 34-36 seconds: Both people paused. 37-46 seconds: Both people did not talk and used a lot of movement (hand waving, panning the room with the camera, etc.) 47-49 seconds: Both people paused. 50-59 seconds: Both people spoke and used a lot of movement. Bandwidth ResultsThis scenario tested a gradual progression from best case (no talking with little movement) to worse case (talking with lots of movement), using the least bandwidth-intensive video settings—a small video window with low quality. The initial spikes occurred during call setup. As expected, the graph shows that the more audio and video input, the more bandwidth is used. Average bandwidth measured ~38 kbps, with bandwidth usage ranging from 0-70 kbps. If this audio and video transmission occurred over a 28.8 kbps modem, audio would remain constant, but video would be scaled back to accommodate the available bandwidth (slower refresh rate).
Scenario 11a Half-duplex audio with small window/low-quality video—mix of conversation and movement Scenario 11b: Half-Duplex Audio with Medium Window/Medium-Quality Video—Mix of Conversation and MovementTest ConditionsScenario 11b used the following test conditions:
Test StepsTwo testers completed the following steps: 0-15 seconds: Person #1 called Person #2; initial video images transmitted. 16-20 seconds: Both people did not talk and used little movement. 21-23 seconds: Both people paused. 24-33 seconds: Both people spoke and used little movement. 34-36 seconds: Both people paused. 37-46 seconds: Both people did not talk and used a lot of movement (hand waving, panning the room with the camera, etc.) 47-49 seconds: Both people paused. 50-59 seconds: Both people spoke and used a lot of movement. Bandwidth ResultsThis scenario tested a gradual progression from best case (no talking with little movement) to worse case (talking with lots of movement), using normal video settings—a medium video window with medium quality—which are the default settings over the local area network. As expected, the graph shows that the more audio and video input, the more bandwidth is used. Average bandwidth measured ~47 kbps, with bandwidth usage ranging from 0-115 kbps.
Scenario 11b Half-duplex audio with medium window/medium-quality video—mix of conversation and movement Scenario 11c: Half-Duplex Audio with Large Window/High-Quality Video—Mix of Conversation and MovementTest ConditionsScenario 11c used the following test conditions:
Test StepsTwo testers completed the following steps: 0-15 seconds: Person #1 called Person #2; initial video images transmitted. 16-20 seconds: Both people did not talk and used little movement. 21-23 seconds: Both people paused. 24-33 seconds: Both people spoke and used little movement. 34-36 seconds: Both people paused. 37-46 seconds: Both people did not talk and used a lot of movement (hand waving, panning the room with the camera, etc.) 47-49 seconds: Both people paused. 50-59 seconds: Both people spoke and used a lot of movement. Bandwidth ResultsThis scenario tested a gradual progression from best case (no talking with little movement) to worse case (talking with lots of movement), using the most bandwidth-intensive video settings—a large video window with high quality. Average bandwidth measured ~115 kbps, with bandwidth usage ranging from 0-410 kbps.
Scenario 11c Half-duplex audio with large window/high-quality video—mix of conversation and movement Scenario 12: Half-Duplex Audio with Medium Window/Medium-Quality Video—Four Calls with Normal ConversationTest ConditionsScenario 12 used the following test conditions:
Test StepsOne at a time, four separate NetMeeting calls were initiated with two computers each. After each call was initiated, testers spoke to each other in a normal, conversational voice and faced the camera using an average amount of movement (typical for a conversation). Bandwidth ResultsIn comparison to Scenario 10b, which used the same video settings in a single call, the following graph shows that four calls produce approximately four times the bandwidth. The average bandwidth measured ~36 kbps for the one-call scenario and ~148 kbps for the four-call scenario. This additive bandwidth can be explained by the fact that NetMeeting video continues to transmit information (either as a new video frame every 15 seconds, or as deltas in the interim) even if there is no movement.
Scenario 12 Half-duplex audio with medium window/medium-quality video—four calls with normal conversation |
