syzygy wrote:sje wrote:If you can read this, then it likely means that you can connect to the Internet. And that means that your machine can use nntp to get the current time.
Network News Transfer Protocol
We're not on rec.games.chess.computer anymore...
Therefore, unless your software is misconfigured, your hardware is horribly buggy, or you have an idiot for a system administrator, then once your Internet connected machine finishes booting its idea of the current time will never be incorrect by thousands of seconds, or even a single second.
That's just silly. Internet connections have downtime. Internet was designed to cope with that. This is not a problem for NTP either, as it will recover. BUT it simply does
not guarantee monotonicity.
Firstly, for monotonic updates you need OS support. POSIX-compliant systems support (small) monotonic updates, but not all systems are POSIX-compliant. NTP does not mandate support for monotonic updates.
Secondly, NTP explicitly allows the clock to be stepped forward or backward in time if the necessary correction exceeds a threshold. This threshold is typically 125ms. (The ntpd implementation on my machine can be forced to adjust slowly using the "-x" option, but as options go this is optional. It also may defeat the purpose of ntp which is to keep your clock in sync with other clocks.)
If your PC has an unreliable hardware clock and your internet connection has a period of downtime, then a backward step in time can easily happen.
And what should not need to be mentioned: if your application relies on NTP working correctly, then you rely on external servers over which you have no control.
For a chess engine this is all relatively unimportant, as nobody will be hurt if the engine loses on time.
Unless there is a hardware failure, or human intervention, time NEVER advances too fast on a computer. It ALWAYS slips backward due to missed RTC interrupts. But by "slipping backward" it does NOT "jump backward" it simply does not advance as quickly as it should. ntpd handles this quite nicely, always keeping the clock moving in the "right direction" as smoothly as possible.
If a human breaks something, anything can happen. But boot it up, let it run, and the clock will always be monotonic until some pesky human breaks something somewhere.
But how about reality. If a machine is suspended, or rebooted, or replaced, or has a power failure, it will come back up, and when it does, the time will be back to correct before the first user can log in. And from that point forward, time will work just as I expect.
The "dark ages" are gone. I watched someone lose a chess game due to daylight savings time shift, when a game at an ACM event (I think it was ACM but am not certain, it was so long ago) stepped over the 2am "fall back" boundary. I watched a program use wall clock and lose on time when a move started before 23:59 am and the clock reset to 0:00 am. gettimeofday() has always worked flawlessly and not been bothered by either of those. ntpd solves the different times on different nodes causing serious file timestamp issues.
Why you want to dream up all these situations where it won't work. As I initially conceded, "any human with root access is a risk here". He can certainly break any timing assumption one might have. But done correctly, ntpd eliminates ALL of that nonsense except when a human intervenes. Granting users root access is dangerous AND foolish. We don't do it here. We've never done it anywhere I have been. And no company I have ever consulted with did either. All understand the risks.