<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Weblazer</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Weblazer"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Weblazer"/>
	<updated>2026-05-13T16:18:18Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82527</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82527"/>
		<updated>2013-11-19T17:09:29Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Other Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue workload management, also called distributed workload management, each processor is responsible for maintaining a sufficient workload. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor workload manager to send work. The remote load manager receiving the request examines its own workload and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their workload and can still manage workloads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory workload at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized workload manager is responsible for distributing workload to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized workload manager. One workload manager would be in charge of distributing workloads to each cluster workload manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Comparisons of Static versus Dynamic==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Table: Comparison of Load Balancing Algorithms&amp;lt;ref name=&amp;quot;complb&amp;quot;&amp;gt;http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
{{cite web&lt;br /&gt;
 |        url = http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
 |      title = Performance Analysis of Load Balancing Algorithms&lt;br /&gt;
 |      last1 = &lt;br /&gt;
 |     first1 = &lt;br /&gt;
 |    middle1 = &lt;br /&gt;
 |      last2 = &lt;br /&gt;
 |     first2 = &lt;br /&gt;
 |    middle2 = &lt;br /&gt;
 |   location = &lt;br /&gt;
 |       date = &lt;br /&gt;
 | accessdate November 19, 2013&lt;br /&gt;
 |  separator = ,&lt;br /&gt;
 }}&lt;br /&gt;
&amp;lt;/ref&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
! Parameters&lt;br /&gt;
! Round Robin&lt;br /&gt;
! Random&lt;br /&gt;
! Central Manager&lt;br /&gt;
! Local Queue&lt;br /&gt;
! Central Queue&lt;br /&gt;
|-&lt;br /&gt;
| Dynamic/Static&lt;br /&gt;
| Static&lt;br /&gt;
| Static&lt;br /&gt;
| Static&lt;br /&gt;
| Dynamic&lt;br /&gt;
| Dynamic&lt;br /&gt;
|-&lt;br /&gt;
| Overload Rejection&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Fault Tolerant&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Forecasting Accuracy&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
|-&lt;br /&gt;
| Stability&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Small&lt;br /&gt;
| Small&lt;br /&gt;
|-&lt;br /&gt;
| Centralized/Decentralized&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
|-&lt;br /&gt;
| Cooperative&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Process Migration&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Resource Utilization&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode &amp;lt;ref name=&amp;quot;pseudocode&amp;quot;&amp;gt;http://code.google.com/p/hypertable/wiki/LoadBalancing&lt;br /&gt;
{{cite web&lt;br /&gt;
 |        url = http://code.google.com/p/hypertable/wiki/LoadBalancing&lt;br /&gt;
 |      title = Load Balancing Design&lt;br /&gt;
 |      last1 = &lt;br /&gt;
 |     first1 = &lt;br /&gt;
 |    middle1 = &lt;br /&gt;
 |      last2 = &lt;br /&gt;
 |     first2 = &lt;br /&gt;
 |    middle2 = &lt;br /&gt;
 |   location = &lt;br /&gt;
 |       date = &lt;br /&gt;
 | accessdate December 28, 2010&lt;br /&gt;
 |  separator = ,&lt;br /&gt;
 }}&lt;br /&gt;
&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
====References====&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Other Sources====&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82526</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82526"/>
		<updated>2013-11-19T17:08:30Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue workload management, also called distributed workload management, each processor is responsible for maintaining a sufficient workload. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor workload manager to send work. The remote load manager receiving the request examines its own workload and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their workload and can still manage workloads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory workload at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized workload manager is responsible for distributing workload to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized workload manager. One workload manager would be in charge of distributing workloads to each cluster workload manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Comparisons of Static versus Dynamic==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Table: Comparison of Load Balancing Algorithms&amp;lt;ref name=&amp;quot;complb&amp;quot;&amp;gt;http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
{{cite web&lt;br /&gt;
 |        url = http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
 |      title = Performance Analysis of Load Balancing Algorithms&lt;br /&gt;
 |      last1 = &lt;br /&gt;
 |     first1 = &lt;br /&gt;
 |    middle1 = &lt;br /&gt;
 |      last2 = &lt;br /&gt;
 |     first2 = &lt;br /&gt;
 |    middle2 = &lt;br /&gt;
 |   location = &lt;br /&gt;
 |       date = &lt;br /&gt;
 | accessdate November 19, 2013&lt;br /&gt;
 |  separator = ,&lt;br /&gt;
 }}&lt;br /&gt;
