[comp.arch] byte rate measurement semantics: MB/s vs. B/uS

egt@hprnd.HP.COM (Eric Tausheck) (03/02/90)

   I posted this in response to other strings in this notesgroup
   discussing burst rates versus sustained rates and the reliance on the
   ambiguous "MB/s" unit of measurement for backplane data rates.  I
   apologize if this is just the latest installment of a perennial
   time-wasting subject...

Is a "mega byte" 1,000,000 (10^6) or 1,024,000 (10^3 x 2^10) or 1,048,576
(2^20) bytes?  <-- this is a rhetorical question, particularly since
there is a way to not have to care what the answer is when considering
units of byte rate measurement.

Personally I think (and usually assume everyone agrees) that MB/s =
1,000,000B/s.  I think that a "MB" should only mean 2^20 in reference to
memory addresses (e.g. amount of memory in a system or, on a disk - oops,
didn't mean to open this can of worms :-)).  However, there are those who
apply the base-2'ism to data rates as well:  the error is not significant
(at around 5%) but would be better to avoid.

I wish we (as in, the world) would (have) use(d) the units
"bytes/microsecond" instead.

The units of B/uS seems to imply a measurement made for a short period of
time and is therefore less likely to be confused with sustained
throughput rates (at least for those of us familiar with the things, like
bus arbitration latency, that can significantly degrade actual sustained
rates down from the to-often quoted burst rates).

The other advantage to B/uS is that nobody (I hope) interprets
"microsecond" to be 2^(-20) or 1/(1024x1000) seconds and so the dispute
over how many bytes in a "mega byte" can continue independently without
contributing to misunderstanding in quotes of data rates.

Anyone else vote for "B/uS"?

A more useful endeavor would be to standardize on how to describe typical
maximum sustained byte rates accurately and fairly - much more
challenging because of the number of variables involved (depending on the
bus or whatever, under consideration).


#include <std.disclaimer>

Eric Tausheck, Hewlett Packard
egt@hprnd.hp.com