I got this question from my friend, new to the operating system area.
We got:
Job number 1
Arrival Time = 0, CPU cycles = 80,
Job number 2
Arrival Time = 22, CPU cycles = 60,
Job number 3
Arrival Time = 44, CPU cycles = 24,
Job Number 4
Arrival Time = 55, CPU cycles = 40.
How can I do the scheduling order for FCFS, SJN, SRT, Round Robin (using a time quantum of 20).
Thank you. If you can give me any ideas...
FCFS: stands for first come first serve Means the job that comes first must be executed at first so it will do it it's work in this way.
Job number 1 then Job number 2 then Job number 3 then Job Number 4.
It will not stop executing when the new process comes in. It has disadvantage that a short process has to wait for a longer process to finish because suppose a shorter process comes at end then it has to wait for all long processes on queue to end.
Shortest job first
This can't be implemented for short-term-scheduler.I will explain why at the end
You next algorithm is SRT is based on this algorithm. Here we get jobs in an order and we don't swith the cpu if the new job is short. However they arrival time of the processes is different so it will first execute job1 then job2 then job3 then job4. May be you think that job3is shorter and it should switch cpu but that only happends if you are allowed to preempt the process and if that's the case then it's not SJB but SRT.
However if you have two process at time 0 with length/burst = 80 and 40 then it will pick the process whose burst is 40.
Only for long term scheduler This algorithm is not for short-term scheduler because you need to know the length/burst of next process which takes time or you can also try to approximate time , there is a complex formula but that does not work always.
SRT: stands for shortest remaining time first: A premptive algorithm/version of shortest job first.
First job : arrival time 0 and CPU cycle 80
second job: arrival time 22 and CPU cycle 60
3rd job : arrival time 44 and CPU cycle 24
4rth job: arrival time 55 and CPU cycle 40
At time 0 the only process you have is F1(means first job) after 22 m-seconds a new process is placed in queue so the scheduler computes it's length and first job was executed for 22 m-seconds now it's remaining time is 80-22 = 58 and the length of new process is 60 which is greater than 58 so scheduler does not switch to the new process. After 44 m-seconds a third job comes in so you have 80-44 = 36 and time required by 3rd job is only 24 so the scheduler places all results of that process on stack and allocatess CPU to the third job/process.
After 55 second another process is placed on the queue with length 40 but the third process is still shorted so the first job is process 3 which will be finished for the first.
Job 1 runs for 44 seconds : remaining time = 36 at this point Job 3 gets processor.
job 3 runs for 24 seconds: finished.
At this point we have job 1 with 36 m-seconds , job 2 with 60 m-seconds and job 4 with 40 seconds. So scheduler allocates again CPU to job 1 because it's the shortest and once it's finished then it allocates to job 4 and then job 2.
Disadvantage: Too much preemption require also time.
Round-Robin: Similar to First-come-first-serve the only difference is that it allocates equal time to each process(means allows preemption where fcfs does not allow). Here you use time quantum of few m-seconds.
There are two possibilities: Either the process completes it's burst then the process releases the CPU voluntarily if not the after the time quantum is over the scheduler take the CPU away from this process and allocates it to the next.
If you have N process in queue then every process will get 1/n cpu time in chunks of at most q time units.
Job1 gets CPU for 20 m-seconds and because there is no other process in queue then this job1 gets again cpu for next 20 sm-seconds.
As the first job has executed 2*20 this time there has been a new process(job2) in the queue so this process will get CPU for 20 seconds. When the job2 was executing there are two other process placed in the queue.(job3 and job4).
Now job3 gets the CPU for 20 seconds and then job4 gets CPU for 20 m-seconds.
After first cycle:
Job1 has executed 2*20 ; remaining time = 40
job2 has executed 20 ; remaining time = 40
job3 has executed 20; remaining time = 4
job4 has executed 20; remaining time = 20.
After second cycle:
- Job1 has executed 40-20 ; remaining time = 20
job2 has executed 40-20 ; remaining time = 20
job3 has executed 4-4; remaining time = finished/only executed for 4 seconds.
job4 has executed 20-20; remaining time = 0/finished.
After third cycle:
- Job1 has executed 20 - 20 ; remaining time = 0
job2 has executed 20 -20 ; remaining time = 0
The performance of this algorithm depends on the size of time-quantum. If you have small time quantum then too many preemptions/context-switches (moving processes to stack and allocating cpu to new process) is also not good and if time quantum is too large then it's also not good and try to think why? :D
Related
The first process is very long but arrives first with nothing else in the queue so that the CPU will process this. I know in nonpreemptive scheduling you cannot interrupt and then resume a process however could I terminate the first process when the shorter process arrives and then restart the process all over again to reduce wait time?
For example
P1=-50 burst time arrival time -0
P2 -5 burst time arrival time -10
P3 -10 burst time arrival time -20
Could I terminate P1, start P2 and then P3, and then restart the whole of P1 to reduce wait time?
I have tried looking online and I can't seem to understand the answer
Example:
`1. No of Threads = 100
Ramp-up time = 20, means every 1 second = 5 requests will be processed.
Loop Count =1
In the same time:
If i will do like below
No of Threads = 100
Ramp-up time = 1,
Loop Count =1`
And put Synchronization Timer : No of Simulated user to group = 5.
In this case as well, J meter process 5 requests at one time.
So what is the different logic between the above 2 concepts.
Considering case 1 where the
Number of threads = 100, Ramp-up time = 20 and loop count =1.
This means that for every one sec 5 threads will be induced.
Depending on the time taken for the response the test will run for at least 20 sec or more.
Considering case 2 where the
Number of threads = 100, Ramp-up=1, loop count=1 and
Adding Synchronization Timer with No of Simulated user to group = 5
A batch of 5 users will be added at once.
Both the tests don't take the same amount of time to complete.
In case 1, 5 users are distributed over a period of one sec. i.e. per 0.2 sec one user is added.
In case 2, 5 users are added to the active thread in one go.
To know more about Synchronizing Timer
To best understand the difference between the 2 use cases, increase the number of threads to 200 while keeping the remaining parameters as is. Then the difference can be noticed easily.
means every 1 second = 5 requests will be processed. Loop Count =1 - this is wrong, JMeter will start 5 threads each second, the processing time depends on application response time. The concurrency (number of requests at the same moment of time) is not guaranteed
A quote from JMeter documentation:
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
See JMeter Ramp-Up - The Ultimate Guide article for more comprehensive explanation.
Synchronizing Timer guarantees that 5 requests will be executed at the same moment so in your 2nd scenario it would be sending requests in "batches" of 5. Normally people go for Synchronizing Timer to do some form of Spike Testing
Let's say that I have the current configuration :
Number of Threads (users): 150
Ramp-up : 30
Loop Count : None
If I add up a duration of 2 mins so :
Number of Threads (users): 150
Ramp-up : 30
Loop Count : None
Duration (minutes) : 2
How does Jmeter going to react? If each Threads take about 10 seconds to complete
Thanks in advance
Both Loop Count and Duration (if both present) are taken into account, whichever comes first. So in first configuration, you are not limiting loop count or duration, so the script will run "forever". In second case, loop count is still not limited, but duration is. So the test will stop 2 minutes after startup of the very first user, and the time includes ramp-up time. Stopping includes not running new samplers, and hard stop for all running samplers.
In your case, 150 users will finish starting after 30 sec. That means the first thread to run will complete 3 iterations (x10 sec) by the time the last thread just started its first.
Within the remaining 90 sec, all threads will complete roughly 8-9 iterations.
So for the first thread you should expect 11-12 iterations, for the very last thread to start, 8-9 iterations. Remaining threads anywhere between those numbers. Assuming ~30 threads executed same number of iterations, between 8 and 12, you get roughly 1500 iterations in total (could be a little over or under). Last iteration of each thread may be incomplete (e.g. some samplers did not get to run before test ran out of time).
Generally, since duration may leave unfinished iterations, I think it's only good as a fall back or threshold in pipeline automation. For example: run is configured to complete 1000 iterations (should take about 16 min if iteration takes 10 sec). So duration is set to 24 min (gives about 50% slack). It won't be needed if performance is decent, but if execution takes extremely long, we may hard stop it at 24 min, since there's no point to continue: we already know something is wrong.
I have a bulk load job using HFileOutputFormat to load a HBase table. My mapper completes within 2-3 mins and then the reducer(PutSortReducer invoked by HFileOutputFomat) completes till 92% in the next 2 mins, but takes around 9 mins to complete the remaining 8%
Totally 10 reduce tasks are spawned in my job, of which always 8 or 9 tasks completes within 2-3 mins and the remaining one or two tasks take then 9 mins. And these one or two last tasks are usually the ones restarted in place of the failed tasks. The logs don't show any evident errors as the reason of the failed tasks
Waiting time is defined as how long each process has to wait before it gets it's time slice.
In scheduling algorithms such as Shorted Job First and First Come First Serve, we can find that waiting time easily when we just queue up the jobs and see how long each one had to wait before it got serviced.
When it comes to Round Robin or any other preemptive algorithms, we find that long running jobs spend a little time in CPU, when they are preempted and then wait for sometime for it's turn to execute and at some point in it's turn, it executes till completion. I wanted to findout the best way to understand 'waiting time' of the jobs in such a scheduling algorithm.
I found a formula which gives waiting time as:
Waiting Time = (Final Start Time - Previous Time in CPU - Arrival Time)
But I fail to understand the reasoning for this formula. For e.g. Consider a job A which has a burst time of 30 units and round-robin happens at every 5 units. There are two more jobs B(10) and C(15).
The order in which these will be serviced would be:
0 A 5 B 10 C 15 A 20 B 25 C 30 A 35 C 40 A 45 A 50 A 55
Waiting time for A = 40 - 5 - 0
I choose 40 because, after 40 A never waits. It just gets its time slices and goes on and on.
Choose 5 because A spent in process previouly between 30 and 35.
0 is the start time.
Well, I have a doubt in this formula as why was 15 A 20 is not accounted for?
Intuitively, I unable to get how this is getting us the waiting time for A, when we are just accounting for the penultimate execution only and then subtracting the arrival time.
According to me, the waiting time for A should be:
Final Start time - (sum of all times it spend in the processing).
If this formula is wrong, why is it?
Please help clarify my understanding of this concept.
You've misunderstood what the formula means by "previous time in CPU". This actually means the same thing as what you call "sum of all times it spend in the processing". (I guess "previous time in CPU" is supposed to be short for "total time previously spent running on the CPU", where "previously" means "before the final start".)
You still need to subtract the arrival time because the process obviously wasn't waiting before it arrived. (Just in case this is unclear: The "arrival time" is the time when the job was submitted to the scheduler.) In your example, the arrival time for all processes is 0, so this doesn't make a difference there, but in the general case, the arrival time needs to be taken into account.
Edit: If you look at the example on the webpage you linked to, process P1 takes two time slices of four time units each before its final start, and its "previous time in CPU" is calculated as 8, consistent with the interpretation above.
Last waiting
value-(time quantum×(n-1))
Here n denotes the no of times a process arrives in the gantt chart.