[Asterisk-Users] LAN card

[Rich Adamson]

I've read several other responses to your post...

> Just an experience to run by all you experts out there. I have started to
> put more VOIP calls into Asterisk, most are pass-through calls and some are
> terminating on the Digium card to PSTN. Whenever I get to 10 calls or more,
> I would start to get choppy sound. I tried to ping other IP addresses from
> the Asterisk and noticed a big packet loss in the vincinity of 7% to 10%,
> but when there is no call, pinging the same IP addresses reap no packet
> loss. It seems that the VOIP packets are causing congestion of some kind on
> the LAN. I am using 100M, full duplex. I tried an autonegotiated switching
> hub as well as a more sophisticated managed switching hub and forcing the
> connection to be 100M Full Duplex, non negotiated. However, I reaped the
> same result.

It is "very" common to see mismatched duplex settings cause the above. Since
the auto-negotiate feature of nic cards and switches are _not_ RFC standards,
the feature will set the duplex incorrectly about 50% of the time. If you
manually lock (statically define) "both" the managed switch interface AND
the nic card on the asterisk system to full-duplex, the problem is likely
to disappear. (Locking the switch interface to 100 meg is more then sufficient
for the Speed setting, as that parameter is easy to auto-negotiate correctly
on the nic-card end.)

Locking the nic card duplex settings on linux systems can be almost impossible
as the utility to do that is not well known, AND, since the duplex setting
is 100% dependent upon exactly "how" the original nic card manufacturer
implemented it (and linux drivers), the utility does not work on some nic cards. 
I can't tell you which ones work and which don't since there are so many different 
old/new nic cards on the market. (I know for an absolute fact that manufacturer 
name recognition has nothing to do with it either.)

Technically, the quality issue is not related to 10 vs 100. Rather, it relates
to a consistent flow of rtp-udp packets "both" inbound and outbound from the
nic card. When the nic card and the switch interface auto-negotiates to the 
half-duplex mode, traffic can only flow in one direction at a time and both
ends are playing by the same duplex rules. That's not a big deal for a small
number of rtp sessions, but it does become a very big deal as the number of rtp 
sessions increase. A 100 meg full duplex interface can (in theory) handle
roughly 500-to-1,000 rtp sessions. (And before every techie jumps all over that
statement, yes there are lots of unstated assumptions in that statement. But 
regardless, the number is very large.)

The worst possible configuration for data flows (regardless of whether its rtp
traffic or something else) is one interface set to full-duplex and the other
interface set to half-duplex. When that happens, the two ends are playing by
different rules, and the full-duplex end is stomping all over the packets being
sent by the half-duplex end. In the rtp (udp) world, there are no retransmissions
of those damaged packets and therefore quality decreases rapidly with an increase
in total traffic volume. (Since rtp traffic through * is very symmetric, its
quality is impacted at much lower traffic volumes compared to any other non-
symmetric data flows.)

Managed switches and managed nic interfaces are an absolute "must have" if you
want to consistently achieve good quality and reasonably high bandwidth. There
are lots of auto-negotiate implementations that can get it right, but those are
highly dependent upon the exact combination of selected nic cards AND switches.
The majority will be unpredictable from one reboot to another though, and by
far, the majority of sys admin's don't have a clue why things work well one time
and not the next. (It doesn't help when there are so many different combinations
of nic cards and linux distributions, and "seeing" what is really going on within
a specific combination can be almost impossible.)

It should also be noted that on most nic & switch interfaces, simply unplugging
and reconnecting that cat 5 cable will cause the interface to auto-negotiate the
duplex settings. Therefore, there is no real need to reboot most linux systems
that are left in auto-negotiate mode. The one exception to that statement is that 
some nic card's duplex settings "cannot" be easily changed manually without a 
reboot (eg, the new settings will not take effect until the next reboot).

Some things you can try that might help identify such issues...
1. run /sbin/ifconfig and check "collisions: xxxx". If a number exists, the nic
   is "probably" running half-duplex. If the value is 0's, you can't assume the
   interface is running full-duplex; some nic card collision values are not
   accessible by ifconfig.
2. download the free "Qcheck" from netiq.com and run multiple instances of this
   helpful performance tool from different machines simultaneously. (Qcheck will
   send udp or tcp data flows in "one" direction at a time; reversing the IP
   addresses in their user interface tool will send data in the opposite direction.
   Run inbound and outbound throughput tests simultaneously, and change the default
   Data Size from 100 kBytes to 1000 kBytes to get average readings.)
3. initiate two large ftp sessions to/from the * box (to two different external
   machines) and time the transfers. Compare the throughput values for one ftp
   session, to two sessions (an ftp in both directions simultaneously). If there
   are _significant_ differences in throughput, suspect a duplex mismatch.
4. if you have a managed switch, clear the interface statistics, and run the ftp
   throughput test again. If you see even small "input error counts" on the 
   switch interface, the linux machine is probably running half duplex.

It is also not all that uncommon for a system to report full-duplex when in fact
it is running half-duplex. But, most of those tend to be Windows-based systems.
Qcheck and/or simple ftp throughput tests will identify those in most cases.

FWIW, the above is based on eleven years of professional network performance
assessments at corporations in 40+ states, which includes about every combination
of system and switch-type you can think of.

Rich