Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Interframe gap




Mark, The interframe gap is not to be used as processing time, this
leads to problems like the 'tailgate scandal' where certain NIC cards
could not see frames back-to-back because of IPG erosion on repeaters.
The standard RX function can have the next RX frame on the event following
CRS deassertion. Runout which you speak of (the time required for the device
to complete its current rx operation before it starts the next rx) is 
a design issue not a standard issue.

For more info on 'tailgate scandal' perform a search on the WEB, there
is plenty of documents about the subject.

Gerhold, Mark wrote:
> 
> 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

-- 
=====================================================================
| Denis R. Beaudoin             _          Email : dbeaudoin@xxxxxx |
| Network Business Unit       _| '-.       Phone : 972-480-3287     |
| Texas Instruments           \,  _}       Lab   : 972-480-3277     |
| PO Box 660199  M/S 8650       \(         FAX   : 972-480-2611     |
| Dallas, Texas 75266-0199                                          |
| Courier:  8505 Forest Lane  M/S 8650   Dallas, Texas 75243, USA   |
=====================================================================