time: use monotonic clock to measure elapsed time

[tsuna]

Go's standard library doesn't provide any API to access a monotonic clock source, which means one can't reliably time how long an operation takes without copy-pasting or importing some low-level platform-dependent code such as the clock package at https://github.com/davecheney/junk.

This API doesn't necessarily need to return a time.Time, just returning a number of nanoseconds as a uint64 would be enough, kinda like Java's System.nanoTime().

[adg]

Do we have a monotonic clock source we can export?

If not, why should this be in the standard library and not just an
importable package?

On 13 October 2015 at 12:42, Benoit Sigoure notifications@github.com
wrote:

Go's standard library doesn't provide any API to access a monotonic clock
source, which means one can't reliably time how long an operation takes
without copy-pasting or importing some low-level platform-dependent code
such as the clock package at https://github.com/davecheney/junk.

This API doesn't necessarily need to return a time.Time, just returning a
number of nanoseconds as a uint64 would be enough, kinda like Java's
System.nanoTime()
http://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--
.

—
Reply to this email directly or view it on GitHub
#12914.

[tsuna]

Why should this be in the standard library: because it's a pretty fundamental thing, especially in a language geared towards systems programming. I see a lot of people timing how long operations take using time.Now() and subtracting two time.Time objects, and I always end up saying "this is not a correct way of measuring how much time elapsed" but don't have a clear alternative to propose.

Come on, even Java has it.

[adg]

I see a lot of people timing how long operations take using time.Now() and subtracting two time.Time objects, and I always end up saying "this is not a correct way of measuring how much time elapsed"

Got any concrete examples?

[tsuna]

Any concrete examples of ..? People using time.Now() or it being wrong because it doesn't take into account changes made to the system time?

[adg]

I suppose what I'm getting at is this: If there's a broad need for such a package, why isn't there one that people are already using?

[extemporalgenome]

This API doesn't necessarily need to return a time.Time, just returning a number of nanoseconds as a uint64 would be enough, kinda like Java's System.nanoTime().

time.Duration happens to represent a 64-bit quantity nanoseconds, and, unless there's some large problem with it, should be favored as the return type for any monotonic duration handling functions.

[taruti]

I think there are two things:

A) A proper monotonic clock package (there are multiple 3rd party ones)

B) Measuring elapsed time on systems where system time may leap to either direction

B is simpler. Either ensure and document that time.Since works
even with clock shifts or define new API like:

type MeasureStart struct { ... }
func (*MeasureStart)Start()
func (*MeasureStart)Elapsed() time.Duration

[crawshaw]

On what platforms is time.Now() not monotonic? For linux/amd64, time.Now is implemented by runtime·nanotime, which is calling clock_gettime (via VDSO) with CLOCK_MONOTONIC. I see similar calls being used on linux/arm, openbsd, freebsd, etc.

Instead of a new interface, can we document time.Now as monotonic?

[ianlancetaylor]

@crawshaw time.Now is not monotonic on any platform that supports settimeofday. On amd64 GNU/Linux time.Now does not actually use CLOCK_MONOTONIC, it uses CLOCK_REALTIME. It's runtime.nanotime that uses CLOCK_MONOTONIC.

[ianlancetaylor]

Sorry, I somehow missed that you mentioned nanotime yourself. That's not what implements time.Now, though, that is implemented by time·now.

[crawshaw]

Ah right, thanks. I got confused by //go:linkname time_runtimeNano time.runtimeNano, which I misread as implementing time.Now

[alexbrainman]

time.Now() is monotonic on windows. We use undocumented way to fetch time, but it is monotonic as far as I know. @dvyukov to confirm.

Alex

[tsuna]

On Mon, Oct 12, 2015 at 9:07 PM, Andrew Gerrand wrote:

I suppose what I'm getting at is this: If there's a broad need for such a package, why isn't there one that people are already using?

Because people incorrectly assume that time only moves forward? It's an extremely common mistake that even at Google we were trying to hammer in people's head. When you see the large impact that things such as leap seconds have (including at Google), it's easy to see this is a well known problem but also a recurring problem.

How is it that a language geared towards systems programming that comes with such a rich standard library offers no standard way of measuring time correctly?

Look at gRPC, every single use of time.Now() there is buggy because it implicitly assumes that time only moves forward and at a constant pace, neither of which is true for CLOCK_REALTIME. Pretty much any distributed systems code that uses time.Now() other than for printing the current time is subtly buggy. And there is a lot of it. And it's there chiefly because there is no alternative in the standard library to get monotonic time so people don't even think about it.