Jean Tourrilhes

Option to dump raw latency

The first test was UDP, so I redid the test with TCP. With TCP, it's looking much better, but there is the occasional glitch. For example, in the experiment I attached, I get a "Connection reset by peer" and you can see that flow with port number 36016 receives far too few bytes. Regards, Jean

Hi, I must apologize. My previous test was incorrect. Now that I'm running the test properly, the bugs are more subtle... The error in my previous test is that I was killing the receiver/server too early. That was my fault, I fixed that. New logs are attached. For the short flows (31KB), the command was : /usr/local/bin/iperf221g -c 10.0.9.5 --time 2.8027674879999998 --num 31000 -y C -e -u -P 1024 -b 878K -l 1468 -p 5000 We can see that man flows don't receive all the bytes that were sent. For example...

iperf truncate --num experiment even when duration is specified

Thanks. Good luck with 2.2.1 ;-) Jean

Put back connection errors on stderr

hmm, I need to look into this a bit more. At a 100ms interval and 292 threads thats an interval report every 342 microseconds. I'm not sure the current implementation will scale to this. With 2.1.9, I can go up to 1024 threads with 100ms interval, and the results looks okay. I must admit, I did not check every single line, but I get the expected number of sum reports. PS. Sorry for the delayed response. I've been out of office for the last week or so. Don't worry, I also have a life, so I understand....

Was this a bounceback? Nope. As I said, a straightforward TCP stream test. Can you post the command line? I don't save my command lines. From rerunning the scripts, I believe the command line was : /usr/local/bin/iperf221f -s -y C -e -M 1464 -p 5000 -i 0.1 -o 10.30.43.43_10.30.37.35_111_cn_3t1x292_bst_9014_lmt_100x_tgt_15-pal_292-1715926388_ci_0_p_0_iperf221f_rcv.icsv /usr/local/bin/iperf221f -c 10.30.37.35 --time 60 -y C -e -Z cubic -P 292 -M 1456 -p 5000 -i 0.1 -o 10.30.43.43_10.30.37.35_111_c...