> > > Thank you! This gets the me disk %busy, which is one of the things I
> > > was looking for. Now, can anyone tell me how to tell what percentage of
> > > processor time is being spent waiting for disk I/O to complete?
> >
> > Uh, none?
> >
> > If there is disk I/O pending, the processor just runs a
> > different process... am I missing your question?
>
> I guess it might be useful to see the difference between
> "true" idle time and time the system couldn't do anything
> useful because it was blocked on the disk (but /should/
> have done something useful...).
You mean because the programmer didn't interleave their I/O,
and wrote to a threads interface, or some other interface
that's prone to subsystem stalling, instead? I think you get
what you pay for, when it comes to engineering skill. It's
easy to write code that stalls, and then expect to be able
to throw clock-doubled hardware at it to "fix it".
I'm always tempted to set up a company where the main
engineers have a centralized batch compile server, so as to
not slow down developement, but requiring that they run no
better than a 386SX/16 on their desktop. If they are good,
I'd give them a full 8M of real RAM, instead of 4M.
Modern bloat-ware really pisses me off; I built the bind
library the other day: the frigging thing was 4M, unstripped.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
