[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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))
> > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |