Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Content-Type: text/plain; charset="us-ascii" From: Emil Briggs Reply-To: emil@baymountain.com Organization: Baymountain, Inc. To: cygwin@cygwin.com Subject: Processor time bug in fhandler_proc.cc Date: Thu, 29 Aug 2002 17:56:37 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208291756.37044.emil@baymountain.com> I think there is a bug in fhandler_proc.cc in the way the results of calls to NTSTATUS ret = NtQuerySystemInformation (SystemProcessorTimes, (PVOID) &spt, sizeof spt, NULL); are handled. Specifically the value of spt.IdleTime.QuadPart is already included in spt.KernelTime.QuadPart but the code to compute the uptime doesn't take that into account and adds in the idle time again as shown below. uptime = (spt.InterruptTime.QuadPart + spt.KernelTime.QuadPart + spt.IdleTime.QuadPart + spt.UserTime.QuadPart + spt.DpcTime.QuadPart) / 100000ULL; Because the Idle time is already included in the KernelTime the computed uptime is always too large. In the case of a lightly loaded system it's about a factor of two and is easy to verify by just letting the system sit for a while and then checking the reported value from /proc/uptime against wall clock time. This also affects /proc/stat entry for CPU usage where you can see that the system value is always larger than the idle value. Regards Emil -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/