&amp;lt;/ref&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
! Parameters&lt;br /&gt;
! Round Robin&lt;br /&gt;
! Random&lt;br /&gt;
! Central Manager&lt;br /&gt;
! Local Queue&lt;br /&gt;
! Central Queue&lt;br /&gt;
|-&lt;br /&gt;
| Dynamic/Static&lt;br /&gt;
| Static&lt;br /&gt;
| Static&lt;br /&gt;
| Static&lt;br /&gt;
| Dynamic&lt;br /&gt;
| Dynamic&lt;br /&gt;
|-&lt;br /&gt;
| Overload Rejection&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Fault Tolerant&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Forecasting Accuracy&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
|-&lt;br /&gt;
| Stability&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Small&lt;br /&gt;
| Small&lt;br /&gt;
|-&lt;br /&gt;
| Centralized/Decentralized&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
|-&lt;br /&gt;
| Cooperative&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Process Migration&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Resource Utilization&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode &amp;lt;ref name=&amp;quot;pseudocode&amp;quot;&amp;gt;http://code.google.com/p/hypertable/wiki/LoadBalancing&lt;br /&gt;
{{cite web&lt;br /&gt;
 |        url = http://code.google.com/p/hypertable/wiki/LoadBalancing&lt;br /&gt;
 |      title = Load Balancing Design&lt;br /&gt;
 |      last1 = &lt;br /&gt;
 |     first1 = &lt;br /&gt;
 |    middle1 = &lt;br /&gt;
 |      last2 = &lt;br /&gt;
 |     first2 = &lt;br /&gt;
 |    middle2 = &lt;br /&gt;
 |   location = &lt;br /&gt;
 |       date = &lt;br /&gt;
 | accessdate December 28, 2010&lt;br /&gt;
 |  separator = ,&lt;br /&gt;
 }}&lt;br /&gt;
&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
====References====&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Other Sources====&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82521</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82521"/>
		<updated>2013-11-19T17:06:32Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue workload management, also called distributed workload management, each processor is responsible for maintaining a sufficient workload. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor workload manager to send work. The remote load manager receiving the request examines its own workload and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their workload and can still manage workloads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory workload at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized workload manager is responsible for distributing workload to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized workload manager. One workload manager would be in charge of distributing workloads to each cluster workload manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Comparisons of Static versus Dynamic==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Table: Comparison of Load Balancing Algorithms&amp;lt;ref name=&amp;quot;complb&amp;quot;&amp;gt;http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
{{cite web&lt;br /&gt;
 |        url = http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
 |      title = Performance Analysis of Load Balancing Algorithms&lt;br /&gt;
 |      last1 = &lt;br /&gt;
 |     first1 = &lt;br /&gt;
 |    middle1 = &lt;br /&gt;
 |      last2 = &lt;br /&gt;
 |     first2 = &lt;br /&gt;
 |    middle2 = &lt;br /&gt;
 |   location = &lt;br /&gt;
 |       date = &lt;br /&gt;
 | accessdate November 19, 2013&lt;br /&gt;
 |  separator = ,&lt;br /&gt;
 }}&lt;br /&gt;
&amp;lt;/ref&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
! Parameters&lt;br /&gt;
! Round Robin&lt;br /&gt;
! Random&lt;br /&gt;
! Central Manager&lt;br /&gt;
! Local Queue&lt;br /&gt;
! Central Queue&lt;br /&gt;
|-&lt;br /&gt;
| Overload Rejection&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Fault Tolerant&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Forecasting Accuracy&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
|-&lt;br /&gt;
| Stability&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Small&lt;br /&gt;
| Small&lt;br /&gt;
|-&lt;br /&gt;
| Centralized/Decentralized&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
|-&lt;br /&gt;
| Dynamic/Static&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
|-&lt;br /&gt;
| Cooperative&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Process Migration&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Resource Utilization&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode &amp;lt;ref name=&amp;quot;pseudocode&amp;quot;&amp;gt;http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
{{cite web&lt;br /&gt;
 |        url = http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
 |      title = Performance Analysis of Load Balancing Algorithms&lt;br /&gt;
 |      last1 = &lt;br /&gt;
 |     first1 = &lt;br /&gt;
 |    middle1 = &lt;br /&gt;
 |      last2 = &lt;br /&gt;
 |     first2 = &lt;br /&gt;
 |    middle2 = &lt;br /&gt;
 |   location = &lt;br /&gt;
 |       date = &lt;br /&gt;
 | accessdate November 19, 2013&lt;br /&gt;
 |  separator = ,&lt;br /&gt;
 }}&lt;br /&gt;
