I'm trying to imagine what kind of application intersects: 1) The set of applications which require fractional-second time precision
2) The set of applications which can be run on GAE, which makes no guarantees WRT clock skew, let alone latency between components. Seems to me that Google's solution is a pretty good one. Any solution needs to balance two risks: 1) Chance an app will be negatively impacted by a second being 0.00001 longer than usual for a day. This chance is probably zero. In fact, I'm willing to bet that many clocks naturally skew by this amount in a day. 2) Chance that a piece of software will barf when confronted with a timestamp like 23:59:60. This is probably quite high. I'll bet 90% of time parsers ever written will fail. I would be pissed if my app started throwing errors for one second. Or wrote data into a database that subsequently couldn't be parsed back out. Yuck. Jeff On Fri, Jun 29, 2012 at 6:15 AM, Cesium <[email protected]> wrote: > That's interesting reading from the Site Reliability Engineering Group > (SREG). > > I read: >> >> Having accurate time is critical to everything we do at Google. > > > Agreed. > > I also read: >> >> Usually when a leap second is almost due, the NTP protocol says a server >> must indicate this to its clients by setting the “Leap Indicator” (LI) field >> in its response. This indicates that the last minute of that day will have >> 61 seconds, or 59 seconds. (Leap seconds can, in theory, be used to shorten >> a day too, although that hasn’t happened to date.) Rather than doing this, >> we applied a patch to the NTP server software on our internal Stratum 2 NTP >> servers to not set LI, and tell a small “lie” about the time, modulating >> this “lie” over a time window w before midnight: > > > Huh? SREG thinks (Lies == accuracy). > > And: >> >> The leap smear is talked about internally in the Site Reliability >> Engineering group as one of our coolest workarounds, that took a lot of >> experimentation and verification, but paid off by ultimately saving us >> massive amounts of time and energy in inspecting and refactoring code. > > > *Forehead slap!* > SREG thinks (coolness > correctness) && (workarounds > hard work). > > Looks like I'll have to get my time from the 'source'. > > David > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/TAlU_-QPZ1QJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
