Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> perhaps it [..] sends a new UDP packet when the other side acknowledges the previous UDP packet. In that case the speed of iperf3 over UDP will always be inferior to that of TCP

It does not, otherwise it would be impossible by a factor ~100x to measure 4.5 Gbit/s as per the bandwidth-delay calculation (the ping is around the usual 0.2 ms).

With iperf3, as with many other UDP measurement tools, you set a sending rate and the other side reports how many bytes arrived.





You are right.

It is a long time since I have last used iperf3, but now that you have mentioned it I have also remembered this.

So the previous poster has misinterpreted the iperf3 results, by believing that UDP was slower, as iperf3 cannot demonstrate a speed difference between TCP and UDP, since for the former the speed is determined by the network, while for the latter the speed is determined by the "--bandwidth" iperf3 command-line option, so the poster has probably just seen some default UDP speed.


But I am "the previous poster".

And I am quite sure that UDP is slower, becuase I increase `--bandwitdh` until throughput stops increasing, which is at 20% of TCP's speed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: