|
Yes. I performed additional test and the issue really exists.
I performed 2 tests of two-way traffic by iperf with a buffer size of 10M (iperf -w 5M) ,one with a rtt of 100ms and the other with a rtt of 500ms, both exhibit "out of phase" isse, and it is more obvious in the 100ms case.
My command is:
on server side:
iperf -s -p 1111 -w 5M -i 1
on client side:
iperf -c **** -p 1111 -w 5M -t 500 -i 1
2006/4/29, Xiaoliang (David) Wei <davidwei@xxxxxxx>:
Pacing can only eliminate the ACK compression effect.
Out of phase synchronization is inheriant with window control algorithm. We did some analysis before. If there is a single flow in each direction, and if the flows are using window control, we can guarantee to have this problem.
But if you have multiple flows in both directions, this problem might be alleviated.
If you have more new results, we are happy to know:)
-David
--------------------------------------------------------- Xiaoliang (David) Wei http://davidwei.org Graduate Student, Netlab, Caltech
======================================
----- Original Message -----
Sent: Friday, April 28, 2006 7:56 PM
Subject: Re: [Discussion] Why dual traffic in 100Mbps envrionment is much less than 100M?
I have just glimpsed the paper right now.
In the paper it said there are two additional features for two-way traffic that may increase link idle time thus reduce performance - ACK compression and out of phase.
Do you know any ways to solve this issue? And may be the pacing mentioned in this paper suitable for this?
Many thanks.
2006/4/29, Xiaoliang (David) Wei <weixl@xxxxxxxxxxx>:
We experienced similar problem: when the numbers of flows in the two
directions are small.
Our understanding is that this is the dynamic of TCP window control. You
can read the paper of Lixia Zhang et al if you want to see the details:
Lixia Zhang, Scott Shenker, David D. Clark: Observations on the Dynamics
of a Congestion Control Algorithm: The Effects of Two-Way Traffic. SIGCOMM
1991: 133-147
(Your case is the out of phase synchronization in that paper).
-David
---------------------------------------------------------
Xiaoliang (David) Wei
http://davidwei.org Graduate Student, Netlab, Caltech
======================================
On Fri, 28 Apr 2006, fu zhijun wrote:
> Hi all,
> Is there anyone who has performed dual-direction tcp performance test (with
> two connections, one connection each direction) in 100M environment ?
> I am working on some modifications with Linux kernel to implement a TCP
> performance enhancement proxy for long fat pipes, currently the goal is for
> 100Mbps environment. Recently, I met a problem which took me a lot of time
> but still haven't been solved.
> In my test, I connect two Linux PC with a Linux bridge running netem(a wan
> emulator,able to set wan parameters such as delay,loss rate ), and running
> iperf to do performance test.
> When I set a delay of several hundred miliseconds, and run iperf to
> generate one direction traffic(set a large buffer with -w, of
> course),performance reachs to over 90Mbps in a few seconds. But when I run
> iperf for dual direction traffic (that means, two connections with the
> opposite direction),the connection can not reach peak performance, sometimes
> one achieve about 90M with the other one almost zero, and sometimes one is
> about 60M and the other is about 30M.
> To make test complete, I also tested cases with no delay, when I set a large
> buffer for iperf, I saw the samiliar issue; but with a small buffer, both
> connections can achieve about 90M.
>
> I also examined /proc/net/snmp, and there is almost no packet loss, and in
> the case with delay, the cwnd has grown to a value large enougth for 100Mbps
> thoughput.
>
> A glue I found is in the case of no delay, when I set a big buffer for
> iperf, the NIC driver called "netif_stop_queue" many times, while with a
> small buffer for iperf, there is seldom. I added some debug info in NIC
> driver to find this.
> Is this related to the problem I met? And how I can locate and solve this
> performance problem?
>
> Thanks a lot in advance.
>
_______________________________________________
Discussion mailing list
Discussion@xxxxxxxxxx
http://internal.web100.org/mailman/listinfo/discussion
|