In the last episode (Feb 04), Poul-Henning Kamp said: > Collecting number of operations and number of errors is a nobrainer. > > The timestamps cost something to make, and my plan was to only > collect them while a monitoring program is running. (Is this a good > idea ?) > > In difference from the devstat framework which measures how big a > percentage of the time a drive has one or more outstanding requests, > I think that measuring the responstime is a much more useful metric. > (comments, input, references welcome)
Can we do both? :) %busy is a nice value if only because it's a nice value to put on a status meter. If you're already timing each transaction it won't cost much. According to the devstat source, timestamping is cheap relative to actually doing math on the values (end_transaction always gets the time, but only uses the value when busy_count goes from >0 to 0). Is this right? > I pressume we also want to collect number of bytes transferred, and > I will add that in the next iteration. Definitely. What I'd like is enough statistics to be able to duplicate Solaris' iostat -x output: extended device statistics device r/s w/s kr/s kw/s wait actv svc_t %w %b r/s, kr/s reads/sec and Kbytes/sec wait = average number of transactions waiting for service actv = average number of transactions actively being serviced svc_t = average time per I/O %w = percent time there are transactions waiting for service %b = percent of time the disk is busy wait and %w may zero on FreeBSD. Do we allow queuing more transactions than the physical device supports? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message