From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] odd clock behaviour In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-yjmbnqqmhbnznqceabfkpejokw" Date: Thu, 13 Mar 2003 11:26:49 -0500 Topicbox-Message-UUID: 7f92a60a-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-yjmbnqqmhbnznqceabfkpejokw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Timesync could be pushing your time up faster than it should. Are you running it? --upas-yjmbnqqmhbnznqceabfkpejokw Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Mar 13 11:19:22 EST 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Mar 13 11:19:19 EST 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.30.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 1C4C219A1C; Thu, 13 Mar 2003 11:19:09 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 966D3199ED for <9fans@cse.psu.edu>; Thu, 13 Mar 2003 11:18:45 -0500 (EST) Received: from athena (athena [12.34.136.114]) by athena.softcardsystems.com (8.11.1/8.11.1) with ESMTP id h2DGMvs10508 for <9fans@cse.psu.edu>; Thu, 13 Mar 2003 11:22:57 -0500 From: Sam X-Sender: To: <9fans@cse.psu.edu> Subject: Re: [9fans] odd clock behaviour In-Reply-To: <536e347f7c2fe951277441d936cfa9bc@vitanuova.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 13 Mar 2003 11:22:57 -0500 (EST) I've noticed a clock drift on my 600E. On Thu, 13 Mar 2003 rog@vitanuova.com wrote: > has anyone else experienced odd clock behaviour on their plan 9 > system? > > i'm running on an IBM Thinkpad (T22), and occasionally (not always) i > get the clock running much faster than it should (#r/rtc still gives > the correct time) > > as an example (i ran this a few minutes ago): > % echo `{cat '#r/rtc'; cat /dev/time; }; sleep 100; echo `{cat '#r/rtc'; cat /dev/time; } > 1047563747 1047629025 1047629025597639124 41354973397504 305454592 > 1047563792 1047629508 1047629508199623282 41502386389760 305454592 > % % echo `{cat '#r/rtc'; cat /dev/time; }; sleep 100; echo `{cat '#r/rtc'; cat /dev/time; } > 1047563991 1047632392 1047632392826308124 42383508857344 305454592 > 1047564039 1047632728 1047632728118785531 42485925484288 305454592 > % % % echo `{cat '#r/rtc'; cat /dev/time; }; sleep 100; echo `{cat '#r/rtc'; cat /dev/time; } > 1047564093 1047633210 1047633210610709377 42633304858112 305454592 > 1047564136 1047633742 1047633742398391924 42795741847808 305454592 > % > > i.e. /dev/time advanced by 483, 336 and 532 seconds respectively, > while #r/rtc advanced by 45, 48 and 43 seconds respectively, > all for a nominally 100 second sleep! > > the power has been plugged in continuously (i.e. it shouldn't have > invoked any funny power-saving clock changing). > > this leads to some odd effects on the user interface, not to mention > the fact that date(1) now thinks it's 11:18am tomorrow... > > cheers, > rog. > --upas-yjmbnqqmhbnznqceabfkpejokw--