I'm doing some throughput testing on some radio units that have narrow channel bandwidth settings (for example sub 250KHz bandwidth). During my testing of iperf3, I noticed that the slowest speed it would ever transfer at despite setting a bandwidth limit on the command-line for iperf3 was 655 KB/sec (even if the command-line argument was set like so):

iperf3 -c -u -i 1 -n 10485760 -b 250K

the resulting server report will report transfer speeds of 655KB/sec instead of 250KB

this behavior occurs when i use both trickle and trickled as well.

trickled seems to work just fine limiting the download speed of wget on the same machine. trickled also limits the upload speed of scp on the same machine as well. is there something that I have to do to get trickle to properly work with iperf3? Also does anybody have an explanation of why iperf3 can't seem to go below 655KB/sec even when its own command-line switch indicates otherwise? I'm fairly certain I'm using the command-line switch properly for iper3 (and trickle). As long as my iperf3 limit is above 655KB/sec, the limitation is applied properly. The problem is I can't get iperf3 to go lower, so I turned to trickle, but trickle/trickled don't seem to work with iperf3.

edit: I also tried this with trickled running on both server machine and client machine both set to -d 250 and -u 250. It still made no difference.

1 Answer 1


I found another comment on superuser. Apparently:

"trickle works by intercepting calls to link in standard library functions for TCP transfers - if an app has these functions statically linked in at compile time then this can not work."

I'm guessing iperf3 is one such program trickle will not work with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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