WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen cluster n/w performance (again!)

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen cluster n/w performance (again!)
From: David Becker <becker@xxxxxxxxxxx>
Date: Fri, 3 Dec 2004 16:23:57 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 04 Dec 2004 08:45:41 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <20041130234221.GJ6264@xxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <20041130210943.GV1102@xxxxxxxxxxx> <E1CZFlg-0007Y4-00@xxxxxxxxxxxxxxxxx> <20041130234221.GJ6264@xxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
I looked closely at tcpdumps of an iperf stream flowing into domain-0 from a
stock linux box.

It looks like my xen0 is not able to send out ACK packets while receiving
incoming data packets. 
That is based on the first attached postscript graph.  It was generated 
by tcptrace/xplot from a tcpdump taken on xen0 while iperf data for xen0
is arriving.
  The green line plots the time of the highest seen ACK seq number.
  The yellow line plots the seq number of the window limit over time.
  The black segments show time of incoming data (diamonds show TCP PUSH flag)

The second postscript graph traces an iperf stream as seen from the sender side.
The sender runs stock linux 2.4.25.  The receiver runs 2.4.27-xen0.

It shows that the sender fills the window as soon as green acks arrive, then
waits quite a while for the next batch of acks to resume transmitting to
xen0.  Increasing the window size makes no difference as the sender keeps the
window full (graphwise that means the yellow and green lines are farther
apart, but the black segments reach the yellow line as soon as the acks
arrive).

Looking at iperf flows between stock linux boxes shows the sender never
fills the window (the black segments rarely reach the yellow line).

I'm guessing this means the handling of Rx interrupts completely blocks out
progress on the Tx side.  I tried throwing in a noapic kernel param but
it made no difference.



Attachment: xendst.ps
Description: PostScript document

Attachment: xensrc.ps
Description: PostScript document

<Prev in Thread] Current Thread [Next in Thread>