packet generator (computer A) ——> cat 5 ——> Router (GB/s LAN port) ——> 2.4 Ghz network ——> wireshark (computer B)

I’m using Ostinato for mac to generate the packets. I’m giving the packets a source MAC address of computer A and a unicast destination MAC address of the receiving computer (B). The lower layers (IPv4, UDP/TCP, raw data) don’t seem to have any effect on throughput, so as of now for testing purposes my packets only consist of the MAC protocol layer and some arbitrary filler data.

ostinato protocal data

raw packet

router: netgear nighthawk R7000 (stock firmware, pretty much DD-WRT)

Everything works as it should at low bandwidth (1 mbps and below). Sending and receiving behavior is as expected.

Issue: I seem to have a bandwidth ceiling of about 4 mbps. No matter how high I set the packet generator rate, the receiving end mbps graph levels off. Additionally, the router’s GUI crashes (I can’t even telnet in). The LAN port is capable of GB/s, the 2.4 Ghz network 600 mbps, and the receiving wifi card at least 54 mbps. So why when I try and send packets at a bandwidth anywhere close to 6 mbps do I encounter problems?

Additional info: I’ve gone through every router setting. QoS is disabled, there’s no firewall at any point. I’ve tried 4 different routers (buffalo, netgear, linksys, starry) - all AC “gb/s” routers. I’ve also tried different packet generating software to no avail. I feel like there must be some buffer in the router that’s filling up, but it doesn’t seem to be bufferbloat. I did testing transferring files - got 60 mbps easily, so I don't understand what this issue could be. Clearly the router is capable, the wifi cards are capable... all the hardware should be capable. Could there be some firmware issue where data streams like those from packet generators are recognized as a DoS attack and automatically blocked?


Looking at that raw packet screenshot, your packets look to have essentially no payload. I imagine that your PC is sending an enormous amount of tiny packets which is crippling your network devices and capping out at 4mbps.

You should send packets with a real TCP/UDP payload to accurately measure network throughput. I realise you have have specific requirements, but iperf is typically used for performance measuring.

  • I've actually done comprehensive testing with real packet data. I used a DAQ board to send UDP packets and ran into the same issue. I also recreated those packets exactly in the generator and tried sending those, but again ran into the same bottleneck – john smith Jul 6 '16 at 19:34
  • but I'm not sure I understand why a high packet/second rate would be any different from a low packet/s rate providing the data size/second rates are equal. Isn't it the same amount of bandwidth? – john smith Jul 6 '16 at 19:36
  • Routers can only process so many packets per second and with almost no payload, your throughput will be low. I'm not sure what a DAQ board is and why you would use it to send UDP packets, however if you are confident that this issue occurs when sending full sized frames, take a tcpdump/wireshark capture on both ends and upload it somewhere. Perhaps the testing software is poorly implemented. The fact that regular transfers are at full speed makes me think this is a software issue. – Mark Riddell Jul 6 '16 at 19:41
  • my real packet info: UDP, len = 1092 bytes on wire. I'd upload a dump but not sure how helpful that'd be considering the actual data is pretty arbitrary. just have some standard headers on there – john smith Jul 6 '16 at 19:47
  • I definitely do have a high packet per second rate though. is that just a physical limitation of routers? so say i needed to send small packets at 20,000 packets a second... routers just can't handle that? – john smith Jul 6 '16 at 19:48

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.