&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
====References====&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Other Sources====&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82519</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82519"/>
		<updated>2013-11-19T17:02:29Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue workload management, also called distributed workload management, each processor is responsible for maintaining a sufficient workload. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor workload manager to send work. The remote load manager receiving the request examines its own workload and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their workload and can still manage workloads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory workload at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized workload manager is responsible for distributing workload to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized workload manager. One workload manager would be in charge of distributing workloads to each cluster workload manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Comparisons of Static versus Dynamic==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Table: Comparison of Load Balancing Algorithms&amp;lt;ref name=&amp;quot;complb&amp;quot;&amp;gt;http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
{{cite web&lt;br /&gt;
 |        url = http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf&lt;br /&gt;
 |      title = Performance Analysis of Load Balancing Algorithms&lt;br /&gt;
 |      last1 = &lt;br /&gt;
 |     first1 = &lt;br /&gt;
 |    middle1 = &lt;br /&gt;
 |      last2 = &lt;br /&gt;
 |     first2 = &lt;br /&gt;
 |    middle2 = &lt;br /&gt;
 |   location = &lt;br /&gt;
 |       date = &lt;br /&gt;
 | accessdate November 19, 2013&lt;br /&gt;
 |  separator = ,&lt;br /&gt;
 }}&lt;br /&gt;
