home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dcom.cell-relay
- Path: sparky!uunet!stanford.edu!ames!sgi!rigden.wpd.sgi.com!rpw3
- From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
- Subject: Re: AAL5-CRC32
- Message-ID: <pee6ubc@sgi.sgi.com>
- Sender: rpw3@rigden.wpd.sgi.com
- Organization: Silicon Graphics, Inc. Mountain View, CA
- Date: Fri, 4 Sep 1992 18:30:18 GMT
- Lines: 82
-
- de@fokus.gmd.de (Dirk Elias) writes:
- +---------------
- | I've got some questions and comments concerning AAL5-CRC32 calculation.
- |
- | 1. Does anybody know something of fast software algorithms to compute CRC32?
- | The fastest I know is based on look-up tables and will take 16 instructions
- | per 32 bit. This results in about 70 MIPS for a bitrate of 150 Mbps!
- +---------------
-
- Well, the fastest byte-at-a-time method I know (with a 1024-byte table) is:
-
- for (i = 0; i < size; ++i)
- crc = (crc >> 8) ^ table[ (crc & 0xff) ^ data[i] ];
-
- That's about 9 cycles/byte (or more), or 36 cycles/word. I suppose you could
- cut that in half if you used a 256 KB table and did it 16 bits at a time.
-
- +---------------
- | Definitely to slow. So, if there is no possible software solution, let's
- | take a look on the hardware, exclusively for AAL5-CRC32. You will need a
- | CRC-chip and glue-logic, consuming "lots" of board space and wasting power
- | for almost nothing!
- +---------------
-
- Why do you say "lots" of board space? A similar parallel algorithm can be
- done is a small gate array, in less space than the buffers to drive the
- host bus.
-
- +---------------
- | ...there are two major ways to calculate CRC by hardware. One is "on-the-fly"
- | while receiving a cell from the ATM layer... I just want to point out that
- | "context-switching" after every cell is lots of work, just to calculate CRC.
- +---------------
-
- BUT YOU HAVE TO DO IT ANYWAY! You have to extract a *lot* more "context" per
- cell than just the previous CRC. You need the buffer pointers & counts (or
- limits), descriptor-ring pointer (for some architectures), etc. The 32 bits
- for the CRC is "just" another pair of "by 16" SRAMs, indexed the same way
- as all the rest.
-
- +---------------
- | Has anybody knowledge of CRC hardware, performing "context-switching" on
- | it's own? (something with integrated memory and some kind of control
- | interface)
- +---------------
-
- Again, you have to do it anyway. Tacking the CRC task on the side is a fairly
- small thing...
-
- +---------------
- | the other is "fly-by" upon transmitting a reassembled packet from the AAL
- | layer to the next higher layer... If I would like to have about 100 VC's
- | using AAL5 and I had to store every packet till it's completed, I would
- | have to allocate 64 KBytes for every VC.
- +---------------
-
- Memory's cheap.
-
- +---------------
- | Since there is still no CPCS-PDU header defined for AAL5, where a packet-size
- | information could be transmitted, I have to assume the maximum CPCS-PDU size!
- +---------------
-
- Not necessarily. You could allocate "chunks" of buffer as the cells arrive
- (a simple linked list).
-
- +---------------
- | This would result in several MBytes of interface-board memory. (Sometimes
- | I remember that S-BUS card size in my nightmares)
- +---------------
-
- It's small, but so is "several MBytes" of RAM.
-
-
- -Rob
-
- -----
- Rob Warnock, MS-9U/510 rpw3@sgi.com
- Silicon Graphics, Inc. (415)390-1673
- 2011 N. Shoreline Blvd.
- Mountain View, CA 94043
-
-