Hello,
Am 04.03.2010 um 17:24 Uhr schrieb Josip Rodin :
> On Thu, Mar 04, 2010 at 05:21:31PM +0100, Markus Hochholdinger wrote:
> > > In my case this manifested itself when some PHP profiling via
> > > microtime() suddenly became useless, and it also caused occasional
> > > PostgreSQL errors with
Hi,
[..]
> In my case this manifested itself when some PHP profiling via microtime()
> suddenly became useless, and it also caused occasional PostgreSQL errors
> with tables that had timestamp columns as keys, since it became possible
> for two independent transactions to come in at the exact same
On Thu, Mar 04, 2010 at 05:21:31PM +0100, Markus Hochholdinger wrote:
> > In my case this manifested itself when some PHP profiling via microtime()
> > suddenly became useless, and it also caused occasional PostgreSQL errors
> > with tables that had timestamp columns as keys, since it became possib
Hi,
Am 23.02.2010 um 22:36 Uhr schrieb Moritz Muehlenhoff :
> On Tue, Feb 23, 2010 at 02:06:41PM +0100, Markus Hochholdinger wrote:
> > Here is my solution to this problem, lenny xen kernel:
> > * dom0 with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0
> > * domU with clocksource=j
On Thu, Feb 25, 2010 at 03:01:41PM +0100, Bastian Blank wrote:
> > > No. The time resolution is not defined and within one step it will
> > > always provide the same value.
> > What? :) The problem here is that a time readout function provides the same
> > value across *two* steps. A monotonic func
On Thu, Feb 25, 2010 at 02:27:55PM +0100, Josip Rodin wrote:
> > No. The time resolution is not defined and within one step it will
> > always provide the same value.
> What? :) The problem here is that a time readout function provides the same
> value across *two* steps. A monotonic function is on
On Thu, Feb 25, 2010 at 12:18:54PM +0100, Josip Rodin wrote:
> Using jiffies as a clock source is not a "solution", it's a workaround,
> because its resolution (CONFIG_HZ^1) is not good enough for reading
> microseconds, that is, time with microseconds will become just monotonic.
> This will cause
On Thu, Feb 25, 2010 at 01:33:05PM +0100, Bastian Blank wrote:
> On Thu, Feb 25, 2010 at 12:18:54PM +0100, Josip Rodin wrote:
> > Using jiffies as a clock source is not a "solution", it's a workaround,
> > because its resolution (CONFIG_HZ^1) is not good enough for reading
> > microseconds, that is
Hi,
Markus Hochholdinger wrote:
> Here is my solution to this problem, lenny xen kernel:
> * dom0 with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0
> * domU with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0
Using jiffies as a clock source is not a "solution", it'
On Tue, Feb 23, 2010 at 02:06:41PM +0100, Markus Hochholdinger wrote:
> Here is my solution to this problem, lenny xen kernel:
> * dom0 with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0
> * domU with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0
> * ntpdate/ntp only
Here is my solution to this problem, lenny xen kernel:
* dom0 with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0
* domU with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0
* ntpdate/ntp only in dom0, NOT in the domUs
I tested it the following way:
While changing the
On Sun, 2009-10-04 at 15:55 +0200, Sergio Gelato wrote:
>
> I had been led to expect (again, by the wiki page, but also by common
> sense) that the domU was meant to get its clock from Xen and didn't
> need to run NTP. This appears to only be the case when the domU kernel
> includes the SuSE patch
severity 534978 normal
thanks
I've made some more progress in understanding this behaviour, and have now
figured out a workaround. I find the documentation at
http://wiki.debian.org/Xen very misleading in several respects.
The domU kernel is receiving time info from the hypervisor as it should.
I think I've made some progress towards figuring out what's going on here.
First I looked at the Xen mini-os kernel, which keeps time correctly.
I added a few printk()s to getttimeofday() and saw that of the values
in the HYPERVISOR_shared_info structure, the vcpu_info data change often
(never mor
Package: linux-image-2.6.26-2-686-bigmem
Version: 2.6.26-15lenny3
Severity: important
I'm running this kernel in a Xen domU using the xen clocksource:
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
xen
The dom0 is running linux-image-2.6.26-2-xen-686 (same version 2.6.26-
15 matches
Mail list logo
