X-Spam-Check-By: sourceware.org Date: Sat, 10 Dec 2005 17:50:43 -0500 (EST) From: Steve Thompson Reply-To: smt AT vgersoft DOT com To: cygwin AT cygwin DOT com Subject: Re: 'uptime' command producing incorrect uptime In-Reply-To: <439B555A.80803@ineedhosting.net> Message-ID: References: <439B555A DOT 80803 AT ineedhosting DOT net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Sat, 10 Dec 2005, Jack wrote: > It appears to me that the uptime command is not producing the correct > uptime and, in fact, is running twice as fast as it should be. > [...] I've noticed a similar effect recently, and looked in the sources. If you take a look at the algorithm used by cygwin (line 467 et seq of fhandler_proc.cc in the 20051123 snapshot), you'll see that it can be wrong for multiprocessor hosts (the sum of KernelTime and UserTime is too large by a factor equal to the number of processors). It also appears to be wrong for uniprocessor hosts that have been up for more than 49.7 days because of the 32-bit value returned by GetTickCount(); my own system reported an uptime of 16 days after being up for 66 days. Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/