Re: Verifying CRCs
From: Rob Warnock (rpw3_at_rpw3.org)
Date: Mon, 12 Jul 2004 02:05:17 -0500
Francois Grieu <email@example.com> wrote:
| firstname.lastname@example.org (Rob Warnock) wrote:
| On why the CRC is setup to all ones, and complemented before
| sending, in many CRC systems, Rob said:
| > (Ethernet) pre-initializes the result to all one's *and* it
| > one's-complements the result before appending it to the outgoing
| > frame [thus improving its ability to detect lost runs of zeros
| > at points in the frame where the current running CRC happens
| > to be zero].
| This is to be understood as: at points in the frame where otherwise
| the current running CRC would happen to be zero, if this
| pre-initialization and final complement was not done. Including,
| for every frame, right before the data, and after the CRC.
| > Although putting multiple CRCs in a packet is done by some protocols.
| > E.g., DEC's DDCMP link-level protocol had a short, fixed-length header
| > which contained both the length of the following variable-length data
| > section *and* a CRC-16 over just the header (including that data length).
| This technique is still useful today in multidrop, half-duplex industial
| networks where nodes are memory-starved, and want to use a single
| buffer for ingoing frames and outgoing frames, while NOT loosing the
| outgoing frame content (for possible retransmission) until it was
| acknowledged. Protecting the packet header with an internal CRC
| avoids a possible problem when the node number field gets corrupted.
Note that DDCMP was also multidrop-capable [we even used it that way
back at DCA], and the node IDs were, of course, in the CRC-protected
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607