&amp;lt;/ref&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
! Parameters&lt;br /&gt;
! Round Robin&lt;br /&gt;
! Random&lt;br /&gt;
! Central Manager&lt;br /&gt;
! Local Queue&lt;br /&gt;
! Central Queue&lt;br /&gt;
|-&lt;br /&gt;
| Overload Rejection&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Fault Tolerant&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Forecasting Accuracy&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
|-&lt;br /&gt;
| Stability&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Small&lt;br /&gt;
| Small&lt;br /&gt;
|-&lt;br /&gt;
| Centralized/Decentralized&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
|-&lt;br /&gt;
| Dynamic/Static&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
|-&lt;br /&gt;
| Cooperative&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Process Migration&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Resource Utilization&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode [http://code.google.com/p/hypertable/wiki/LoadBalancing [1]] &lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
====References====&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
====Other Sources====&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82511</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82511"/>
		<updated>2013-11-19T16:54:43Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue workload management, also called distributed workload management, each processor is responsible for maintaining a sufficient workload. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor workload manager to send work. The remote load manager receiving the request examines its own workload and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their workload and can still manage workloads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory workload at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized workload manager is responsible for distributing workload to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized workload manager. One workload manager would be in charge of distributing workloads to each cluster workload manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Comparisons of Static versus Dynamic==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Table: Comparison of Load Balancing Algorithms&lt;br /&gt;
|-&lt;br /&gt;
! Parameters&lt;br /&gt;
! Round Robin&lt;br /&gt;
! Random&lt;br /&gt;
! Central Manager&lt;br /&gt;
! Local Queue&lt;br /&gt;
! Central Queue&lt;br /&gt;
|-&lt;br /&gt;
| Overload Rejection&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Fault Tolerant&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Forecasting Accuracy&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
|-&lt;br /&gt;
| Stability&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Small&lt;br /&gt;
| Small&lt;br /&gt;
|-&lt;br /&gt;
| Centralized/Decentralized&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
|-&lt;br /&gt;
| Dynamic/Static&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
|-&lt;br /&gt;
| Cooperative&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Process Migration&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Resource Utilization&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode [1]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82510</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82510"/>
		<updated>2013-11-19T16:53:55Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Dynamic Load Balancing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue workload management, also called distributed workload management, each processor is responsible for maintaining a sufficient workload. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor workload manager to send work. The remote load manager receiving the request examines its own workload and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their workload and can still manage workloads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory workload at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized workload manager is responsible for distributing workload to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized workload manager. One workload manager would be in charge of distributing workloads to each cluster workload manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Comparisons of Static versus Dynamic==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Table: Comparison of Load Balancing Algorithms&lt;br /&gt;
|-&lt;br /&gt;
! Parameters&lt;br /&gt;
! Round Robin&lt;br /&gt;
! Random&lt;br /&gt;
! Central Manager&lt;br /&gt;
! Local Queue&lt;br /&gt;
! Central Queue&lt;br /&gt;
|-&lt;br /&gt;
| Overload Rejection&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Fault Tolerant&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Forecasting Accuracy&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
|-&lt;br /&gt;
| Stability&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Large&lt;br /&gt;
| Small&lt;br /&gt;
| Small&lt;br /&gt;
|-&lt;br /&gt;
| Centralized/Decentralized&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
| D&lt;br /&gt;
| C&lt;br /&gt;
|-&lt;br /&gt;
| Dynamic/Static&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| S&lt;br /&gt;
| D&lt;br /&gt;
| D&lt;br /&gt;
|-&lt;br /&gt;
| Cooperative&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| Process Migration&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| No&lt;br /&gt;
| Yes&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| Resource Utilization&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| Less&lt;br /&gt;
| More&lt;br /&gt;
| Less&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82506</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82506"/>
		<updated>2013-11-19T16:51:12Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Static Load balancing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue work load management, also called distributed work load management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines its own work load and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their work load and can still manage work loads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory work load at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized work load manager. One work load manager would be in charge of distributing work loads to each cluster work load manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Comparisons of Static versus Dynamic==&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82502</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82502"/>
		<updated>2013-11-19T16:37:30Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to improved performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, work loads are evenly spread by random chance. Random is fairly easy to implement with little overhead. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large effect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue work load management, also called distributed work load management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines its own work load and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their work load and can still manage work loads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory work load at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized work load manager. One work load manager would be in charge of distributing work loads to each cluster work load manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of its central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 //sort the load data and store it in different orders for use later&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
 //While the deviation is too high, iterate through the nodes&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD)&lt;br /&gt;
 {&lt;br /&gt;
   //get the tasks for node [0], and sort them&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   i=0;&lt;br /&gt;
   //iterates through the past load data for this node&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp; i &amp;lt; range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     &amp;amp;nbsp;&lt;br /&gt;
     //If a given swap results in a lesser deviation&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation)&lt;br /&gt;
     {&lt;br /&gt;
        //swap and update load balance data related to the load swap&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //if true, then the entire load has been processed for this node, and entry [0] which is the current node can be removed&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
   {&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   }&lt;br /&gt;
 &amp;amp;nbsp;&lt;br /&gt;
   //re-balance the load before iterating again on the next node&lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Simulation of Static Load Balancing Algorithms on Homogeneous and Heterogeneous CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://masters.donntu.edu.ua/2010/fknt/babkin/library/article11.pdf Performance Analysis of Load Balancing Algorithms]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82289</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82289"/>
		<updated>2013-10-31T16:15:22Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue work load management, also called distributed work load management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their work load and can still manager work loads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory work load at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized work load manager. One work load manager would be in charge of distributing work loads to each cluster work load manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of it's central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ics.uci.edu/~cs237/reading/parallel.pdf Strategies for Dynamic Load Balancing on Highly Parallel Computers] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx SIMULATION OF STATIC LOAD BALANCING ALGORITHMS ON HOMOGENEOUS AND HETEROGENEOUS CPUs ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82288</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82288"/>
		<updated>2013-10-31T16:13:50Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue work load management, also called distributed work load management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their work load and can still manager work loads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory work load at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized work load manager. One work load manager would be in charge of distributing work loads to each cluster work load manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of it's central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
====Weather Modeling====&lt;br /&gt;
&lt;br /&gt;
====Visible Human Project====&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.vsrdjournals.com/CSIT/Issue/2013_05_May/Web/1_Jagdeep_Singh_1670_Research_Article_VSRDIJCSIT_May_2013.docx Strategies for Dynamic Load Balancing on Highly Parallel Computers ] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82285</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82285"/>
		<updated>2013-10-31T16:06:52Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Central Manager */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. The central node assigns each new task to the slave processor which currently has the least load. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing. This method also greatly reduces the chance that any one processor is overworked or left idle.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue work load management, also called distributed work load management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their work load and can still manager work loads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory work load at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request. In systems with large numbers of processors, clusters can be formed of groups of processors with each cluster have a centralized work load manager. One work load manager would be in charge of distributing work loads to each cluster work load manager. This scheme has a lower fault tolerance as the system can be at risk of being brought down if the central load manager were to stop working. Also, an entire cluster could stop producing of it's central load manager were to stop functioning.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82282</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82282"/>
		<updated>2013-10-31T16:01:25Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue work load management, also called distributed work load management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager. This algorithm scheme is fault tolerant in that if any processor were to fail, the other nodes would be able to continue working as they still have their work load and can still manager work loads with other processors. Unfortunately, this scheme generally requires a relatively large amount of inter-processor communications to maintain a satisfactory work load at all processors.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://paper.ijcsns.org/07_book/201006/20100619.pdf A Guide to Dynamic Load Balancing in Distributed Computer Systems] &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82279</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82279"/>
		<updated>2013-10-31T16:00:17Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Random */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also assign multiple large tasks to a single processor in a short period of time, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82278</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82278"/>
		<updated>2013-10-31T15:59:21Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Static Vs. Dynamic Techniques */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also sparingly assign multiple large tasks to a single processor, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82277</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82277"/>
		<updated>2013-10-31T15:59:08Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Static Load balancing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
     ==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also sparingly assign multiple large tasks to a single processor, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82276</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82276"/>
		<updated>2013-10-31T15:58:26Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Static Vs. Dynamic Techniques */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
==='''Static Load balancing'''===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also sparingly assign multiple large tasks to a single processor, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82275</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82275"/>
		<updated>2013-10-31T15:57:56Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Static Load balancing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
'''===Static Load balancing==='''&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also sparingly assign multiple large tasks to a single processor, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82274</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82274"/>
		<updated>2013-10-31T15:55:34Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Central Manager */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also sparingly assign multiple large tasks to a single processor, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
Central manager is a load balancing scheme which selects a certain processor to act as the &amp;quot;central node&amp;quot;, which handles the balancing. This method has a different overhead than usual. Before there would be intercommunication between all processors, where as with central load balancing, the communication exists solely between the central node and the other processors. A drawback of the Central Management is that it usually works best with smaller networks of processors. A hierarchy of master central nodes controlling lesser central nodes is possible, but adds more complexity. It is possible for a central control node to be inundated by messages from its children nodes, locking up the system and causing great drops in performance. The Central Manager policy has an advantage because it requires fewer messages to be sent in order to facilitate load balancing.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
Under local queue management, each processor is responsible for maintaining a sufficient work load. When a load drops below a threshold, the load manager for the processor fires off a request to another random processor work load manager to send work. The remote load manager receiving the request examines it's own work load and, if it has sufficient extra work load, will send work to the requesting load manager.&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
A centralized work load manager is responsible for distributing work load to processors under the central queue algorithm. The central manager is aware of all work to be distributed to the processors. When a processor's load falls below a threshold, a request for more work is sent to the central load manager, which then distributes more work. If there is not enough work in the central queue to meet the demand, the request is buffered until there enough work is available to meet the request.&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82260</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82260"/>
		<updated>2013-10-31T15:31:22Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Random */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
Random load balancing relies on the hope that over the course of enough time, workloads are evenly spread by random chance. Random is fairly easy to implement with little overheard. Generating good &amp;quot;random&amp;quot; values is one challenge, because the function is called so many times that any bias will have a large affect. Random suffers from the same drawbacks as round robin though. There is always the chance that a certain processor is randomly picked in an unusually frequent fashion, leading to wait times for other processors. Random could also sparingly assign multiple large tasks to a single processor, which would also lead to uneven load balancing.&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82259</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=82259"/>
		<updated>2013-10-31T15:24:23Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Round Robin */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
In multi-processor systems, load-balancing is used to break-up and distribute the work load to individual processors in order to make effective use of processor time. When the work load is divided up at compile-time, the balance is said to be ''statically'' balanced. Dividing the work load up during run-time is ''dynamically'' balancing the load. Static load balancing has reduced overhead as the work is divided before run time. Dynamic load balancing assigns work as processors become idle, so there is greater overhead. However, dynamic balancing can lead to increased performance of load balancing due to being able to assign work to a processor when it does become idle, reducing the overall idle time of processors.&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
Round robin is a load balancing technique which evenly distributes tasks across available processors. Each processor is lined up, and given a task one after the other until it loops around again back to the first processor. Visualize a dealer in a casino passing out cards to each player in a circle, one at a time. The advantage is that this is a very simple load balancing technique to implement, with very little overhead. A disadvantage is that there is no care given to the job size or performance. This can create problems if a processor is unlucky and is continually assigned large tasks, causing it to fall behind.&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80131</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80131"/>
		<updated>2013-10-08T16:00:30Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80130</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80130"/>
		<updated>2013-10-08T15:59:58Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://code.google.com/p/hypertable/wiki/LoadBalancing Load Balancing PseudoCode and other information]  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80129</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80129"/>
		<updated>2013-10-08T15:57:09Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80128</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80128"/>
		<updated>2013-10-08T15:56:21Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Dynamic Load Balancing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
====Local Queue====&lt;br /&gt;
&lt;br /&gt;
====Central Queue====&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80127</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80127"/>
		<updated>2013-10-08T15:53:45Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Static Load balancing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
====Round Robin====&lt;br /&gt;
&lt;br /&gt;
====Random====&lt;br /&gt;
&lt;br /&gt;
====Central Manager====&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80119</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80119"/>
		<updated>2013-10-08T15:44:40Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
 server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
 while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
   populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
   sort descending range_load_vec;&lt;br /&gt;
   i=0;&lt;br /&gt;
   while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
             i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
     if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
        add range_load_vec[i] to balance plan&lt;br /&gt;
        partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
        server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
        server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
        server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
        server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
     }&lt;br /&gt;
     i++;&lt;br /&gt;
   }&lt;br /&gt;
   if (i == range_load_vec.size())&lt;br /&gt;
     remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
   server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80118</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80118"/>
		<updated>2013-10-08T15:43:08Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
  populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
  sort descending range_load_vec;&lt;br /&gt;
  i=0;&lt;br /&gt;
  while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
            i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
    if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
       add range_load_vec[i] to balance plan&lt;br /&gt;
       partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
       server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
       server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
       server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
    }&lt;br /&gt;
    i++;&lt;br /&gt;
  }&lt;br /&gt;
  if (i == range_load_vec.size())&lt;br /&gt;
    remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
  server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80117</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80117"/>
		<updated>2013-10-08T15:40:33Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
  populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
  sort descending range_load_vec;&lt;br /&gt;
  i=0;&lt;br /&gt;
  while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
            i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
    if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
       add range_load_vec[i] to balance plan&lt;br /&gt;
       partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
       server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
       server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
       server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
    }&lt;br /&gt;
    i++;&lt;br /&gt;
  }&lt;br /&gt;
  if (i == range_load_vec.size())&lt;br /&gt;
    remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
  server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
}&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80116</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80116"/>
		<updated>2013-10-08T15:40:19Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
{&lt;br /&gt;
&lt;br /&gt;
server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
  populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
  sort descending range_load_vec;&lt;br /&gt;
  i=0;&lt;br /&gt;
  while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
            i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
    if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
       add range_load_vec[i] to balance plan&lt;br /&gt;
       partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
       server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
       server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
       server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
    }&lt;br /&gt;
    i++;&lt;br /&gt;
  }&lt;br /&gt;
  if (i == range_load_vec.size())&lt;br /&gt;
    remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
  server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
}&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80115</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80115"/>
		<updated>2013-10-08T15:40:00Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
  populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
  sort descending range_load_vec;&lt;br /&gt;
  i=0;&lt;br /&gt;
  while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
            i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
    if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
       add range_load_vec[i] to balance plan&lt;br /&gt;
       partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
       server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
       server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
       server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
    }&lt;br /&gt;
    i++;&lt;br /&gt;
  }&lt;br /&gt;
  if (i == range_load_vec.size())&lt;br /&gt;
    remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
  server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
}&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80114</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80114"/>
		<updated>2013-10-08T15:39:35Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Load Balancing in action */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;br /&gt;
