[Discuss] Dev Ops - architecture (local not cloud)

[bogstad at pobox.com (Bill Bogstad)]

On Sat, Dec 14, 2013 at 12:48 AM, Edward Ned Harvey (blu)
<blu at nedharvey.com> wrote:
 This is the behavior of other
>> network switching topologies (in particular IB and FC) but it is not the
>> behavior of Ethernet.  Because Ethernet is asynchronous, buffered, store
>> and forward, with flow control packets and collisions...  Sure, the most
>> intelligent switches can eliminate collisions, but flow control is still necessary,
>> buffering is still necessary...  You have network overhead, and congestion
>> leads to degradation of efficiency.  Each of the 10 clients might be getting 5%
>> of the bandwidth, which is an ungraceful degradation.
>>
>> Ed:  Can you define what you mean by "collision" in the context of an
>> Ethernet switch where twisted pair wiring is being used?   (i.e. any
>> of the commonly used *BaseT wiring systems)
>
> Did you stop reading at the first instance of the word "collision?"  Because I think I went into that immediately thereafter.  Switches eliminate collisions (although hubs did not) but everything else is still relevant.

I read everything that you wrote.   Including the statement "most
intelligent switches".    I assumed that the modifiers you applied to
switches  meant something.   I was hoping that you would tell how they
differed from regular generic Ethernet switches.  Or perhaps you were
referring to ancient thinnet or thicknet Ethernet switches where
collisions could  place on the individual segments.  Mostly I was
trying to suggest that talking about collisions in the context of
Ethernet in this century is not particularly useful.   It may very
well be that all of the other ills that you ascribe to Ethernet are
true, but there is really no reason to talk about collisions anymore.

Bill Bogstad