hi,
On Wed, Oct 14, 2009 at 1:56 PM, Chuck Swiger <[email protected]> wrote:
> What is the output, from running it? From a machine with a clock which is
> in sync, I get:
>
> # sntp -V -P no -r clock.fmt.he.ne
> sntp options: a=2 v=2 e=0.100 E=5.000 P=2147483647.000
> d=15 c=5 x=0 op=1 l=/etc/sntp.pid f= clock.fmt.he.net
> sntp: offset=-0.003+/-0.011 disp=0.000
> sntp: correction -0.003 +/- 0.000+0.011 secs - ignored
service ntp stop
Shutting down network time protocol daemon (NTPD)
done
sntp -V -P no -r clock.fmt.he.net
sntp options: a=2 v=2 e=0.100 E=5.000 P=2147483647.000
d=15 c=5 x=0 op=1 l=/etc/sntp.pid f= clock.fmt.he.net
sntp: offset=-0.970+/-0.024 disp=0.000
sntp: time changed by -0.970 secs to 2009 Oct 14 13:58:18.176 +/- 0.000+0.024
sntp -V -P no -r clock.fmt.he.net
sntp options: a=2 v=2 e=0.100 E=5.000 P=2147483647.000
d=15 c=5 x=0 op=1 l=/etc/sntp.pid f= clock.fmt.he.net
sntp: offset=-0.012+/-0.020 disp=0.000
sntp: correction -0.012 +/- 0.000+0.020 secs - ignored
service ntp start
Starting network time protocol daemon (NTPD)
done
r...@server /root >
> If you wait an hour, or a day, without running ntpd, and try to re-run the
> sntp command again, what is the offset you are seeing?
that's a worthwhile experiment. starting now ...
> If your clock is drifting by more than about a minute per day (I think the
> actual value is 43 seconds), your hardware clock is too broken to be able to
> sync with real time short of extreme measures. You might be better off not
> running ntpd at all in such case, and just run sntp via cron every hour.
> Right, OK-- from your earlier mail, you mentioned something about running
> with Xen Dom0/DomU. There is absolutely no point to running ntpd in a guest
> domain-- you should only try to run ntpd in a normal OS, or, as a last
> resort, in the Dom0 domain.
actually, that's not at all the recommendation I've repeatedly been
getting from numerous sources.
> The other domains can and should simply use the
> HW clock, because latencies and such for the guest domains are highly
> unpredictable.
which is why the recommendation is to sync EVERY Dom0/DomU against an
accurate clock via ntpd ...
tho, personally, i think the whole sync-time-in-Xen business is screwy
-- and i currently am very suspicious of the clocksource. e.g., on
opensuse, it's either "xen" or "jiffies". in newer kernels, and
pepppered throughout the kernel lists there's discussion of hpet, tsc
& acpi_pm clocksources being recommended -- NONE of which are
available as time source to me.
atm, i'm _strongly_ leaning to saying the heck with ntpd, and
_manually_ syncing too a good time source, using e.g. sntp, via
cronjob ...
> There may be a sysctl or Linux /proc thingy called
> xen.independent_wallclock which can be toggled.
yes. in DomU, one uses:
echo "1" > /proc/sys/xen/independent_wallclock
echo "jiffies" >
/sys/devices/system/clocksource/clocksource0/current_clocksource
which disables the dependence of DomU on Dom0, and then one runs ntpd ...
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
