A second is a long time

I agree with the general point that you might be over-smoothing if you graph data with large window sizes, but you don't have to change the units on the graph as well, and probably shouldn't, since "Mbit per half second" is a confusingly nonstandard unit--- the units of measurement and the granularity of measurement don't have to be tied. An Mbit/s is a <i>rate</i>, and you can graph the rate in that unit for data points taken over a window of 1/2-second also.<p>Same as how in physics, lots of things are expressed in rates of "per second", but this does not necessarily imply that the measurement window was one second; it might be vastly larger or smaller than that. Or, with cars, you can measure the speed in mph or km/hr much more frequently than once per hour. =]

I think he's made some unfortunate mistakes with his language and use of units:<p>"<i>we could transfer 900 Mbit for a half of a second and another 100 Mbit for the other half of that second. How much data was transferred during that second? The answer is 1 Gbit per second.</i>"<p>"for" implies multiplication, i.e. 2Mbit/s for 3s transfers 6Mbit in total, 2Mbit/s * 3s = 6Mbit. The phrase "900Mbit for half a second" should probably read "900Mbit <i>in</i> half a second", giving 1.8Gbit/s (and thus supporting the point of the article).<p>"The answer is [<i>not</i>] 1Gbit per second", it is 1Gbit. It is a measure of data, not transfer rate.<p>He makes a good point though, averaging may mask important details.

The resolution of data and units the data is expressed in are orthogonal. You can still use X/second units but report 10 samples per second. Changing the units is confusing. I don't have an immediate frame of reference for how fast Mb/half-second is without doing a conversion in my head.

<i>For example, we could transfer 900 Mbit for a half of a second and another 100 Mbit for the other half of that second. How much data was transferred during that second? The answer is 1 Gbit per second.</i><p>The dimensional analysis doesn't work here. He asks for a quantity of data and answers with a transfer rate. Also it shouldn't be surprising that the instantaneous transfer rate at a given time is different than the average transfer rate over a period of time.

It's a fabulous troubleshooting effort made by the admins - "we saw we would frequently burst the 1 Mbit per millisecond rate of the so called 1 Gbit/s interfaces"

&#62; This effect is made even worse by most monitoring tools because most take samples every 5 minutes.<p>Who exactly is using monitoring tools that sample every 5 <i>minutes</i>? Goodness. Maybe I've been spoiled, but I couldn't imagine using such a blunt tool.

rrdtool[1] can be configured to "merge" measurements in various ways: by default, the pixel at (say) "4min" is an <i>average</i> of the measurements at (e.g.) 3:30, 3:40, ..., 4:20 [2], but it can also be configured to be the <i>maximum</i> (or minimum, or median) of these measurements.<p>[1] the database and graph software which underlies most (Unix?) server monitoring tools, including e.g. Munin and Cacti.<p>[2] Or the measurements at 4:00, ..., 4:50, or those at 3:10, ..., 4:00; I forgot, and it's not important.

What you need is standard deviation and other stats of all the samples.