Too bad G+ doesn’t allow the WayBack machine or Archive.is to archive the whole thread at [WayBack] [Archive.is] Das es inzwischen fast überall Standard ist die Uhren mit einem guten Zeitsignal zu synchronisiseren (NTP, DCF-77, GPS etc) ist eigentlich eine gute Sache… – Kristian Köhntopp – Google+ so here are a few quotes below.
The generatel conclusions seem to be that:
- for most jobs, especially the ones on dynamic instances like containers, you need some form of jitter
- jitter can have other words like splay
- even absolute times are no guarantee against jitter
- you can do jitter on many levels/tools, for instance:
- https://docs.saltstack.com/en/latest/ref/states/all/salt.states.schedule.html
- https://www.freebsd.org/cgi/man.cgi?cron(8)
- https://forge.univention.org/svn/dev/branches/ucs-4.0/ucs-4.0-5/base/univention-config-registry/scripts/jitter
- https://www.freedesktop.org/software/systemd/man/systemd.timer.html
- https://github.com/Jimdo/periodicnoise
- not doing cron at all, but sleeping a random time after each job execution
- ensure the jitter is part of the contract between the systems producing and consuming data
This was the start:
Nils Ketelsen originally shared:
Guckt man live sieht es schon anders aus: Während die RunQueue meist so bei 4-5 liegt (bei 21vCPUs kein Problem) springt sie jede volle Minute einige Sekunden lang auf 20. Bei durch 2 Teilbaren Minuten auf ca. 40. Bei durch 10 Teilbaren Minuten auf 70, bei durch 15 teilbaren Minuten auf 150…. Ich habe eben durch einen schlecht getimten Toilettenbesuch die volle Stunde verpasst, das muss ich gleich mal anders hinbekommen, aber ich gehe davon aus, daß es da noch schlimmer ist.
And these some of the comments:







