Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Mar 1999 07:37:48 -0500
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        tlambert@primenet.com, hasty@rah.star-gate.com, wes@softweyr.com, ckempf@enigami.com, wpaul@skynet.ctr.columbia.edu, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Gigabit ethernet -- what am I doing wrong? 
Message-ID:  <199903221237.HAA38608@whizzo.transsys.com>
In-Reply-To: Your message of "Sun, 21 Mar 1999 23:40:20 PST." <199903220740.XAA16463@apollo.backplane.com> 
References:  <199903220545.WAA10719@usr01.primenet.com>  <199903220740.XAA16463@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> :>     The solution to this at MAE-WEST was to clamp down on the idiots who
> :>     were selling transit at MAE-WEST and overcommitting their ports, plus
> :
> :With respect, technology should operate in the absence of human
> :imposition of policy.  It should have been technically impossible
> :for the idiots to successfully engage in the behaviour in the first
> :place, and if it wasn't, then that's a design problem with the
> :gigaswitches.
> 
>     With respect, you are assuming that the problems can be solved trivially. 
>     These are *NOT* trivial problems.  Very not trivial problems.  Not even
>     *CLOSE* to trivial problems.  I can't repeat this enough times.

Alternatively, you buy hardware that doesn't have pathological performance
in certain operating regions.  The head-of-line blocking experienced in the
DEC FDDI gigaswitches is a classic and well-known characteristic of that
type of switch fabric.  It has other interesting characteristics, such
as having to work hard to avoid deadlocking the switch fabric when multiple
input ports are trying to deliver a multicast/broadcast frame to to
overlapping output ports.  You have to implement partial completion in
the the crossbar fabric to avoid this problem.

The human intervention that Matt references wasn't tuning the operation of
the swtich directly; it was arranging to avoid the part of the operating
regime where the swtich exhibits poor performance.  If the switch wasn't
broken, you wouldn't have to indirectly engineer loading to avoid head of
line blocking.  But in any case you still have to do large-system type
engineering to avoid the 10 pounds of packets in a 5 pound sack problem.

You just can't think of these switches in the context of a general purpose
computer with busses and peripherals.  High-performance switches and 
routers are fundamentally architecturally different beasts than the the
FreeBSD box on your desk.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903221237.HAA38608>