http://wiki.cas.mcmaster.ca/index.php?feed=atom&target=Simpsoa&title=Special%3AContributions 2026-04-10T00:20:02Z From Computing and Software Wiki MediaWiki 1.15.1 http://wiki.cas.mcmaster.ca/index.php/Five_Interaction_Styles 2009-11-23T20:49:16Z

<p>Simpsoa:&#32;/* Menus */</p> <hr /> <div>The '''Five Interaction Styles''' originally presented by Ben Shneiderman in 1983 represent the five basic ways that humans interact with a computer interface. Each interaction style effects the overall efficiency and usability of the computer system, but that is not to say there are good or bad interaction styles. The styles all have benefits and trade offs when dealing with certain types of users and it is often in an interface designers best interest to use a combination of styles instead of anyone one style alone.<br /> <br /> = Shneiderman's Five Interaction Styles =<br /> <br /> == Visual representation ==<br /> [[Image:DirectManipulation.jpg|thumb|300px|right|Simple example of file/folder metaphor in Windows Vista]]<br /> <br /> Visual representation (also known as [[Direct Manipulation]]) features a natural representation of task [http://www.cas.mcmaster.ca/wiki/index.php/The_Object-Action_%28or_visa-versa%29_model_and_its_applications objects and actions]. This helps present the process as actually performing a task itself directly even though it is being doing through an intermediary like a computer. The visual representation usually takes the form of a metaphor related to the actual task being performed. In this way well designed visual representation systems tend to make the interaction enjoyable for the users, which is excellent for novice users or complex tasks that can lead to anxiety.<br /> <br /> === + Advantages ===<br /> * Visual presentation of task concepts<br /> * Allows easy learning<br /> * Encourages exploration<br /> * Users can immediately see if their actions are furthering their goals<br /> * Users gain confidence because they feel in control and can predict system responses<br /> <br /> === - Disadvantages ===<br /> * Can be hard to implement<br /> * Requires graphics display/pointing devices<br /> <br /> == Menus ==<br /> [[Image:menus1.gif|thumb|100px|right|Example of a typical menu in Windows XP]]<br /> [[Image:menus2.gif|thumb|100px|right|Microsoft Office's &quot;ribbon&quot; UI, an example of tabbed toolbars]]<br /> <br /> Menus provide a way to visually organise a very large set of actions. Menus are nearly ubiquitous in modern applications, with the most standard format being the &quot;File/Edit&quot; style strip located across the top of windows (such as in Microsoft Windows) or the user's workspace (such as in [[Multiple Document Interfaces]], or in Mac OS X). Menus do not have any obvious physical metaphor, and rely on users being able to tell the difference between an action, and a category which can be expanded into a child set of actions and/or further categories. Menus can also change depending on context, from enabling or disabling individual items depending on the program's state, to using &quot;tabbed toolbars&quot; to flip between item collections.<br /> <br /> === + Advantages ===<br /> * Accessible to novice and intermittent users <br /> * Allows for a very large palette of structured commands which can be easily &quot;explored&quot;<br /> * Facilitates Multiple Document Interfaces well<br /> * Does not rely on parsing input<br /> <br /> === - Disadvantages ===<br /> * Can bury useful features under complex hierarchies<br /> * Number of items limited by screen resolution<br /> * Convention restricts how menu items are categorised<br /> <br /> == Fill-In-The-Blanks ==<br /> [[Image:formfillin1.gif|thumb|300px|right|Classic Fill-In-The-Blanks]]<br /> [[Image:formfillin2.gif|thumb|300px|right|Modern-day Fill-In-The-Blanks]]<br /> The Fill-In-The-Blanks interaction style (also known as &quot;Form Fill-in&quot;) is best suited to data input, which was aimed at a different set of users than command language, specially non-experts users. Originally Fill-In-The-Blanks is to arrange one or more fields in the form of a prose sentence or phrase, with the fields as &quot;blanks&quot; to be filled in by the user. The TAB-key was designed and is still being used to switch between the fields and ENTER to submit the form. Therefore a pointing device (such as a mouse) was not really needed at that time. However it's very common to mix forms with other interaction styles in software design, such as drop down menus, check boxes etc. The spreadsheet is a variation on the Form Fill-in interaction style. Even today, there are quite a few computers are still purely forms-based in the industry, like cash registers, financial systems, stock control systems, and so on. The main reason is because the Fill-In-The-Blanks interface is especially useful for routine, clerical work or those tasks require a great amount of data entry.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Simplifies data entry<br /> * Minimal training - Shortens learning in that the fields are predefined and need only be 'recognized'.<br /> * Gives convenient assistance - Guides the user via the predefined rules<br /> * Permits use of form-management tools<br /> <br /> === - Disadvantages ===<br /> * Screen space consuming<br /> * requires more keystrokes<br /> * requires handling typing errors (bad for users with poor typing skills)<br /> <br /> == Command Line ==<br /> [[Image:Commandline.png|thumb|300px|right|Ubuntu command line showing basic commands]]<br /> <br /> Command line is the earliest used interaction style and is still seen predominantly in Unix operating systems though still usable to varying degrees on Windows and OSX. This style is mainly used by expert users by typing into a prompt that allows them to quickly execute commands. Unfortunately command line places a considerable burden on the user to learn and recall commands from memory. It is often the case that commands take parameters as well and most of the added benefits (mainly in the way of efficiency) come from using them. This leads to an unfriendly environment for both novice and intermediate users that may attempt to use this style. The large overhead in learning commands and minimal help for the user leaves this style almost exclusively in the domain of the expert user.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * quick and powerful for experienced users<br /> * user-controlled interaction<br /> * minimal amount of typing (no mouse use)<br /> * can be used in conjunction with other user interfaces<br /> <br /> === - Disadvantages ===<br /> * little or no prompting<br /> * requires user’s knowledge of system, programs<br /> * relies on recall of commands and syntax<br /> * difficult to learn<br /> * error prone<br /> <br /> == Natural Language ==<br /> Natural Language is an interaction style which allows the user to communicate with their computer through a series of spoken commands, similar to how one may issue spoken commands to another person. However the benefits and applicability of Natural Language systems thus far is very limited, largely due to the imprecise and verbose nature of spoken languages. A major issue with using spoken language is that to communicate with computer systems the vocabulary would need to be limited to a specific subset of a full natural language, in order to both reduce ambiguity and keep processing time within reasonable bounds. One solution to the ambiguity of spoken languages is to utilize gestural language, which is considered at least as natural as verbal language. At the same time, the definition of what makes a natural language is very important. It is not as though humans are born knowing spoken word or gestures; a natural language is simply one which can be grasped fluently by the time one is required to draw upon it. A language could be considered natural, if upon approaching a computer the typical user already possesses language skills adequate for communicating desired concepts in a fluent and articulate manner. So in a sense Natural Language could involve a kind of language humans develop with the sole purpose of communicating with computer systems, thus potentially eliminating the ambiguities of the current natural spoken languages. Thus far however Natural Language has not seen widespread use, and often requires each user to train the computer to recognize their own voice. Natural Language could be very useful for those with minimal keyboard skills, and once it more accurately interprets verbal commands may even see widespread use one day. &lt;sup&gt;[2][3]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Allows users to communicate with their system naturally<br /> * Can reduce or eliminate the need for keyboards, great for those with poor keyboard skills<br /> * Once it is more accurate at interpreting speech, commands may be able to be spoken faster than they are typed<br /> <br /> === - Disadvantages ===<br /> * Currently cannot accurately interpret much of verbal language, which is too ambiguous<br /> * Requires a lot of training for each user so it can interpret their verbal commands<br /> <br /> = See also =<br /> <br /> * [[Motivations for the Studies of HCI]]<br /> * [[Contexts for HCI]]<br /> * [[Process for User-centered Development]]<br /> * [[Social issues influencing HCI design and use]]<br /> * [[HCI - Accommodating human diversity]]<br /> * [[User Interface Standards]]<br /> * [[The Object-Action (or visa-versa) model and its applications]]<br /> * [[Direct Manipulation]]<br /> <br /> = References =<br /> # Mads Soegaard, &quot;Interaction Styles&quot;, interaction-design.org, http://www.interaction-design.org/encyclopedia/interaction_styles.html<br /> # Byron Long, &quot;Natural Language as an Interaction Style&quot;, Retrieved on November 21st, 2009 from http://www.dgp.toronto.edu/people/byron/papers/nli.html<br /> # Bill Buxton, &quot;The &quot;Natural&quot; Language of Interaction&quot;, Retrieved on November 21st, 2009 from http://www.billbuxton.com/natural.html<br /> # Microsoft Office Online, &quot;Use the Ribbon - Help and How-to&quot;, Retrieved on November 23rd, 2009 from http://office.microsoft.com/en-us/help/HA100898951033.aspx<br /> <br /> --[[User:Shensw|Shensw]] 22:55, 20 November 2009 (EST)<br /> <br /> --[[User:Collim|Collim]] 23:50, 21 November 2009 (EST)<br /> <br /> --[[User:Frostd|Frostd]] 00:58, 22 November 2009 (EST)<br /> <br /> --[[User:Simpsoa|Simpsoa]] 15:45, 23 November 2009 (EST)</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/File:Menus2.gif 2009-11-23T20:48:23Z

