Re: [Xen-devel] Time in Xen

["Ian C. Blenke" <ian@xxxxxxxxxx>]

On Mon, Oct 27, 2003 at 05:06:48PM +0000, Keir Fraser wrote:
> 
> > I have a strange problem. One of my various xen test boxes doesn't
> > accept to set its time. Basically, it's stuck to RTC time.
> > 
> > ntpdate, date, hwclock all "seem" to work, but they don't actually
> > change the system time. The only way I have to change it right now is
> > to change it in the BIOS, which is not a good thing.
> 
> The checked-in tree (ssh://xen@xxxxxxxxxxxxxx/xeno-unstable.bk)
> now contains a number of fixes for the handling of time.
> 
> Briefly, Xen now reads the RTC at start of day and by default will
> track that with the precision of the periodic timer crystal.
> 
> Xen's estimate of the wall-clock time can only be updated by domain 0
> (this may be fixed in the future by introducing some access/update
> capabilities). If domain 0 runs ntpdate, ntpd, etc. then the
> synchronised time will automatically be pushed down to Xen
> every minute (and written to the RTC every 11 minutes, just as normal
> x86 Linux does). 

It would be nice to have a selectable "disparate system times", as a
normal standalone machine would act. Allowing each domain kernel to keep
track of its own unique system time (and ensuring that each domain gets
the interrupts to update their clock reliably) would be great for
development and QA environments.

> All other domains always track Xen's wall-clock time: setting the
> date, or running ntpd, on these domains will not affect their
> wall-clock time!! If this is a problem then I can add a sysctl which
> would turn this off if desired (i.e., setting the flag would prevent
> the domain from tracking Xen's estimate of wall-clock time).

For development environments, it really would help to be able to disable
this behavior. There's nothing quite like fiddling with the clock,
troubleshooting some timestamp behavior, only to find the system time
"fixed" after a testing run. 

UML's system clock is really more a suggestion than a real usable time
source as a result of some of the host's system time confusion.  Try a
"sleep 10" in a UML image, and see how long it *really* takes.  I'd hate
to see this happen to Xen as well.

- Ian C. Blenke <ian@xxxxxxxxxx>



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel