Contents

Executive Summary:...................................................................................................................................... 2
First Phase: ................................................................................................................................................ 2
Second phase: ........................................................................................................................................... 2
Third phase: .............................................................................................................................................. 2
Focus: ............................................................................................................................................................ 3
Event Description: ..................................................................................................................................... 3
Attributes: ................................................................................................................................................. 3
Proposed Schedule: ...................................................................................................................................... 4
Flowcharts for Methods:............................................................................................................................... 5
Method 1: ................................................................................................................................................. 5
Method 2: ................................................................................................................................................. 6
Description of Flowcharts: ............................................................................................................................ 7
Method 1: ................................................................................................................................................. 7
Method 2: ................................................................................................................................................. 7
Source of the Flowcharts: ......................................................................................................................... 7
Comparison: .................................................................................................................................................. 8
Conclusion: .................................................................................................................................................... 8
Screenshots of Program: ............................................................................................................................... 9
TIME SHARED MODEL:
Executive Summary:
A time sharing framework enables numerous clients to share the PC assets at the same time. At the end
of the day, time sharing alludes to the allotment of PC assets in schedule openings to a few projects all
the while. For instance a centralized server PC that has numerous clients signed on to it. Every client
utilizes the assets of the centralized server - for example memory, CPU and so forth. The clients feel that
they are select client of the CPU, despite the fact that this is beyond the realm of imagination with one
CPU for example shared among various clients.

The time sharing frameworks were created to give an intelligent utilization of the PC framework. A
period shared framework utilizes CPU planning and multiprogramming to furnish every client with a
little part of a period shared PC. It enables numerous clients to share the PC assets all the while. As the
framework changes quickly from one client to the next, a brief span space is given to every client for
their executions.

The time sharing framework gives the immediate access to countless where CPU time is separated
among every one of the clients on booked premise. The OS allots a lot of time to every client. At the
point when this time is terminated, it passes control to the following client on the framework. The time
permitted is incredibly little and the clients are given the feeling that they each have their very own CPU
and they are the sole proprietor of the CPU. This brief timeframe amid that a client gets consideration of
the CPU; is known as a period cut or a quantum.

First Phase:
The first phase of time sharing model is an arrival of function. When the function arrive its attributed are
calculated and are placed in a queue after that the idleness of CPU is checked if it is idle the start CPU
function is invoked and the job is otherwise if CPU is not idle it returned to queue.
Second phase:
The second phase of time sharing model is when the job is invoked to CPU and the CPU starts to execute
this job. The first thing which is done is that to remove the job from CPU and add it to the CPU. The job
is now decremented from queue and its remaining service time is also decremented, now if the job is
completed the end CPU function is executed and if it is not the job is again placed in the queue.
Third phase:
The third and last phase of time sharing model is to end the CPU run. The first task which is done is to
remove the completed job from the model if the job does not require more time if it is then it placed in
the queue and then start the invoke cup run and return to the queue again. If the job does not require
extra CPU time then the jobs statistics are gather if the job require more time than the arrival event is
scheduled on terminal for this job. In queue of jobs processed the one is added to the queue. After the
job is done than CPU checks if there are no jobs in the terminal than the simulation is end. If there are
more jobs than again start CPU function is invoked.
Focus:
The time sharing model was built in late 50’s and in the starting of early 60’s. The main focus to build a
system like that was to create a model which can do tasks simultaneously. In our project we have
followed a same approach to make such model in which tasks can be done simultaneously. The main
problem which can be arrived in such models are the computational power of the CPU, if the
computational power of the CPU is not that good enough to treat all the jobs entering from each
terminal the model simply became useless. The other problem which can be arriving is that the number
of jobs entering from particular terminals should be restricted so the terminal not gets overwhelmed
and crashed unfortunately. These are the main focus that should be taken care of to build a system that
lie in the properties of the time sharing model.

In the building of this model we have strictly taken care of these constraints. Our system has fixed
amount of terminals with a restricted job at inputs. The time to treat jobs is also fixed so the queue also
not gets overwhelmed.

Event Description:
The events for this model are:

Arrival of a job to the CPU from a terminal at the end of a think time.

End of a CPU run, when a job either completes its services requirement or has received the max
processing quantum Q.

End of a simulation.

Attributes:
LIST1 ATTRIBUTES 1 ATTRIBUTE 2
Queue Time of arrival of job to Remaining service time
computer
CPU Time of arrival to job to Remaining service time after the
computer present CPU pass(negative if the
present CPU pass is the last one
needed for job)
Event list Event time Event type

