Hello,
Am 04.03.2010 um 17:24 Uhr schrieb Josip Rodin j...@debbugs.entuzijast.net:
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
Hi,
Am 23.02.2010 um 22:36 Uhr schrieb Moritz Muehlenhoff j...@inutil.org:
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
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 possible
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
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's a
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, time
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 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 one
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 function is
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 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 in
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
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
15 matches
Mail list logo
