>>> Ok. That makes sense. The output reports "including connections >>> establishing" and "excluding connections establishing" regardless with >>> -C, so we should measure delays in the same way. >> >> On second thought, it's more reasonable and less confusing not to >> measure the disconnection delays at all? Since whether the benchmark >> result >> should include the disconnection delays or not is not undocumented, >> probably we cannot say strongly the current behavior (i.e., the >> disconnection >> delays are not measured) is a bug. Also since the result has not >> included >> the disconnection delays so far, the proposed change might slightly >> change >> the benchmark numbers reported, which might confuse the users. >> ISTM that at least it's unwise to change long-stable branches for >> this... Thought? > > My 0.02€: From a benchmarking perspective, ISTM that it makes sense to > include disconnection times, which are clearly linked to connections, > especially with -C. So I'd rather have the more meaningful figure even > at the price of a small change in an undocumented feature.
+1. The aim of -C is trying to measure connection overhead which naturally includes disconnection overhead. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp