🚀 go-pugleaf

jsims@uswest.com (John Sims) writes:
+---------------
| I'm curious what people feel is the correct way to report FDDI
| (or for that matter data comm systems in general) throughput.
| 
| Now the raw data rate of FDDI being 100 Mbps or 100,000,000 bps.
| If I report N KB/sec does that mean N*1024 bytes/sec or N*1000 bytes/sec.
...
| It strikes me that since the raw data rate does not have 1024 factored into 
| it anywhere the throughput result shouldn't either. I have three different
| versions of ttcp here, each does this a different way.  Any opinions?
+---------------

This has been discussed at great length before (it's a terribly religious
issue), but my personal opinion is: The whole 1024 versus 1000 thingy is a
mistake that we in the computer science community made, and now can't easily
undo. It was a way of speaking conveniently but sloppily of large numbers
which were powers-of-2, *especially* sizes of data in the memories of
binary-addressed machines. [The issue didn't arise in the old decimal or
BCD-addressed machines!]

I realize I'm dating myself, but when I started playing with computers, we
still spoke of 131072 as "131 K", not "128 K". But only a few years later,
if you said "131 K", other computer people would look at you and say, "Hunh?"

However, the physics, engineering, and data communications communities,
not having any objects in their domains which were naturally powers-of-2,
assumed then and continue to assume now that the meanings of "K", "M", etc.
are "1000", "1000000", etc., as they always have been. For example, a DS-0
PCM voice channel (or an ISDN B-channel) is 64 Kb/s, that is, *exactly*
64000 bits/sec (it's an 8-bit sample every 125.0 microseconds).

And that inconsistency was o.k., until we started to communicate (later,
"network") data which came from power-of-2 sized structures. The computer
guy sees, "Well, that 2**20-byte structure which we call '1 MB' was moved in
one second, so that must be 8 Mb/s." (B = byte, b = bit.) And the datacomm
guy sees that 8388608 bits moved in one second, so that's 8.4 Mb/s (or 8.39
Mb/s, whatever precision is needed).

My *personal* opinion [with which others at SGI differ] is that data
communications or networking rates should be reported in "real" -- that
is, engineering or physics -- units, since coax & fiber cables don't
come in powers-of-2 capacities. However, having said that, I have *not*
pushed to have the local version of "ttcp" changed to use real units,
for two reasons:

1. "ttcp" is mostly used for benchmarking, and it doesn't really matter
   all that much what units are used for a standard benchmark, as long
   as everyone reports in the same units. Both of the "standard" versions
   (BRL's and SGI's) report by default in units called "KB/s", which is
   bytes/1024/seconds.

2. If "the computer networking community" ever decides to shift enmasse to
   true engineering units for communications rates, our reported throughput
   number will only get *better* by 2.4%. [And that's a much more desirable
   situation to be in than the opposite!]

So I continue to run "ttcp" and brag about funny 1024-scaled "KB/s"...


-Rob

p.s. But I *don't* divide large "ttcp" KB/s answers by yet another 1024 and
call them "MB/s", though some people (and some programs) do. Leave bad enough
alone.

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043