bandwidth test - lost packets during receive but not send

hi,
i got 3 MT units on a tower (433 and mini pc) and they are alll connected to a switch via CT5.
when i do a bandwidth test between them using UDP and i use the receive direction, i get about 97 mbps and massive packet loss. When I use the send direction, i get about the same mbps and ZERO packet loss.

Any idea why?

the reason i need this is because i am running VoIP over them and clients are complaining that the call to them is breaking up badly (download from client perspective) allthough the person they are talking to can hear them perfectly (upload from client perspective)

It is normal to get packet loss with UDP bandwidth on Rx tests because of the way the test works. The remote end is getting packet loss on the Tx testing but it is not being reported to you with the tool… I would wager that testing from the remote end will show you the same results.

If your having VoIP issues in your network then these issues can be resolved with QoS. It is amazing how much difference queuing can make especially when you control the network bottleneck. Better QoS implementations are the number one solution for most VoIP issues.

Can you view the jitter on the VoIP connection another solution may be to increase the buffer on the VoIP device. When we setup our VoIP service I spent a couple of weeks testing and implementing QoS across the entire network. The network was much nicer after QoS and call quality is awesome. When there is a call issue it is very easy to find the issue because one of the links is obviously having issues. One thing in particular that was helpful was penalizing the bandwidth test ports. This allows me to flood the links without taking priority over customer traffic. I can freely push the links whenever the link quality is in question.

Good Luck… and let me know if you need anything.

Without knowing your topology - if you use ip phones and classic ip connections on same network infrastructure, you might have to implement vlans.

good luck.