The time appears to be perfect inside dom0, however all the domU''s tend to have a slightly faster date which gets further out of sync every day. I''m currently using Xen 3.0.3 with Gentoo Linux, under 3.0.2 I had no problems with domU clocks. Are there any known issues which could cause this? I''d strongly prefer not to run ntpd in every domU, having all domU clocks in sync with dom0 is quite important for me. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, 2006-11-24 at 20:28 +0000, Phillip Mumford wrote:> The time appears to be perfect inside dom0, however all the domU''s > tend to have a slightly faster date which gets further out of sync > every day. > > I''m currently using Xen 3.0.3 with Gentoo Linux, under 3.0.2 I had no > problems with domU clocks. Are there any known issues which could > cause this? I''d strongly prefer not to run ntpd in every domU, > having all domU clocks in sync with dom0 is quite important for me. >What are the values of /proc/sys/xen/independent_wallclock and /proc/sys/xen/permitted_clock_jitter respectively? By default, your guests should be using dom-0''s clock and should always be in sync. I have found that when I use independent HW clocks that the guests tend to stay a little behind dom-0, but I always chalked this up to a second or so difference between whatever ntp server the guests were using vs dom-0 Since the only reason to keep them independent is to allow for a difference, I never gave it much thought :) If you do a head -c1 /dev/null > /proc/sys/xen/independent_wallclock (or echo 0 to it) then rdate on dom-0, your guests should have the exact time as dom-0. I''m also not sure of what unit is used in permitted_clock_jitter in order to guide you on changing it .. can''t seem to find that one in the docs. If you found independent wall clocks to already be null or 0, you might try adjusting the permitted jitter. Hope this helps. Best, - Tim> _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 25 Nov 2006 at 14:27, Tim Post wrote: [...]> If you do a head -c1 /dev/null > /proc/sys/xen/independent_wallclock (or > echo 0 to it) then rdate on dom-0, your guests should have the exact > time as dom-0. >For what''s worth it: I saw a time difference up to three seconds on a four CPU SMP machine. Only after using NTP with independen clocks, the clocks look OK now. [...] Ulrich _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, 25 Nov 2006, Tim Post wrote:> > On Fri, 2006-11-24 at 20:28 +0000, Phillip Mumford wrote: >> The time appears to be perfect inside dom0, however all the domU''s >> tend to have a slightly faster date which gets further out of sync >> every day. >> >> I''m currently using Xen 3.0.3 with Gentoo Linux, under 3.0.2 I had no >> problems with domU clocks. Are there any known issues which could >> cause this? I''d strongly prefer not to run ntpd in every domU, >> having all domU clocks in sync with dom0 is quite important for me.same problem here (xen 3.0.3 + sched=credit)> What are the values of /proc/sys/xen/independent_wallclock > and /proc/sys/xen/permitted_clock_jitter respectively?DOM0 [root@dom0 ~]# cat /proc/sys/xen/independent_wallclock 0 [root@dom0 ~]# cat /proc/sys/xen/permitted_clock_jitter 10000000 DOMU [root@domU ~]# cat /proc/sys/xen/independent_wallclock 0 [root@domU ~]# cat /proc/sys/xen/permitted_clock_jitter 10000000 with same hw and xen3.0.2-2 is time ok --------------------------------------- Marek Cervenka ====================================== _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I see the same problem here (xen-3.0.2 from SUSE 10.1): dom0 is synched via ntpd, and the domUs drift away from dom0 and ntp server. 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@science-computing.de ^^^^^ ^^^^^ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Monday 27 November 2006 5:24 am, Harald Koenig wrote:> I see the same problem here (xen-3.0.2 from SUSE 10.1): > dom0 is synched via ntpd, and the domUs drift away from dom0 and ntp > server.and the hardware clock? does it drift too? if not, doing a ''hwclock --hctosys'' helps? -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 27 Nov 2006 at 11:24, Harald Koenig wrote:> I see the same problem here (xen-3.0.2 from SUSE 10.1): > dom0 is synched via ntpd, and the domUs drift away from dom0 and ntp server.Harald, use independent clocks everywhere, and it will work: "rkdvmso1" is a Dom0, every other is a DomU somewhere: # 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@science-computing.de ^^^^^ ^^^^^ > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> On 27 Nov 2006 at 11:24, Harald Koenig wrote: > >> I see the same problem here (xen-3.0.2 from SUSE 10.1): >> dom0 is synched via ntpd, and the domUs drift away from dom0 and ntp server. > > Harald, > > use independent clocks everywhere, and it will work: "rkdvmso1" is a Dom0, every > other is a DomU somewhere:i (and others too) do not want run ntpd in every domU. this is wasting of resources> # 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@science-computing.de ^^^^^ ^^^^^ >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >--------------------------------------- Marek Cervenka ====================================== _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 28 Nov 2006 at 15:28, marek cervenka wrote:> > On 27 Nov 2006 at 11:24, Harald Koenig wrote: > > > >> I see the same problem here (xen-3.0.2 from SUSE 10.1): > >> dom0 is synched via ntpd, and the domUs drift away from dom0 and ntp server. > > > > Harald, > > > > use independent clocks everywhere, and it will work: "rkdvmso1" is a Dom0, every > > other is a DomU somewhere: > > i (and others too) do not want run ntpd in every domU. this is wasting of > resourcesI didn''t tell you that you must ;-) Regards, Ulrich _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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 > resourcesYou 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@science-computing.de ^^^^^ ^^^^^ > >> > >> _______________________________________________ > >> Xen-users mailing list > >> Xen-users@lists.xensource.com > >> http://lists.xensource.com/xen-users > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > --------------------------------------- > Marek Cervenka > ======================================> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
ntp is to correct drift. It was not designed be the clock itself. If the. clock doesn't keep proper time, do you add more clocks to keep it correct? No, you fix the clock. Ntp has it's place. But, it doesn't work well with a broken clock. Throwing ntp at this is inappropriate. -----Original Message----- From: Tim Post <tim.post@netkinetics.net> Date: Wed, 29 Nov 2006 17:19:53 To:marek cervenka <cervajs@fpf.slu.cz> Cc:xen-users@lists.xensource.com Subject: Re: [Xen-users] Time/clock issues with Xen 3.0.3? 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 > resourcesYou 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@science-computing.de ^^^^^ ^^^^^ > >> > >> _______________________________________________ > >> Xen-users mailing list > >> Xen-users@lists.xensource.com > >> http://lists.xensource.com/xen-users > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > --------------------------------------- > Marek Cervenka > ======================================> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/29/06, Chad Oleary <oleary.chad@gmail.com> wrote:> ntp is to correct drift. It was not designed be the clock itself. If the. clock doesn''t keep proper time, do you add more clocks to keep it correct? No, you fix the clock. > > Ntp has it''s place. But, it doesn''t work well with a broken clock. Throwing ntp at this is inappropriate.FWIW, the clock in my dom0 and domU''s are perfectly in sync. (2.6.16.29-xen_3.0.3.0 installed from 32-bit xensource.com rpm''s) jerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, 29 Nov 2006, Jerry Amundson wrote:> On 11/29/06, Chad Oleary <oleary.chad@gmail.com> wrote: >> ntp is to correct drift. It was not designed be the clock itself. If the. >> clock doesn''t keep proper time, do you add more clocks to keep it correct? >> No, you fix the clock. >> >> Ntp has it''s place. But, it doesn''t work well with a broken clock. Throwing >> ntp at this is inappropriate. > > FWIW, the clock in my dom0 and domU''s are perfectly in sync. > (2.6.16.29-xen_3.0.3.0 installed from 32-bit xensource.com rpm''s)which xen scheduler? how many domU? i have same hw, same xen3.0.3.0 with sched=sedf and 1 domU dom0 and domU are perfectly in sync too but same hw, same xen3.0.3.0 sched=credit, 15domU and time in domUs is slightly faster --------------------------------------- Marek Cervenka ====================================== _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, 2006-11-29 at 10:58 +0000, Chad Oleary wrote:> ntp is to correct drift. It was not designed be the clock itself.> If the. clock doesn''t keep proper time, do you add more clocks to keep it correct?> No, you fix the clock. >Sometimes you can''t ... and when you need to keep a cluster of machines in step with each other its very practical. ULV (Ultra low voltage) machines typically suffer from shotty clocks, Especially PII / Pentium Pro based boards. The comparison is quite relevant because resource usage on (very) small guests was voiced as a concern. Very small guests with jittery clocks are very much like ULV biscuits.> Ntp has it''s place. But, it doesn''t work well with a broken clock> Throwing ntp at this is inappropriate.Its very appropriate since its drift we''re correcting. Best, -Tim _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/29/06, marek cervenka <cervajs@fpf.slu.cz> wrote:> On Wed, 29 Nov 2006, Jerry Amundson wrote: > > > On 11/29/06, Chad Oleary <oleary.chad@gmail.com> wrote: > >> ntp is to correct drift. It was not designed be the clock itself. Ifthe.> >> clock doesn''t keep proper time, do you add more clocks to keep itcorrect?> >> No, you fix the clock. > >> > >> Ntp has it''s place. But, it doesn''t work well with a broken clock.Throwing> >> ntp at this is inappropriate. > > > > FWIW, the clock in my dom0 and domU''s are perfectly in sync. > > (2.6.16.29-xen_3.0.3.0 installed from 32-bit xensource.com rpm''s) > > which xen scheduler?Hmm. I''ve not had much hands-on with sched - how can I tell? "xm sched-sedf" returns Name ID Period(ms) Slice(ms) Lat(ms) Extra Weight Domain-0 -1 -0.0 -0.0 -0.0 -1 -1 dom1 -1 -0.0 -0.0 -0.0 -1 -1 dom2 -1 -0.0 -0.0 -0.0 -1 -1> how many domU?Just 2, currently... jerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Nov 29, Chad Oleary wrote:> ntp is to correct drift. It was not designed be the clock itself. If the. clock doesn''t keep proper time, do you add more clocks to keep it correct? No, you fix the clock.so what''s your suggestion to fix frequency errors of cheap quartz crystals ? and how about temperature drift of the crystal etc ? soldering every PC main board with temperature controlled oscilators (or better a rubidium clock or similar) just isn''t feasible for everybody...> Ntp has it''s place. But, it doesn''t work well with a broken clock. Throwing ntp at this is inappropriate.so throw away every PC based hardware ? hmmm... do you have any better suggestion how to synchronize a network of (e.g. build) servers (mixed Linux and legacy un*x) to a common sense of "time" with max. time offsets far below 1 sec over a period of weeks to months ? 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@science-computing.de ^^^^^ ^^^^^ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, 29 Nov 2006, Jerry Amundson wrote:> On 11/29/06, marek cervenka <cervajs@fpf.slu.cz> wrote: >> On Wed, 29 Nov 2006, Jerry Amundson wrote: >> >> > On 11/29/06, Chad Oleary <oleary.chad@gmail.com> wrote: >> >> ntp is to correct drift. It was not designed be the clock itself. If > the. >> >> clock doesn''t keep proper time, do you add more clocks to keep it > correct? >> >> No, you fix the clock. >> >> >> >> Ntp has it''s place. But, it doesn''t work well with a broken clock. > Throwing >> >> ntp at this is inappropriate. >> > >> > FWIW, the clock in my dom0 and domU''s are perfectly in sync. >> > (2.6.16.29-xen_3.0.3.0 installed from 32-bit xensource.com rpm''s) >> >> which xen scheduler? > > Hmm. I''ve not had much hands-on with sched - how can I tell?[root@xen0 ~]# xm dmesg|grep sched (XEN) Using scheduler: Simple EDF Scheduler (sedf) --------------------------------------- Marek Cervenka ====================================== _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/29/06, marek cervenka <cervajs@fpf.slu.cz> wrote:> [root@xen0 ~]# xm dmesg|grep sched > (XEN) Using scheduler: Simple EDF Scheduler (sedf)Oops - so obvious I thought I''d checked. Well, that explains why it works for me... # xm dmesg | grep sched (XEN) Using scheduler: SMP Credit Scheduler (credit) jerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> On 11/29/06, marek cervenka <cervajs@fpf.slu.cz> wrote: >> [root@xen0 ~]# xm dmesg|grep sched >> (XEN) Using scheduler: Simple EDF Scheduler (sedf) > > Oops - so obvious I thought I''d checked. Well, that explains why it > works for me... > # xm dmesg | grep sched > (XEN) Using scheduler: SMP Credit Scheduler (credit)this is not true. i have time problem on server where is sched=credit --------------------------------------- Marek Cervenka ====================================== _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11/27/06, marek cervenka <cervajs@fpf.slu.cz> wrote:> same problem here (xen 3.0.3 + sched=credit) > > > What are the values of /proc/sys/xen/independent_wallclock > > and /proc/sys/xen/permitted_clock_jitter respectively? > > DOM0 > [root@dom0 ~]# cat /proc/sys/xen/independent_wallclock > 0 > [root@dom0 ~]# cat /proc/sys/xen/permitted_clock_jitter > 10000000 > > DOMU > [root@domU ~]# cat /proc/sys/xen/independent_wallclock > 0 > [root@domU ~]# cat /proc/sys/xen/permitted_clock_jitter > 10000000 > > with same hw and xen3.0.2-2 is time okIdentical setup (all default values), so I''ve submitted a bug report to bugzilla <http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=828>. I''ve tried fiddling around with a few values and changing the scheduler, but not had much luck. I''d prefer not having to use a date with cron hack or ntp in every domU! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users