home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / modems / 17205 < prev    next >
Encoding:
Text File  |  1992-11-24  |  1.5 KB  |  33 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!cis.ohio-state.edu!mstar!mstar!bob
  3. From: bob@MorningStar.Com (Bob Sutterfield)
  4. Subject: Re: Efficient CRC routine?
  5. In-Reply-To: jroth@aegis.or.jp's message of 23 Nov 92 14: 48:38 GMT
  6. Message-ID: <BOB.92Nov23233408@volitans.MorningStar.Com>
  7. Sender: news@MorningStar.Com
  8. Nntp-Posting-Host: volitans.morningstar.com
  9. Organization: Morning Star Technologies
  10. References: <1394@minya.UUCP> <By5Hrs.GI3@wsrcc.com> <3246@aegis.or.jp>
  11. Date: Tue, 24 Nov 1992 04:34:12 GMT
  12. Lines: 19
  13.  
  14. In article <3246@aegis.or.jp> jroth@aegis.or.jp (Joel Roth) writes:
  15.    wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes:
  16.       jc@minya.UUCP (John Chambers) writes:
  17.          I've generally dismissed the use of CRCs in software, because
  18.          the only algorithm I'd seen to generate (or check) them were
  19.          so incredibly slow (shifting the bits out of each byte,
  20.          plugging each into a polynomial, and all that) that the
  21.          performance hit was totally out of the range of
  22.          acceptability.
  23.  
  24.       Its only one or two lines of C depending on how you count it.
  25.       Any good compiler will render it into 10 or less instructions.
  26.  
  27.    Some kind soul responded to an earlier query about this with code
  28.    for using a lookup table instead of calculating the values with
  29.    bit-shifting. Happy to post it if you like.
  30.  
  31. See Appendix B of RFC-1331.  The lookup table is fairly compact, and
  32. the algorithm is plenty fast.  Of course, hardware is always faster...
  33.