This is a somewhat theoretical question. I have 2 CRON jobs that run in a staggered interval, one every 13 minutes, and the other every 15 minutes.
I know it's very easy to stop them running at the same time etc with locks/stops.
However it got me thinking in a theoretical sense, how the synchronisations in time; when they both run at the same minute could be visualised.
So far it's actually a pretty interesting logic, as it's a case of converting the 13 minutes and 15 minutes into similar 24 based hour formats, and then detecting if any of them match. This bit isn't too hard, and the basic logic I have sort of got in this jsFiddle (Very ugly and janky/long way around, but it sort of works): http://jsfiddle.net/wigster/kdo5bwk9/
I can't quite visualise how/when these sync/simultaneousness' will occur though (I know they WILL occur, I just don't know if that's day's/weeks/months apart etc).
This may possibly be a question I should ask on https://math.stackexchange.com/ but StackOverflow is my frequent, so I'll try here first.
As I said, this is not for any real world application, simply a maths logic that has intrigued me today.
TL:DR 2 "Things" running at 13 minutes and 15 minutes. At first it may seem simple, numbers that are divisible by both 13 and 15. Eg, we know they will both run at 9:30 eventually. But HOW OFTEN / regularly will the 13 min cycle hit 9:30 at the same time the 15 minute cycle hits 9:30 as it's likely to be ahead/behind most of the time.
#MrWigster
Related
There would be 30 total games where 12 are non conf. and 18 conf.
The conference are no smaller than 8 and no larger than 16 and can have odd or even numbers.
There will be up to a couple hundred schools to matchup.
If there is an odd number there will be non-conf games mixed into the conference schedule.
I am thinking of making it 31 or 32 weeks and adding a bye or 2 byes so that will not have to happen.
I am using swift.
I have tried creating randomizing all possible matchups and then creating the schedule from there and having troubles. I also have done the basic round-robin equation but it doesn't work for odd number without a bye.
Anybody has a reference for how AnyLogic implements it's rate per day? Specifically, my agent is at different locations (based on time of day) throughout the day. If there are 10 triggers a day, do they happen randomly for each agent throughout the day, or only at the beginning of a day (when agent is at home), etc.?
Thank you, Amy! Your explanation was very helpful.
The rate follows the Poisson distribution. If you divide 1/rate, you will get an inter-arrival time that follows the exponential.
As this is random, you may not actually get 10 a day - you may get 9 one day and 11 the next. If you want to get exactly 10 in a day, you need to think about writing your own code to make that happen. That might be something like generating 10 dynamic events randomly sampled times that all trigger a transition in their action code (that would not be exponential between events).
I have a question here about round-robin and I was wondering if this answer is correct(it is the dr.'s answer).
We are supposed to get the average turnaround time of the processes who all come at same time which came in order as in the picture, it uses round robin with quantum of 5 seconds
Given answer was like that
But I think there are some extra counted time in there so my answer is like that
(26+27+12+16+30) / 5 = 22.2
I was wondering which one is correct, in my answer I tracked each process got its finish time and subtracted from start time which is 0 in this case.
According to the question given, the correct answer is 22.2
We're keeping our backend servers in sync using NTP but are not sure how synchronized are the time stamps retrieved on the fronted (using NSDate). Can you please comment if you have experience with this issue?
In my experience, although often it can be fairly close, from time to time it can be inaccurate by several seconds, and the offset vary even over several hours.
Also, the tower time it syncs to can be off, I've seen 15 seconds, 60 seconds (for months), and once : 1 hour when daylight savings was applied when it shouldn't have been. Once it isn't syncing to the tower it can drift 10s of seconds per day, and worse when "off".
Hey all, I've got a method of recording that writes the notes that a user plays to an array in real time. The only problem is that there is a slight delay and each sequence is noticeably slowed down when playing back. I upped the speed of playback by about 6 miliseconds, and it sounds right, but I was wondering if the delay would vary on other devices?
I've tested on an ipod touch 2nd gen, how would that preform on 3rd, and 4th as well as iphones? do I need to test on all of them and find the optimal delay variation?
Any Ideas?
More Info:
I use two NSThreads instead of timers, and fill an array with blank spots where no notes should play (I use integers, -1 is a blank). Every 0.03 seconds it adds a blank when recording. Every time the user hits a note, the most recent blank is replaced by a number 0-7. When playing back, the second thread is used, (2 threads because the second one has a shorter time interval) that has a time of 0.024. The 6 millisecond difference compensates for the delay between the recording and playback.
I assume that either the recording or playing of notes takes longer than the other, and thus creates the delay.
What I want to know is if the delay will be different on other devices, and how I should compensate for it.
Exact Solution
I may not have explained it fully, that's why this solution wasn't provided, but for anyone with a similar problem...
I played each beat similar to a midi file like so:
while playing:
do stuff to play beat
new date xyz seconds from now
new date now
while now is not > date xyz seconds from now wait.
The obvious thing that I was missing was to create the two dates BEFORE playing the beat...
D'OH!
It seems more likely to me that the additional delay is caused by the playback of the note, or other compute overhead in the second thread. Grab the wallclock time in the second thread before playing each note, and check the time difference from the last one. You will need to reduce your following delay by any excess (likely 0.006 seconds!).
The delay will be different on different generations of the iphone, but by adapting to it dynamically like this, you will be safe as long as the processing overhead is less than 0.03 seconds.
You should do the same thing in the first thread as well.
Getting high resolution timestamps - there's a a discussion on apple forums here, or this stackoverflow question.