Problem 4 Coding Assignment: In this problem you will develop code to simulate a single-server queue,...

Transcribed Image Text:

Problem 4 Coding Assignment: In this problem you will develop code to simulate a single-server queue, with se- lectable queuing policy. The time to process a request at the server is modeled using an exponential distri- bution, while the arrival process of the requests follows a Poisson distribution (Hint: recall that if an arrival process is Poissonian, then the inter-arrival time between requests is exponentially distributed). a) Write a Java class called "Simulator" that implements a simple discrete event simulator with a single server capable of processing requests. This calls for at least three more classes. First, a Request class should be used to model a unit of workload to be processed in the server. Second, a Server class should be used to enqueue and process arriving requests following a given policy-FIFO or Shortest Job Next (SJN). Third, a Simulator class should be used to control the whole simulation. You are free to design the methods/attributes in these classes as you best see fit. But you should structure the general logic of the simulation following the approach presented in class. The simulator should have a method with the following prototype: void simulate (double time), that simulates the arrival and execution of requests at a generic server for time milliseconds, where time is passed as a parameter to the method. The class should be implemented in its own java file, named Simulator.java. The simulator class will internally use a exponentially-distributed random number generator, a timeline and two load generators. For these, you can re-use/adapt the classes you wrote as part of the previous assignment. Please be mindful of the capitalization in all the files you submit. Apart from implementing the simulate (...) method, the class should also include a main (...) function. The main (...) function should accept 5 parameters from the calling environment (in the following order): (a) length of simulation time in milliseconds. This should be passed directly as the time parameter to the simulate (...) function. (b) average arrival rate of requests of class X (λx); (c) (ignored, passed as 0. Will be used in HW3) (d) average service time at the server for requests of class X (Tsx); (e) (ignored, passed as 0. Will be used in HW3) (f) queuing policy which can either be "FIFO" or "SJN". If you are not familiar with how to pass parameters (a.k.a. command-line arguments) from the calling environment to a Java program, take a look at this: https://www.journaldev.com/12552/ public-static-void-main-string-args-java-main-method. It is responsibility of the main (...) function to internally invoke the implemented simulate(...) function only once. In this first version, the simulate (...) function will need to print in the console To generate a sequence of ARR events with the right inter-timing, reuse the loadGenerator approach from HW1. In this case, the releaseRequest(...) should do TWO things: (1) just like before, generate the next arrival using λx; and (2) create a new Request object and pass it to the Server. Thus, the Server class should have some receiveRequest(...) method that can be called by the loadGenerator for this purpose. Under the FIFO policy, the order of service is the same as the order of arrival. In this case, the output must look like this: XO ARR: <timestamp> LEN: <length> XO START: <timestamp> X1 ARR: <timestamp> LEN: <length> X2 ARR: <timestamp> LEN: <length> XO DONE: <timestamp> X1 START: <timestamp> X1 DONE: <timestamp> X2 START: <timestamp> X2 DONE: <timestamp> where <timestamp> is the simulated time in milliseconds at which the event occurred printed in decimal format, and <length> is the service time of the request. Be extremely careful to follow the format described above. CodeBuddy will be very sensitive to output formatting issues. Under the SJN policy, if two or more requests are queued, the one with the shortest service time is picked for execution. Thus, if SJN is selected and assuming that <x2_length> ¡ <x1_length>, the correct output will be: XO ARR: <timestamp> LEN: <length> XO START: <timestamp> X1 ARR: <timestamp> LEN: <x1_length> X2 ARR: <timestamp> LEN: <x2_length> XO DONE: <timestamp> X2 START: <timestamp> X2 DONE: <timestamp> X1 START: <timestamp> X1 DONE: <timestamp> b) Modify the code of the simulator written in the first part of this problem to measure utilization, average queue length, and average response time of requests. The simulator remains the same in terms of interface, accepted parameters, and simulation logic. However, in addition to printing out the simulation trace just like before, the simulator should add three lines at the end of its output, i.e. after the trace. This should be formatted as: UTIL: <utilization> QAVG: <avg. number of requests in the system> WAVG: <avg. number of requests waiting for service> TRESP: <avg. response time of requests> TWAIT: <avg. time spent in the queue> queue length> is a decimal where <utilization> is a decimal number between 0 and 1, <avg. response time of requests> is a decimal number expressed in milliseconds. number, and <avg. Problem 4 Coding Assignment: In this problem you will develop code to simulate a single-server queue, with se- lectable queuing policy. The time to process a request at the server is modeled using an exponential distri- bution, while the arrival process of the requests follows a Poisson distribution (Hint: recall that if an arrival process is Poissonian, then the inter-arrival time between requests is exponentially distributed). a) Write a Java class called "Simulator" that implements a simple discrete event simulator with a single server capable of processing requests. This calls for at least three more classes. First, a Request class should be used to model a unit of workload to be processed in the server. Second, a Server class should be used to enqueue and process arriving requests following a given policy-FIFO or Shortest Job Next (SJN). Third, a Simulator class should be used to control the whole simulation. You are free to design the methods/attributes in these classes as you best see fit. But you should structure the general logic of the simulation following the approach presented in class. The simulator should have a method with the following prototype: void simulate (double time), that simulates the arrival and execution of requests at a generic server for time milliseconds, where time is passed as a parameter to the method. The class should be implemented in its own java file, named Simulator.java. The simulator class will internally use a exponentially-distributed random number generator, a timeline and two load generators. For these, you can re-use/adapt the classes you wrote as part of the previous assignment. Please be mindful of the capitalization in all the files you submit. Apart from implementing the simulate (...) method, the class should also include a main (...) function. The main (...) function should accept 5 parameters from the calling environment (in the following order): (a) length of simulation time in milliseconds. This should be passed directly as the time parameter to the simulate (...) function. (b) average arrival rate of requests of class X (λx); (c) (ignored, passed as 0. Will be used in HW3) (d) average service time at the server for requests of class X (Tsx); (e) (ignored, passed as 0. Will be used in HW3) (f) queuing policy which can either be "FIFO" or "SJN". If you are not familiar with how to pass parameters (a.k.a. command-line arguments) from the calling environment to a Java program, take a look at this: https://www.journaldev.com/12552/ public-static-void-main-string-args-java-main-method. It is responsibility of the main (...) function to internally invoke the implemented simulate(...) function only once. In this first version, the simulate (...) function will need to print in the console To generate a sequence of ARR events with the right inter-timing, reuse the loadGenerator approach from HW1. In this case, the releaseRequest(...) should do TWO things: (1) just like before, generate the next arrival using λx; and (2) create a new Request object and pass it to the Server. Thus, the Server class should have some receiveRequest(...) method that can be called by the loadGenerator for this purpose. Under the FIFO policy, the order of service is the same as the order of arrival. In this case, the output must look like this: XO ARR: <timestamp> LEN: <length> XO START: <timestamp> X1 ARR: <timestamp> LEN: <length> X2 ARR: <timestamp> LEN: <length> XO DONE: <timestamp> X1 START: <timestamp> X1 DONE: <timestamp> X2 START: <timestamp> X2 DONE: <timestamp> where <timestamp> is the simulated time in milliseconds at which the event occurred printed in decimal format, and <length> is the service time of the request. Be extremely careful to follow the format described above. CodeBuddy will be very sensitive to output formatting issues. Under the SJN policy, if two or more requests are queued, the one with the shortest service time is picked for execution. Thus, if SJN is selected and assuming that <x2_length> ¡ <x1_length>, the correct output will be: XO ARR: <timestamp> LEN: <length> XO START: <timestamp> X1 ARR: <timestamp> LEN: <x1_length> X2 ARR: <timestamp> LEN: <x2_length> XO DONE: <timestamp> X2 START: <timestamp> X2 DONE: <timestamp> X1 START: <timestamp> X1 DONE: <timestamp> b) Modify the code of the simulator written in the first part of this problem to measure utilization, average queue length, and average response time of requests. The simulator remains the same in terms of interface, accepted parameters, and simulation logic. However, in addition to printing out the simulation trace just like before, the simulator should add three lines at the end of its output, i.e. after the trace. This should be formatted as: UTIL: <utilization> QAVG: <avg. number of requests in the system> WAVG: <avg. number of requests waiting for service> TRESP: <avg. response time of requests> TWAIT: <avg. time spent in the queue> queue length> is a decimal where <utilization> is a decimal number between 0 and 1, <avg. response time of requests> is a decimal number expressed in milliseconds. number, and <avg.

Answer rating: 100% (QA)

Image 1 Circuit Design This image shows a circuit with a decoder and a multiplexer While these components can be used in various ways its difficult to ... View the full answer