From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27298 invoked from network); 2 Jan 2002 22:36:47 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 2 Jan 2002 22:36:47 -0000 Received: (qmail 14484 invoked by alias); 2 Jan 2002 22:36:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16391 Received: (qmail 14472 invoked from network); 2 Jan 2002 22:36:41 -0000 Date: Wed, 2 Jan 2002 22:36:41 +0000 To: =?unknown-8bit?Q?Ra=FAl_N=FA=F1ez?= de Arenas Coronado Cc: Zsh Subject: Re: Maybe a bug? Message-ID: <20020102223641.GB28822@fysh.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Zefram Ra?l N??ez de Arenas Coronado wrote: > Well, the matter now is that the builtin 'time' command report >wrong numbers when the measured time is slow. First of all, it tends >too much to give '0.000' as the elapsed time, even if the user or >kernel times are not 0. The elapsed time should be, at least, the sum >of user and kernel time, shouldn't it?. Strictly speaking no; on a multi-processor system one can use more CPU time than elapsed wall time, by using CPU time on more than one processor simultaneously. What you're more likely seeing, though, is differences in the way CPU time and wall time are counted. That's up to the kernel, and there's nothing zsh can do to fix it. > The other issue is a possible bug with the percentage escape >sequence. When the elapsed time is 0, it obviously reports a wrong >CPU percentage usage... It should return 0, not 18887% as it uses. Obviously the elapsed time is not zero in this case, it's just too small to show as non-zero in the output format we use. We used to cap displayed CPU usage to 100% in these cases (where elapsed time is less than CPU time), but removed that because of the multi-processor issue -- it can be correct to show more than 100% CPU usage (if the program averaged using more than one CPU at a time). -zefram