4 ms·

May I ask why?

sk5t 6y ago
To appease the cicadas.
dimtion 6y ago
Not OP, but one good reason to do that is to reduce probability and frequency of collision with other periodically running jobs. Let's say you run your job on the hour, and you have a job running every 4h and another every 24h, without planning, because 4 divides 24, you have one in four chance of having them collide and having the 24h job running at the same time than the 4h job. If you add more 4h jobs, the probability that one of those 4h jobs collide each time with the 24h job increases. The more jobs you have, the higher the probability that some will be divisors of others. Using prime number for scheduling reduce the probability at a given time that those jobs collides. If you create a job every 5h and another every 23h, the 23h will collide with the 5h job every 115h. PPCM(5, 23) = 115. Interestingly, this technique is used in nature by cicadas who developed long, prime-numbered, periodical life cycles to avoid gaining a predator that can sync up with the cicadas[0]. [0] https://www.cicadamania.com/cicadas/cicadas-and-prime-numbers/ https://www.cicadamania.com/cicadas/cicadas-and-prime-number...
- MayeulC 6y ago
  And the number of teeth on two interacting gears is usually coprime, to distribute wear more evenly.
cbhl 6y ago
If you have a bunch of computers each on a fixed timer, and their clocks are synchronized (say, with NTP), then on the least common multiple of all of those timers you'll get a stampede of requests from all of the computers. If you're on a sufficiently large network, that surge can cause failures. And a fixed retry policy will just cause the same stampede to recur on the retry intervals; you want to add jitter to ensure that you spread the load out.
- Dylan16807 6y ago
  > If you're on a sufficiently large network, that surge can cause failures. The more prime numbers you use, the rarer a stampede affecting a certain percent of nodes will be. To an extent that makes a bigger network safer. Adding more nodes with the same prime numbers means the peak load scales linearly with the network size. So wouldn't that mean that a "sufficiently large" network is no worse off than a small network? Also a backup is a bulk upload that can easily run a thousand times slower than normal and still succeed. Even if every server triggers at once, that shouldn't inherently cause failures.
pkphilip 6y ago
So that it backs up at a different time each day? For instance, if it is set to 11H, and you were starting at 4pm on a day, then the backup would run next at: 15h, 2h, 9h, 20h, 7h....etc. So you won't have the backup running at the same time everyday. Personally speaking I would prefer that the backup runs at the same time everyday but some people don't.
- xvedejas 6y ago
  Well, it's not that the number is prime. There are many numbers which don't back up at the same time every day that aren't prime, like 25hrs or 22hrs. Numbers which are more complex fractions of a full day will take longer to repeat. Depending on a more exact statement of the goal, the best constant interval to avoid repeating parts of the day on nearby dates would be to multiply a day's length by the golden ratio; this would be about every 38.833 hours. Since the golden ratio is irrational, you'll technically never repeat the same time. But if I remember correctly, it's the best number to space out the times uniformly throughout the day and also distantly between nearby days.

May I ask why?

sk5t 6y ago

To appease the cicadas.

Not OP, but one good reason to do that is to reduce probability and frequency of collision with other periodically running jobs. Let's say you run your job on the hour, and you have a job running every 4h and another every 24h, without planning, because 4 divides 24, you have one in four chance of having them collide and having the 24h job running at the same time than the 4h job. If you add more 4h jobs, the probability that one of those 4h jobs collide each time with the 24h job increases. The more jobs you have, the higher the probability that some will be divisors of others. Using prime number for scheduling reduce the probability at a given time that those jobs collides. If you create a job every 5h and another every 23h, the 23h will collide with the 5h job every 115h. PPCM(5, 23) = 115. Interestingly, this technique is used in nature by cicadas who developed long, prime-numbered, periodical life cycles to avoid gaining a predator that can sync up with the cicadas[0]. [0] https://www.cicadamania.com/cicadas/cicadas-and-prime-numbers/ https://www.cicadamania.com/cicadas/cicadas-and-prime-number...

MayeulC 6y ago
And the number of teeth on two interacting gears is usually coprime, to distribute wear more evenly.

cbhl 6y ago

If you have a bunch of computers each on a fixed timer, and their clocks are synchronized (say, with NTP), then on the least common multiple of all of those timers you'll get a stampede of requests from all of the computers. If you're on a sufficiently large network, that surge can cause failures. And a fixed retry policy will just cause the same stampede to recur on the retry intervals; you want to add jitter to ensure that you spread the load out.

Dylan16807 6y ago
> If you're on a sufficiently large network, that surge can cause failures. The more prime numbers you use, the rarer a stampede affecting a certain percent of nodes will be. To an extent that makes a bigger network safer. Adding more nodes with the same prime numbers means the peak load scales linearly with the network size. So wouldn't that mean that a "sufficiently large" network is no worse off than a small network? Also a backup is a bulk upload that can easily run a thousand times slower than normal and still succeed. Even if every server triggers at once, that shouldn't inherently cause failures.

pkphilip 6y ago

So that it backs up at a different time each day? For instance, if it is set to 11H, and you were starting at 4pm on a day, then the backup would run next at: 15h, 2h, 9h, 20h, 7h....etc. So you won't have the backup running at the same time everyday. Personally speaking I would prefer that the backup runs at the same time everyday but some people don't.

xvedejas 6y ago
Well, it's not that the number is prime. There are many numbers which don't back up at the same time every day that aren't prime, like 25hrs or 22hrs. Numbers which are more complex fractions of a full day will take longer to repeat. Depending on a more exact statement of the goal, the best constant interval to avoid repeating parts of the day on nearby dates would be to multiply a day's length by the golden ratio; this would be about every 38.833 hours. Since the golden ratio is irrational, you'll technically never repeat the same time. But if I remember correctly, it's the best number to space out the times uniformly throughout the day and also distantly between nearby days.