<p>Simpsoa:&#32;An example of the Ribbon UI in Microsoft Office. Source: http://office.microsoft.com/en-us/help/HA100898951033.aspx</p> <hr /> <div>An example of the Ribbon UI in Microsoft Office.<br /> <br /> Source: http://office.microsoft.com/en-us/help/HA100898951033.aspx</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/File:Menus1.gif 2009-11-23T20:47:57Z

<p>Simpsoa:&#32;An example of a Windows XP menu. Source: http://www.interaction-design.org/encyclopedia/interaction_styles.html</p> <hr /> <div>An example of a Windows XP menu.<br /> <br /> Source: http://www.interaction-design.org/encyclopedia/interaction_styles.html</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Five_Interaction_Styles 2009-11-23T20:47:15Z

<p>Simpsoa:&#32;</p> <hr /> <div>The '''Five Interaction Styles''' originally presented by Ben Shneiderman in 1983 represent the five basic ways that humans interact with a computer interface. Each interaction style effects the overall efficiency and usability of the computer system, but that is not to say there are good or bad interaction styles. The styles all have benefits and trade offs when dealing with certain types of users and it is often in an interface designers best interest to use a combination of styles instead of anyone one style alone.<br /> <br /> = Shneiderman's Five Interaction Styles =<br /> <br /> == Visual representation ==<br /> [[Image:DirectManipulation.jpg|thumb|300px|right|Simple example of file/folder metaphor in Windows Vista]]<br /> <br /> Visual representation (also known as [[Direct Manipulation]]) features a natural representation of task [http://www.cas.mcmaster.ca/wiki/index.php/The_Object-Action_%28or_visa-versa%29_model_and_its_applications objects and actions]. This helps present the process as actually performing a task itself directly even though it is being doing through an intermediary like a computer. The visual representation usually takes the form of a metaphor related to the actual task being performed. In this way well designed visual representation systems tend to make the interaction enjoyable for the users, which is excellent for novice users or complex tasks that can lead to anxiety.<br /> <br /> === + Advantages ===<br /> * Visual presentation of task concepts<br /> * Allows easy learning<br /> * Encourages exploration<br /> * Users can immediately see if their actions are furthering their goals<br /> * Users gain confidence because they feel in control and can predict system responses<br /> <br /> === - Disadvantages ===<br /> * Can be hard to implement<br /> * Requires graphics display/pointing devices<br /> <br /> == Menus ==<br /> [[Image:menus1.gif|thumb|300px|right|Example of a typical menu in Windows XP]]<br /> [[Image:menus2.gif|thumb|300px|right|Microsoft Office's &quot;ribbon&quot; UI, an example of tabbed toolbars]]<br /> <br /> Menus provide a way to visually organise a very large set of actions. Menus are nearly ubiquitous in modern applications, with the most standard format being the &quot;File/Edit&quot; style strip located across the top of windows (such as in Microsoft Windows) or the user's workspace (such as in [[Multiple Document Interfaces]], or in Mac OS X). Menus do not have any obvious physical metaphor, and rely on users being able to tell the difference between an action, and a category which can be expanded into a child set of actions and/or further categories. Menus can also change depending on context, from enabling or disabling individual items depending on the program's state, to using &quot;tabbed toolbars&quot; to flip between item collections.<br /> <br /> === + Advantages ===<br /> * Accessible to novice and intermittent users <br /> * Allows for a very large palette of structured commands which can be easily &quot;explored&quot;<br /> * Facilitates Multiple Document Interfaces well<br /> * Does not rely on parsing input<br /> <br /> === - Disadvantages ===<br /> * Can bury useful features under complex hierarchies<br /> * Number of items limited by screen resolution<br /> * Convention restricts how menu items are categorised<br /> <br /> == Fill-In-The-Blanks ==<br /> [[Image:formfillin1.gif|thumb|300px|right|Classic Fill-In-The-Blanks]]<br /> [[Image:formfillin2.gif|thumb|300px|right|Modern-day Fill-In-The-Blanks]]<br /> The Fill-In-The-Blanks interaction style (also known as &quot;Form Fill-in&quot;) is best suited to data input, which was aimed at a different set of users than command language, specially non-experts users. Originally Fill-In-The-Blanks is to arrange one or more fields in the form of a prose sentence or phrase, with the fields as &quot;blanks&quot; to be filled in by the user. The TAB-key was designed and is still being used to switch between the fields and ENTER to submit the form. Therefore a pointing device (such as a mouse) was not really needed at that time. However it's very common to mix forms with other interaction styles in software design, such as drop down menus, check boxes etc. The spreadsheet is a variation on the Form Fill-in interaction style. Even today, there are quite a few computers are still purely forms-based in the industry, like cash registers, financial systems, stock control systems, and so on. The main reason is because the Fill-In-The-Blanks interface is especially useful for routine, clerical work or those tasks require a great amount of data entry.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Simplifies data entry<br /> * Minimal training - Shortens learning in that the fields are predefined and need only be 'recognized'.<br /> * Gives convenient assistance - Guides the user via the predefined rules<br /> * Permits use of form-management tools<br /> <br /> === - Disadvantages ===<br /> * Screen space consuming<br /> * requires more keystrokes<br /> * requires handling typing errors (bad for users with poor typing skills)<br /> <br /> == Command Line ==<br /> [[Image:Commandline.png|thumb|300px|right|Ubuntu command line showing basic commands]]<br /> <br /> Command line is the earliest used interaction style and is still seen predominantly in Unix operating systems though still usable to varying degrees on Windows and OSX. This style is mainly used by expert users by typing into a prompt that allows them to quickly execute commands. Unfortunately command line places a considerable burden on the user to learn and recall commands from memory. It is often the case that commands take parameters as well and most of the added benefits (mainly in the way of efficiency) come from using them. This leads to an unfriendly environment for both novice and intermediate users that may attempt to use this style. The large overhead in learning commands and minimal help for the user leaves this style almost exclusively in the domain of the expert user.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * quick and powerful for experienced users<br /> * user-controlled interaction<br /> * minimal amount of typing (no mouse use)<br /> * can be used in conjunction with other user interfaces<br /> <br /> === - Disadvantages ===<br /> * little or no prompting<br /> * requires user’s knowledge of system, programs<br /> * relies on recall of commands and syntax<br /> * difficult to learn<br /> * error prone<br /> <br /> == Natural Language ==<br /> Natural Language is an interaction style which allows the user to communicate with their computer through a series of spoken commands, similar to how one may issue spoken commands to another person. However the benefits and applicability of Natural Language systems thus far is very limited, largely due to the imprecise and verbose nature of spoken languages. A major issue with using spoken language is that to communicate with computer systems the vocabulary would need to be limited to a specific subset of a full natural language, in order to both reduce ambiguity and keep processing time within reasonable bounds. One solution to the ambiguity of spoken languages is to utilize gestural language, which is considered at least as natural as verbal language. At the same time, the definition of what makes a natural language is very important. It is not as though humans are born knowing spoken word or gestures; a natural language is simply one which can be grasped fluently by the time one is required to draw upon it. A language could be considered natural, if upon approaching a computer the typical user already possesses language skills adequate for communicating desired concepts in a fluent and articulate manner. So in a sense Natural Language could involve a kind of language humans develop with the sole purpose of communicating with computer systems, thus potentially eliminating the ambiguities of the current natural spoken languages. Thus far however Natural Language has not seen widespread use, and often requires each user to train the computer to recognize their own voice. Natural Language could be very useful for those with minimal keyboard skills, and once it more accurately interprets verbal commands may even see widespread use one day. &lt;sup&gt;[2][3]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Allows users to communicate with their system naturally<br /> * Can reduce or eliminate the need for keyboards, great for those with poor keyboard skills<br /> * Once it is more accurate at interpreting speech, commands may be able to be spoken faster than they are typed<br /> <br /> === - Disadvantages ===<br /> * Currently cannot accurately interpret much of verbal language, which is too ambiguous<br /> * Requires a lot of training for each user so it can interpret their verbal commands<br /> <br /> = See also =<br /> <br /> * [[Motivations for the Studies of HCI]]<br /> * [[Contexts for HCI]]<br /> * [[Process for User-centered Development]]<br /> * [[Social issues influencing HCI design and use]]<br /> * [[HCI - Accommodating human diversity]]<br /> * [[User Interface Standards]]<br /> * [[The Object-Action (or visa-versa) model and its applications]]<br /> * [[Direct Manipulation]]<br /> <br /> = References =<br /> # Mads Soegaard, &quot;Interaction Styles&quot;, interaction-design.org, http://www.interaction-design.org/encyclopedia/interaction_styles.html<br /> # Byron Long, &quot;Natural Language as an Interaction Style&quot;, Retrieved on November 21st, 2009 from http://www.dgp.toronto.edu/people/byron/papers/nli.html<br /> # Bill Buxton, &quot;The &quot;Natural&quot; Language of Interaction&quot;, Retrieved on November 21st, 2009 from http://www.billbuxton.com/natural.html<br /> # Microsoft Office Online, &quot;Use the Ribbon - Help and How-to&quot;, Retrieved on November 23rd, 2009 from http://office.microsoft.com/en-us/help/HA100898951033.aspx<br /> <br /> --[[User:Shensw|Shensw]] 22:55, 20 November 2009 (EST)<br /> <br /> --[[User:Collim|Collim]] 23:50, 21 November 2009 (EST)<br /> <br /> --[[User:Frostd|Frostd]] 00:58, 22 November 2009 (EST)<br /> <br /> --[[User:Simpsoa|Simpsoa]] 15:45, 23 November 2009 (EST)</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Five_Interaction_Styles 2009-11-23T20:44:18Z

