Large Software System Programming Project
CPSC410 – Operating Systems
Loman: Distributed Traveling Salesman
Utilizing Simulated Annealing Schedules
FINAL REPORT
Principle Investigators
Christopher Hewitt
Martin Press
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community
Ask the community for help and clear up your study doubts
University Rankings
Discover the best universities in your country according to Docsity users
Free resources
Our save-the-student-ebooks!
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Distributed Approach to Traveling Salesman Problem using Simulated Annealing with Loman, Study Guides, Projects, Research of Operating Systems
Loman is a large software system programming project that utilizes a distributed approach to find approximate solutions to the np-complete traveling salesman problem using simulated annealing. The project was developed using sparc solaris machines and openmpi libraries for message passing. The computational engine is portable and can be extended to solve other np-complete problems. The project provides hands-on experience with various operating system principles, including security, networking, batch processing, access control, priority queues, multithreading, multiprocessing, and user interface. The larger the number of towns simulated, the longer it takes for a worker node to converge to a reasonable solution, but utilizing parallelism of a cluster, reasonable solutions are likely to be found sooner with an increasing number of worker nodes.
Typology: Study Guides, Projects, Research
Pre 2010
1 / 12
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Distributed Approach to Traveling Salesman Problem using Simulated Annealing with Loman and more Study Guides, Projects, Research Operating Systems in PDF only on Docsity!
Large Software System Programming Project CPSC410 – Operating Systems
Loman: Distributed Traveling Salesman Utilizing Simulated Annealing Schedules
FINAL REPORT
Principle Investigators
Christopher Hewitt Martin Press
(1) Executive Summary
The Loman Project attempts to find approximate solutions to the classical NP complete problem of traveling salesmen utilizing a distributed approach. A cluster was created using SPARC Solaris machines running a combination of C and Java code to provide a simulation environment. A variety of services were also installed and configured such as LDAP, DNS, NFS to allow for a distributed environment. Communication between nodes utilized OpenMPI libraries for message passing.
(2) System Selection
Traveling Salesman is a classic example of an NPcomplete problem in the field of computer science [5]. The problem involves finding the optimal path of visiting n cities without visiting any cities twice. The only known solution is trying all possible permutations of travel routes between cities. While it possible to solve this problem using brute force techniques, in all practicality finding a best solution through brute force only works for small values of n. BigO for the Traveling Salesman problem has been computed as O(N1)! , thus showing the NPcompleteness of the problem at hand. A reasonable approximation can, however, be computed using a variety of techniques, such as simulated annealing. Loman is an attempt to bring the simulated annealing method of solving the Traveling Salesman problem to a distributed environment. The project is aptly named after the main character of the classic American stage play Death of a Salesman by Arthur Miller.
Loman’s computational engine is portable and can be further extended to solve a variety of NPcomplete problems. Through manipulating the fitness function and encoding methods used in the problem, problems such as the Four Color Theorem can be demonstrated. Loman could also be used to compute optimal flight paths when certain destinations are required as well as demonstrate the use of network routing algorithms. Development, implementation, and use of a clustering environment provides handson experience with a multitude of operating system principles including security, networking, batch processing, access control, and priority queues. Loman additionally focuses on other operating system principles, such as multithreading, multiprocessing, and user interface.
(3) System Analysis
Simulated annealing is a probabilistic algorithm, which utilizes a cooling scheduling for decreasing probability for choosing less optimal routes. Through using probability to accept less efficient routes, the likelihood of the simulation getting stuck in a local minimum route is greatly reduced. Greedy algorithms, unlike simulated annealing, have a large potential to become stuck in local minimum solutions and not reach a global optimal solution. Some of the more common cooling schedules include exponential,
Remotely, the cluster is only accessible through the head node. Services enabled on the head node, including DHCP, LDAP, DNS, and NFS, allow each worker node to have access to shared filesystem data, account information, and automatically configure network access[4].
Services
DHCP, or Dynamic Host Configuration Protocol, provides automaticallyassigned network IP addresses to each worker node. This prevents address conflicts and enables easy setup and configuration of cluster networking properties. LDAP, or Lightweight Directory Access Protocol, provides a centralized database for user account information across all cluster nodes. DNS, or Domain Name Service, provides assigned hostnames to each worker nodes on the cluster. Any worker node should not only be accessible through IP address, but also an easy to remember hostname. NFS, or Network File System, provides shared user account home directories and computational executables and libraries for use across the clustering environment.
(4) System Design
GUI Design
The graphical user interface was created in a modular fashion to promote encapsulation and cohesion within objects managed by the interface. Three different objects were created in the development of Loman’s graphical user interface: Loman, RoutePanel, and Town.
The Loman object is the heart of user interaction. It provides all the necessities for creation and execution of the simulation. Querying the user, the Loman object asks for the number of towns in simulation, the minimal distance between towns. It also allows the user to input a maximum allowed duration of simulation time in milliseconds. The simulation will then run based on the Sun Microsystems Solaris C libraries operating under the head node of the segfault cluster, aptly named “gomez.” The Loman object is also responsible for the creation and display of the RoutePanel object.
The RoutePanel object is responsible for pseudorandomly creating the towns based on the input parameters from the Loman object. It is also accountable for displaying calculated routes to the user by the underlying worker nodes. When the towns are created, it produces an “input.txt” file used for communication between the distributed OpenMPI C program and the Java graphical user interface.
The file produced has the following format:
input.txt
Once the file is output, the OpenMPI process is spawned on the head node of the cluster. To check if the processing is complete, the RoutePanel object checks if the output file exists in the current directory. If this file does not exist, the current thread of the graphical user interface sleeps for one thousand milliseconds. The time which the thread waits allows the graphical user interface to be constantly redrawn by the operating system to give the illusion that the graphical user interface is, in fact, always active. Once the file is located, the file is quickly read and promptly deleted. Deletion of the output file ensures that in sequential simulation executions, the old output file is not mistaken for the results of a simulation or overwritten. The output file is described by the following format:
output.txt
Each town index corresponds with a Town object within the RoutePanel object. This list of indexes gives the order of the solution from the OpenMPI worker node programs. Once the file is fully read, the resulting path is displayed to the user one link at a time. The overall distance traveled by the “salesman” is also displayed to give the user to provide a sense of reference when comparing path results of other routes. A detailed file comparing the results of each worker node is also created and accessible through the “Detailed Results” feature of RoutePanel, which is only accessible when a solution has been found. The routes are displayed to the user in different colors.
User Interface Demonstration
Application Flow Diagram
Produce Consume Interprocess Communication
Termination
Spawn Instance of OpenMPI Controller (Head Node)
Configuration File Output Results File
Java Execution GUI (Head Node) ()()
(Worker Node 1)
(Worker Node 2)
(Worker Node n)
(7) Solutions to points of Operating System Techniques
The issues of interprocess communication can easily be solved by implementing a semaphore to let the other processes know when the head node finds the solution and when the maximum iteration count has been achieved. This same semaphore can also be used when an emergency halt has been issued from the graphical user interface. The notification lets the nodes know to send back the data to the head node and then promptly exit, freeing up valuable system resources on the worker node. Semaphores are also used to block the process of the worker node until all the data has been sent in a single communication to and from the worker and head node. This insures that data is completely sent before a solution is attempted.
The issue of scheduling can simply be solved using a first come first basis. Each node of the cluster is given one job. If more jobs are needed the there are nodes then each node is given another job. The process is repeated until all jobs are given out by the Loman system. This ensures that there is a balanced load and allows faster convergence to solutions. Using this methodology, it is possible to achieve a one to one ration of nodes to jobs which is optimal.
File management issues are addressed by using builtin library calls within Java and C. These allow permissions to be set on a file basis to allow only the Loman System to have access to the file; this prevents users from changing the data within Loman. Secondly, library calls are used for file deletion. Once the input and output files are created in Loman and read, they a promptly deleted using these calls. This ensures the current file being read by the system is the most recently created one.
MultiThreading is a solution used to address the responsiveness problem of the user interface. A thread is created whenever a sleep is needed when waiting on solution file. This allows the user interface to be able to accept user input from I/O devices such as the mouse and keyboard which ultimately allow for the user to be able to halt jobs within the Loman system.
(8) Methodology and Technology of Operating System Techniques
The Java client utilizes multiple threads for updating the graphical user interface and to check for results from the head node of the Segfault Cluster. This action is implemented by using the “Runnable” interface in Java which allows for the creation of independent threads within the system. Code fragments within the run method of the class which extend “Runnable” will then be executed as a separate thread within the Java Virtual Machine on runtime. Two different threads are created in the graphical user interface. Both threads are used to allow for the user interface to maintain interactive response. The threads are terminated once a solution file is found. Resources are then freed by the garbage collector. These threads can then be created when a new solution is requested to be solved by the end user. Duplicate threads are prevented by a simple
boolean check to ensure users do not try to use up all of the systems resources. This action is accomplished by spawning multiple solution checking threads for a single solution.
OpenMPI commands are utilized for interprocess communication between different nodes of the Segfault Cluster. Each process has “send” and “receive” commands which act as semaphores for the critical sections of the code. These critical sections require synchronization for sending and receiving data. These synchronizations are mainly used when first dispatching a job to each individual worker node. Before computation of an optimal route is allowed to start, all nodes must be fed the two integer work arrays. These arrays are used for the x and y location in the Cartesian coordinate plane of the towns. After the data is transmitted between nodes, each worker node must check the status of a halting semaphore which belongs to the head node. This action is performed after each iteration of the simulation. If the value of the semaphore becomes one, an emergency halt has been issued by the user. Upon this event, all jobs must promptly report the results at the end of the current iteration. Data is then sent back to the head node where it is gathered into a large work array. The contents of this work array are placed into a detailed results text file. The graphical client application reads the results of this detailed text file and draws the necessary route connections to the route panel object.
Job scheduling in Loman is handled by the Sun Grid Engine which is installed on the Segfualt cluster. It was manually configured to use the First Come First Serve job algorithm to ensure that a balanced load is achieved on runtime. All processes have the ability to choose the type of annealing schedule used for the job. The OpenMPI “Processor ID,” however, is used to select the next unused annealing schedules. In the cases where there are more worker nodes than schedules, a schedule is repeated. This is allowed as the worker node will have a different randomization of the route for the initial state, which may provide a better solution over the given time interval.
The file management is handled by the file remove and file delete commands which are within C and Java respectively. These are found within the file and stdio libraries installed on the cluster. These system calls will delete the file to prevent any erroneous versions existing within the system. File management is further implement by limiting file creation to a single directory where the MPI backend exists. Users do not have permission to edit objects in the directory by default. This ensures that only privileged processes such as the Loman client can create or edit files within the directory.