[Asterisk-doc] (Fwd) Re: [Asterisk-Users] re hardware requirement - asterisk

[Nick Bachmann]

In the sake of making sure we don't falsely document everything, I have
some comments about this post:
> There are no RFC standards on "how" duplex settings are negotiated

Hold the phone! (bad pun, *har har*).  It is true that there are no RFCs
about Ethernet auto-negotiation, but there are no RFCs about Ethernet,
either.  Ethernet is defined in IEEE 802.3 (the CSMA/CD standard) which,
since 1995 (when the 802.3u supplement came out, my books tell me),
Auto-Negotiation has been part of the standard.  Auto negotiation is
supported for the most common copper media.
> across a cat 5 cable, etc. Most vendors support auto-negotiate, but
> somewhere near 50% of the time, its negotiated incorrectly. Part of the

If auto-negotiation fails, the link probably won't come up... the
negotiation is part of the FLP messages that also set up timing and such. 
The only situation where this could happen is on devices that don't
support auto negotiation and are manually configured for a certain speed.
> problem is that both ends of the cable attempt to negotiate at roughly
> the same time, one end locks into full while the other locks into half.

No, if they can't match, the link won't come up.  If they do, you have
some broken devices.  The only time this could ever happen is if one end
of the link was manually set at a speed.
> When that happens, the end that "thinks" full duplex is fine steps all
> over the packets being sent from the half-duplex end, causing damaged
> packets, etc. Since we're talking about UDP traffic, that's Not A Good
> Thing.

Like I said, if speeds were manually set, and the device on the other end
of the link wasn't intelligent (i.e. a cheap repeater), there would be
late collisions and lost frames.  This is why messing with
auto-negotiation on a repeater is an especially dangerous idea.
> The system will run fine if both ends are operating at half duplex,
> however bandwidth (and performance) will be limited to something below
> about 30% utilization. In many systems, that is more then adequate.
> However, on a heavily loaded system, statically locking the interfaces
> (at both ends) to full duplex will allow utilizations up towards 90%
> without degradation.

I do agree that full-duplex will speed things up tremendously in VoIP
applications.
In most applications the difference is small.  Consider this
over-simplification of how most protocols work:Alice                Bob
------------------------------------------------
Opens connection.
                     Gives Go-Ahead
Asks for data
                     (Maybe) Acknowledges asking
                     Sends Some Data
Acks data
                     Sends some more
Acks that.
                     Tells Alice that he's done
Thanks Bob
Closes connection

In this example, the protocol is half-duplex by nature, thus making a
full-duplex connection is really just benefiting the other protocols that
are sending the occasional message in the background (DHCP or NTP, for
example) rather than the connection that the user is engaging in.  But for
VoIP applications, both sides of the primary application are
connection-less and transmitting at the same time -- full duplex by
nature.
Not trying to be mean or arrogant, I just want to set the facts straight.

Nick