&lt;br /&gt;
Server Load balancing pseudocode&lt;br /&gt;
&lt;br /&gt;
server_load_vec_desc = sort_descending(server_load_vec);&lt;br /&gt;
server_load_vec_asc = sort_ascending(server_load_vec);&lt;br /&gt;
while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD) {&lt;br /&gt;
  populate_range_load_vector(server_load_vec_desc[0].server_name);&lt;br /&gt;
  sort descending range_load_vec;&lt;br /&gt;
  i=0;&lt;br /&gt;
  while (server_load_vec_desc[0].deviation &amp;gt; DEVIATION_THRESHOLD &amp;amp;&amp;amp;&lt;br /&gt;
            i &amp;lt; range_load_vec.size()) {&lt;br /&gt;
    if (moving range_load_vec[i] from server_load_vec_desc[0] to server_load_vec_asc[0] reduces deviation) {&lt;br /&gt;
       add range_load_vec[i] to balance plan&lt;br /&gt;
       partial_deviation = range_load_vec[i].loadestimate * loadavg_per_loadestimate;&lt;br /&gt;
       server_load_vec_desc[0].loadavg -= partial_deviation;&lt;br /&gt;
       server_load_vec_desc[0].deviation -= partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].loadavg += partial_deviation;&lt;br /&gt;
       server_load_vec_asc[0].deviation += partial_deviation;&lt;br /&gt;
       server_load_vec_asc = sort_ascending(server_load_vec_asc); &lt;br /&gt;
    }&lt;br /&gt;
    i++;&lt;br /&gt;
  }&lt;br /&gt;
  if (i == range_load_vec.size())&lt;br /&gt;
    remove server_load_vec_desc[0] and corresponding entry in server_load_vec_asc  &lt;br /&gt;
  server_load_vec_desc = sort_descending(server_load_vec_desc);&lt;br /&gt;
}&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80109</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80109"/>
		<updated>2013-10-08T15:27:25Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Static Load balancing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing===&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80108</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80108"/>
		<updated>2013-10-08T15:27:15Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Load Balancing=&lt;br /&gt;
