Prior to checking these items, please ensure that the RF link is indeed good. RSSI should be within 3 dB of the projected value and MSE typically should be in the -30s. For most links engineered to run at qam256 or higher, the MSE should be -35 or better.
If necessary, please consult:
Possible causes of packet loss and steps to resolve the issue:
- Verify the duplex and speed settings in the Ethernet port are correct (100 or 1 Gbit) and match the connected equipment, and that no CRC errors on the port are occurring. CLI command: status port and sysinfo 4.
- Verify that the Ethernet ports are connected properly. The Apex and Giga family of radios are port mapped, meaning that the traffic going into Ethernet Port 1 on the local side will only appear at port 1 of the remote side, local side port 2 traffic will appear on the remote side port 2, etc.
- Check the Ethernet cables for correct wiring. If 1000BaseT is being implemented, Cat6 cable should be used. Ensure that the cable is shielded and proper grounding is applied to the RJ45 connector. It is strongly suggested to test the cable with a cable tester that can check for open connections and shorts.
- If possible, clear the counters <status clear> and send a fixed number of packets across the link (i.e. 1,000,000) and check status port on both sides to see where the packet loss is occurring. If it is not possible to isolate the traffic, check the counters over a regular time period and determine if they are changing roughly as expected or if it becomes obvious where the traffic is dropping.
- Set the egress_margin to the default of 10% or a more restrictive number, like 5% and continue testing.
- Check for dropped packets or uncorrected blocks in siglevel. Note that it is normal for a number to show after the link is established and the counters must be cleared <status clear> prior to comparing this number.
- If testing with iPerf, please see FAQ regarding testing with iPerf and other software based throughput testers.
- Try setting the port speed to 100 Mbps and test if packet loss continues. If no packet loss at 100 Mbps, it is likely that the observed packet loss is the result of bursty traffic being dropped. Please see Packet Pushers Podcast regarding Buffbloat and bufferbloat.net for information regarding why it is better to drop a packet than to buffer it and suffer increased latency which negatively impacts jitter and live applications.
Comments
0 comments
Article is closed for comments.