On 25 May 2008, at 18:58 , Joerg Sonnenberger wrote:
On Sun, May 25, 2008 at 06:32:35PM -0700, Dennis Ferguson wrote:That patch is much better. On 11 Jan 2009, at 22:38 , Joerg Sonnenberger wrote:Well, setitimer is supposed to change with the real time and I would argue that settimeofday modifies the real time.I think you are confusing real time with real time intervals. The two are different enough that timekeeping conferences mention them as separatetopics, e.g.I'm quoting the wording of SUS of setitimer(2) here.
Well, if we're reduced to quoting standardese, how about this one
from the SUS for clock_settime():
Setting the value of the CLOCK_REALTIME clock via clock_settime()
shall have no effect on threads that are blocked waiting for a
relative time service based upon this clock, including the
nanosleep() function; nor on the expiration of relative timers
based
upon this clock. Consequently, these time services shall expire
when
the requested relative interval elapses, independently of the new
or
old value of the clock.
The "relative timers based upon this clock" it is talking about that
shouldn't
be effected by clock_settime() include the one managed via
setitimer(). This
directly contradicts what you asserted above.I've attached a program which exercises this. Notice the interval between "alarm 4" and "alarm 5" is very different when a call to clock_settime() is made compared to when it isn't. That's the behaviour the standard disallows.
If you want a timescale where the difference betweentwo timestamps reliably reflects the interval between them you can't use a timescale which is subject to phase adjustments, which is why the kerneluptime works here while kernel time is a bit broken.The problem with using uptime is that it won't help for stepping in thetime as done e.g. by settimeofday. This matches the description of clock_gettime. The uptime behavior would match the non-existing ITIMER_MONOTONIC. That doesn't make a difference during normaloperation, but as soon as e.g. the system can be suspended for arbitraryintervals, it becomes quite obvious.
I don't know what behaviour you are talking about. time and uptimeare (or should be) the same time from the same clock; they differ only by
a near-constant "boottime" which is maintained so that
time = uptime + boottime
Essentially boottime and uptime are the separated phase and frequency
components of CLOCK_REALTIME time. boottime is only changed by calls
to clock_settime(), settimeofday() and the equivalent operation at the
NTP system call interface. Otherwise time and uptime are entirely
synchronous and advance at the same rate. They are the same clock. So,
when the standard says you need to use a time which is CLOCK_REALTIME,
but which is unaffected by calls to clock_settime(), they are talking
precisely about uptime because that is what uptime is.
I don't have a good handle on what timers should do when the system
isn't
running (nor does the SUS, for that matter), so if you don't like what uptime does when the system is suspended feel free to fix that (maybe you can set uptime = time - boottime when you wake up). I can tell you for sure, however, that what uptime does when the system is running is exactly, precisely what relative time functions need (if it isn't it should be fixed). That is its purpose, its only purpose. Note that this is a very small problem in most cases since, as you pointout, most people don't use settimeofday() very often. What is mystifying
me, however, is that while someone went to a great deal of trouble to add the infrastructure to your kernel to entirely eliminate this small problem (and many others like it, actually), you are declining to use it for precisely the thing it was meant to be used for. What was the point of adding it?
Given the guarantied reslution of 1/HZ only the effect of phase adjustments should be irrelevant.
Umm, we're not talking small differences here. Try the attached program.
Dennis Ferguson
Attachment:
r.c
Description: Binary data