The upcoming Y2038 catastrophe

[syzygy]

Monotonicity is not a guarantee of anything other than monotonicity. If scratch a tally mark on the bathroom wallpaper every time I take a leak, that's monotonic but it's not a reliable time keeper.

An engine will not break if time is slowed down a bit.
An engine might very well break if time goes backward.
This is why the advice was to use a monotonic timing source.
http://talkchess.com/forum/viewtopic.ph ... 684#589684

[syzygy]

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.

http://www.ehow.com/how_7379772_fix-pc- ... -fast.html
http://social.technet.microsoft.com/For ... progeneral
http://www.tomshardware.co.uk/forum/279 ... -runs-fast

Just the top 3 hits.

[bob]

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.

http://www.ehow.com/how_7379772_fix-pc- ... -fast.html
http://social.technet.microsoft.com/For ... progeneral
http://www.tomshardware.co.uk/forum/279 ... -runs-fast

Just the top 3 hits.

You should read 'em. Operating system bug. Sort of hard to have ANY useful time when the system is broken. We've been primarily talking about unix anyway, but if something is broken, who expects it to work?

[sje]

The original statement I made was that it is dangerous to have a root user that can adjust the clock, as there is nothing you can do to prevent him from jumping it forward, jumping it backward, etc.

Although all Internet connected machines should use ntpd, some don't. For those hosts, there is the program ntpdate, runnable only by root when used to set the time (like date).

Interestingly, ntpdate refuses to run if it sees that ntpd is already doing the job. This is in part because they both use the same socket, but also because unnecessary manual intervention involving time setting needs to be discouraged.

[sje]

An engine might very well break if time goes backward.

My program will also break if God tosses a meteor at my house as a punishment for me wasting too much time on trivial issues. I suggest that these two events have roughly equal probability.

[sje]

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.

And missed RTC interrupts rarely, if ever, occur with modern machinery. From what I've seen, clock interrupts are always given a very high priority, or the highest priority and are far more likely to cause other interrupts to be missed than to be missed themselves.

The exceptions were interrupts for power supply failure and for CPU-on-fire. These could be problems for a chess program, too.

[syzygy]

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.

http://www.ehow.com/how_7379772_fix-pc- ... -fast.html
http://social.technet.microsoft.com/For ... progeneral
http://www.tomshardware.co.uk/forum/279 ... -runs-fast

Just the top 3 hits.

You should read 'em. Operating system bug. Sort of hard to have ANY useful time when the system is broken. We've been primarily talking about unix anyway, but if something is broken, who expects it to work?

I had a quick look and found no indication of a Windows bug. Please show me what you saw then... yawn.

Anyway:
http://askubuntu.com/questions/3689/clo ... g-too-fast
http://www.linuxquestions.org/questions ... st-285791/
http://www.linuxquestions.org/questions ... -a-514702/
http://www.linuxquestions.org/questions ... -a-132078/
http://superuser.com/questions/235178/w ... k-on-linux

Whatever the precise reason in each case, it is simply "false" that a PC clock could not run too fast, to put it in nice words.

[bob]

second link you posted:

Question
Sign in to vote
0
Sign in to vote
Hi Mleiper,

Mostly, this issue is caused by Windows Time service corrupt. You can try to take following steps to troubleshoot this issue.

Run the following command in a elevate privileges cmd window.
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
Then, please restart the computer to test the issue again.

That was from the 2nd thread you posted the first time.

Did you actually read the stuff you posted? A bad crystal oscillator. Bad this. Bad that.

I believe I said that time works perfectly with no human interference and with no broken hardware. Toss in either of those and all bets are off.

[bob]

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.

And missed RTC interrupts rarely, if ever, occur with modern machinery. From what I've seen, clock interrupts are always given a very high priority, or the highest priority and are far more likely to cause other interrupts to be missed than to be missed themselves.

The exceptions were interrupts for power supply failure and for CPU-on-fire. These could be problems for a chess program, too.

The problem is, when interrupts are disabled, and two RTC interrupts occur, you will only see one when you re-enable. In any case, ntpd handles that just fine.

[syzygy]

An engine might very well break if time goes backward.

My program will also break if God tosses a meteor at my house as a punishment for me wasting too much time on trivial issues. I suggest that these two events have roughly equal probability.

Do you know what we are talking about?