Re: [Xen-users] Time/clock issues with Xen 3.0.3?

[Tim Post <tim.post@xxxxxxxxxxxxxxx>]

On Tue, 2006-11-28 at 15:28 +0100, marek cervenka wrote:
> 
> i (and others too) do not want run ntpd in every domU. this is wasting of 
> resources

You could try rdate on boot, which would sync well.. I'm not sure
however how far the clock will drift thereafter (in the dom-u). 

ntp consumes almost no resources afiak, it barely malloc()'s (the only
strings it has to deal with are hostnames and time data) .. and I
believe rides in dentry for the most part once started. Its really not
much of a resource loss at all.

There was a fork of ntp/ntpd that was developed for SMM (embedded)
systems that used 99.9% file handles vs cache for everything, so that
the native 2.4 kernel on these systems would relinquish the memory
associated with those file handles instantly. However this also assumes
a CF drive (no i/o loss having it sync every few seconds). 

It came about because some of the cheaper ULV boards have horrible
clocks and 4 - 16 MB of RAM - so cache is precious real estate in that
setting.

I fail to recall the name of it but I *think* its available as a meta
package in Debian , check the debian-embedded list if your interested in
finding it. Was made for Kiosks and such years ago. Even if its orphaned
and unmaintained you should be able to dig it up .. if ntp resource use
is that much of a concern.

I know for all intensive purposes most of us code and install as
defensively on dom-0 as we would on a small memory model or embedded
system .. but we're really not talking about that big of a loss here :)

Best,
-Tim

> 
> > # ntpq -p
> >     remote           refid      st t when poll reach   delay   offset  
> > jitter
> > ==============================================================================
> > LOCAL(0)        LOCAL(0)        10 l   12   64  377    0.000    0.000   
> > 0.001
> > *rkdvmso1.dvm.kl 132.199.176.97   2 u  987 1024  377    0.207    0.035   
> > 0.742
> > +rksapas01.dvm.k 192.168.0.61     3 u  997 1024  377    0.120    0.020   
> > 0.772
> > +rksapas02.dvm.k 192.168.0.61     3 u  992 1024  377    0.101    0.049   
> > 0.769
> > +rksapas03.dvm.k 192.168.0.62     3 u  995 1024  377    0.282    0.019   
> > 4.211
> > +rksapas04.dvm.k 192.168.0.62     3 u  997 1024  377    0.274    0.001   
> > 0.775
> > +rksapas05.dvm.k 192.168.0.63     3 u   78 1024  377    0.281   -0.093   
> > 0.800
> > +rksapas06.dvm.k 192.168.0.63     3 u  999 1024  377    0.230   -0.213   
> > 0.825
> > rksapas07.dvm.k .INIT.          16 u    - 1024    0    0.000    0.000 
> > 4000.00
> > +rksapas08.dvm.k 192.168.0.41     4 u   78 1024  377    0.243   -0.168   
> > 0.796
> >
> > Ulrich
> >
> >
> >>
> >> for an example how to reproduce this problem, see below...
> >>
> >>
> >> right now I use a cron job on dom0 which re-sets the dom0 clock
> >> via date -s `date` (ntpdate doesn't work here).
> >>
> >>
> >> On Nov 25, Tim Post wrote:
> >>
> >>> What are the values of /proc/sys/xen/independent_wallclock
> >>> and /proc/sys/xen/permitted_clock_jitter respectively?
> >>
> >>    os2 koenig > cat /proc/sys/xen/independent_wallclock
> >>    0
> >>
> >>    os2 koenig > cat /proc/sys/xen/permitted_clock_jitter
> >>    10000000
> >>
> >> maybe I should just set /proc/sys/xen/independent_wallclock to 1
> >> and run ntpd on all domUs ?
> >>
> >>
> >> now, how I was able to reproduce the domU clock due to ntp clock drift in 
> >> dom0
> >> using SUSE 10.1 xen stuff.  in this examle both xen, dom0 and domU are 
> >> SUSE 10.1
> >> and use the SUSE xen-kernel, but on my real XEN server I run may different
> >> distributions and kernels -- all alike...
> >>
> >>
> >> step 1: perfect clock sync with drift==0 :
> >>
> >> run ntpd on dom0 with the following config file /etc/ntp.conf which uses
> >> only the dom0 system clock as "source", so it doesn't adjust the clock
> >> ever.
> >>
> >> ----------------------------- /etc/ntp.conf 
> >> -----------------------------------
> >> restrict default noquery notrust nomodify
> >> restrict 127.0.0.1
> >> restrict 192.168.8.0 mask 255.255.255.0
> >> server 127.127.1.1
> >> driftfile /var/lib/ntp/drift/ntp.drift
> >> logfile /var/log/ntp
> >> -------------------------------------------------------------------------------
> >>
> >> before starting ntpd, make sure the clock drift is set to zero with
> >>
> >>    echo 0 > /var/lib/ntp/drift/ntp.drift
> >>
> >> now start ntpd, start domU (don't run ntpd in domU) and check the domU
> >> clock drift with
> >>
> >>    ntpdate -d dom0
> >>
> >> that's how it should always work (in theory;).  but in real world
> >> the real clock drift of a PC clock is not zero. prrtty often the clock
> >> shows a frequency error of 100 ppm and more (which is 8.64 secs per day!).
> >>
> >>
> >> now, let's add some drift to dom0:
> >>
> >>    /etc/init.d/ntpd stop
> >>    echo 100 > /var/lib/ntp/drift/ntp.drift
> >>    /etc/init.d/ntpd start
> >>
> >>
> >> now you check the domU clock by running ntpdate on domU:
> >>
> >>    ntpdate -d dom0 ; sleep 60 ; ntpdate -d dom0
> >>
> >> and there will be a domU clock drift relative to dom0 or any other ntpd 
> >> server
> >> of ~6 msec per minute == 100 ppm.  qed.
> >>
> >>
> >> hope this helps to track and fix this clock problem!
> >>
> >> Harald Koenig
> >> --
> >> "I hope to die                                      ___       _____
> >> before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
> >> Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
> >>                                                     \  \/OOOOOOOOOOOOOOO\
> >>                                                       \ 
> >> OOOOOOOOOOOOOOOOO|//
> >> Harald Koenig                                          \/\/\/\/\/\/\/\/\/
> >> science+computing ag                                    //  /     \\  \
> >> koenig@xxxxxxxxxxxxxxxxxxxx                            ^^^^^       ^^^^^
> >>
> >> _______________________________________________
> >> Xen-users mailing list
> >> Xen-users@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-users
> >
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-users
> >
> 
> ---------------------------------------
> Marek Cervenka
> =======================================
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users