Re: Clarification on behaviour of Iperf's -w option
Lawrence,
Glad to see we achieved mutual understanding on the technical side.
On Wed, 1 Aug 2007, Lawrence Stewart wrote:
Agreed. This would save quite a bit of confusion. Although dropping the
"window size" term completely is perhaps not quite the right way to
handle it. As you note below, the receive buffer size is related to the
TCP window. Perhaps changing the terminology to refer to "maximum
advertised window" would make it clearer.
Also please note that, due to latency, the sender systematically sees
a smaller TCP window than the one published to him by the receiver at
the same time.
That's really the big problem with the current documentation: it makes
the user believes she can set a complex and very dynamic protocol
value. Untrue. And we are not even speaking of congestion avoidance
here.
But I'm fine with "maximum advertised".
I feel that having a switch behave differently when used in 2 different
contexts is very confusing. You could change the documentation to
explain the current behaviour, but that would involve describing 2
different behaviours depending on running in client or server mode, and
also makes it more difficult to implement an additional switch to
provide the fine grained control over either send or receive buffer sizes
depending on whether you run in client or server mode.
You do make a fair point regarding the entrenched use of the "-w" switch
in its current form. Perhaps the "-w" switch could be left intact and a
pair of new switches added to specifically set the send/receive socket
buffer sizes. Use of these switches and the "-w" switch could be made
mutually exclusive so they don't step on eachother's toes. To me,
leaving the "-w" switch intact still feels a bit hacky... but I can see
why it would be useful.
I'm less affirmative concerning user interface design but I believe in
backward compatibility. I agree that the "too clever" behaviour of the
current -w option is a bit confusing, but it seems to me it still can
be documented correctly. This can even be terse provided it stands
after the new options. Something like this:
-X1
Sets the receive buffer size / maximum TCP window size
[blabla].
-X2
Sets the send buffer size [blabla].
-w
"Magic" buffer size: sizes the receive buffer on the receiver,
and the send buffer on the sender.
This does not solve the case of "-w" for bi-directional tests. IMHO
people performing bi-directional tests have already buried themselves
in deep complexity, so simplify the interface and documentation for
them should not be the priority :-> I would not bother and leave the
magic "-w" option "undefined" for bi-directional tests.
In any case, you are actively working on this (unlike me), so your
word has de-facto more weight than mine.
Cheers,
Marc.
PS: after all this, I'd like to remind that iperf is a really great
tool. Else we would not even bother spending so much time arguing
about making it even better.