&lt;br /&gt;
==Static Vs. Dynamic Techniques==&lt;br /&gt;
&lt;br /&gt;
===Static Load balancing===&lt;br /&gt;
&lt;br /&gt;
===Dynamic Load Balancing&lt;br /&gt;
&lt;br /&gt;
==Real World applications of Load Balancing==&lt;br /&gt;
&lt;br /&gt;
==Examples of Load Balancing in action==&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80106</id>
		<title>CSC 456 Fall 2013/4a bc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/4a_bc&amp;diff=80106"/>
		<updated>2013-10-08T15:23:26Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: Created page with &amp;quot;rsfsdfdf&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;rsfsdfdf&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76814</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76814"/>
		<updated>2013-09-17T16:05:10Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [6]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers]  Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1] Wikipedia&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray XK7] Wikipedia&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, 	Thomas R. Puzak&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76813</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76813"/>
		<updated>2013-09-17T16:04:43Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [6]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers]  Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1] Wikipedia&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7] Wikipedia&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, 	Thomas R. Puzak&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76811</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76811"/>
		<updated>2013-09-17T16:04:18Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [6]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers]  Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, 	Thomas R. Puzak&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76810</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76810"/>
		<updated>2013-09-17T16:04:02Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [6]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ] Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, 	Thomas R. Puzak&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76807</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76807"/>
		<updated>2013-09-17T16:02:32Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Examples of Pipeline changes in Different Processors */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [6]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, 	Thomas R. Puzak&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76806</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76806"/>
		<updated>2013-09-17T16:02:21Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, 	Thomas R. Puzak&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76804</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76804"/>
		<updated>2013-09-17T16:01:10Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth] A. Hartstein, 	Thomas R. Puzak&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76802</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76802"/>
		<updated>2013-09-17T16:00:09Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi &amp;amp; Murakami&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76801</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76801"/>
		<updated>2013-09-17T15:59:29Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase, Magoshi &amp;amp; Murakami]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture: Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76798</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76798"/>
		<updated>2013-09-17T15:55:40Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* An Example of Pipeline changes in Cray Systems */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==Examples of Pipeline changes in Different Processors==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76795</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76795"/>
		<updated>2013-09-17T15:55:01Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* An Example of Pipeline changes in Cray Systems */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==An Example of Pipeline changes in Cray Systems==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76794</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76794"/>
		<updated>2013-09-17T15:54:43Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Factors Favoring Shorter Pipeline Length */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==An Example of Pipeline changes in Cray Systems==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif An example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76788</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76788"/>
		<updated>2013-09-17T15:50:16Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* An Example of Pipeline changes in Cray Systems */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length..&lt;br /&gt;