Since there is only single discrete-time statistics of interest (the response time we need only single
variable)

Sampst variable no Meaning

1 Response time
There are two types of random variables for this model, and we use the following streams assignments

Stream Purpose
1 Think times
2 Service time

Proposed Schedule:
Phase 1
Searching for Algos and Implementation
1 Week

Phase 2
Designing of UI and Discuss implementation
2 Week

Phase 3
Implementation
3 Week

Phase 4
Testing and Submission
1 Week
Flowcharts for Methods:
Method 1:
Method 2:
Description of Flowcharts:
Method 1:
In first method, we have a certain number of terminals, at first, a job arrival method will invoke for each
of those terminals. A job will arrive from the CPU or queue, each job has its own few attributes, such as
its arrival time and service time. The record of this newly arrived job is placed at the end of queue. If or
when the CPU is idle, the start_CPU_run method will invoke. This method takes the first job of the
queue, decrement the remaining service time of the job by full quantum, place it in the CPU, and
schedule the time when it will leave the CPU, by virtue of either being completely done or having used
up an entire quantum. After this, the end_CPU_run method will invoke. In end_CPU_run, the job is first
removed from the CPU, after which a check is made to see if it still needs more CPU time, if so, it is
simply put back at the end of queue and start_CPU_run method is invoked to remove the first job from
the queue and begin its processing. On the other hand, if the job coming out of the CPU is finished, then
the job’s response time is calculated, the job will go back to its respective terminal, and the increment
by 1 will be made in jobs processed variable, which will then get checked whether enough job has
processed or not, if not, then jobs will continue to get processed, if yes, then an end_simulation event
will occur, which will generate the report of the simulation and end the program.

Method 2:
In first method, we have a certain number of terminals, at first, a job arrival method will invoke for each
of those terminals. A job will arrive from the CPU or queue, each job has its own few attributes, such as
its arrival time and service time. The record of this newly arrived job is placed at the end of queue. If or
when the CPU is idle, the start_CPU_run method will invoke. This method takes the first job of the
queue, decrement the remaining service time of the job by full quantum, place it in the CPU, and
schedule the time when it will leave the CPU, by virtue of either being completely done or having used
up an entire quantum. After this, the end_CPU_run method will invoke. In end_CPU_run, the job is first
removed from the CPU, after which a check is made to see if it still needs more CPU time, if so, it is
simply put back at the end of queue and start_CPU_run method is invoked to remove the first job from
the queue and begin its processing. On the other hand, if the job coming out of the CPU is finished, then
the job’s response time is calculated, the job will go back to its respective terminal, and the increment
by 1 will be made in jobs processed variable, which will then get checked whether enough job has
processed or not, if not, then jobs will continue to get processed, if yes, then an end_simulation event
will occur, which will generate the report of the current simulation, will check if the current number of
terminals are less than max number of terminals allowed, if so, it will increment the number of
terminals and then the arrival function will get invoked, and if not and the current number of
terminals is equal to the maximum number of terminals allowed, then it will end the program.

Source of the Flowcharts:

Flowcharts are made online at https://www.draw.io/

First Method.xml Second Method.xml

Source files:
Comparison:
FIRST METHOD
In the first method, we are
using a fixed random number
of terminals to get the required
jobs done. The average
response time with respect to
the said number of terminals
will be considered ideal.
In first method, we are
considering the average
response time to be ideal,
calculated through the fixed
number of terminals.
SECOND METHOD
In the second method, we are
using multiple iterations to get
the ideal number of terminals
to get the required job done,
which will be observed from the
given average response time.
In second method, we are
running multiple simulations to
calculate the ideal number of
terminals on the basis of given
average response time.
THIRD METHOD
In the third method, we are
again using multiple iterations
of the number of terminals to
get the job done, to eventually
find the ideal number of
terminals from the given turn-
around time.
In third method, we are running
multiple simulations to
calculate the ideal number of
terminals on the basis of given
turn-around time.

Conclusion:
To conclude this, the second method was found to be the most efficient, because in second method, we
are running multiple simulations to find the ideal number of terminals by increasing the number of
terminals after end of each simulation instead of just a fixed random number of terminals and consider
it ideal. Among those multiple simulations of different number of terminals, those number of terminals
will be considered ideal whose average response time will be or lie in the range of the client’s given
average response time, in contrast to consider the turn-around time because turn-around time is the
system-time of a job, while response time is the time after which the job gets the CPU, so even if a
simulation’s average turn-around is greater than the other simulation’s, if its average response time is
less, it will be considered ideal.
Screenshots of Program: