On Sun, May 9, 2010 at 4:15 PM, Ryan Rix <ry@xxxxxxxx> wrote: > Here is how I see this: The user installs their system for the first time, > they set their clock using NTP while they have the connection to the > internet when they installed their packageset/updates. Now they have an > accurate clock. > > How much drift can happen that each and every time they connect to the > internet, even if it's only for five minutes, would they need to resync > their clock? I have NTP disabled altogether on this machine, and since > I've installed it, it's still within about 5 seconds of my mother's > Windows machine which _does_ have ntp disabled. The amount of drift you may see is highly dependant on your hardware. A mere 1% frequency offset will gain or lose almost two hours per week. Arguably a system which drifts unacceptably is broken yet depending on your definition of unacceptably all of the available PC hardware is broken. And a constant frequency offset like that is trivially fixable. My last laptop lost a minute or two per week of uncorrected operation. At the time I was travelling a lot— and ending up habitually a late for a conference calls would remind me to unwedge it. The current laptop has, fortunately, only lost 2 seconds since Friday. Two headless systems of mine with "good" clocks in a temperature controlled environment show drift of 16 and 37 ppm (0.7 and 1.6 minutes per month respectively). A typical decent crystal oscillator simply running 10 deg C off its design temperature might be ~20 ppm off on its own. > I find that having NTP enabled in most cases for mobile systems is simply > unnecessary; there is a large (I would say upwards of 95% in my most > unscientific guessings) chance that these users aren't going to be doing > anything which requires their clocks to be synced with any amount of > precision. And if they are, they should _know_ that and be able to set up > a tool (whether it is NTP or Crony) themselves. > > Imo the use cases for having a constantly synced-to-the-second clock are > minimal at best. "I find that having non-root accounts enabled in most cases for mobile systems is simply unnecessary"(...) But really— having accurate time is important for all systems: Have you never had the experience of trying to debug a networked system only to eventually discover that there was a few seconds clock skew confusing your troubleshooting? At least in my world there are increasingly only two kinds of machines: mobile devices and headless servers, in that context what you're saying is that only servers need correct time, and I think that is quite wrong. Errors at the level of minutes are easily accumulated on common hardware and will impact human affairs. Sub-minute errors will frustrate technical troubleshooting— confusing the mutual ordering of events between systems even when the timestamps look quite different. An inaccurate clock even reduces user privacy on the internet as it makes hosts more easily distinguishable when the client's time is available over the network. If timekeeping really hard to fix on the lossy hardware we use I might buy an argument that fixing it wasn't worth the cost, but fortunately it is easily fixed to sub-second levels by running a simple daemon. Though, unfortunately, the NTP package will often fail to do anything useful when used on the increasingly common configurations with highly intermittent network connectivity. Perhaps you may not care about these things— but other people do for good reason, and you ought not oppose their efforts to advance the usefulness of the system. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
