RE: Xen system skew MUCH worse than tsc skew (was RE: [Xen-devel] RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasing hvm guest time))

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

> > SO XEN SYSTEM TIME MAX SKEW IS >30X WORSE THAN TSC MAX SKEW!
> >
> > Looks to me like there's still something algorithmically wrong
> > and its not just natural skew and jitter.  Maybe some corner
> > case in the scale-delta code?  Also, should interrupts be turned
> > off during the calibration part of init_pit_and_calibrate_tsc()
> > (which might cause different scaling factors for each CPU)?
> 
> I didn't measure skew across CPUs. I measured jitter between 
> one local TSC
> and the chosen platform timer for calibration (in my case I 
> think this was
> the HPET). I did this because getting a consistent tick rate from the
> platform timer, and from each local TSC, is the basis for the 
> calibration
> algorithm. The more jitter there is between them, the less 
> well it will
> work.
> 
> I implemented a user-space program to collect the required 
> stats. It used
> CLI/STI to prevent getting interrupted when reading the timer pair.

Hi Keir -

I'm still looking at whether all of the intra-processor stime
skew I'm seeing is due to jitter vs algorithmic.

Would you expect system load to impact stime skew between
processors (using hpet as a system timer)?  I can repeatably
watch skew get worse when I am launching an hvm domain.  It is
MUCH worse when the new domain is in its early stages of booting.
CPU load on domain0 has little or no impact but I/O load
on dom0 seems to make skew get worse.

Thanks,
Dan


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