[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] Slow TCP performance between Windows Vista and XenPV-on-HVM guest

  • To: "Fischer, Anna" <anna.fischer@xxxxxx>, <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Sat, 12 Jun 2010 13:20:34 +1000
  • Cc:
  • Delivery-date: Fri, 11 Jun 2010 20:21:50 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcsJmHd6hL7u+8LkTJqjS+weJ4GGZAAIlZeQAAhX2bAAAGCBMA==
  • Thread-topic: [Xen-users] Slow TCP performance between Windows Vista and XenPV-on-HVM guest

> > Are you capturing packets on the windows machine or on the Dom0?
> Dom0. Note that the Windows machine doesn't even run Xen or anything,
it is
> just some random machine on the network. Only the Linux guest runs on

Yes, I'd figured that.

> > If you are using tcpdump on dom0, make sure you use '-s0' so that
> > capture the entire packup, and possibly '-v' as well. Without
> > the entire packet, tcpdump can't tell you if the checksum is correct
> > not. Even if the checksum is incorrect on Dom0 it doesn't
> > tell you that there is a problem though. A bad checksum on received
> > packets on the windows machine would definitely suggest a problem
> > though.
> I capture with Ethereal. I definitely catch all packet. If this was a
> problem, then communication wouldn't work at all. However, SSH and
> (slower) connections work just fine. The problem is only on bulk data
> using TCP. If the Linux guest was sending a packet with an invalid
> then the Windows guest would *never* send out the ACK. However, it is
> sending out the ACK, but only after the retransmit, to ACK the
> packet. If this was a checksum problem, then the retransmitted packet
> also have an invalid checksum and so it would basically never be
> I have read about Vista's TCP "auto-tuning" feature, and I wonder if
> like this might be the problem here that the Xen guest cannot cope

It might then be a 'large send' problem. That would manifest itself as
low volume traffic being mostly okay, but as the throughput increased,
>MTU sized packets would be sent from DomU via Dom0, with the intent
that the hardware will split them up into <=MTU sized. If those were
dropped somewhere then the retransmit would happen, and the retransmit
would typically not use the 'large' packet, so it would probably work.

tcpdump should show >1500 byte packets in Dom0 on the vif interface
belonging to the DomU, and in the DomU if this is happening.

Use ethtool in DomU to disable as many offload features as possible and
see if things improve.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.