RE: Interframe gap

["Gerhold, Mark" <Mark.Gerhold@xxxxxxxxxx>]

The interframe gap has been used on NICs and Switches to process the
received packet and prepare for the next packet.  There are counters to be
updated, buffers to be allocated.  For example, setting up the DMA for the
next buffer takes a few clocks, and depends on whether the current packet
had an error and should be discarded.  

The interframe gap is a small price to pay.  And it's become more important
over time, since comm bandwidth is increasing faster than processing. 

Mark
-----Original Message-----
From: Drew Perkins [mailto:drew.perkins@xxxxxxxxxxxx]
Sent: Friday, May 21, 1999 3:07 PM
To: 'msalzman@xxxxxxxxxx'; 'stds-802-3-hssg@xxxxxxxxxxxxxxxxxx'
Subject: RE: A telephony carrier industry perspective



I am assuming that we get rid of the Inter-Packet Gap. This should add a
small amount of bandwidth, but I honestly haven't had a chance to work the
math. It would be interesting if someone did this. If there is still a
discrepancy, then you'd be forced to buffer and flow control in some manner.

Drew
---------------------------------------------------------
Ciena Corporation                 Email: ddp@xxxxxxxxxxxx
Core Switching Division                 Tel: 408-865-6202
10201 Bubb Road                         Fax: 408-865-6291
Cupertino, CA 95014              Cell/Pager: 408-829-8298


-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Michael M.
Salzman
Sent: Friday, May 21, 1999 1:48 AM
To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Subject: RE: A telephony carrier industry perspective



Hi Drew,

Someone earlier (Paul Bottorf I think) raised the issue of speed mismatch
between OC192 and 10 Gig, a small matter of 0.4Gbps.  Are you proposing the
use of precisely OC192 and STM64 as the underlying layer - if so, how do you
propose to pack the frames?


...stuff deleted