RE: Iperf results explanation (-t)
>>On Wed, Aug 20, 2003 at 03:07:49PM +0200, Binken, Rens wrote:
>> Hi,
>>
>> I am using Iperf to test a satellite link (e.g. high latency). I am
running
>> the test for 10 sec (-t 10) with the -r option to do a reverse test.
>> The following are the results.
>>
>> ------------------------------------------------------------
>> Server listening on TCP port 5001
>> TCP window size: 128 KByte (WARNING: requested 128 KByte)
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> Client connecting to SERVER, TCP port 5001
>> TCP window size: 128 KByte (WARNING: requested 128 KByte)
>> ------------------------------------------------------------
>> [ 4] local CLIENT port 1795 connected with SERVER port 5001
>> [ ID] Interval Transfer Bandwidth
>> [ 4] 0.0-38.5 sec 10.4 MBytes 2.26 Mbits/sec
>> [ 4] local CLIENT port 5001 connected with SERVER port 32771
>> [ ID] Interval Transfer Bandwidth
>> [ 4] 0.0-10.8 sec 1.24 MBytes 962 Kbits/sec
>>
>> My question is : Why is the interval upstream 38.5 sec (for a 10 sec
test)
>> and the downstream interval 10.8 sec? Does this mean that for 28.5/0.8
sec
>> Iperf is waiting for ACKs?
> Yes, that is probably what is happening. I've seen a situation where an
> Iperf will never exit because it is waiting for unacknowledged segments.
In
> that particular case there was a duplex mismatch that was causing the
> problems. (I suppose it may have exited eventually, but the tcpdumps I
did
> showed mostly the same segments being retransmitted again and again...)
>> Does this have to do with Iperf waiting for ACKs, if so what is the exact
>> function of -t ? D
> Well for TCP it means run for approximately 10 seconds -- since TCP is a
> reliable protocol you have a little less say in the exact timing since
the
> kernel is handling the protocol transactions. That said, Iperf could and
> probably should implement a timer that goes off at t + .5t or something
> which will force the connection to close and exit.
> With UDP -t has a more straighforward meaning, Iperf will run for 10
seconds
> and exit. (With some skew due to timers and context switches and such.)
Jon,
many thanks for your reply. I have another question that you could perhaps
assist me with.
when performing the above mentioned test, I noticed that the MTU was set to
1400 and the interface was set to "unknown". Path MTU is on. I checked the
settings on the client and server and MTU was set to 1500 on both machines.
I then send out packets using HPING2 and ping with maximum segment sizes
(1460 for tcp, 1472 for ICMP) with "Don't fragment" bit set, and they did
get through. So there are no hops between client and server that change MTU,
i think. I sniffed the traffic and iperf is actually sending data with MTU
1400 (MSS 1360).
I also set the -B option to bind iperf to a particular interface, hoping it
would report eth0 and perhaps fix the MTU problem. (still got interface
"unknown" message). I read on the website that the interface "unknown" could
be OS related. I am running RedHat 9 on both machines.
1) Do you have any ideas on why iperf is reporting 1400 MTU setting, could
iperf be setting this?
2) Do you have any pointers/ideas on the getting the correct interface
reported in iperf?
Regards,
Laurens Binken.
**********************************************************************
De informatie verzonden met dit e-mailbericht (en bijlagen)
is uitsluitend bestemd voor de geadresseerde(n) en zij die
van de geadresseerde(n) toestemming kregen dit bericht te
lezen. Gebruik door anderen dan geadresseerde(n) is
verboden. De informatie in dit e-mailbericht (en bijlagen)
kan vertrouwelijk van aard zijn en kan binnen het bereik
vallen van een geheimhoudingsplicht en een verschonings-
recht.
Any information transmitted by means of this e-mail (and any
of its attachments) is intended exclusively for the addressee
or addressees and for those authorized by the addressee
or addressees to read this message. Any use by a party
other than the addressee or addressees is prohibited.
The information contained in this e-mail (or any of its
attachments) may be confidential in nature and fall under a
duty of non-disclosure and the attorney-client privilege.
**********************************************************************