<p>Simpsoa:&#32;/* Menus */</p> <hr /> <div>The '''Five Interaction Styles''' originally presented by Ben Shneiderman in 1983 represent the five basic ways that humans interact with a computer interface. Each interaction style effects the overall efficiency and usability of the computer system, but that is not to say there are good or bad interaction styles. The styles all have benefits and trade offs when dealing with certain types of users and it is often in an interface designers best interest to use a combination of styles instead of anyone one style alone.<br /> <br /> = Shneiderman's Five Interaction Styles =<br /> <br /> == Visual representation ==<br /> [[Image:DirectManipulation.jpg|thumb|300px|right|Simple example of file/folder metaphor in Windows Vista]]<br /> <br /> Visual representation (also known as [[Direct Manipulation]]) features a natural representation of task [http://www.cas.mcmaster.ca/wiki/index.php/The_Object-Action_%28or_visa-versa%29_model_and_its_applications objects and actions]. This helps present the process as actually performing a task itself directly even though it is being doing through an intermediary like a computer. The visual representation usually takes the form of a metaphor related to the actual task being performed. In this way well designed visual representation systems tend to make the interaction enjoyable for the users, which is excellent for novice users or complex tasks that can lead to anxiety.<br /> <br /> === + Advantages ===<br /> * Visual presentation of task concepts<br /> * Allows easy learning<br /> * Encourages exploration<br /> * Users can immediately see if their actions are furthering their goals<br /> * Users gain confidence because they feel in control and can predict system responses<br /> <br /> === - Disadvantages ===<br /> * Can be hard to implement<br /> * Requires graphics display/pointing devices<br /> <br /> == Menus ==<br /> [[Image:menus1.gif|thumb|300px|right|Example of a typical menu in Windows XP]]<br /> [[Image:menus2.gif|thumb|300px|right|Microsoft Office's &quot;ribbon&quot; UI, an example of tabbed toolbars]]<br /> <br /> Menus provide a way to visually organise a very large set of actions. Menus are nearly ubiquitous in modern applications, with the most standard format being the &quot;File/Edit&quot; style strip located across the top of windows (such as in Microsoft Windows) or the user's workspace (such as in [[Multiple Document Interfaces]], or in Mac OS X). Menus do not have any obvious physical metaphor, and rely on users being able to tell the difference between an action, and a category which can be expanded into a child set of actions and/or further categories. Menus can also change depending on context, from enabling or disabling individual items depending on the program's state, to using &quot;tabbed toolbars&quot; to flip between item collections.<br /> <br /> === + Advantages ===<br /> * Accessible to novice and intermittent users <br /> * Allows for a very large palette of structured commands which can be easily &quot;explored&quot;<br /> * Facilitates Multiple Document Interfaces well<br /> * Does not rely on parsing input<br /> <br /> === - Disadvantages ===<br /> * Can bury useful features under complex hierarchies<br /> * Number of items limited by screen resolution<br /> * Convention restricts how menu items are categorised<br /> <br /> == Fill-In-The-Blanks ==<br /> [[Image:formfillin1.gif|thumb|300px|right|Classic Fill-In-The-Blanks]]<br /> [[Image:formfillin2.gif|thumb|300px|right|Modern-day Fill-In-The-Blanks]]<br /> The Fill-In-The-Blanks interaction style (also known as &quot;Form Fill-in&quot;) is best suited to data input, which was aimed at a different set of users than command language, specially non-experts users. Originally Fill-In-The-Blanks is to arrange one or more fields in the form of a prose sentence or phrase, with the fields as &quot;blanks&quot; to be filled in by the user. The TAB-key was designed and is still being used to switch between the fields and ENTER to submit the form. Therefore a pointing device (such as a mouse) was not really needed at that time. However it's very common to mix forms with other interaction styles in software design, such as drop down menus, check boxes etc. The spreadsheet is a variation on the Form Fill-in interaction style. Even today, there are quite a few computers are still purely forms-based in the industry, like cash registers, financial systems, stock control systems, and so on. The main reason is because the Fill-In-The-Blanks interface is especially useful for routine, clerical work or those tasks require a great amount of data entry.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Simplifies data entry<br /> * Minimal training - Shortens learning in that the fields are predefined and need only be 'recognized'.<br /> * Gives convenient assistance - Guides the user via the predefined rules<br /> * Permits use of form-management tools<br /> <br /> === - Disadvantages ===<br /> * Screen space consuming<br /> * requires more keystrokes<br /> * requires handling typing errors (bad for users with poor typing skills)<br /> <br /> == Command Line ==<br /> [[Image:Commandline.png|thumb|300px|right|Ubuntu command line showing basic commands]]<br /> <br /> Command line is the earliest used interaction style and is still seen predominantly in Unix operating systems though still usable to varying degrees on Windows and OSX. This style is mainly used by expert users by typing into a prompt that allows them to quickly execute commands. Unfortunately command line places a considerable burden on the user to learn and recall commands from memory. It is often the case that commands take parameters as well and most of the added benefits (mainly in the way of efficiency) come from using them. This leads to an unfriendly environment for both novice and intermediate users that may attempt to use this style. The large overhead in learning commands and minimal help for the user leaves this style almost exclusively in the domain of the expert user.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * quick and powerful for experienced users<br /> * user-controlled interaction<br /> * minimal amount of typing (no mouse use)<br /> * can be used in conjunction with other user interfaces<br /> <br /> === - Disadvantages ===<br /> * little or no prompting<br /> * requires user’s knowledge of system, programs<br /> * relies on recall of commands and syntax<br /> * difficult to learn<br /> * error prone<br /> <br /> == Natural Language ==<br /> Natural Language is an interaction style which allows the user to communicate with their computer through a series of spoken commands, similar to how one may issue spoken commands to another person. However the benefits and applicability of Natural Language systems thus far is very limited, largely due to the imprecise and verbose nature of spoken languages. A major issue with using spoken language is that to communicate with computer systems the vocabulary would need to be limited to a specific subset of a full natural language, in order to both reduce ambiguity and keep processing time within reasonable bounds. One solution to the ambiguity of spoken languages is to utilize gestural language, which is considered at least as natural as verbal language. At the same time, the definition of what makes a natural language is very important. It is not as though humans are born knowing spoken word or gestures; a natural language is simply one which can be grasped fluently by the time one is required to draw upon it. A language could be considered natural, if upon approaching a computer the typical user already possesses language skills adequate for communicating desired concepts in a fluent and articulate manner. So in a sense Natural Language could involve a kind of language humans develop with the sole purpose of communicating with computer systems, thus potentially eliminating the ambiguities of the current natural spoken languages. Thus far however Natural Language has not seen widespread use, and often requires each user to train the computer to recognize their own voice. Natural Language could be very useful for those with minimal keyboard skills, and once it more accurately interprets verbal commands may even see widespread use one day. &lt;sup&gt;[2][3]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Allows users to communicate with their system naturally<br /> * Can reduce or eliminate the need for keyboards, great for those with poor keyboard skills<br /> * Once it is more accurate at interpreting speech, commands may be able to be spoken faster than they are typed<br /> <br /> === - Disadvantages ===<br /> * Currently cannot accurately interpret much of verbal language, which is too ambiguous<br /> * Requires a lot of training for each user so it can interpret their verbal commands<br /> <br /> = See also =<br /> <br /> * [[Motivations for the Studies of HCI]]<br /> * [[Contexts for HCI]]<br /> * [[Process for User-centered Development]]<br /> * [[Social issues influencing HCI design and use]]<br /> * [[HCI - Accommodating human diversity]]<br /> * [[User Interface Standards]]<br /> * [[The Object-Action (or visa-versa) model and its applications]]<br /> * [[Direct Manipulation]]<br /> <br /> = References =<br /> # Mads Soegaard, &quot;Interaction Styles&quot;, interaction-design.org, http://www.interaction-design.org/encyclopedia/interaction_styles.html<br /> # Byron Long, &quot;Natural Language as an Interaction Style&quot;, Retrieved on November 21st, 2009 from http://www.dgp.toronto.edu/people/byron/papers/nli.html<br /> # Bill Buxton, &quot;The &quot;Natural&quot; Language of Interaction&quot;, Retrieved on November 21st, 2009 from http://www.billbuxton.com/natural.html<br /> <br /> --[[User:Shensw|Shensw]] 22:55, 20 November 2009 (EST)<br /> <br /> --[[User:Collim|Collim]] 23:50, 21 November 2009 (EST)<br /> <br /> --[[User:Frostd|Frostd]] 00:58, 22 November 2009 (EST)</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Five_Interaction_Styles 2009-11-23T20:32:45Z

<p>Simpsoa:&#32;/* Menus */</p> <hr /> <div>The '''Five Interaction Styles''' originally presented by Ben Shneiderman in 1983 represent the five basic ways that humans interact with a computer interface. Each interaction style effects the overall efficiency and usability of the computer system, but that is not to say there are good or bad interaction styles. The styles all have benefits and trade offs when dealing with certain types of users and it is often in an interface designers best interest to use a combination of styles instead of anyone one style alone.<br /> <br /> = Shneiderman's Five Interaction Styles =<br /> <br /> == Visual representation ==<br /> <br /> Visual representation (also known as [[Direct Manipulation]]) features a natural representation of task [http://www.cas.mcmaster.ca/wiki/index.php/The_Object-Action_%28or_visa-versa%29_model_and_its_applications objects and actions]. This helps present the process as actually performing a task itself directly even though it is being doing through an intermediary like a computer. The visual representation usually takes the form of a metaphor related to the actual task being performed. In this way well designed visual representation systems tend to make the interaction enjoyable for the users, which is excellent for novice users or complex tasks that can lead to anxiety.<br /> <br /> === + Advantages ===<br /> * Visual presentation of task concepts<br /> * Allows easy learning<br /> * Encourages exploration<br /> * Users can immediately see if their actions are furthering their goals<br /> * Users gain confidence because they feel in control and can predict system responses<br /> <br /> === - Disadvantages ===<br /> * Can be hard to implement<br /> * Requires graphics display/pointing devices<br /> <br /> == Menus ==<br /> [[Image:menus1.gif|thumb|300px|right|Example of a typical menu in Windows XP]]<br /> [[Image:menus2.gif|thumb|300px|right|Microsoft's new &quot;ribbon&quot; menu]]<br /> <br /> Menus provide a way to visually organise a very large set of actions. Menus are nearly ubiquitous in modern applications, with the most standard format being the &quot;File/Edit&quot; strip located across the top of windows (such as in Microsoft Windows) or the user's workspace (such as in Multiple Document Interfaces or in Mac OS X).<br /> <br /> === + Advantages ===<br /> * Accessible to novice and intermittent users <br /> * Allows for a very large pallette of structured commands which can be easily &quot;explored&quot;<br /> * Facilitates Multiple Document Interfaces well<br /> * Does not rely on parsing input<br /> <br /> === - Disadvantages ===<br /> * Can bury useful features under complex hierarchies<br /> * Number of items limited by screen resolution<br /> * Convention restricts how menu items are categorised<br /> <br /> == Fill-In-The-Blanks ==<br /> [[Image:formfillin1.gif|thumb|300px|right|Classic Fill-In-The-Blanks]]<br /> [[Image:formfillin2.gif|thumb|300px|right|Modern-day Fill-In-The-Blanks]]<br /> The Fill-In-The-Blanks interaction style (also known as &quot;Form Fill-in&quot;) is best suited to data input, which was aimed at a different set of users than command language, specially non-experts users. Originally Fill-In-The-Blanks is to arrange one or more fields in the form of a prose sentence or phrase, with the fields as &quot;blanks&quot; to be filled in by the user. The TAB-key was designed and is still being used to switch between the fields and ENTER to submit the form. Therefore a pointing device (such as a mouse) was not really needed at that time. However it's very common to mix forms with other interaction styles in software design, such as drop down menus, check boxes etc. The spreadsheet is a variation on the Form Fill-in interaction style. Even today, there are quite a few computers are still purely forms-based in the industry, like cash registers, financial systems, stock control systems, and so on. The main reason is because the Fill-In-The-Blanks interface is especially useful for routine, clerical work or those tasks require a great amount of data entry.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Simplifies data entry<br /> * Minimal training - Shortens learning in that the fields are predefined and need only be 'recognized'.<br /> * Gives convenient assistance - Guides the user via the predefined rules<br /> * Permits use of form-management tools<br /> <br /> === - Disadvantages ===<br /> * Screen space consuming<br /> * requires more keystrokes<br /> * requires handling typing errors (bad for users with poor typing skills)<br /> <br /> == Command Line ==<br /> [[Image:Commandline.png|thumb|300px|right|Ubuntu command line showing basic commands]]<br /> <br /> Command line is the earliest used interaction style and is still seen predominantly in Unix operating systems though still usable to varying degrees on Windows and OSX. This style is mainly used by expert users by typing into a prompt that allows them to quickly execute commands. Unfortunately command line places a considerable burden on the user to learn and recall commands from memory. It is often the case that commands take parameters as well and most of the added benefits (mainly in the way of efficiency) come from using them. This leads to an unfriendly environment for both novice and intermediate users that may attempt to use this style. The large overhead in learning commands and minimal help for the user leaves this style almost exclusively in the domain of the expert user.&lt;sup&gt;[1]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * quick and powerful for experienced users<br /> * user-controlled interaction<br /> * minimal amount of typing (no mouse use)<br /> * can be used in conjunction with other user interfaces<br /> <br /> === - Disadvantages ===<br /> * little or no prompting<br /> * requires user’s knowledge of system, programs<br /> * relies on recall of commands and syntax<br /> * difficult to learn<br /> * error prone<br /> <br /> == Natural Language ==<br /> Natural Language is an interaction style which allows the user to communicate with their computer through a series of spoken commands, similar to how one may issue spoken commands to another person. However the benefits and applicability of Natural Language systems thus far is very limited, largely due to the imprecise and verbose nature of spoken languages. A major issue with using spoken language is that to communicate with computer systems the vocabulary would need to be limited to a specific subset of a full natural language, in order to both reduce ambiguity and keep processing time within reasonable bounds. One solution to the ambiguity of spoken languages is to utilize gestural language, which is considered at least as natural as verbal language. At the same time, the definition of what makes a natural language is very important. It is not as though humans are born knowing spoken word or gestures; a natural language is simply one which can be grasped fluently by the time one is required to draw upon it. A language could be considered natural, if upon approaching a computer the typical user already possesses language skills adequate for communicating desired concepts in a fluent and articulate manner. So in a sense Natural Language could involve a kind of language humans develop with the sole purpose of communicating with computer systems, thus potentially eliminating the ambiguities of the current natural spoken languages. Thus far however Natural Language has not seen widespread use, and often requires each user to train the computer to recognize their own voice. Natural Language could be very useful for those with minimal keyboard skills, and once it more accurately interprets verbal commands may even see widespread use one day. &lt;sup&gt;[2][3]&lt;/sup&gt;<br /> <br /> === + Advantages ===<br /> * Allows users to communicate with their system naturally<br /> * Can reduce or eliminate the need for keyboards, great for those with poor keyboard skills<br /> * Once it is more accurate at interpreting speech, commands may be able to be spoken faster than they are typed<br /> <br /> === - Disadvantages ===<br /> * Currently cannot accurately interpret much of verbal language, which is too ambiguous<br /> * Requires a lot of training for each user so it can interpret their verbal commands<br /> <br /> = See also =<br /> <br /> * [[Motivations for the Studies of HCI]]<br /> * [[Contexts for HCI]]<br /> * [[Process for User-centered Development]]<br /> * [[Social issues influencing HCI design and use]]<br /> * [[HCI - Accommodating human diversity]]<br /> * [[User Interface Standards]]<br /> * [[The Object-Action (or visa-versa) model and its applications]]<br /> * [[Direct Manipulation]]<br /> <br /> = References =<br /> # Mads Soegaard, &quot;Interaction Styles&quot;, interaction-design.org, http://www.interaction-design.org/encyclopedia/interaction_styles.html<br /> # Byron Long, &quot;Natural Language as an Interaction Style&quot;, Retrieved on November 21st, 2009 from http://www.dgp.toronto.edu/people/byron/papers/nli.html<br /> # Bill Buxton, &quot;The &quot;Natural&quot; Language of Interaction&quot;, Retrieved on November 21st, 2009 from http://www.billbuxton.com/natural.html<br /> <br /> = External links =<br /> <br /> --[[User:Shensw|Shensw]] 22:55, 20 November 2009 (EST)<br /> <br /> --[[User:Collim|Collim]] 23:50, 21 November 2009 (EST)<br /> <br /> --[[User:Frostd|Frostd]] 00:58, 22 November 2009 (EST)</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-13T02:31:11Z

<p>Simpsoa:&#32;Finalising</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> Due to communication over large distances, [[satellite]] [[internet]] connections naturally have a large amount of latency regardless of bandwidth.<br /> <br /> ==Measuring Latency==<br /> [[Image:Ping.JPG|thumb|right|350px|Using Ping to calculate network latency in Microsoft Windows XP.]]<br /> Network conditions constantly fluctuate, and so measuring the latency in transmitting a packet between the same two endpoints multiple times can have differing results. Because of this, the latency of any single packet may not be a meaningful measurement. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Round-trip communication times can be measured from a single host, and taking the average latency over several packets provides a reasonable estimate of the delay needed for future packets to arrive. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher. Also, the time a host takes to process packets is typically not included when calculating a round-trip time, but users and applications waiting for data will experience this delay just the same.<br /> <br /> Using [[Ping]] is a simple way to find your latency relative to some host address.<br /> <br /> ==Issues==<br /> ===Streaming media===<br /> Latency in [[streaming]] video or audio is not itself an issue, and (ideally) only delays receipt by an absolute amount roughly equal to the connection's average latency. Sudden spikes in latency may cause the stream to be interrupted, though [[buffering]] is effective at preventing this to a point. Latency however becomes an issue when communication or interactivity is involved. Live television broadcasts have noticeable latency due to the nature of their transmission, which becomes apparent during satellite interviews and the like. This delay is a common problem with [[VoIP]] services such as [http://www.skype.com/intl/en/ Skype]<br /> <br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|450px|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine implement a number of lag compensation techniques&lt;sup&gt;[1]&lt;/sup&gt;. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as ''client-side prediction''.<br /> <br /> In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a [[naive]] collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).<br /> <br /> ==Potential Uses==<br /> Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible. An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of [[time dilation]].&lt;sup&gt;[2]&lt;/sup&gt; The end result is that through using what are called ''local perception filters'' a fully synchronized game can appear to be going in slow motion for short periods to some players but not others. If implemented naively, this disparity in game speeds would cause players to desynchronize.<br /> <br /> ==References==<br /> *1. [http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking Source Engine Multiplayer Networking]<br /> *2. [http://www.sciencedirect.com/science?_ob=ArticleURL&amp;_udi=B6VRG-4G94G99-2&amp;_user=10&amp;_rdoc=1&amp;_fmt=&amp;_orig=search&amp;_sort=d&amp;view=c&amp;_acct=C000050221&amp;_version=1&amp;_urlVersion=0&amp;_userid=10&amp;md5=64b8d82ca3ba63232b0e8712ce061840 Realizing the bullet time effect in multiplayer games with local perception filters]<br /> * [http://compnetworking.about.com/od/speedtests/a/network_latency.htm About.com, Network Bandwidth and Latency]<br /> * [http://developer.valvesoftware.com/wiki/Lag_Compensation Valve development wiki page on lag compensation]<br /> <br /> ==See Also==<br /> *[[Packet-switching]]<br /> *[[Multiplayer Games]]<br /> *[[Ping]]<br /> *[[Computer Networking]]<br /> *[[Bandwidth]]<br /> <br /> ==External Links==<br /> *[http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html Wide Awake Developers, Architecting for Latency]<br /> *[http://www.wikihow.com/Test-Network-and-Internet-Latency-(Lag)-in-Microsoft-Windows wikiHow, Instructions for testing latency in Microsoft Windows]</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-13T02:13:58Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> Due to communication over large distances, [[satellite]] [[internet]] connections naturally have a large amount of latency regardless of bandwidth.<br /> <br /> ==Measuring Latency==<br /> [[Image:Ping.JPG|thumb|right|350px|Using Ping to calculate network latency in Microsoft Windows XP.]]<br /> Network conditions constantly fluctuate, and so measuring the latency in transmitting a packet between the same two endpoints multiple times can have differing results. Because of this, the latency of any single packet may not be a meaningful measurement. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Round-trip communication times can be measured from a single host, and taking the average latency over several packets provides a reasonable estimate of the delay needed for future packets to arrive. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher. Also, the time a host takes to process packets is typically not included when calculating a round-trip time, but users and applications waiting for data will experience this delay just the same.<br /> <br /> Using [[Ping]] is a simple way to find your latency relative to some host address.<br /> <br /> <br /> ==Issues==<br /> ===Streaming media===<br /> Latency in [[streaming]] video or audio is not itself an issue, and (ideally) only delays by an absolute amount roughly equal to the packets' average latency. Sudden spikes in latency may cause the media to be interrupted, though [[buffering]] is effective at preventing this to a point. Latency however becomes an issue when communication or interactivity is involved. Live television broadcasts have noticeable latency due to the nature of their transmission, and becomes apparent during satellite interviews and the like.<br /> <br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|450px|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine implement a number of lag compensation techniques&lt;sup&gt;[1]&lt;/sup&gt;. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).<br /> <br /> ==Potential Uses==<br /> <br /> Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible. An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of [[time dilation]].&lt;sup&gt;[2]&lt;/sup&gt; The end result is that through using what are called ''local perception filters'' a fully synchronized game can appear to be going in slow motion for short periods to some players but not others.<br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> ==References==<br /> *1. http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> *2. http://www.sciencedirect.com/science?_ob=ArticleURL&amp;_udi=B6VRG-4G94G99-2&amp;_user=10&amp;_rdoc=1&amp;_fmt=&amp;_orig=search&amp;_sort=d&amp;view=c&amp;_acct=C000050221&amp;_version=1&amp;_urlVersion=0&amp;_userid=10&amp;md5=64b8d82ca3ba63232b0e8712ce061840<br /> *3. https://developer.mozilla.org/En/Link_prefetching_FAQ<br /> *4. http://developer.valvesoftware.com/wiki/Lag_Compensation<br /> ==See Also==<br /> *[[Packet-switching]]<br /> *[[Multiplayer Games]]<br /> *[[Ping]]<br /> *[[Computer Networking]]<br /> *[[Bandwidth]]<br /> ==External Links==<br /> http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-13T00:35:27Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> [[Image:Ping.JPG|thumb|right|350px|Using Ping to calculate network latency in Microsoft Windows XP.]]<br /> Network conditions constantly fluctuate, and so measuring the latency in transmitting a packet between the same two endpoints multiple times can have differing results. Because of this, the latency of any single packet may not be a meaningful measurement. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Round-trip communication times can be measured from a single host, and taking the average latency over several packets provides a reasonable estimate of the delay needed for future packets to arrive. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher. Also, the time a host takes to process packets is typically not included when calculating a round-trip time, but users and applications waiting for data will experience this delay just the same.<br /> <br /> Using [[Ping]] is a simple way to find your latency relative to some host address.<br /> <br /> <br /> ==Issues==<br /> ===Web Surfing===<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|500px|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine &lt;sup&gt;[x]&lt;/sup&gt; implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).<br /> <br /> ==Potential Uses==<br /> <br /> Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible. An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of [[time dilation]].&lt;sup&gt;[x]&lt;/sup&gt; The end result is that through using what are called ''local perception filters'' a fully synchronized game can appear to be going in slow motion for short periods to some players but not others.<br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> ==References==<br /> {{reflist}}<br /> http://en.wikipedia.org/wiki/Link_prefetching<br /> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> ==See Also==<br /> http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/File:Ping.JPG 2009-04-13T00:08:08Z

