From owner-freebsd-xen@FreeBSD.ORG Tue Jan 4 01:50:12 2011 Return-Path: Delivered-To: freebsd-xen@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5896F1065670 for ; Tue, 4 Jan 2011 01:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE5A8FC0C for ; Tue, 4 Jan 2011 01:50:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p041oCDQ003522 for ; Tue, 4 Jan 2011 01:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p041oCaQ003521; Tue, 4 Jan 2011 01:50:12 GMT (envelope-from gnats) Date: Tue, 4 Jan 2011 01:50:12 GMT Message-Id: <201101040150.p041oCaQ003521@freefall.freebsd.org> To: freebsd-xen@FreeBSD.org From: Greg Holmberg Cc: Subject: Re: kern/153620: Xen guest system clock drifts in AWS EC2 (FreeBSD 9.0-CURRENT i386 T1-micro) X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Greg Holmberg List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 01:50:12 -0000 The following reply was made to PR kern/153620; it has been noted by GNATS. From: Greg Holmberg To: FreeBSD PR kern/153620 Cc: Subject: Re: kern/153620: Xen guest system clock drifts in AWS EC2 (FreeBSD 9.0-CURRENT i386 T1-micro) Date: Tue, 4 Jan 2011 02:10:29 +0100 > On Sun, Jan 02, 2011 at 03:16:52AM -0800, Colin Percival wrote: > > 3. Did the clock _drift_, or _jump_? > I started a new VM (ami-5b82b72f) using the latest available 2011-01-01 code. The problem -- the system clock losing 2200 seconds -- is still present. Last night, the clock in the new AMI seems to have lost 2200 seconds twice in a 14 hour idle period. The system clock seemed to be stopped before login. It started incrementing smoothly again when I logged in to check on the system in the morning. The system clock itself only managed to advance 14 minutes (837 seconds) overnight. After subtracting the accumulated drift from the previous evening's work, we see that the offset with a nearby NTP server at the moment I logged in was 4398.107077. This value is very close to 2 * (2^41) / 1e9. system clock NTP source ... 20110103-141513UTC 0.437444 # drift is gradual, linear 20110103-141613UTC 0.438124 # clock is running slow 20110103-141713UTC 0.438786 20110103-141813UTC 0.439584 20110103-141914UTC 0.440247 20110103-142014UTC 0.440957 20110103-142114UTC 0.441663 20110103-142214UTC 0.442313 20110103-142314UTC 0.443064 20110103-143711UTC 4398.550141 <--- 4398.107077 second difference 20110103-143811UTC 4398.550755 between slow clock and NTP src ... I have noticed that it only seems to happen when there are no active login sessions. I have seen a large jump in system time happen with a monitor script backgrounded from a single login shell, sometime after logout. I have seen it happen when the script runs in the foreground of a window in GNU screen. I have not been able to provoke it during an interactive login session. Maybe I just need to be more creative. Best regards, Greg Holmberg