On Mon, 18 Apr 2005, Marc Lehmann wrote: > On Mon, Apr 18, 2005 at 11:26:36AM +0200, Dag Wieers <[EMAIL PROTECTED]> > wrote: > > > dstat also has an option to print a report less frequent, but it only > > > does a random sampling (i.e. "vmstat 7" outputs a report for 7 secodns, > > > every 7 seconds, while dstat outputs a report for the last second, every 7 > > > seconds, which is much less useful, as the variance is very high). > > > > Hmm, are you sure about what you're saying ? > > No, I was just guessing form the output. with, say, "vmstat 7", I get, > in the disk/io r column, values like 723, 726, 850 etc., while a dstat 7 > running in parallel tends to give me values like 506k, 1003k, 502k and so > on, while I was streaming a few files on my vidoe recorder system, and so > it looked as if vmstat would give me averages while dstat doesn't.
Well, maybe it is confusing that when vmstat only show you the average over a 7sec period, dstat shows you if these average had peeks or lows. I've always been very interested in adding the deviation too somehow, but the line-based interface makes this almost impossible. And it's not like I have plenty of room :) I guess the documentation could clarify this better, what these intermediate updates really are. Since it is an average over the completed delay time and not a per second average this may be confusing. The advantage of the current implementation is that it tends to get closer and closer to the resulting average. > However, dstat is definitely doing averaging, as further testing showed > (dstat is my new toy...). The intermediate updates are very nice when you need averages for a longer delay, but still want to see how it evolves. My experience is that during these tests you are able to determine other problems or a faulty setup. (eg. if you expect steady results and you see peaks and lows). Of course you can run 2 dstats, one with a 7sec delay, and one with a 1sec delay. But I use dstat together with screen to monitor multiple nodes in a cluster and having 2 dstats for each node limits the overview. In fact, I wrote dstat because I didn't want a vmstat, ifstat and iostat per node and I wasn't interested in most of the values. Too much information limits the capability to relate values or see trends. > It's possible that the difference in starting time of dstat and vmstat did > the trick, as I can reproduce the different behaviour in only in about 4 > out of 10 cases. If you want to compare dstat with vmstat, it's better to first start dstat. And then start a vmstat at the right interval to get them in sync. dstat has a small delay (that seems to vary more depending on the job scheduling of the system). > > I think it does. > > It does indeed. I still wonder why vmstat tends to give me nicer numbers, > though, but it might just have been luck. It shouldn't give 'nicer' numbers. In fact in case both are not synchronized, if you add the numbers they should be the same. (dstat tends to be a bit more precise in some cases). Could you give me the output of what you mean with 'nicer' ? Is this a rounding thing, a synchronization problem, or something else ? -- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
