Re: Interframe gap
- To: Denis Beaudoin <dbeaudoin@ti.com>, "Gerhold, Mark" <Mark.Gerhold@unisys.com>
- Subject: Re: Interframe gap
- From: Rich Seifert <seifert@netcom.com>
- Date: Fri, 21 May 1999 18:26:32 -0800
- Cc: Drew Perkins <drew.perkins@lightera.com>, "'stds-802-3-hssg@majordomo.ieee.org'" <stds-802-3-hssg@majordomo.ieee.org>
- In-Reply-To: <3745CB44.1C0B9B9D@ti.com>
- References: <8E37550684B3D211A20B0090271EC59D0176B01C@tr-exchange-1.tr.unisys.com>
- Sender: owner-stds-802-3-hssg@majordomo.ieee.org
At 4:08 PM -0500 5/21/99, Denis Beaudoin wrote:
>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.
>
It may be a design issue, but it is *precisely* the reason why the IFG was
included in the first place. There is a certain amount of housekeeping that
is performed between frames, and the IFG is there to provide some
"breathing room".
I agree that it was a mistake to assume, in a repeated LAN, that the
receiver would always see the full IFG as generated by a transmitter, but
it was NOT unreasonable to assume that there would be *some* IFG available
for housekeeping functions. It was never the intent of the standard to
require receivers to live with zero IFG. Yes, it is a design issue, but the
IFG supports a practical design.
--
Rich Seifert Networks and Communications Consulting
seifert@netcom.com 21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 395-1966 FAX
"... specialists in Local Area Networks and Data Communications systems"