Re: clarification please

[Paul Koning <ni1d@arrl.net>]

>>>>> "Luben" == Luben Tuikov <ltuikov@yahoo.com> writes:

 Luben> Hello, I have a question.  The draft says: - the CRC register
 Luben> is initialized with all 1s (equivalent to complementing the
 Luben> first 32 bits of the message)

 Luben> Those two are NOT equivalent, e.g. if the message started with
 Luben> 32 1's then complementing will yield 32 0's, and this is not
 Luben> like ``initializing'' the CRC with 32 1's?

 Luben> Does this mean that the first 32 most significant bits of the
 Luben> message are complemented, or does it mean that the message is
 Luben> _prefixed_ with 32 1's and then the division starts?

 Luben> If it means prefixing, could you please use that word, as is
 Luben> customary in computer science literature... and to diminish
 Luben> ambiguities...

It does NOT mean prefixing.  The wording about "complementing" comes
directly from the Ethernet spec, and is common to all recent CRC
algorithms. 

The wording in the spec implies that the following two descriptions
are equivalent:

1. Initialize the CRC register to all 1s, then process the data
2. Initialize the CRC to all 0s, complement the first 32 bits of the
   data, then process it

Consider a packet that begins with 32 bits of 1.  It's obvious that
the second description will result in an all-zero CRC register after
those 32 bits have been processed.

The first description has the same effect.  For each bit, you shift
out a 1 from one end; that is XORed with the data bit, resulting in a
zero shifting into the other end, and the other bits remaining the
same.  Do that 32 times and you end up with an all-zero CRC register,
just as for description 2.

Incidentally, this implies that this CRC will not detect the insertion
of any number of 0 bits immediately after a packet beginning of 32
bits of 1.  That's a fine tradeoff, since that error pattern is a lot
less likely than simply having extraneous 0 bits at packet start --
which is why the complement was introduced into datacomm CRC
algorithms. 

     paul