<p>Simpsoa:&#32;Using Ping to calculate network latency in Microsoft Windows XP.</p> <hr /> <div>Using Ping to calculate network latency in Microsoft Windows XP.</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-12T23:59:57Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Network conditions constantly fluctuate, and so measuring the latency in transmitting a packet between the same two endpoints multiple times can have differing results. Because of this, the latency of any single packet may not be a meaningful measurement. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Round-trip communication times can be measured from a single host, and taking the average latency over several packets provides a reasonable estimate of the delay needed for future packets to arrive. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher. Also, the time a host takes to process packets is typically not included when calculating a round-trip time, but users and applications waiting for data will experience this delay just the same.<br /> <br /> Using [[Ping]] is a simple way to find your latency relative to some host address.<br /> <br /> <br /> ==Issues==<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|600px|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine &lt;sup&gt;[x]&lt;/sup&gt; implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).<br /> <br /> ==Compensating for latency==<br /> When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching<br /> <br /> Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds. <br /> ===Prefetching===<br /> Some web browsers (such as Mozilla Firefox &lt;sup&gt;[x]&lt;/sup&gt;)<br /> <br /> ===Prediction===<br /> <br /> <br /> ===Interpolation===<br /> [[Image:Interpolation.gif|right|]]<br /> Programs which <br /> <br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> http://en.wikipedia.org/wiki/Link_prefetching<br /> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> ==See Also==<br /> http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-12T22:45:53Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Issues caused ==<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|600px|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine &lt;sup&gt;[x]&lt;/sup&gt; implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).<br /> <br /> ==Compensating for latency==<br /> When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching<br /> <br /> Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds. <br /> ===Prefetching===<br /> Some web browsers (such as Mozilla Firefox &lt;sup&gt;[x]&lt;/sup&gt;)<br /> <br /> ===Prediction===<br /> <br /> <br /> ===Interpolation===<br /> [[Image:Interpolation.gif|right|]]<br /> Programs which <br /> <br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> http://en.wikipedia.org/wiki/Link_prefetching<br /> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> ==See Also==<br /> http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-12T22:22:28Z

