As of now, the code is just a proof of concept for achieving higher throughput than what currently available tools (e.g., nping/hping3) are capable of. Other than that, nping is just too slow, and hping3 has not been updated in 12 years; in any case, both of them lack proper support for "newer" TCP/IP features (e.g., DSCP/ECN instead of IP ToS, or TCP Options in general).
I am currently in the process of re-writing this proof of concept to actually become a full-fledged alternative to those tools. At first, I was planning to fork hping3 as to maintain it, but its code just had too many questionable design choices; there were global variables and unnecessary function calls all over the place.
Those underpowered processors were only used as an optimization benchmark; if it runs good enough there, you could always throw more computational power and cores at it.
EDIT: Also, the numbers were in MiB/s (mebibytes per second), not Megabits per second; 10.5 MiB/s would be ~88 Mbp/s (megabits per second).
Again, I am under the impression that SYN flood is an essentially solved problem in the linux kernel and is defeated by the use of SYN cookies, which leaves the main DoS mechanism to be BW exhaustion... I'm pretty sure there are more effective ways to achieve this...
As for the question wtf is this useful for - debugging issues in your network. E.g. I recently used ping -f to track down an ethernet cable causing around 0.5% of package loss...
I am currently in the process of re-writing this proof of concept to actually become a full-fledged alternative to those tools. At first, I was planning to fork hping3 as to maintain it, but its code just had too many questionable design choices; there were global variables and unnecessary function calls all over the place.