[Asterisk-Users] What business IP phone to use

[Rich Adamson]

> Aha, micro seconds in networking terms is normally written usecs or us
> (actually it's the greek letter mu as in ulaw) rather than ms which are
> milliseconds seconds - what had me puzzled was that it was stated that this
> could harm the voice path!
> 
> > The difference can also cause unnecessary delays and therefor echo in the
> > path. For example, procurve switches typically have 13ms switching time,
> > the high-end netgears about 21ms. As soon as you stack a couple of
> > switches you are talking 26ms vs 42ms extra delay in the path!
> 
> There is then only 8 usecs between the two switches, how on earth would this
> make any difference to the voice path at all? Let alone induce any echo... 
> 
> Obviously the originally poster didn't understand the difference. And based
> on this, he's probably advising people not to use Netgear switches for
> voice, oh dear.  

I'll jump in here to make a couple of comments relative to ethernet switches.
Not all switches are created equal!!!

If you take the cover off a switch, write down the part numbers for the
chips used, and read the doc on those chips, you'll see major differences.
(We've actually tested several switches over the past several years in
real customer's networks as well.)

Many entry level switches on the market have only minimal buffering for
inbound and outbound packets. Its not uncommon for output buffers to be
limited to one or two packets, and as a user, you can't chnage it.

Port congestion frequently shows up when two (or more) devices connected
to a switch (assume 100 mbs for now) try to communicate via a single
upstream port (assume 100 mbs for now). The instantanous offered traffic
is essentially 200 mbs, and the switch is expected to send that traffic
out via a 100 mbs port. For those devices with minimal buffering, packets
will be dropped. For newer switches with deeper buffers, "some" packets
will be held up in the chip's internal queue waiting to get on the
outbound port's wire. The delay in the buffer will become jitter, and
depending upon exactly how many ports are contending for the outboud
port, the jitter _can_ become noticable. (That _is_ one of the reasons
why some switch vendors support QoS.)

One can talk about "wire speed throughput", etc, and it doesn't mean
squat. Those are all marketing and sales words, not engineering specs.

There are plenty of very well known switch vendors that purchase switches
from other manufacturers and put their names on the front covers. Some
of those have characteristics as noted above, while others manage the
buffering and queuing much better then what their marketing/sales words
imply.

Its fairly common to see engineers in large corporate networks using
workgroup switches to consolidate traffic from multiple wiring closets,
and not pay any attention whatsoever to "dropped packets" in the switches.
That's about the time when senior mgmt intervens and asks an external
company to assess their network performance to resolve the internal 
fingerpointing. Our company has completed many of these.

The _only_ way to know for sure what a switch is doing (eg, dropping pkts)
is to ensure the switches have some form of network management. Even the
simple Dell 2708 (eight port gig switch for $100) has "some" level of
mgmt in it. Certainly not the best, but at least you can identify some 
issues.

With the pricing drops that we've all seen over the last couple of years,
its fairly easy to find managed switches at very reasonable cost. I'd
_never_ using unmanaged switches in any environment where critical
application data flows across the net, and I'd suggest voip traffic
represents "critical" traffic in all production networks.