|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: clarification pleaseHi Paul, I used to agree with you on this, and that is what I had also communicated to Luben ( it was I who originally asked Julian to put in the iSCSI spec the same initial conditions for the CRC register as in ethernet), but ... based on your description, the circuit you appear to have in mind is the circuit that performs simultaneous multiplication by x^32 and division by G(x). When you go through the same reasoning for the circuit that performs only division (and thus requires you to perform the pre-multiplication by x^32 externally) your two descriptions appear not to be equivalent; and that surprised me! Please refer to my recent memo to the reflector "effect of initializing ..." for details. Vince |-----Original Message----- |From: Paul Koning [mailto:ni1d@arrl.net] |Sent: Monday, December 10, 2001 9:23 AM |To: ltuikov@yahoo.com |Cc: ips@ece.cmu.edu |Subject: Re: clarification please | | |>>>>> "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 |
Home Last updated: Thu Dec 13 01:17:42 2001 8036 messages in chronological order |