Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Maybe a bug?
- X-seq: zsh-workers 16391
- From: Zefram <zefram@xxxxxxxx>
- To: =?unknown-8bit?q?Ra=FAl_N=FA=F1ez?= de Arenas Coronado <raul@xxxxxxxxxxxx>
- Subject: Re: Maybe a bug?
- Date: Wed, 2 Jan 2002 22:36:41 +0000
- Cc: Zsh <zsh-workers@xxxxxxxxxx>
- In-reply-to: <E16LthG-0004w2-00@xxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <E16LthG-0004w2-00@xxxxxxxxxxxxxxxxxxxxx>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author