Strange numbers from gettimeofday(2)

Manuel Bouyer <bouyerantioche.eu.org> writes:

> On Fri, Jan 13, 2006 at 11:21:58PM -0500, Jed Davis
wrote:
>> Problem 1: It's still completely ignoring time(9),
which is very wrong
>> AIUI; and resettodr() is a no-op, which makes it
worse.
>
> AFAIK, time(9) is properly handled by hardclock(), and
resettodr() can't
> be anything but a no-op on a domU.

Right, there's nothing resettodr() can reasonably do; I
mentioned it
because the combination of both that and ignoring time(9)
made
ntpdate(8) be a no-op, which was somewhat surprising.

>> Problem 2: I tried this, and the shadow_tv was 42
seconds fast and
>> drifting slowly but noticeably forward; the dom0
was running ntpdate
>> from cron and was on time.  (Hm... the DOM0_SETTIME
is called only
>> when resettodr() is, so if the drift is small
enough for ntpdate to
>> always use adjtime(2), it won't ever correct Xen's
time?)
>
> Maybe not, until the system is rebooted. But I'm not
sure it's desireable to
> correct the time this way. This would make the time go
sometime backward
> in the domU.
> I checked Xen3, there isn't a way to correct the clock
drift in the
> hypervisor. We can just set the time to a new value.

I looked over Linux's clock code, at Thor's suggestion; it
will set
the Xen clock from the dom0 every so often if needed, and
has some
measures to keep the clock from going backwards no matter
what
(barring settimeofday, of course).  I'd have to stare at it
more to be
more specific than that.

Linux also has a sysctl-alike for whether to use Xen's time
or to have
an independent clock.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x
y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s)
l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car
l)) ((f (cdr l))
(C k)))))))    '((#J #d #D #v #s) (#e #space #a #i
#newline)))))