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