Kernel release status [LWN.net]

Kernel release status

Posted Feb 21, 2003 1:15 UTC (Fri) by zooko (subscriber, #2589)
In reply to: Kernel release status by Ross
Parent article: Kernel release status

I need a timer for internal scheduling purposes in my app. It need not be, and indeed should not be the same as the timer used for human-meaningful things like file timestamps. If it were the same, then the human sysadmin may need to change it, for example because his clock is out of sync with UTC, which breaks my app.

The whole "gettimeofday() is more or less much monotonically non-decreasing" argument is classic "worse is better" (and I mean "w-i-b" in the bad way here). gettimeofday() cannot guarantee both non-decreasing and synchronization with UTC. In practice, it fails in both of these sometimes. Failure to be synced to UTC is generally just a hassle for the human to deal with. Failure to be non-decreasing can cause unpredictable behavior in your applications that depend on non-decreasingness.

The worse-is-better approach is just to say "Yep, gettimeofday() tries to be non-decreasing. That's pretty much good.".

For what it's worth, I became intimately aware of this problem last year when my gettimeofday was experiencing jitter due to my laptop CPU slowing down to save energy. This manifested as events in my application code going off in a different order than I had specified them. Boy was that tricky to debug.

The worse-is-better approach is to change the behavior in this particular instance so that gettimeofday is non-decreasing even in the presence of CPU throttling. The Right Way To Do It is specify a service that actually guarantees non-decreasingness in all cases up to very unusual hardware failure or a bug in the implementation. Therefore, this service cannot also guarantee synchronization with UTC, so the Right Way To Do It is to specify clearly that this service is not synchronized in any way with UTC.

The fact that a lot of people don't understand the difference between these two approaches is the worse-is-better legacy.

Regards,

Zooko

(Log in to post comments)

Kernel release status

Posted Feb 21, 2003 6:07 UTC (Fri) by Ross (subscriber, #4065) [Link]

Yes, you are right that gettimeofday() can jump back if settimeofday() is used by the root user to change the time. Hmm... the root user, who is trusted with the ability to do anything, can break the monotonic guarantee. That's not surprising. The root user can break just about everything.

And I'm not saying you can't do time synchronization. You can. Getting the time right at boot is a start. Using NTP or something similar which doesn't change the time but changes the rate of time adjustment is another.

Of course if you absolutely don't trust it you can do it yourself. Just set up a timer and increment a variable yourself. Or use a separate process or thread doing usleep() or select(). It can't go backwards unless the system can somehow take back signals or scheduling time.

But don't forget, root can attach to your process with ptrace() and modify your variable. ;)

monotic time

Posted Feb 23, 2003 22:45 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

Like most things in a computer, gettimeofday() is monotonic or not depending on what level you look at. If you look at it above the system administration policy level, it can be monotonic. Just establish a policy of not turning back the clock.

But any level below that, it is not monotonic. Ordinary system calls are provided to set the clock back. It is thus normal. And customary. And necessary.

We need to be able write programs that work in spite of system administration policy.

Within the kernel, nobody every uses the real time clock to measure passage of time. They use the 'jiffies' clock, which cannot be turned back at any level higher than "modifying the operating system." We need that at user level.

BTW, Daylight Savings Time is _not_ an issue here. It has always been possible to get absolute time (absolute time, whether it follows the UTC standard or not, doesn't vary according to where the sun appears or local custom).

monotic time

Posted Feb 27, 2003 6:56 UTC (Thu) by hpreg (guest, #9842) [Link]

"Within the kernel, nobody every uses the real time clock to measure passage of time. They use the 'jiffies' clock, which cannot be turned back at any level higher than 'modifying the operating system.' We need that at user level."

You already have it. And it is Posix.

man 2 times

monotonic time

Posted Feb 27, 2003 18:54 UTC (Thu) by zooko (subscriber, #2589) [Link]

Thanks! That's useful.

I still have two challenges to deal with, but the fundamental one of the clock running backward can be fixed by using this. Thanks again.

(Those two challenges are (a) communicating between processes e.g. IPC or storing persistent state between invocations, and (b) mapping to programmer-meaningful elapsed time by dividing by "clocks per second".)

Regards,

Zooko