Implementation issues Determining local load NOT difficult (despite what tannenbaum says) The case he mentions is possible but not dominant Do not ask for "perfect" informantion (not clear what it means) Normally use a weighted mean of recent loads with more recent weighted higher Normally uniprocessor stuff Do not forget that complexity (i.e. difficulty) is bad Of course Do not forget the cost of getting additional information needed for a better decision. Of course Example algorithms Min cut determanistic algorithm Define a graph with processes as nodes and IPC traffic as arcs Goal: Cut the graph (i.e some arcs) into pieces so that All nodes in one piece can be run on one processor Mem constraints Processor completion times Values on cut arcs minimized Min the max min max traffic for a process pair min the sum min total traffic (tannenbaum's def) min the sum to/from a piece don't overload a processor min the sum between pieces min traffic for processor pair Tends to get hard as you get more realistic Want more than just processor constraints Figures of merit discussed above The same traffic between different processor pairs does not cost the same HOMEWORK 12-14 Up-down centralized algorithm Centralized table that keeps "usage" data for a USER, the users are defined to be the workstation owners. Call this the score for the user. Goal is to give each user a fare share. When workstation requests a remote job, if wkstation avail it is assigned For each process user has running remotely, the user's score increases a fixed amt each time interval. When a user has an unsatisfied request pending (and none being satisfied), the score decreases (can go negative). If no requests pending and none being satisfied, score bumped towards zero. When a processor becomes free, assign it to a requesting user with lowest score. Hierarchical algorithm This was used in a system where each processor could run at most one process. But we describe a more general situation. Quick idea of algorithm Processors in tree Requests go up tree until subtree has enought resourses Request is split and parts go back down tree Arrange processors in a hierarchy (tree) This is a logical tree independent of how physically connected Each node keeps (imperfect) track of how many available processors are below it. If a processor can run more than one process, must be more sophisticated and must keep track of how many processes can be allocated (without overload) in the subtree below. If a new request appears in the tree, the curent node sees if it can be satisfied by the processors below (plus itself). If so, do it. If not pass the request up the tree Actually since machines may be down or the data on availability may be out of date, you actually try to find more processes than requested Once a request has gone high enough to be satisfied, the current node splits request into pieces and sends each piece to appropriate child. What if a node dies? Promote one of its children say C Now C's children are peers with the previous peers of C If this is considered too unbalanced, can promote one of C children to take C's place. How decide which child C to promote? Peers of dead node have an election Children of dead node have an election Parent of dead node decides What if root dies? Must use children since no peers or parent If want to use peers, then do not have a single root I.e. the top level of the hierarchy is a collection of roots that communicate This is a forest, not a tree What if multiple requests are generated simutaneously? Gets hard fast as information gets stale and potential race conditions and deadlocks are possible. See Van Tilborg and Wittie Distributed heuristic algorithm Send probe to random If remote load is low, ship job If remote load is high, try another random probe After k (parameter of implementation) probes all say load is too high, give up and run job locally. Modelled analytically and seen to work fairly well Bidding View the dist system as a collection of competing servide providers and processes (users?) as potential customers. Customers bid for service and computers pick the highest bid. This is just a sketch. MUCH needs to be filled in. Scheduling General goal is to have processes that communicate frequently run simultaneously If not and use busy waiting for msgs will have an huge disaster. Even if use context switching, may have a small disaster as only one msg transfer can occur per time scheduling slot Co-scheduling (aka gang scheduling). Processes belonging to a job are scheduled together Time slots are coordinated among the processors. Some slots are for gangs; other slots are for regular processors. HOMEWORK 12-16 (use figure 12-27b) Tannenbaum asserts "there is not much to say about scheduling in a distributed system" Wrong. Concept of job scheduling In many big systems (e.g. SP2, T3E) run job scheduler User gives max time (say wall time) and number of processors System can use this information to figure out the latest time a job can run (i.e. assumes all preceeding jobs use all their time). If a job finishes early and the following job needs more processors than avail, look for subsequent jobs that Don't need more processors than available Won't run past the time the scheduler promised to the following job. This is called backfilling