What is the minimum interval to execute the function “scheduledJob”?
What is the minimum interval to execute a scheduled job? Is it 10 minutes? Or 20 minutes?
Till the 1.30.13 version, DolphinDB’s minimum execution time interval is 5 minutes for single scheduled task (the scheduleJob)
If you want to perform some timed tasks below this frequency, you can set up multiple timed tasks, and then stagger the execution time.
Related
I would like to get the mean waiting time of each unit spending in my queue of every hour. (so betweeen 7-8 am for example 4 minutes, 8-9 10 minutes and so on). Thats my current queue with my timemeasure Is there a way to do so?
]
Create a normal dataset and call it datasetHourly. Deactivate the option Use time as horizontal value. This is where we will store your hourly data.
Creat a cyclic event and set the trigger to cyclic, once every hour.
This cyclic event will get the current mean of your time measurement ( waiting time + service time in your example) and save this single value in the extra dataset.
Also we have to clear the dataset that is integrated into the timeMeasurementEnd, in order to get clean statistics again for the next hour interval.
datasetHourly.add(time(HOUR),timeMeasureEnd.dataset.getYMean());
timeMeasureEnd.dataset.reset();
You can now visualise the hourly development by adding the hourlyDataset to a normal plot.
I have a job scheduling engine which can run jobs on various machines. I have a queue of pending jobs coming in as a stream (usually at least 10s of thousands of jobs waiting for execution). I have an algorithm to execute jobs on different machines.
One of the core metrics to track is how long after a job gets requested does it get scheduled for execution (usually it is less than 5 minutes, but can be up to 1 hour due to various reasons).
Is there a way to plot the percentiles of how long the current unassigned jobs have been in there for using Prometheus + Grafana (or mix of prometheus and other solutions like Redis)? I want to know what is Median waiting time, 95 and 99 percentiles of waiting times for the jobs.
The issue is until the job gets scheduled for execution there is no event generated and longer we wait the higher bucket the job will move into. Furthermore, since the job could take very different times to get scheduled (not each job is the same), simply relying on how long past few jobs took to get scheduled is wrong.
One simple way would to iterate over all pending jobs and compute the percentiles continuously, but that would be very expensive.
The Prometheus histogram implementations assume a fixed set of buckets (e.g. less than 1 second, less than 2 seconds, less than 5 seconds etc.) which may only be incremented (together with all buckets above them).
In your case, you have 2 options:
Record the duration each job has been queued for in the histogram. The problems with this approach are that (a) you would have to keep "moving" every job up the histogram as time goes on; and (b) you can't remove a job from the histogram once it is processed (because of the monotonicity requirement).
Record the time when each job was added into a histogram (e.g. records added before 1 minute past the hour, records added before 2 minutes past the hour etc.). The problem here is that your histogram is not static in size and will grow indefinitely (assuming your Prometheus client allowed it in the first place).
You are thus left with a couple of alternatives:
Iterate over your queue and create a fresh histogram (or directly the percentiles you're interested in) every time you're scraped by Prometheus. Tens of thousands of jobs to iterate over doesn't sound all that bad, it should take milliseconds to do. You could even replace the data structure you use for your queue with e.g. a binary search tree, which should make it real easy to figure out the exact percentiles you are interested in, in logarithmic time.
Give up on recording queuing times for pending jobs and only do it for processed jobs. Every time a job is processed, you increment a histogram. It doesn't get simpler than that.
Assuming that the CPI of a program is 1.5 and the clock period is 500ns. What is the execution time?.
What is the execution time?.
I think that the execution time is the time the program takes to execute 1 instruction like latency.
It is impossible to know the execution time of a program just by looking at the CPI and the clock period. CPI gives the average number of cycles it takes to execute an instruction. If you executed 1 billion instructions, or 1 million instructions you can still have the same CPI. So, without knowing the number of instructions that are executed there is no way you can infer the execution time. If you had the number of instructions, the execution time would be:
t_execution = (Clock period) x CPI x (Number of executed instructions)
.
I am writing pseudocode for a CE scheduling algo. By the looks of it, task E is never going to be complete. Can anyone see where I'm going wrong? Am I choosing the correct interrupt time of 25 msec for this cyclic executive schedule?
Task Period p msec Exec Time msec
A 25 10
B 25 5
C 50 5
D 50 5
E 100 2
while(true)
wait_for_int (waits 25ms)
taskA()
taskB()
taskC()
taskD()
wait_for_int (waits 25ms)
taskA()
taskB()
wait_for_int (waits 25ms)
taskA()
taskB()
taskC()
taskD()
wait_for_int (waits 25ms)
taskA()
taskB()
endloop;
You are going wrong by thinking that all five tasks need to run in the same 25 millisecond period. That's not the case. All five tasks need to run every 100 milliseconds, and some tasks need to run more than once in that 100 millisecond period, but never do all five tasks need to run in the same 25 millisecond period.
For example, tasks C and D run every 50 milliseconds. But they don't have to run in the same 25 millisecond phase. They can run out of phase by 25 milliseconds. If you divide the 100 millisecond period into 25 millisecond phases then at most you need to run only four tasks in any given phase.
(If you break the 100 milliseconds into smaller phases, such as 5 milliseconds, then you might be able to design it such that no two tasks ever need to run in the same phase.)
Read this article, Multi-rate Main Loop Tasking, for a detailed explanation of what you're trying to do along with a great example.
You need to interleave C and D so that E can be executed in any 25ms period:
Period 0ms 25ms 50ms 100ms
-----------------------
A A A A
B B B B
C D C D
- - - E
-----------------------
Exec Time 20ms 20ms 20ms 22ms
This error ocurres when you have set an arrival cycle and click play to run the model.
Solution: "For arriving at Queue: A new cycle has been scheduled to start before the current cycle will be completed!"
The problem is that the arrival cycle table is defined in hours, and the frequency is normally set in minutes, this error could be avoided by setting a higher or equal time than the maximum time set in the arribe cycle table.
i.e. if you define a cycle of 36 hours, you should put in frequency a minimum of "36 hr" or "2160" (36 x 60) by doing this your simulation shouldn't give the error.