&amp;quot; When a performance increase is attempted by further increasing the number of stages for a processor in which  the  number  of  stages  is  more  than  90%  of  the optimum for performance, the performance is found not to be increased unless the increasable latch overhead time is less than the overhead time. &amp;quot; [5] - An Analysis about Increasable Latch Overhead Time for Processor Pipeline Depth Increase&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==An Example of Pipeline changes in Cray Systems==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 &lt;br /&gt;
| 3 [2]&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23 [7]&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7&lt;br /&gt;
| 12 for scalar , 17 for vector [3]&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif An example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76787</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76787"/>
		<updated>2013-09-17T15:49:42Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length..&lt;br /&gt;
&amp;quot; When a performance increase is attempted by further increasing the number of stages for a processor in which  the  number  of  stages  is  more  than  90%  of  the optimum for performance, the performance is found not to be increased unless the increasable latch overhead time is less than the overhead time. &amp;quot; [5] - An Analysis about Increasable Latch Overhead Time for Processor Pipeline Depth Increase&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==An Example of Pipeline changes in Cray Systems==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 [2]&lt;br /&gt;
| 3&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7 [3]&lt;br /&gt;
| 12 for scalar , 17 for vector&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif An example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76785</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76785"/>
		<updated>2013-09-17T15:48:14Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length..&lt;br /&gt;
