On Thu, Apr 07, 2016 at 10:19:35PM +0200, Peter Kietzmann wrote: > Dear list, > > first of all let me say that I'm new to this list. So if I'm completely > wrong in my concern please excuse the noise and guide me to the right place. > If you can :-)! > > For some experiments I'm trying to send "great" numbers of UDP packets with > "great" payloads as fast as possible from a RasPi equipped with the Openlabs > transceiver. With another RasPi+transceiver I'm sniffing the traffic. It > turns out that just the first x packets are sent out correctly before the > outgoing packets come out irregularly. The number of correctly sent packets > depends on the UDP payload size and it looks like the problem occurs after > ~30-35 kB Bytes (gross) in total have been transmitted (fragmentation > overhead included). I already increased the send socket memory to a > reasonably high value, without success. But still I assume some buffer > problems. Do you have a hint which screw to adjust? > > BTW: Introducing a delay after each packet to send fixes the problem. But > I'd like to do stress-testing... 1. You cannot be sure that a monitor interface shows all traffic which is on the air. You have at least hardware limitations which begins at "rising IRQ" and ends at "framebuffer readed". 2. Try to enable ack request bit. This is default disabled because you need to know what you doing when you enable it. Be sure all nodes supports ACK handling before that. You can do that with: iwpan dev $WPAN_DEV set ackreq_default 1 3. Change tx queue setting: ip link set txqueuelen 1000 dev $WPAN_DEV Please reply if that helped you otherwise we will maybe find another tweaks. :-) - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
