The upcoming Y2038 catastrophe

[bob]

* Important note: The kernel discipline is used only if the
* step threshold is less than 0.5 s, as anything higher can
* lead to overflow problems. This might occur if some misguided
* lad set the step threshold to something ridiculous.

Funny, the author put in a warning just for you.

clock_gettime() with CLOCK_MONOTONIC guarantees that any discontinuities due to invocations of settimeofday() are ignored. It does exactly what you would want (unless you prefer to ignore adjtime() invocations as well in which case you need CLOCK_MONOTONIC_RAW).

Warning is not for me. I am not some "misguided lad". That would be YOUR interpretation of how ntpd actually works that is "misguided".

"clock()" also gives you a monotonic "time" that is not a time. It measures pure CPU time which doesn't care about suspend/resume or anything else. Not worth much for doing things with real time however. You can even do your OWN clock if you want. Define a variable and increment it every so often. Wait. We have that. It is the node counter in a chess engine. But we have to play by a real clock, not a pseudo-clock.

[bob]

As for gettimeofday() being obsolete, I'll believe it when I see the routine removed from any BSD or GNU C library. Until then, its obsolescence is just an opinion coming from POSIX 2008 and which hasn't caught on yet.

In standard setting lingo, "obsolete" means "does not work as previously advertised, use of an alternative is recommended". It is a precursor to "deprecated", which means "use at own risk, functionality may be removed in a future version of the standard". The final stage is "removed". In any case, "obsolete" is most assuredly not just an opinion but a technical matter of fact. The long purgatory stage (typically a decade or more) is to give sinners the chance to see the light, before sending them to hell.

Sorry, you went too far. It does NOT mean "does not work as previously advertised". It means that SOMEONE "thinks there is a better way of doing this that should supersede the old approach." gettimeofday() + ntpd has been working for decades and has always been monotonic unless a pesky human does something silly.

[syzygy]

Which never happens once it has been running for a bit.

"never"

(and ntpd source says 500ms or more in the comments in one place, 125ms elsewhere.)

In ntp_loopfilter.c from the production release at www.ntp.org:

Code: Select all

#define CLOCK_MAX	.128	/* default step threshold (s) */

and

Code: Select all

double	clock_max = CLOCK_MAX;	/* step threshold */
...
		if (fabs(fp_offset) > clock_max && clock_max > 0) {
			step_systime(fp_offset);

Anyway, it's not like there is a single "ntpd source". Different systems will use different implementations. Maybe you don't care about platform independence, but others do.

The RFC specifies the step threshold to be 125ms, but the reference implementation it includes sets it to 128ms. So this number is clearly not set in stone. But relying on this value to be big enough so that stepping will "never" happen on any of your users' systems is... well... naive.

If stepping really never happens, which is what you are hoping for, then using gettimeofday() is equivalent to using clock_gettime() with CLOCK_MONOTONIC.

If you switch to clock_gettime(), there is no need to cling to the illusion that stepping never happens.

Face it, Crafty would have used clock_gettime if it had been available when you wrote Crafty's time handling code.

[bob]

Which never happens once it has been running for a bit.

"never"

(and ntpd source says 500ms or more in the comments in one place, 125ms elsewhere.)

In ntp_loopfilter.c from the production release at www.ntp.org:

Code: Select all

#define CLOCK_MAX	.128	/* default step threshold (s) */

and

Code: Select all

double	clock_max = CLOCK_MAX;	/* step threshold */
...
		if (fabs(fp_offset) > clock_max && clock_max > 0) {
			step_systime(fp_offset);

Anyway, it's not like there is a single "ntpd source". Different systems will use different implementations. Maybe you don't care about platform independence, but others do.

The RFC specifies the step threshold to be 125ms, but the reference implementation it includes sets it to 128ms. So this number is clearly not set in stone. But relying on this value to be big enough so that stepping will "never" happen on any of your users' systems is... well... naive.

If stepping really never happens, which is what you are hoping for, then using gettimeofday() is equivalent to using clock_gettime() with CLOCK_MONOTONIC.

If you switch to clock_gettime(), there is no need to cling to the illusion that stepping never happens.

Face it, Crafty would have used clock_gettime if it had been available when you wrote Crafty's time handling code.

You DO realize (I have pointed this out many times now) that this:

scrappy% man clock_gettime
No manual entry for clock_gettime
scrappy%

is what OS/X thinks about clock_gettime()? So HOW is one going to use that and be portable? Answer: he is NOT.

second point. 125ms or 128 ms does not matter. Once ntpd is up and running, you will NEVER see that kind of time slip unless something is broken (where NO time will work) or unless a human interferes (same problem).

Face it, I would not have used something that was non-standard, period. I specifically run this on all varieties of unix, some of which don't support clock_gettime(). gettimeofday() works absolutely flawlessly, as does my internal time measurement. Even if you use the date command to set the clock back 5 seconds, it won't hurt me one bit. My time is always measured as "end_time - start_time" Backing up end-time won't cause me to do anything other than take 5 seconds longer on this move. But it doesn't cause any other issue. And it does not happen on a system running ntpd and with no root users fooling around.

[syzygy]

You DO realize (I have pointed this out many times now) that this:

scrappy% man clock_gettime
No manual entry for clock_gettime
scrappy%

is what OS/X thinks about clock_gettime()? So HOW is one going to use that and be portable? Answer: he is NOT.

OK, you don't consider it worth the trouble to special case a disadvantaged system like OS/X. That's fair enough. But then just say that and don't bury yourself in the usual hopeless argumentation.

Even if you use the date command to set the clock back 5 seconds, it won't hurt me one bit. My time is always measured as "end_time - start_time" Backing up end-time won't cause me to do anything other than take 5 seconds longer on this move.

And then you ran out of time and lost the game.

But it doesn't cause any other issue.

True, it doesn't burn down any houses nor does it kill animals or human beings. Not because gettimeofday() is any good, but because it's just a chess engine.

[bob]

You DO realize (I have pointed this out many times now) that this:

scrappy% man clock_gettime
No manual entry for clock_gettime
scrappy%

is what OS/X thinks about clock_gettime()? So HOW is one going to use that and be portable? Answer: he is NOT.

OK, you don't consider it worth the trouble to special case a disadvantaged system like OS/X. That's fair enough. But then just say that and don't bury yourself in the usual hopeless argumentation.

Even if you use the date command to set the clock back 5 seconds, it won't hurt me one bit. My time is always measured as "end_time - start_time" Backing up end-time won't cause me to do anything other than take 5 seconds longer on this move.

And then you ran out of time and lost the game.

But it doesn't cause any other issue.

True, it doesn't burn down any houses nor does it kill animals or human beings. Not because gettimeofday() is any good, but because it's just a chess engine.

OSX is not "disadvantaged". It handles "adjtime() correctly, which solves any potential problem I can imagine, other than the problem represented by a rogue/inexperienced super-user...

If this were ACTUALLY a problem, I'd be working on a solution. In the days of COS (cray's original operating system before they moved to unix) we had a 24 hour clock that wrapped at midnight. I had to take special precautions there since our ACM/ICCA events generally played rounds at night starting between 7 and 8 pm. At a 40 moves in 2 hours time control, going past midnight was quite common, and quite a few lost on time due to the wraparound.

I've never lost a game, or made a move that took longer or less than expected, by my internal 10ms time resolution. I don't see any point in fixing a problem that doesn't exist, particularly when the solution has to be done in a non-portable way since many systems don't support this clock_*() function at all and would need special code surrounded by a spaghetti of #ifdef's...

You should do what I did. Crank up ntpd on a linux laptop, and then see if you can figure out ANYTHING to cause gettimeofday() to behave non-monotonically, short of resorting to root use of the date command or anything similar. Suspend it. Open it. turn wireless off. whatever you want' But before you start fiddling around, let ntpd run for a while to train the clock. Then see what, if anything, will cause it to jump backward by any amount. Nothing anyone can do about forward jumps across a suspend/resume however.

[sje]

There have been times when I've been a silent bystander listening to two borderline fanatical members of the same religion arguing legalisms to prove which of the two was more holy than the other.

In can be amusing, but only for a while. There really is no benefit to monitor a legalistic religious argument which has nothing to do with real holiness, just like there's no benefit to listen to an argument about timing whose legalistic proponents have no idea regarding techniques proven in the real world to be portable and reliable for writing chess software.

I'm sure that the legalistic holier-than-thou guys get something from their efforts, but no one else does. I'll make them a deal: I won't post in your threads, and you're welcome not to post in mine. The same for messaging, too. If you think you've scored some kind of victory, that's okay by me because I don't care. I'm too busy writing real world applications.

And that is my last post and and last visit to this thread.

[syzygy]

And that is my last post and and last visit to this thread.

Surely has nothing to do with the realisation that what you were claiming in your last series of posts turns out to be incorrect, right?

[abulmo]

We already knew that clock_gettime() is not present on any released version of Mac OS/X all the way up to 10.9.5, the latest.

And now after a extensive search, I can't find any reference to clock_gettime() in the unreleased OS/X 10.10 Yosemite.

There are a lot of coders writing applications for desktop OS/X and its pal, gadget iOS. If they felt that there was a need for clock_gettime(), then they'd have it.

Well, clock_gettime() is supported by anything else claiming to be a Unix system: AIX, Linux, Solaris, HP-UX, OpenBSD, NetBSD, FreeBSD, ...
Whatever, clock_gettime() or gettimeofday() are not supported by microsoft's Windows, i.e. the number one OS based on its market share. There is nothing portable to measure accurately elapsed time, and you have to use what is provided by the OS.
About OS/X, most of the optional part of the POSIX standard is not supported, pthread_spinlock_t are not supported for example. What is surprising is that OS/X have something equivalent called OSSPinLock, so the lack of support looks more like lazyness. Same for clock_gettime: OS/X has got a lot of time management functions, clock_get_time(), mach_absolute_time(), ... and interfacing clock_gettime() to them looks quite easy.

[mvk]

Here we have one caught in the wild:

bobo.c:

Code: Select all

#include <stdio.h>
#include <time.h>
#include <sys/time.h>  

int main&#40;void&#41;
&#123;
        struct timeval tv1, tv2;   

        gettimeofday&#40;&tv2, NULL&#41;;
        do &#123;
                tv1 = tv2;

                gettimeofday&#40;&tv2, NULL&#41;;
        &#125; while&#40;&#40;tv1.tv_sec < tv2.tv_sec&#41; ||
                (&#40;tv1.tv_sec == tv2.tv_sec&#41; && &#40;tv1.tv_usec <= tv2.tv_usec&#41;));

        printf&#40;"tv1&#58; %ld %d\n", tv1.tv_sec, tv1.tv_usec&#41;;
        printf&#40;"tv2&#58; %ld %d\n", tv2.tv_sec, tv2.tv_usec&#41;;

        return 0;
&#125;

Output:

Code: Select all

tv1: 1412665030 366901
tv2: 1412665029 267027

System log:

Code: Select all

7 Oct '14 8:57:09.268 AM ntpd[131]: ntpd: wake time set -1.099871 s

Nobody was near the computer when this happened, as I had just left a couple of minutes earlier. Last reboot was 3 days before.