[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
Xen.

Yes, I'd figured that.

> 
> 
> > If you are using tcpdump on dom0, make sure you use '-s0' so that
you
> > capture the entire packup, and possibly '-v' as well. Without
capturing
> > the entire packet, tcpdump can't tell you if the checksum is correct
or
> > not. Even if the checksum is incorrect on Dom0 it doesn't
necessarily
> > 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
checksum
> problem, then communication wouldn't work at all. However, SSH and
other
> (slower) connections work just fine. The problem is only on bulk data
transfer
> using TCP. If the Linux guest was sending a packet with an invalid
checksum,
> then the Windows guest would *never* send out the ACK. However, it is
actually
> sending out the ACK, but only after the retransmit, to ACK the
*retransmitted*
> packet. If this was a checksum problem, then the retransmitted packet
would
> also have an invalid checksum and so it would basically never be
ACKed.
> 
> I have read about Vista's TCP "auto-tuning" feature, and I wonder if
something
> like this might be the problem here that the Xen guest cannot cope
with?
> 

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.

James


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

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