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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
