diagnosing network speed bottlenecks [SOLVED]

[Jerry Feldman]

Basically, (as you did mention in the last paragraph) data
communications are almost always serial. However dialup modems are
capable of transmitting synchronized signals. Normally, when dealing
with dialup modems, you are dealing with a byte oriented protocol where
each 8-bit byte is framed with a stop and start bit (actually I don't
recall whether it is an extra stop of start such that an 8-bit byte
becomes 10 bits on the line). But modems are also capable of doing
synchronized traffic that does not require a stop and start bit. And, at
speeds above 1200 bits per second, the actual line protocol between the
2 modems is quite different to achieve the compression and higher
effective bit rates, but the computer itself sends the bits to the modem
in serial fashion.  Actually, it really does not matter because very few
of us actually use a phone modem any longer.

On 10/01/2009 09:40 AM, Ben Scott wrote:
> On Wed, Sep 30, 2009 at 9:47 PM, Greg Rundlett (freephile)
> <greg at freephile.com> wrote:
>   
>> Sorry, I was misreading Comcast service as being measured in megaBytes
>> (big B) while it's actually stated in megabits (little b).
>>     
>   Be aware there's no standard symbol for bytes, bits, or octets.  The
> "B = byte, b = bit" convention used by some is by no means universal.
> When dealing with communications, I always spell out "byte" or "bit",
> for this reason.
>
>   In communications technology, speeds are almost always given in bits
> per second.  Further, prefixes like "mega" and "kilo" are almost
> always the actual SI prefixes, not the "binary prefixes".  In other
> words, one kilobit/sec is 1000 bits per second, not 1024 bits per
> second.
>
>   For those interested in history, there is a technical reason for
> this difference:
>
>   Computers don't process bits, they process machine words (e.g., on
> i386, a word is 32 bits).  Storage devices generally store blocks.
> For example, IDE and SATA hard disks work with blocks of 512 octets.
> So the machine is actual incapable of working with "10 bytes" or "1000
> bytes" as unit quantities.  If you want 1000 octets of SATA disk, the
> computer had to work with two blocks totaling 1024 octets.  So working
> in bytes, with unit quantities based on multiples of 2, makes sense.
>
>   (Which is why computer scientists adopted a bastardized version of
> the SI prefixes: They needed prefixes.  SI already had a system of
> prefixes, in base ten.  The base ten multiples weren't useful, but the
> prefix names were handy.  In retrospect, that was a bad move, as the
> double meaning of the prefixes has caused endless confusion since.
> It's not always clear by context even when everyone is being honest.
> And salesmen always use the meaning that makes their product sound
> better.)
>
>   Communications equipment, on the other hand, is almost always serial
> in nature.  You send a bit, then another bit, then another bit.  It's
> up to higher levels in the communications stack to impose framing.
> With dial-up modems, you have to tell the system how many bits are in
> a byte, and how many stop bits come after each byte, because those
> concepts don't exist in the serial data stream itself.  In the world
> of cable modems, that's all handled by the DOCSIS specs, but on the
> wire, it's still fundamentally a serial data stream.
>
>   So the transceiver works in bits per second.  There's no "byte" at
> that level.  "1024 bits" isn't anything in particular.  "1000 bits"
> isn't anything in particular, either, but the SI system uses multiples
> of ten, so that's what the telecom world adopted.  (And the telecom
> world was already using "bits per second" for voice encoding back when
> the computer world was just getting started -- there was no standard
> for word and byte size back then.  If they could have seen into the
> future, they might have picked the "binary prefix" system instead,
> just to be consistent with the major application.)
>
>   


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20091001/0d66b1df/attachment.bin