Jean Tourrilhes

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...

Hi, I see more problems with the sum reports. This time, it was with a straightforward TCP stream test. I'm sorry I could not simplify/reduce the test case, and sorry it's CSV output, but I attached a file that show the issue. Regards, Jean

I found a bug. Patch attached. Regards, Jean

Hi, Two more patches for your enjoyment... 1) Support CSV for isochronous, both UDP and TCP 2) Reorganise CSV report assignement to be more logical. Regards, Jean

Am I missing something? I must admit, I must be the one missing something. A bit a web searching indicates that it might be a printf formater issue : https://stackoverflow.com/questions/50547661/gettimeofday-microsecond-not-limited-to-below-second Anyway, I saw that happening in some big experiment with the latest iperf. It's obviously hard to reproduce, and I don't know what is causing it. I did not test my fix, and now I see that it may not be fixing the issue. Hmm.... Jean