Ashley Yakeley wrote:

In article , Ketil Malde wrote:

...

It would be nice if the interface was such that it didn't matter to the user. Couldn't it be an opaque type? And does the resolution have to be standardized? Standardizing on picoseconds is probably safe, but I think it would be better to be able to query about the underlying clock resolution, instead of getting a long sequence of non-significant digits.

Bear in mind that the time type might be used for time calculations unrelated to the system clock. Whether or not we hide the constructor, I think its internal resolution and general behaviour ought to be known and platform-independent.

I understand what Ashley is saying, but that type of calculation is very different from a calculation related to the system clock. The choices that seem to be on the table here are flawed. To force all time calculations to be no better than the system clock resolution is not sensible, for the reasons that Ashley states. However, it is also not acceptable for a function to return an incorrect value for calculations involving the system clock. If, say, I make two calls to read the current time, and both return the same value, what does that mean? Clearly it doesn't mean that no time has passed. It means that the clock hasn't ticked, but it provides no information about exactly what that means. Does it mean that the elapsed time is less than a second? A millisecond? A microsecond? Without knowledge about the resolution of the system clock, there is no way to find out. I think that this particular pair of birds can't be killed with one stone. The system clock resolution is platform dependent, and this fact must be dealt with in a way that doesn't produce incorrect answers. Time values whose source is the system clock are different not only in resolution but also in kind. As presented, the choice is between having a cripled library that is a slave to the system clock resolution, or having a useful computational capability for time but returning incorrect answers w.r.t. the system clock. Clearly these are two different things. The core of the time calculation can be shared by these two different types of time, but at the user level it needs to be clear whether a value is derived from the system clock, or is not. I don't see any way around the need for a different interface for each. The alternatives are unacceptable.

Ashley Yakeley wrote:

In article <41FE033F.1080507@cql.com>, Seth Kurtzberg wrote:

...

If, say, I make two calls to read the current time, and both return the same value, what does that mean?

That's an interesting question. For "Unix time" that's not supposed to happen: successive calls must return strictly later times unless the clock has been set back by more than a certain amount. This only really becomes an issue for leap-seconds, when one is trying to set the clock back one second. In such a case, successive clock calls increment one tick until time has caught up.

It might be helpful to have the platform-dependent clock resolution available as a value.

Doesn't automatically forcing a system clock tick screw up the time? Also, what happens when you are using NTP? NTP might just correct it, but it would screw up the calculations NTP uses and it could start oscillating.

...

Clearly these are two different things.

Well, the system clock is just one of many sources for time values. The user might be dealing with times from some other clock, or measured times from a scientific experiment, or appointment times from a datebook, or phenomenon times from astronomical calculations. How should these all be represented?

