NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/dcom/cellrel/444

Text File | 1992-08-31 | 1.7 KB | 43 lines

Newsgroups: comp.dcom.cell-relay
Path: sparky!uunet!decwrl!sgi!rigden.wpd.sgi.com!rpw3
From: [e-mail] (Rob Warnock)
Subject: Re: followup to reordering thread
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 1 Sep 1992 05:08:02 GMT
Lines: 32

[e-mail] (Brian Carpenter   CERN-CN) writes:
+---------------
| Another (very minor) disagreement with Craig. You should compute
| the AAL CRC on the fly as the cells arrive, not after the last cell.
| (I'm assuming you have hardware assist of course.)
+---------------

Basically, I agree with you. One doesn't want to waste either the bandwidth
or the latency of another pass over the data just for the CRC. However, there
exist reasonable potential architectures for an ATM interface for which one
might *not* want to do the CRC "on the fly" at cell-arrival time, since that
involves fetching the old CRC from the per-VCI "context", shifting in the
new stuff (8, 16, or 32 bits at a time), and then saving the new CRC in the
per-VCI "context" -- once per cell.

Depending on the bandwidth and latency to the VCI context memory, and on
the cost of the SAR part of the interface, one might wish to defer the CRC
calculation until the whole packet is being DMA'd to the host and do it
in fly-by mode then (without context changes), for example. Costs nothing
in added bandwidth or latency, and is potentially cheaper. (But also has
the limitation that one must be willing to go ahead and DMA a packet with
a potentially bad CRC. Tanstaafl.)


-Rob

-----
Rob Warnock, MS-9U/510        [e-mail]
Silicon Graphics, Inc.        [phone]
2011 N. Shoreline Blvd.
Mountain View, CA  94043