<p>Simpsoa:&#32;/* Issues Caused by Latency and Solutions */</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Issues caused ==<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|600px|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine &lt;sup&gt;[x]&lt;/sup&gt; implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).<br /> <br /> ==Compensating for latency==<br /> When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching<br /> <br /> Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds. <br /> ===Prefetching===<br /> Some web browsers (such as Mozilla Firefox &lt;sup&gt;[x]&lt;/sup&gt;)<br /> <br /> ===Prediction===<br /> <br /> <br /> ===Interpolation===<br /> [[Image:Interpolation.gif|right|]]<br /> Programs which <br /> <br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> http://en.wikipedia.org/wiki/Link_prefetching<br /> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-12T22:02:36Z

<p>Simpsoa:&#32;/* Effects */</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Issues Caused by Latency and Solutions==<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|600px|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine &lt;sup&gt;[x]&lt;/sup&gt; implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> In order to mitigate the discrepancies between the server's gamestate and the clients', latency can be factored into critical gameplay calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state.<br /> <br /> ==Compensating for latency==<br /> When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching<br /> <br /> Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds. <br /> ===Prefetching===<br /> Some web browsers (such as Mozilla Firefox &lt;sup&gt;[x]&lt;/sup&gt;)<br /> <br /> ===Prediction===<br /> <br /> <br /> ===Interpolation===<br /> [[Image:Interpolation.gif|right|]]<br /> Programs which <br /> <br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> http://en.wikipedia.org/wiki/Link_prefetching<br /> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-12T21:58:37Z

<p>Simpsoa:&#32;/* Real-Time Gaming */</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Effects==<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|600px|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine &lt;sup&gt;[x]&lt;/sup&gt; implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> In order to mitigate the discrepancies between the server's gamestate and the clients', latency can be factored into critical gameplay calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state.<br /> <br /> ==Compensating for latency==<br /> When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching<br /> <br /> Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds. <br /> ===Prefetching===<br /> Some web browsers (such as Mozilla Firefox &lt;sup&gt;[x]&lt;/sup&gt;)<br /> <br /> ===Prediction===<br /> <br /> <br /> ===Interpolation===<br /> [[Image:Interpolation.gif|right|]]<br /> Programs which <br /> <br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> http://en.wikipedia.org/wiki/Link_prefetching<br /> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-12T21:22:27Z