The way you suggested. I'm not saying that there shouldn't be a computation library with better resolution. That's necessary for two reasons; one, the type of applications you just mentioned, and, two, because you _do_ want a clock library independent of the system clock. I'm saying that you _also_ need to handle the system clock case. I'm also saying that I don't like the idea of using the same resolution w.r.t. the system clock, because it suggests that the time is known to a greater precision than is actually the case. I don't think we disagree, in general, it's more a question of whether or not system clock related computations should match the precision of the system clock. 123.45000 implies that the value is known to be accurate to five decimal points (just picking an arbitrary number of digits beyond the decimal point, because I don't recall the actual precision of the high resolution library). Truncating at the end is also not "correct," because the final result in general might be different if you compute with five digits and truncate, rather than computing with two digits throughout. (Again, whatever the number is; I pulled 2 digit out of the air, just to use a number.) To me all this shows that the system clock needs to be handled as a special case, not just converted into the high resolution representation

...

The core of the time calculation can be shared by these two different types of time, but at the user level it needs to be clear whether a value is derived from the system clock, or is not. I don't see any way around the need for a different interface for each. The alternatives are unacceptable.

Wouldn't the user already know whether a value is derived from the system clock or not, from the program they write?

I see you haven't met some of the programmers who work for me. :) Seriously, yes, they would know, but there are portability concerns. Which, of course, is what you have been saying; I just have a slightly different take on it.

Seth Kurtzberg writes:

Also, what happens when you are using NTP? NTP might just correct it, but it would screw up the calculations NTP uses and it could start oscillating.

The NTP client (at least on Linux) adjusts the time by making a jump only if the time is very inaccurate. If the time only drifted a bit, it temporarily adjusts the speed of the system clock instead.

I'm also saying that I don't like the idea of using the same resolution w.r.t. the system clock, because it suggests that the time is known to a greater precision than is actually the case.

I don't think this would be a practical problem.

To me all this shows that the system clock needs to be handled as a special case, not just converted into the high resolution representation

Using a different representation of time just because somebody might not be aware that the resolution of the system clock is not as good as the representation suggests? No, this is an unnecessary complication. Anyway, what does the "resolution of the system clock" mean? On Linux the timeout of select(), poll() and epoll() is accurate only to the timer interrupt (10ms on older kernels and 1ms on newer ones), yet the gettimeofday is more precise (it returns microseconds, quite accurately; the call itself takes 2us on my system). So even if gettimeofday is accurate, sleeping for some time might be much less accurate. BTW, this means that the most accurate way to make a delay is to use select/poll/epoll to sleep for some time below the given time (i.e. shorter by the typical largest interval by which the system makes the delay longer than requested), then to call gettimeofday in a loop until the given time arrives. The implementation of my language does that under the hood. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

In article <41FE95DF.50000@cql.com>, Seth Kurtzberg wrote:

I'm not, I hope, being pedantic here and talking about an irrelevant issue. But if you look in any first year engineering textbook (for an engineering discipline other than CS), you will find that the display of a value with a precision greater than the known precision of the inputs is a cardinal sin. It's the wrong answer. The roundoff error behavior is clearly going to be different.

Well, how do you feel about using Rationals everywhere? That way there's never any question of some irrelevant specified unused accuracy. newtype ClockTime = ClockTime Rational deriving (Eq, etc.) I quite like the idea of using Rational for ClockTime, but I worry that it might be slow. But it does allow you to do things such as dividing times into n pieces and adding them all up again without error. -- Ashley Yakeley, Seattle WA

In article <87acqor67i.fsf@qrnik.zagroda>, Marcin 'Qrczak' Kowalczyk wrote:

The numerator and denominator can too easily become huge, e.g. if one is computing absolute times of an event repeating in uneven intervals, without retrieving a rounded value from the system clock each time. He won't easily notice that the numbers grow out of control.

If I read you correctly, your complaint is that certain calculations would be too accurate, thus leading to large representation. -- Ashley Yakeley, Seattle WA

Marcin 'Qrczak' Kowalczyk writes:

Ashley Yakeley writes:

...

If I read you correctly, your complaint is that certain calculations would be too accurate, thus leading to large representation.

The accuracy is of course illusory, the extra information is meaningless.

Not necessarily. You might very well be using Haskell (and its new time library) to perform calculations with data that comes from a source which _does_ have this kind of accuracy. Peter

Aaron Denney wrote:

[...] If we were to use the posix timer CLOCK_REALTIME with clock_gettime(), then clock_getres() should would give us the precision, but not, of course, the accuracy.

I agree with everything you wrote, and I think it's worth making a big deal of the fact that precision and accuracy are different things, because it's easy to confuse them in discussions like this. Every time-related system call specifies a precision, but I don't think any of them say anything about accuracy. Furthermore, on nearly every system the differential accuracy of a system clock will be orders of magnitude better than its absolute accuracy, so it's ambiguous to talk about accuracy without specifying which one you mean. Yet another distinct concept is that of a time interval like "1 February 2005 UTC", which has infinite precision and accuracy even though it's fuzzy in a different way. It doesn't make sense to represent the day with picosecond precision because then you're effectively talking about a particular picosecond in that day, which is a totally different concept. Possibly we could get away with talking always about intervals of time (rather than points), but allowing intervals of different sizes. E.g. (trying to retain static typing here): newtype AbsPicoseconds = AbsPicoseconds Integer newtype RelPicoseconds = RelPicoseconds Integer newtype AbsSeconds = AbsSeconds Integer newtype RelSeconds = RelSeconds Integer newtype AbsDays = AbsDays Integer newtype RelDays = RelDays Integer Conversions from AbsPicoseconds to AbsSeconds to AbsDays may make sense, but the reverse don't. And no conversions on Rel times make sense. These data types don't carry accuracy information around with them, because I think that's hopeless. -- Ben

Seth Kurtzberg writes:

But if you look in any first year engineering textbook (for an engineering discipline other than CS), you will find that the display of a value with a precision greater than the known precision of the inputs is a cardinal sin.

The time expressed as an absolute number of ticks is primarily used for computation, not for display. For display you usually choose the format explicitly, it rarely includes more precision than seconds, and if it does, you are aware how many digits you want to show.

I can certainly work around the problem at the application code level, but that's a clear violation of the encapsulation principle, because I'm relying on the implementation of the calculations and not just the interface.

When I program timers, usually I don't even care what is the exact resolution of the timer, as long as it's good enough for users to not notice that delays are inaccurate by a few milliseconds. The OS can preempt my process anyway, the GC may kick in, etc. If someone makes a real-time version of Haskell which runs on a real-time OS, it's still not necessary to change the resolution of the interface - it's enough for the program to know what accuracy it should expect.

...

Anyway, what does the "resolution of the system clock" mean? On Linux

It means, in general, a clock tick. poll, select, etc. cannot provide a timeout of greater precision than the system clock, and in general, since execution of an assembly language instruction takes multiple clock ticks, poll and its family actually can't even reach the precision of a single clock tick.

Ah, so you mean the processor clock, not the timer interrupt. What has the processor clock to do with getting the current time and setting up delays? Anyway, I don't propose picoseconds nor attoseconds. Some numbers from my PC: - my processor's tick has 0.8ns - gettimeofday interface has a resolution of 1us - clock_gettime interface uses 1ns, but the actual time is always a multiple of 1us - a gettimeofday call takes 2us to complete - select interface uses 1us, but the actual delay is accurate to 1ms - poll allows to sleep for delays accurate to 1ms, but it must be at least 1ms-2ms (two timer interrupts) - epoll allows to sleep for delays accurate to 1ms - if the same compiled program is run on an older kernel, select/poll precision is 10 times worse So I have two proposals for the resolution of Haskell's representation of absolute time: 1. Use nanoseconds. 2. Use an implementation-dependent unit (will be probably nanoseconds or microseconds with current implementations, but the interface will not have to be changed if more accurate delays become practical in 10 years).

It's important to distinguish between the fact that a method allows you to use a value, and the fact that, in a given environment, all values lower than some minimum (something of the order of 10 clock ticks, which is optimistic) are simply treated as zero. Not in the sense that zero means blocking, in the sense that the interval from the perspective of poll() is actually zero. The next time a context switch (or an interrupt, if poll is implemented using interrupts) the timeout will be exceeded. Checking the documentation of poll, there is even a warning that you cannot rely on any given implementation to provide the granularity that poll allows you to specify.

Note that the behavior of poll and epoll on Linux differs, even though they use the same interface for expressing the delay (number of milliseconds as a C int). poll rounds the time up to timer interrupts (usually 1ms or 10ms), and sleeps for the resulting time or up to one tick *longer*. epoll rounds the time up to timer interrupts, and sleeps for the resulting time or up to one tick *shorter* (or sometimes longer if the process is preempted). The behavior of poll is consistent with POSIX, which tells that the specified time is the minimum delay. The behavior of epoll allows to sleep for the next timer interrupt by specifying 1ms (poll always sleeps at least one full timer interrupt - I mean when it returns because the delay has expired). I've heard that by accident select is like epoll, not like poll (except that the interface specifies microseconds; it's not more accurate though), but I haven't checked. So the compiler of my language measures (at ./configure time) the time poll/epoll will usually sleep when asked to sleep for 1ms just after a timer interrupt. This is used to calculate the delay to ask poll/epoll for. The remaining time is slept using a loop which calls gettimeofday, unless another thread wants to run. This gives a practical accuracy of about 20us here. But this becomes 1ms when other threads or processes interfere. This means that the "resolution of a delay" is not a well defined concept. It depends on too many variables, for example on the time it takes for gettimeofday call to return and on activity of threads and processes. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Ashley Yakeley wrote: [snip]

Can we assume that the system clock will be set to UTC?

No, you can't assume it. But I believe you can assume that the calls to obtain the time are smart enough to convert it to UTC if necessary.

This is apparently in the POSIX standard. What about on Windows platforms? If so, the system clock should return POSIX time.

I would want to verify that windows behaves correctly, rather than assume it. Microsoft is not a big POSIX fan.

Do we want the same resolution in all three? Should it be fixed or platform-dependent? Bear in mind that there are applications for this that may not involve the system clock at all.

Since clearly the library cannot _allways_ know the precision, one can make a good case that the responsibility for determining the precision is the library user, not the library itself. And/or, you can isolate the platform-dependent aspects and allow the user to set them, or have the library try to determine the correct values and allow the user to override the values. Which implies that the user can get the values in the first place.