In Search of the "Perfect" Pager Rotation?
jSpectre asks: "At my new job the Unix SA team has increased from 5 to 7. We're trying to work out a new, rotating on-call schedule and everyone has 'perfect' but conflicting ideas. Twelve weeks on and 6 off, 25 weeks on and 10 off. I thought someone out there must have come up with the perfect formula given N number of people you could rotate through the weekdays and weekend most efficiently. My google and web searches have come up with nothing. Does anyone know of a good formula/solution? The requirements are this, we have 7 people (but the forumla should ideally apply to N people) who should rotate through the weekdays (a 24 hour period) and the weekend (a 48 hour period). There is a desginated primary and a secondary person. They should be on for a few weeks and off entirely for a few. Sound like a good thesis/research problem for someone? By the way, Google comes up with a lot of people's schedules if you search for pager rotation. Tisk tisk."
Hmmm - maybe we're onto something . . . ;>
...don't worry about pager rotations because our datacenters never have failures, you insensitive clod!
I want to win the Powerball® jackpot which is estimated at $250 million.
Does anyone know of a good formula/solution? The requirements are this, I want to win this Powerball® jackpot (but the forumla should ideally apply such that out of the N times I play, I should win at least N-1 times). Sound like a good thesis/research problem for someone? By the way, Google comes up with a lot of pages if you search for lucky Powerball® numbers. Tisk tisk.
I've found that the best rotation is the everyone-gets-paged-and-if-you-don't-see-it-fixed- within-a-few-minutes-find-a-terminal rotation.
For example, let's say you have N people working (and all are interchaingable, to start with). That means that each of them should be on call for K = 1000/N milliseconds out of every second (on average). Provided there are less than 500 people to be scheduled, you can accomplish this by rounding K to an integer (for the case where there are more that 500 people to be scheduled, either schedule them for one millisecond each, or go to a finer grained time-base). One important point to remember is that you must resource lock the call to the person in << K ms to avoid race conditions (which can garble text messages and result in an annoying high-pitched noise if two or more people try to return the call simultainiously and get multiplexed--
Hot damn, my run just finished.
G'night all...
-- MarkusQ