&amp;quot; When a performance increase is attempted by further increasing the number of stages for a processor in which  the  number  of  stages  is  more  than  90%  of  the optimum for performance, the performance is found not to be increased unless the increasable latch overhead time is less than the overhead time. &amp;quot; [5] - An Analysis about Increasable Latch Overhead Time for Processor Pipeline Depth Increase&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==An Example of Pipeline changes in Cray Systems==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 [2]&lt;br /&gt;
| 3&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7 [3]&lt;br /&gt;
| 12 for scalar , 17 for vector&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif An example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76780</id>
		<title>CSC 456 Fall 2013/1d vb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC_456_Fall_2013/1d_vb&amp;diff=76780"/>
		<updated>2013-09-17T15:42:23Z</updated>

		<summary type="html">&lt;p&gt;Weblazer: /* Sources */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Trends in Pipelining=&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.  &lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Longer Pipeline Length==&lt;br /&gt;
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work. &lt;br /&gt;
&lt;br /&gt;
There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.&lt;br /&gt;
&lt;br /&gt;
==Factors Favoring Shorter Pipeline Length==&lt;br /&gt;
&lt;br /&gt;
The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple &amp;quot;best&amp;quot; pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.&lt;br /&gt;
&lt;br /&gt;
Latch delays can also play a role when you increase pipeline Length..&lt;br /&gt;
&amp;quot; When a performance increase is attempted by further increasing the number of stages for a processor in which  the  number  of  stages  is  more  than  90%  of  the optimum for performance, the performance is found not to be increased unless the increasable latch overhead time is less than the overhead time. &amp;quot; [5] - An Analysis about Increasable Latch Overhead Time for Processor Pipeline Depth Increase&lt;br /&gt;
&lt;br /&gt;
==Power Consumption vs. Performance==&lt;br /&gt;
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan, &lt;br /&gt;
&lt;br /&gt;
==An Example of Pipeline changes in Cray Systems==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Pipeline Specifications of Cray Systems&lt;br /&gt;
|-&lt;br /&gt;
! Year&lt;br /&gt;
! Name&lt;br /&gt;
! Pipeline Length&lt;br /&gt;
! Number of Pipelines&lt;br /&gt;
|-&lt;br /&gt;
| 1976&lt;br /&gt;
| Cray 1 [2]&lt;br /&gt;
| 3&lt;br /&gt;
| 12&lt;br /&gt;
|-&lt;br /&gt;
|2006&lt;br /&gt;
|IBM Cell BE&lt;br /&gt;
|23&lt;br /&gt;
|16&lt;br /&gt;
|-&lt;br /&gt;
| 2012&lt;br /&gt;
| Cray XK7 [3]&lt;br /&gt;
| 12 for scalar , 17 for vector&lt;br /&gt;
| 6&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif An example of the Cell Pipeline]&lt;br /&gt;
&lt;br /&gt;
==Sources==&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=1&amp;amp;cad=rja&amp;amp;ved=0CE4QFjAA&amp;amp;url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&amp;amp;ei=hQsmUv6LKMnJsASb8IGACQ&amp;amp;usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&amp;amp;sig2=fZvAhhwalsuZAs7GuamDHg&amp;amp;bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers ]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/Cray-1 Cray 1]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://en.wikipedia.org/wiki/XK7 Cray SK7]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[https://www.google.com/url?sa=t&amp;amp;rct=j&amp;amp;q=&amp;amp;esrc=s&amp;amp;source=web&amp;amp;cd=2&amp;amp;cad=rja&amp;amp;ved=0CDkQFjAB&amp;amp;url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&amp;amp;ei=BwwmUtX-D7OgsQSrxYCgDw&amp;amp;usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&amp;amp;sig2=Hfx9Gs6MI8XtOVT3PvoDlw&amp;amp;bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;[http://dl.acm.org/citation.cfm?id=956566 Optimum Power/Performance Pipeline Depth]&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;/div&gt;</summary>
		<author><name>Weblazer</name></author>
	</entry>
</feed>