<p>Simpsoa:&#32;Much new content in gaming section</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Effects==<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Image:Lag_compensation.jpg|thumb|right|600px|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate for the delay by performing input earlier than actually desired.<br /> <br /> Modern [[game engines]] such as Valve Software's Source Engine &lt;sup&gt;[x]&lt;/sup&gt; implement a number of lag compensation techniques. To eliminate the apparent delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden &quot;jerking&quot; effect known as &quot;rubber-banding&quot;). This method is known as '''client-side prediction'''.<br /> <br /> Client-side prediction is based off the assumption that basing gameplay events off of clients' individual latencies as well as the server's authoritative state provides a smoother experience. Whenever a predicted effect <br /> <br /> ==Compensating for latency==<br /> When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching<br /> <br /> Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds. <br /> ===Prefetching===<br /> Some web browsers (such as Mozilla Firefox &lt;sup&gt;[x]&lt;/sup&gt;)<br /> <br /> ===Prediction===<br /> <br /> <br /> ===Interpolation===<br /> [[Image:Interpolation.gif|right|]]<br /> Programs which <br /> <br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> http://en.wikipedia.org/wiki/Link_prefetching<br /> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/File:Interpolation.gif 2009-04-12T17:54:46Z

<p>Simpsoa:&#32;A diagram describing a form of lag compensation known as entity interpolation.</p> <hr /> <div>A diagram describing a form of lag compensation known as entity interpolation.</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/File:Lag_compensation.jpg 2009-04-12T17:38:44Z

<p>Simpsoa:&#32;An example of lag compensation in Counter-Strike: Source.</p> <hr /> <div>An example of lag compensation in Counter-Strike: Source.</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-08T23:22:37Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Effects==<br /> ===Quantum Computing===<br /> ===Real-Time Gaming===<br /> [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate their actions for the delay, but most games now use some method of client-side prediction in order to avoid the need to.<br /> <br /> ==Mitigation strategies==<br /> ===Prefetching===<br /> <br /> ===Prediction===<br /> ===Interpolation===<br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Ping 2009-04-05T17:58:19Z

<p>Simpsoa:&#32;Ping moved to Ping (disambiguation): This was originally intended as a disambiguation page.</p> <hr /> <div>#REDIRECT [[Ping (disambiguation)]]</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Ping_(disambiguation) 2009-04-05T17:58:19Z

<p>Simpsoa:&#32;Ping moved to Ping (disambiguation): This was originally intended as a disambiguation page.</p> <hr /> <div>'''Ping''' may refer to:<br /> <br /> *[[Ping (utility)]], a computer networking tool used to test whether a particular host is reachable across an IP network.<br /> *[[Network Latency]], in the context of online multiplayer games.</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Ping_(disambiguation) 2009-04-05T17:57:30Z

<p>Simpsoa:&#32;New page: '''Ping''' may refer to: *Ping (utility), a computer networking tool used to test whether a particular host is reachable across an IP network. *Network Latency, in the context of ...</p> <hr /> <div>'''Ping''' may refer to:<br /> <br /> *[[Ping (utility)]], a computer networking tool used to test whether a particular host is reachable across an IP network.<br /> *[[Network Latency]], in the context of online multiplayer games.</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Lag 2009-04-05T17:34:23Z

<p>Simpsoa:&#32;Redirecting to Network Latency</p> <hr /> <div>#REDIRECT [[Network Latency]]</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-04T00:15:08Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> The round-trip time of a packet is also commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Effects==<br /> ===Quantum Computing===<br /> ===Space Exploration===<br /> ===Real-Time Gaming===<br /> [[Real-time]] [[online]] multiplayer [[games]] suffer from network latency, causing a delay between the players' inputs and the game's response. Games of this type are typically designed to use a [[client-server networking]] model. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. Initially the only way to circumvent this was for players to mentally compensate their actions for the delay, but most games now use some method of client-side prediction in order to avoid the need to.<br /> <br /> ==Mitigation strategies==<br /> ===Prefetching===<br /> <br /> ===Prediction===<br /> ===Interpolation===<br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-04T00:10:08Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> The round-trip time of a packet is also commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Effects==<br /> ===Quantum Computing===<br /> ===Space Exploration===<br /> ===Real-Time Gaming===<br /> Real-time online multiplayer games suffer from network latency, in that a delay is caused between the players' inputs and the game's response. Games in this format are typically designed to use a client-server networking model, with one instance of the application acting as the authority on the game's current state, and client instances through which the players interface with the server. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players.<br /> <br /> ==Mitigation strategies==<br /> ===Prefetching===<br /> <br /> ===Prediction===<br /> ===Interpolation===<br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-03T23:55:31Z

<p>Simpsoa:&#32;</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect.<br /> <br /> In the context of [[packet-switching]] networks, latency can refer to any of the following:<br /> <br /> *The time from when a packet is sent to when that packet reaches its destination<br /> *The round-trip time of a packet<br /> *The perceived delay in communication between hosts<br /> <br /> The round-trip time of a packet is also commonly known as '''ping'''.<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as [[bandwidth]] limitations and [[routing]] issues contribute to the time that a message spends in transit.<br /> ===Application performance===<br /> Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as [[packet collisions]]), because the user will only see the time from when the request was sent to when the message was successfully received.<br /> ===Distance===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.<br /> <br /> ==Measuring Latency==<br /> Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue with measuring latency is the fact that any communication between hosts reporting the latency experienced on either end will itself be information subject to delay on the network.<br /> <br /> A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.<br /> <br /> Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.<br /> ==Effects==<br /> ===Quantum Computing===<br /> ===Space Exploration===<br /> <br /> ==Mitigation==<br /> ===Prefetching===<br /> ===Prediction===<br /> ===Interpolation===<br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-03T23:02:08Z

<p>Simpsoa:&#32;Added sections.</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''Latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect. In computer networking, '''Network Latency''' commonly refers to the round-trip time of a network [http://en.wikipedia.org/wiki/Packet_(information_technology) packet] (also known as &quot;ping&quot;).<br /> <br /> ==Causes==<br /> ===Traffic Congestion===<br /> ===Distance===<br /> ===Application performance===<br /> ===Propagation===<br /> Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours.<br /> <br /> ==Effects==<br /> ===Quantum Computing===<br /> ===Space Exploration===<br /> <br /> ==Mitigation==<br /> ===Prefetching===<br /> ===Prediction===<br /> ===Interpolation===<br /> <br /> <br /> &lt;ref&gt;{{cite journal |title=Realizing the bullet time effect in multiplayer games with local perception filters |author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen |journal=Computer Networks |volume=49 |issue=1 |pages=27-37 |date=31 May 2005}}&lt;/ref&gt;<br /> <br /> <br /> ==References==<br /> {{reflist}}<br /> ==See Also==<br /> ==External Links==</div>

Simpsoa http://wiki.cas.mcmaster.ca/index.php/Network_Latency 2009-04-03T19:49:17Z

<p>Simpsoa:&#32;New page: As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''Latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect. In co...</p> <hr /> <div>As an [http://en.wikipedia.org/wiki/Engineering Engineering] term, '''Latency''' refers to the span of time taken from when some action is initiated to when it actually takes effect. In computer networking, '''Network Latency''' commonly refers to the round-trip time of a network [http://en.wikipedia.org/wiki/Packet_(information_technology) packet] (also known as &quot;ping&quot;).</div>

Simpsoa