anchor.diff:  </tr>
   </table>
   
  -The Auctioneer then orders the jobs like this:
  +The Auctioneer then builds an ordered sequence of LRP instances by cycling through the list of LRPs in decreasing order of load. With each cycle, it adds another instance of each LRP to the sequence, until all desired instances of the LRP have been added. With the example above, the Auctioneer would order the LRPs like this:
   
   ![LRP Sequence](../images/diego/diego-LRP-stack.png)
   
  -The Auctioneer then builds an ordered sequence for all jobs, both LRPs and Tasks. Reflecting the priority order above, the first instances of LRP jobs are first priority, Tasks are next, and duplicate LRP jobs follow. Adding one-time Task-C (load = 4) and Task-D (load = 3) to the above example, the priority order becomes:
  +The Auctioneer then builds an ordered sequence for all jobs, both LRPs and Tasks. Reflecting the auction batch [priority order](#order), the first instances of LRPs are first priority. Tasks are next, in decreasing order of load. Duplicate LRP jobs come last.
  +
  +Adding one-time Task-C (load = 4) and Task-D (load = 3) to the above example, the priority order becomes:
   
   ![Auction Sequence](../images/diego/diego-auction-stack.png)
   
  
positive.code: 
  The Diego Auction algorithm allocates jobs to VMs to fulfill the following outcomes, in decreasing **priority** order:
  
  1. Keep at least one instance of each LRP running
  
  1. Run all of the Tasks in the current batch
  
  1. Distribute as much of the total desired LRP load as possible over the remaining available VMs, by spreading multiple LRP instances broadly across VMs and their [Availability Zones](../glossary.html).
  
  To achieve these outcomes, each auction begins with the [Diego Auctioneer](./diego-components.html#auctioneer) component arranging the batch's jobs into a priority order. The Auctioneer sorts all jobs in decreasing order of memory load, so that larger units of work are placed first. Some of these jobs may be duplicate instances that Diego needs to allocate for high-traffic LRPs, to meet demand.
  
  The Auctioneer then builds an ordered sequence of LRP instances by cycling through the list of LRPs in decreasing order of load, and adding instances of each onto the sequence until all LRPs reach their desired instance count, the number of duplicate instances for each LRP that it will allocate.
  
  For example, if the job LRP-A has a desired instance count of 3 and a memory load of 2, and job LRP-B has 2 desired instances and a load of 5, the Auctioneer creates a list of jobs as follows:
  
  <table border="1" class="nice" >
  <tr>
  
negative.code: 
  ##<a id='another'></a>Triggering Another Auction
  
  The Diego Auction process repeats to adapt a Cloud Foundry deployment to its changing workload. For example, the [Cloud Controller](../architecture/cloud-controller.html) initiates a new auction when it detects that the actual number of running instances of LRPs does not match the number desired. The Cloud Controller’s [BBS](./diego-components.html#bbs) component monitors the number of instances of each LRP that are currently running. The [Converger](./diego-components.html#converger) component periodically compares this number with the desired number of LRP instances, as configured by the user. If the actual number falls short of what is desired, the Converger triggers a new auction. In the case of a surplus of application instances, the Converger kills the extra instances and initiates another auction.
  
  The Cloud Controller also triggers an auction whenever a Cell fails. After any auction, if a Cell responds to its work request with a message that it cannot perform the work after all, the Auctioneer carries the unallocated work over into the next batch. But if the Cell fails to respond entirely, for example if its connection times out, the unresponsive Cell may still be running its work. In this case, the Auctioneer does not automatically carry the Cell's work over to the next batch. Instead, the Auctioneer defers to the Converger to continue monitoring the states of the Cells, and to re-assign unassigned work later if needed.
  
  