<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Marcin 'Qrczak' Kowalczyk wrote:
<blockquote cite="mid87k6ptpvhk.fsf@qrnik.zagroda" type="cite">
<pre wrap="">Seth Kurtzberg <a class="moz-txt-link-rfc2396E" href="mailto:seth@cql.com"><seth@cql.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't think this would be a practical problem.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
If everyone disagrees with me, I'll shut up, but I truly believe that
this is a serious error.<br>
<blockquote cite="mid87k6ptpvhk.fsf@qrnik.zagroda" type="cite">
<pre wrap="">
Anyway, what does the "resolution of the system clock" mean? On Linux
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
You have a synchronous machine here (down at the processor level) and
an instruction cannot be executed before the previous instruction has
completed. (There are pipeline processors for which this isn't
precisely true, but it is true that there is _some_ amount of time that
is the maximum achievable granularity for any machine.)<br>
<blockquote cite="mid87k6ptpvhk.fsf@qrnik.zagroda" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
It definitely would be less accurate. But I don't see why that is
relevant to the discussion. Sleep generally causes a context switch,
so the granularity is much higher. Whether poll causes a context
switch is implementation dependent, and also dependent on the specified
timeout. A smart machine might use a spin lock for a very low poll
timeout value. At the end of the day, there is a a minimum granularity
for any machine, and this minimum granularity is always going to be
higher than a clock, most frequently the system clock (or, if you will,
the virtual system clock, as divider circuits that slow the clock value
presented to different components, e.g., the bus vs. the memory vs. the
processor).<br>
<br>
As I said, I'll drop it if every disagrees with me, but I think it is
worth some thought and should be based on the actual behavior of a
machine, not on the fact that a method may allow you to specify a lower
timeout value. That makes sense, because you wouldn't want to code
poll in such a way that it can't take advantage of higher clock
speeds. The speed is not infinite, and thus the granularity is not
unlimited.<br>
<blockquote cite="mid87k6ptpvhk.fsf@qrnik.zagroda" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
Agreed, but again, the question isn't which is the best way to do it,
the question is what is the granularity of the best way to do it.<br>
<br>
</body>
</html>